Bug 11307 - Random printf values under different optimization levels.
Summary: Random printf values under different optimization levels.
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-24 14:46 UTC by Patrick Audley
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i386-linux
Target: i386-linux
Build: i386-linux
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Distilled test case. (100 bytes, application/octet-stream)
2003-06-24 14:48 UTC, Patrick Audley
Details
Distilled test case .s file (399 bytes, application/octet-stream)
2003-06-24 14:49 UTC, Patrick Audley
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Audley 2003-06-24 14:46:44 UTC
The following code:

------------8<----------------
main() {
  int n = 10;
  double s = 5;
  printf( "int n = %i\n", n );
  printf( "double s = %f\n", s );
  printf( "n, s: %f, %f\n", n, s );
  printf( "s, n: %f, %f\n", s, n );
}
---------->8------------------

Generates different output under -O0 and -O1 or higher.

O0:
ant:/tmp$ gcc -O0 yak.c; ./a.out
int n = 10
double s = 5.000000
       n, s:   0.000000, 223404472442755743744.000000
       s, n:   5.000000, 223404437215434309632.000000

O1:
ant:/tmp$ gcc -O1 yak.c; ./a.out
int n = 10
double s = 5.000000
       n, s:   0.000000, 0.000000
       s, n:   5.000000, 223404437215434309632.000000

This case was distill from a larger file which is avaible if you'd like it.

Output of gcc -v
ant:/tmp$ gcc -v -save-temps yak.c
Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.3 (Debian)
 /usr/lib/gcc-lib/i386-linux/3.3/cc1 -E -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 yak.c yak.i
ignoring nonexistent directory "/usr/i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /homes/paudley/system/stow/include
 /usr/local/include
 /usr/lib/gcc-lib/i386-linux/3.3/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i386-linux/3.3/cc1 -fpreprocessed yak.i -quiet -dumpbase yak.c
-auxbase yak -version -o yak.s
GNU C version 3.3 (Debian) (i386-linux)
        compiled by GNU C version 3.3 (Debian).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128862
 as -V -Qy -o yak.o yak.s
GNU assembler version 2.14.90.0.4 (i386-linux) using BFD version 2.14.90.0.4
20030523 Debian GNU/Linux
 /usr/lib/gcc-lib/i386-linux/3.3/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc-lib/i386-linux/3.3/../../../crt1.o
/usr/lib/gcc-lib/i386-linux/3.3/../../../crti.o
/usr/lib/gcc-lib/i386-linux/3.3/crtbegin.o -L/homes/paudley/system/stow/lib
-L/usr/lib/gcc-lib/i386-linux/3.3 -L/usr/lib/gcc-lib/i386-linux/3.3/../../..
yak.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i386-linux/3.3/crtend.o
/usr/lib/gcc-lib/i386-linux/3.3/../../../crtn.o
Comment 1 Patrick Audley 2003-06-24 14:48:31 UTC
Created attachment 4276 [details]
Distilled test case.
Comment 2 Patrick Audley 2003-06-24 14:49:03 UTC
Created attachment 4277 [details]
Distilled test case .s file
Comment 3 Andrew Pinski 2003-06-24 15:02:49 UTC
Not a bug, if you are going to using printf and %f to print ints, you have to 
use casts. Also -Wall will warning about this.
Comment 4 Patrick Audley 2003-06-24 16:18:49 UTC
Subject: Re: [bugc/11307] Random printf values under different optimization levels.

    pinskia> uc dot edu 2003-06-24 15:02 ------- Not a bug, if you are
    pinskia> going to using printf and %f to print ints, you have to
    pinskia> use casts. Also -Wall will warning about this.

    Agreed, but the value of "double s" is giving the wrong value as well.

Comment 5 Wolfgang Bangerth 2003-06-24 16:23:47 UTC
Why do people not learn to include the proper function declarations?
Including stdio.h and running gcc with -W -Wall would have said

tmp/gg> gcc -c x.c -W -Wall
x.c:2: warning: return type defaults to `int'
x.c: In function `main':
x.c:7: warning: double format, different type arg (arg 2)
x.c:8: warning: double format, different type arg (arg 3)
x.c:9: warning: control reaches end of non-void function


Which is not surprising given this call
  printf( "n, s: %f, %f\n", n, s );
with n being an integer. Everything that comes after that is at an
unexpected position on the stack and will be wrong, of course.

W.
Comment 6 Joseph S. Myers 2003-06-24 20:06:51 UTC
Subject: Re:  Random printf values under different optimization
 levels.

On Tue, 24 Jun 2003, bangerth at dealii dot org wrote:

> Why do people not learn to include the proper function declarations?

Why do people not read our bug reporting documentation?  It clearly says
first to test with -Wall to see if that shows up problems in the code -
what can we do to improve the documentation so that it gets followed?

Comment 7 Patrick Audley 2003-06-24 22:41:29 UTC
Subject: Re: [bugc/11307] Random printf values under different optimization levels.


    >> Why do people not learn to include the proper function
    >> declarations?

    Did I not say in my bug that this was a distilled test case?

    jsm> Why do people not read our bug reporting documentation?  It
    jsm> clearly says first to test with -Wall to see if that shows up
    jsm> problems in the code - what can we do to improve the
    jsm> documentation so that it gets followed?

    I _did_ test it with -Wall and saw the warnings my question was
why the incorrect specification of the first format led to the
incorrect value of the second.  I recieved a tip from a kind person to
look at the implementation of varargs and think I know why now.  I can
honestly understand the frustration that most people have when they
talk of reporting bugs.  The process of reporting bugs is made no
easier by snide comments like the first one.  We are not all compiler
gods you know...