gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64

[Rafal Jaworowski]

On 2011-12-07, at 21:28, Arnaud Lacombe wrote:

> Hi,
> 
> On Sat, Nov 19, 2011 at 5:01 AM, Gleb Kurtsou <gleb.kurtsou at gmail.com> wrote:
>> Hi,
>> 
>> I was lucky to write a bit of code which gcc 4.2 fails to compile
>> correctly with -O2. Too keep long story short the code fails for gcc
>> from base system and last gcc 4.2 snapshot from ports. It works with gcc
>> 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and
>> -Os optimization levels are fine (I've tried with all -f* flags
>> mentioned in documentation)
>> 
>> -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I
>> presume i386 should be fine. These options are also used for
>> compilation of kernel (with debugging enabled) and modules.
>> 
>> I'm not able to share the code, but have a test case reproducing the
>> bug. I've encountered the issue over a week ago and tried narrowing it down
>> to a simple test I could share but without much success.
>> 
>> The code itself is very common: initialize two structs on stack, call a
>> function with pointers to those stucts as arguments. A number of inlined
>> assertion functions. gcc fails to correctly optimize struct assignments
>> with -fno-omit-frame-pointer, I have a number of small structs assigned,
>> gcc decides not to use data coping but to assign fields directly. I've
>> tried disabling sra, tweaking sra parameters -- no luck in forcing it
>> to copy data. Replacing one particular assignment with memcpy produces
>> correct code, but that's not a solution.
>> 
>> -O2 -fno-omit-frame-pointer -fno-inline is buggy
>> -O2 -fno-omit-frame-pointer -frename-registers is buggy
>> 
>> I found similar issue with gcc 4.6, but I'm not able to reproduce it
>> with gcc test case:
>> https://bugzilla.redhat.com/show_bug.cgi?id=679924
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
>> 
> this PR seems highly irrelevant, the cause has been identified to a
> commit made in mid-2010, that's 3 years older than gcc in base.
> 
>> I'll be glad to help debugging it and will be hanging on #bsddev during
>> weekend as glk.
>> 
> at least, can you share the testcase and miscompilation details ?

I believe we suffer from a very similar issue on PowerPC as well, we'll provide detailed information shortly.

Rafal