Bug 520916
| Summary: | gcc improperly rearranges instructions that could fail | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Tom Lane <tgl> | ||||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Petr Muller <pmuller> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 6.0 | CC: | fche, hhorak, jks, ohudlick | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | s390x | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-09-09 13:21:07 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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. |
Description of problem: At optimization level -O2 (or above?), gcc improperly rearranges code like the following: int x, y, z; if (y == 0) elog(ERROR, "division by zero"); z = x / y; where elog is a function that won't return (because it throws a longjmp). What I am seeing is that a SIGFPE occurs anyway, indicating that the division has been moved to before the function call. This is most certainly a violation of the C standard's requirements about sequence points. I have heard occasional reports of this behavior in various gcc versions on various platforms for awhile, but it is now reproducible in Red Hat's version for RHEL6 on s390x. Version-Release number of selected component (if applicable): gcc-4.4.1-3.s390x How reproducible: 100% Steps to Reproduce: 1. try to build any recent postgresql SRPM using gcc (prior to 8.4.0-3.2.fc12, as it reduces the optimization level to -O1 to avoid this bug). Actual results: several regression tests fail with "ERROR: floating-point exception" reported instead of the expected output "ERROR: division by zero" Expected results: successful build Additional info: If you wish I'll put together a more self-contained test case, but I thought first I'd check that you agree this behavior is an optimization bug and not something programmers should be expected to work around.