Bug 37936 - Conditional operator optimization error with const int&
Summary: Conditional operator optimization error with const int&
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-28 13:25 UTC by Jeff Harris
Modified: 2008-10-29 14:47 UTC (History)
2 users (show)

See Also:
Host: x86_64-redhat-linux
Target: x86_64-redhat-linux
Build:
Known to work: 4.3.0 4.3.2 4.4.0
Known to fail: 4.2.4 4.1.2
Last reconfirmed:


Attachments
Source code for bug (4.32 KB, text/plain)
2008-10-28 13:27 UTC, Jeff Harris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Harris 2008-10-28 13:25:31 UTC
I have found an error in the optimizer that is causing it to over-optimze a conditional operator, ?:.  The optimizer will always choose the first option regardless of the value of the condition.  In the code, the call to setHelpInt1 is always passed the value for UP even though DOWN is the correct option at runtime.  Subsequent uses of the same condition produce the correct output.  Swapping UP and DOWN in getState() causes DOWN to be forced.

The incorrect output generated is:
setInt 1 to 1
setInt 2 to 2
val: 2

The correct output is:
setInt 1 to 2
setInt 2 to 2
val: 2


A slight change in the code will cause the error to not occur.  Any of the following changes will cause the optimizer to work correctly:
- Make getState() not inlined
- Change the getState() function to write out the conditional operator as an if/else statement
- Remove the if(gok) test in main()
- Change if(gok) to if(gflags) in main()
- Compile with -O instead of -O2
- Change the signature of setHelpInt2 to take a const int instead of a const int&.  This is the strangest 'fix' as it occurs after the call to setHelpInt1.

The error is present on a RHEL 5.1 64-bit system with GCC 4.1.2 with the specified configuration:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE badref2.cpp -mtune=generic -Wall -O2 -fpch-preprocess -o badref2.ii
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
 /usr/include
End of search list.
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -fpreprocessed badref2.ii -quiet -dumpbase badref2.cpp -mtune=generic -auxbase badref2 -O2 -Wall -version -o badref2.s
GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-14) (x86_64-redhat-linux)
        compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6f6d1884a37abf7abe8da2d985ac9045
 as -V -Qy -o badref2.o badref2.s
GNU assembler version 2.17.50.0.6-5.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-5.el5 20061020
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 badref2.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o

It has also been reproduced on a PPC cross-compiler with GCC 4.2.1.  Both systems exhibit the same behavior regarding the changes that fix the problem.
Using built-in specs.
Target: powerpc-ai-linux
Configured with: /tmphome/jeffh/dev/toolkit-rh5/modules/gcc/configure --prefix=/usr/local/ai/ppc826x-lx2.4-1.70 --srcdir=/tmphome/jeffh/dev/toolkit-rh5/modules/gcc --enable-languages=c,c++ --target=powerpc-ai-linux --with-libs=/usr/local/ai/ppc826x-lx2.4-1.70/target/lib --with-headers=/usr/local/ai/ppc826x-lx2.4-1.70/target/usr/include --enable-shared --disable-nls --with-cpu=603e --enable-threads --enable-__cxa_atexit --with-gnu-ld --with-gnu-as
Thread model: posix
gcc version 4.2.1
 /usr/local/ai/ppc826x-lx2.4-1.70/libexec/gcc/powerpc-ai-linux/4.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix badref2.cpp -mcpu=603e -O2 -fpch-preprocess -o badref2.ii
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1/powerpc-ai-linux
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include/c++/4.2.1/backward
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/include
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/sys-include
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/include
End of search list.
 /usr/local/ai/ppc826x-lx2.4-1.70/libexec/gcc/powerpc-ai-linux/4.2.1/cc1plus -fpreprocessed badref2.ii -quiet -dumpbase badref2.cpp -mcpu=603e -auxbase badref2 -O2 -version -o badref2.s
GNU C++ version 4.2.1 (powerpc-ai-linux)
        compiled by GNU C version 4.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e4edbb3391ee1d6def0b3ae5cb8fda9a
 /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/bin/as -mppc -many -V -Qy -o badref2.o badref2.s
GNU assembler version 2.17.50.0.17 (powerpc-ai-linux) using BFD version (Linux/GNU Binutils) 2.17.50.0.17.20070615
 /usr/local/ai/ppc826x-lx2.4-1.70/libexec/gcc/powerpc-ai-linux/4.2.1/collect2 --eh-frame-hdr -V -Qy -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o /tmphome/jeffh/dev/remote/staging/a.out /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/lib/crt1.o /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/lib/crti.o /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/crtbegin.o -L/usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1 -L/usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/lib badref2.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/crtsavres.o /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/crtend.o /usr/local/ai/ppc826x-lx2.4-1.70/lib/gcc/powerpc-ai-linux/4.2.1/../../../../powerpc-ai-linux/lib/crtn.o
GNU ld (Linux/GNU Binutils) 2.17.50.0.17.20070615
  Supported emulations:
   elf32ppclinux
   elf32ppc
   elf32ppcsim
Comment 1 Jeff Harris 2008-10-28 13:27:03 UTC
Created attachment 16572 [details]
Source code for bug
Comment 2 Jeff Harris 2008-10-28 13:27:51 UTC
Compiled as: g++ -Wall -O2 -v -save-temps badref2.cpp
Comment 3 Paolo Carlini 2008-10-28 13:34:38 UTC
Cannot be reproduced in mainline and 4_3-branch.
Comment 4 Manuel López-Ibáñez 2008-10-28 15:24:19 UTC
I can reproduce in vanilla 4.2.4 and 4.1.2 but cannot reproduce in 4.3.2 and trunk. Not sure if this is a regression from 4.0 or earlier but in any case it is fixed in 4.3.2 and mainline and there no more planned releases of the 4.2 branch.