[Bug c/16920] New: possible generation of broken asm code? (C, C++, gcc 3.4.1)

[Bug c/16920] New: possible generation of broken asm code? (C, C++, gcc 3.4.1)

[eleven at ludojad dot itpp dot pl]

attached example program produces wrong results when compiled as 64 bit binary.
it works ok when compiled with -Os optimization OR into 32 bit binary (forced
with -m32 switch). 

it grabs two timestamps (format: YYYYMMDDHH:MM:SS), converts them with strptime
into tm struct and displays unix epoch time generated with mktime() - when
compiled as 64 bit binary, one timestamp has wrong value (the difference between
original timestamps is 180s, whereas it shows it's 3420 seconds after using
mktime()). it shows proper 180 seconds difference when compiled with -m32 or -Os.

my gcc -v:
Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/specs
Configured with: /usr/local/portage/portage/gcc-3.4.1/work/gcc-3.4.1/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4/info --enable-shared
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++,objc --enable-threads=posix --enable-long-long
--disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/include/g++-v3
--with-local-prefix=/usr/local --disable-werror --enable-shared --enable-nls
--without-included-gettext --enable-multilib --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 3.4.1  (Gentoo Linux 3.4.1, ssp-3.4-2, pie-8.7.6.3)

-- 
           Summary: possible generation of broken asm code? (C, C++, gcc
                    3.4.1)
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: eleven at ludojad dot itpp dot pl
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/16920] possible generation of broken asm code? (C, C++, gcc 3.4.1)

[eleven at ludojad dot itpp dot pl]

------- Additional Comments From eleven at ludojad dot itpp dot pl  2004-08-08 16:22 -------
Created an attachment (id=6906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6906&action=view)
wrong timestamps test case


-- 


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

[Bug target/16920] possible generation of broken asm code? (C, C++, gcc 3.4.1)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-08 18:16 -------
So this fails at -O0 right?
Also does this fail with an unmodified compiler as the compiler you are using has been modified by 
Gentoo.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |ABI, wrong-code


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

[Bug c/16920] possible generation of broken asm code? (C, C++, gcc 3.4.1)

[eleven at ludojad dot itpp dot pl]

------- Additional Comments From eleven at ludojad dot itpp dot pl  2004-08-08 18:18 -------
yes, it behaves ugly with -O0 (only with -Wall in fact). I'll try to test how
does it work with vanilla gcc 3.4.1 soon.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |c


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

[Bug c/16920] possible generation of broken asm code? (C, C++, gcc 3.4.1)

[eleven at ludojad dot itpp dot pl]

------- Additional Comments From eleven at ludojad dot itpp dot pl  2004-08-08 19:42 -------
the bug is absent with plain gcc from gnu.org. moreover, the original bug seems
to be gone after glibc upgrade, so I guess this successfully classifies this bug
as missed...

-- 


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

[Bug c/16920] possible generation of broken asm code? (C, C++, gcc 3.4.1)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-08 19:43 -------
So closing as worksforme.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


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

[Bug c/16920] possible generation of broken asm code? (C, C++, gcc 3.4.1)

[eleven at ludojad dot itpp dot pl]

------- Additional Comments From eleven at ludojad dot itpp dot pl  2004-08-08 20:47 -------
unfortunately - the "bug" is still there until I have setlocale(LC_TIME, "C")
before calling sesstime(). in fact it generates wrong results whatever LC_TIME
value I use (and 64 bit code is generated). setlocale() has no effect when
compiled with -m32 (it works ok then). this makes me wonder if it may be rather
some glibc issue rather than gcc problem. I'd appreciate any hints on that.

-- 


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