This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/46619] New: gcc thinks like of code can be removed.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46619

           Summary: gcc thinks like of code can be removed.
           Product: gcc
           Version: 4.4.5
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: eskil@obsession.se


Created attachment 22495
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22495
file with the missiing line.

While porting over encryption code for the network protocol Verse using XCode,
I found that the pure c code failed on the Mac but worked on my VisualStudio
compiled version. This was a bit weird since the code was originally developed
using gcc on Linux. After digging around I eventually found by looking at the
assembly code that the compiler on the Mac removed the line:

high = (uv & 0x80000000) != 0;

I think its a casting issue since i think the following works even though it
shouldn't make a differance:

high = (uv & (signed int)0x80000000) != 0;

Even though XCode is based in Gcc I assumed Apple had done something bad with
it until I got a mail from someone who reported the same problem using gcc on
Linux! My feeling is that its a issue that has crept in with later versions of
gcc.

He even managed to test it with a few compiler settings that showed:

gcc -O0 -> works
gcc -O1 -> works
gcc -O2 -> fails
gcc -O3 -> fails
gcc -Os -> fails

clang -O0 -> works
clang -O1 -> works
clang -O2 -> works
clang -O3 -> works
clang -Os -> works

Yes, I'm fairly sure we have been able to create code that repeatably breaks
gcc!

I'm attaching the file with the critical line and two header files needed to
compile it. I can get you the entire project too, but since you see the missing
line with this code it should be enough. Please feel free to contact me over
Email!

The specs of the Linux machine is as follows:

gcc version:

Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --enable-targets=all
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

My machine (/proc/cpuinfo):

processor        : 0
vendor_id        : GenuineIntel
cpu family        : 15
model                : 6
model name        : Intel(R) Celeron(R) D CPU 3.20GHz
stepping        : 5
cpu MHz                : 3192.488
cache size        : 512 KB
fdiv_bug        : no
hlt_bug                : no
f00f_bug        : no
coma_bug        : no
fpu                : yes
fpu_exception        : yes
cpuid level        : 6
wp                : yes
flags                : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
up pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr pdcm lahf_lm
bogomips        : 6384.97
clflush size        : 64
cache_alignment        : 128
address sizes        : 36 bits physical, 48 bits virtual
power management:

Operating system:

Linux hilfy 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC
2010 i686 GNU/Linux


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]