Please provide a preprocessed testcase and used gcc options that show this.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Created attachment 359604 [details]
gzipped preprocessed source code

The problem case is compiled as

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -march=z9-109 -mtune=z10 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2   -c -o int8.o int8.c

Attached is the -S preprocessor output for this.  Breaking it down to a tiny test case proved a bit harder than I thought; apparently, some part of the issue is the details of the code that I referred to as just an "elog" call.  It's actually several nested function calls.  What I see in the assembly output is that there is a dsgr instruction in the main code path in the expected place, but there is *also* one in the elog code sequence, just before the call to "errcode".  In gdb it looks like this:

Program received signal SIGFPE, Arithmetic exception.
0x0000000080258d6e in int48div (fcinfo=<value optimized out>) at int8.c:922
922                     ereport(ERROR,
(gdb) x/i $pc
0x80258d6e <int48div+106>:      brasl   %r14,0x802daa3c <errcode>
(gdb) x/16i $pc-60
0x80258d32 <int48div+46>:       lmg     %r6,%r15,208(%r15)
0x80258d38 <int48div+52>:       br      %r4
0x80258d3a <int48div+54>:       lghi    %r2,20
0x80258d3e <int48div+58>:       larl    %r3,0x8048d3b0
0x80258d44 <int48div+64>:       lghi    %r4,924
0x80258d48 <int48div+68>:       larl    %r5,0x8048d312 <__func__.13835>
0x80258d4e <int48div+74>:       lghi    %r6,0
0x80258d52 <int48div+78>:       brasl   %r14,0x802d8a00 <errstart>
0x80258d58 <int48div+84>:       tml     %r2,255
0x80258d5c <int48div+88>:       je      0x80258d20 <int48div+28>
0x80258d60 <int48div+92>:       lgfr    %r13,%r13
0x80258d64 <int48div+96>:       lgfi    %r2,33816706
0x80258d6a <int48div+102>:      dsgr    %r12,%r12                                       ************** trouble **************
0x80258d6e <int48div+106>:      brasl   %r14,0x802daa3c <errcode>
0x80258d74 <int48div+112>:      lr      %r11,%r2
0x80258d76 <int48div+114>:      larl    %r2,0x8048a5a6
(gdb) 


Let me know if I can provide anything else.

Oh, forgot to mention: there are several division routines in this file, but the ones that show the problem are the cross-type routines, notably int28div and int48div which are exercised in the Postgres regression tests.

Created attachment 359607 [details]
stripped-down source code

Just enough source code ...

Some experimentation suggests that "gcc -O2" is enough to provoke the misplaced division, the remaining switches are just window dressing.

Oh, I think I see why these particular division routines and not other ones are affected.  Most of the division functions contain a second if-test that checks for possible integer overflow, and all of those seem to work as expected.  The ones where a narrow type is divided by a wider type just have the zero-divide test and the actual division, and all three of them show the failure.  It might be that the bug is still there in the other ones, but if the division is propagated into the overflow error report path then there wouldn't be any obvious external effect ...

OK, one further comment and then I'll shut up.  The Postgres project has been hearing reports of this type of failure for quite a long time; it's been seen on sparc and sparc64 as far back as gcc 4.0.2.  I suspect you may find that alpha and hppa are affected too.  It's been reported upstream at least once:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
but I'm not convinced that the test program given there actually triggered the bug.

The code is quite questionable, will have to discuss it.
In any case, if you do the right thing, which is mark errfinish with __attribute__((noreturn)), if it never returns, then the second dsgr is certainly gone.  FYI it is the scheduler which reorders the division before the call, and only does that in this case for -mtune=z10, so if you changed -O2 into -O1 for all arches, it was definitely a bad idea.

Unfortunately noreturn is not usable because the function does return if the error severity level is less than ERROR.  In any case I find it difficult to see how this is not a bug per the C standard's definition of sequence points:

"At certain specified points in the execution sequence called sequence points, all side  effects  of previous evaluations shall be complete and no side effects of subsequent evaluations shall  have  taken place."

The semicolon is a sequence point.  The function's longjmp is a side effect.  The SIGFPE is a side effect.  Where is your wiggle room?

It is undefined behavior to integral division by zero, SIGFPE isn't something the C standard guarantees that will happen.

Anyway, we agreed that we'll change the scheduler, see PR41239.

Fixed in gcc-4.4.1-10 and above.