[Bug c/39990] New: Failed to compile mplayer

[yast4ik at yahoo dot com]

GCC 4.4.1 (prerelease) 20090425

The output can be seen here:
http://www.spinics.net/lists/fedora-testing/msg78463.html


-- 
   Summary: Failed to compile mplayer
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yast4ik at yahoo dot com


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

[Bug c/39990] Failed to compile mplayer

[yast4ik at yahoo dot com]

--- Comment #1 from yast4ik at yahoo dot com  2009-05-01 08:05 ---
Created an attachment (id=17788)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17788&action=view)
mangle.h config.h imdct.i imdct.c


-- 


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

[Bug c/39990] Failed to compile mplayer

[yast4ik at yahoo dot com]

--- Comment #2 from yast4ik at yahoo dot com  2009-05-01 08:07 ---
Command line is:

gcc -v -save-temps -Wundef -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith
-Wredundant-decls -O4 -march=core2 -msse4.1 -pipe -ffast-math
-fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -I.  -D_REENTRANT -I/usr/include/directfb -I/usr/include/
   -D_REENTRANT   -Ilibdvdread4  -I/usr/include/freetype2 -I/usr/include  
-I/usr/include/dirac imdct.c


-- 


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

[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog

[ramana at gcc dot gnu dot org]

--- Comment #5 from ramana at gcc dot gnu dot org  2009-05-01 08:39 ---
*** Bug 39989 has been marked as a duplicate of this bug. ***


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||carrot at google dot com


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

[Bug target/39989] No need to save LR in some cases

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2009-05-01 08:39 ---
Marking as duplicate of PR38570

*** This bug has been marked as a duplicate of 38570 ***


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2009-05-01 08:44 ---
I still see no answer to my question from comment #1.


-- 


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

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[gbarnt at student dot dtu dot dk]

--- Comment #10 from gbarnt at student dot dtu dot dk  2009-05-01 09:01 
---
In reply to #9:

I have tried to build gcc with and without my own patch on our solaris
machines. While both of them fails they fail at the same place (namely
configuration of [arch]/libgcc trying to figure out the object suffix). They do
however die of different reasons (the patched dies due to xgcc seg. faulting
and the unpatched dies because cc1 is unable to locate libmpfr), but that is a
different matter and probably also another bug-thread.

I checked the "build-[arch]/fixincludes" and I cannot see a different between
the patched and the unpatched prior to line 51. Of course these files are
auto-generated, so ... I did however notice that line 50 is the first line in
the make file to use ":=" rather than "=" (both in patched and unpatched
version).

  target = sparc-sun-solaris2.10
  target_noncanonical:=sparc-sun-solaris2.10

Then I realized that we have a GNU Make installed, which I have been using. If
I use a non-GNU make it also fails with that error in that directory. 

  make: Fatal error in reader: Makefile, line 51: Unexpected end of line seen

Nevertheless it also dies in the unpatched version - same place, same error.
(NB: For this test I did not rebuild, I just ran the other make in that dir.)

Opening the Makefile and replacing the ":=" with "=" seems remove the
"Unexpected end of line seen". The other issue you met does not go away though.
But I get this issue with two out of the 4 different "make"s we have installed.
The two succeeding are different version of the GNU make and the failing onces
are (probably) not GNU make (they do not understand --version and -v is
interpreted as something else ... probably verbose).

Nevertheless, from what I can see your issue is likely to originate from a
syntax issue with the Makefile. Since my patch requires running autoconf, the
issue might be that the version of autoconf you used was designed to work with
a newer version of make than the ones failing. My suggestion is to try using an
older autoconf or a newer make or/and a GNU make.

Sorry for the late reply by the way. Hope it helps.

~Niels


-- 


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

[Bug fortran/39991] New: wrong locus in error message

[dfranke at gcc dot gnu dot org]

$> cat locus.f90
MODULE m
  PUBLIC :: s
CONTAINS
  SUBROUTINE s()
  END SUBROUTINE
  SUBROUTINE s()
  END SUBROUTINE
END MODULE

$> gfortran-svn locus.f90
locus.f90:6.14:

  SUBROUTINE s()
  1
locus.f90:2.13:

  PUBLIC :: s
 2
Error: Procedure 's' at (1) is already defined at (2)


Without "PUBLIC :: s", the correct message is printed:
$> gfortran-svn locus.f90
locus.f90:6.14:

  SUBROUTINE s()
  1
locus.f90:4.14:

  SUBROUTINE s()
  2
Error: Procedure 's' at (1) is already defined at (2)


-- 
   Summary: wrong locus in error message
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2009-05-01 09:39 ---
On i686-apple-darwin9:

[ibook-dhum] bug/java_test% /opt/gcc/gcc4.5w/bin/gcj -v
Using built-in specs.
Reading specs from
/Volumes/MacBook/opt/gcc/gcc4.5w/bin/../lib/gcc/i686-apple-darwin9/4.5.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: i686-apple-darwin9
Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w
--mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/sw
--with-ppl=/sw
Thread model: posix
gcc version 4.5.0 20090426 (experimental) [trunk revision 146795p6] (GCC) 

but also (from the last bootstrap without java)

[ibook-dhum] bug/java_test% /opt/gcc/gcc4.5w/bin/gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w
--mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran --with-gmp=/sw
--with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --with-cloog=/sw --with-ppl=/sw
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 147015p6] (GCC) 

[ibook-dhum] bug/java_test%
/opt/gcc/gcc4.5w/libexec/gcc/i686-apple-darwin9/4.5.0/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols
-quiet -mmacosx-version-min=10.5.6 -m64 -mtune=generic -g -O2 -Wno-deprecated
-ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fjni
-findirect-dispatch -fno-indirect-classes -fno-common
-fbootclasspath=/opt/gcc/_gcc_clean/libjava/classpath/lib/
-fdump-tree-all-details

No error and I get 94 files from

gnuPOA$RefTemplate.class.003t.original
...
gnuPOA$RefTemplate.class.126t.optimized
gnuPOA$RefTemplate.class.127t.nrv
gnuPOA$RefTemplate.class.128t.blocks
gnuPOA$RefTemplate.class.129t.final_cleanup
gnuPOA$RefTemplate.class.206t.statistics
gnuPOA$RefTemplate.class.s

On powerpc-apple-darwin9, bootstrapped without fatal error:

[karma] bug/java_test% /opt/gcc/gcc4.5w/bin/gcj -v
Using built-in specs.
Reading specs from
/opt/gcc/gcc4.5w/lib/gcc/powerpc-apple-darwin9/4.5.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w
--mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info
--build=powerpc-apple-darwin9
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --with-cloog=/sw --with-ppl=/sw
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 146999p3] (GCC) 
[karma] bug/java_test% /opt/gcc/gcc4.5w/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w
--mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info
--build=powerpc-apple-darwin9
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --with-cloog=/sw --with-ppl=/sw
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 146999p3] (GCC) 

[karma] bug/java_test%
/opt/gcc/gcc4.5w/libexec/gcc/powerpc-apple-darwin9/4.5.0/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols
-quiet -mmacosx-version-min=10.5.6 -m64 -g -O2 -Wno-deprecated -ffloat-store
-fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fjni
-findirect-dispatch -fno-indirect-classes -fno-common
-fbootclasspath=/opt/gcc/_gcc_clean/libjava/classpath/lib/
-fdump-tree-all-details
gnu/CORBA/Poa/gnuPOA.java: In class 'gnu.CORBA.Poa.gnuPOA$RefTemplate':
gnu/CORBA/Poa/gnuPOA.java: In constructor '(gnu.CORBA.Poa.gnuPOA)':
In file included from :0:
gnu/CORBA/Poa/gnuPOA.java:0: error: type mismatch in indirect reference
struct java.lang.String[]

void

# VUSE <.MEM_215>
#slot#8#31_227 = #ref#5#2_71->length;

gnu/CORBA/Poa/gnuPOA.java:0: internal compiler error: verify_stmts failed

and I get 92 files

gnuPOA$RefTemplate.class.003t.original
...
gnuPOA$RefTemplate.class.126t.nrv
gnuPOA$RefTemplate.class.128t.optimized
gnuPOA$RefTemplate.class.209t.statistics
gnuPOA$RefTemplate.class.s

where the files

gnuPOA$RefTemplate.class.127t.nr

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[schwab at linux-m68k dot org]

--- Comment #11 from schwab at linux-m68k dot org  2009-05-01 09:51 ---
GNU make is required for building gcc.


-- 


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

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #14 from dominiq at lps dot ens dot fr  2009-05-01 11:13 ---
Note 1: java is broken on ppc-darwin with -m64.

Note 2: the error does not appear at -O1 and -m32 (default).

Note 3: removing the -quiet and some other options, I get:

[karma] bug/java_test%
/opt/gcc/gcc4.5w/libexec/gcc/powerpc-apple-darwin9/4.5.0/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -O2 -fencoding=UTF-8 -fbootstrap-classes
-fjni -findirect-dispatch -fno-indirect-classes -fno-common
-fbootclasspath=/opt/gcc/_gcc_clean/libjava/classpath/lib/ -fdump-tree-all 

class gnu.CORBA.Poa.gnuPOA$RefTemplate class java.lang.ObjectIn file included
from :0:
gnu/CORBA/Poa/gnuPOA.java:0: warning: cannot find file for class
org.omg.PortableInterceptor.ObjectReferenceTemplate
 (gnu.CORBA.Poa.gnuPOA)gnu/CORBA/Poa/gnuPOA.java: In class
'gnu.CORBA.Poa.gnuPOA$RefTemplate':
gnu/CORBA/Poa/gnuPOA.java: In constructor '(gnu.CORBA.Poa.gnuPOA)':

In file included from :2:
gnu/CORBA/Poa/gnuPOA.java:126: warning: cannot find file for class
java.util.ArrayList
gnu/CORBA/Poa/gnuPOA.java:127: warning: cannot find file for class
gnu.CORBA.Poa.gnuPOA
gnu/CORBA/Poa/gnuPOA.java:132: warning: cannot find file for class
org.omg.PortableServer.POA
In file included from :2:
gnu/CORBA/Poa/gnuPOA.java:138: warning: cannot find file for class
java.lang.String
 gnu.CORBA.Poa.gnuPOA$RefTemplate.adapter_name()
gnu.CORBA.Poa.gnuPOA$RefTemplate.orb_id()gnu/CORBA/Poa/gnuPOA.java: In method
'gnu.CORBA.Poa.gnuPOA$RefTemplate.orb_id()':

In file included from :2:
gnu/CORBA/Poa/gnuPOA.java:162: warning: cannot find file for class
gnu.CORBA.Poa.ORB_1_4
 gnu.CORBA.Poa.gnuPOA$RefTemplate.server_id()gnu/CORBA/Poa/gnuPOA.java: In
method 'gnu.CORBA.Poa.gnuPOA$RefTemplate.server_id()':

gnu/CORBA/Poa/gnuPOA.java:170: warning: cannot find file for class
gnu.CORBA.OrbFunctional
 gnu.CORBA.Poa.gnuPOA$RefTemplate.make_object(java.lang.String,byte[])
gnu.CORBA.Poa.gnuPOA$RefTemplate._truncatable_ids()gnu/CORBA/Poa/gnuPOA.java:
At top level:

gnu/CORBA/Poa/gnuPOA.java:186: warning: cannot find file for class
java.lang.Class

Analyzing compilation unit
Performing interprocedural optimizations
 
 Assembling functions:
 gnu.CORBA.Poa.gnuPOA$RefTemplate._truncatable_ids()
gnu.CORBA.Poa.gnuPOA$RefTemplate.server_id()
gnu.CORBA.Poa.gnuPOA$RefTemplate.make_object(java.lang.String,byte[])
gnu.CORBA.Poa.gnuPOA$RefTemplate.orb_id()
gnu.CORBA.Poa.gnuPOA$RefTemplate.adapter_name()
(gnu.CORBA.Poa.gnuPOA)gnu/CORBA/Poa/gnuPOA.java: In constructor
'(gnu.CORBA.Poa.gnuPOA)':

In file included from :0:
gnu/CORBA/Poa/gnuPOA.java:0: error: type mismatch in indirect reference
struct java.lang.String[]

void

# VUSE <.MEM_11>
#slot#8#31_225 = #ref#5#2_129->length;

gnu/CORBA/Poa/gnuPOA.java:0: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug middle-end/39685] ICE: in copyprop_hardreg_forward_1, at regrename.c:1603

[MR dot Swami dot Reddy at nsc dot com]

--- Comment #6 from MR dot Swami dot Reddy at nsc dot com  2009-05-01 11:42 
---
This problem is reproduced with latest gcc-4.4.0 release tools (ie crx-elf-gcc
version 4.4.0).


-- 


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

[Bug inline-asm/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN

[pinskia at gcc dot gnu dot org]

--- Comment #17 from pinskia at gcc dot gnu dot org  2009-05-01 13:15 
---
*** Bug 39990 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||yast4ik at yahoo dot com


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

[Bug c/39990] Failed to compile mplayer

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-05-01 13:15 ---


*** This bug has been marked as a duplicate of 39543 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/39992] New: cc1plus exhausts memory with deeply nested unclosed constructor parens

[cbm at whatexit dot org]

a nested copy constructor with unclosed parentheses, if
nested sufficiently deeply, exhausts memory and kills the
compiler after several minutes of churning.

class C;
C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(
// (40 nested unclosed constructor parentheses)

in the syntactically correct case, the compile finishes
in less than one second.

class C;
C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(;

i've tested on both RedHat FC7 and Solaris 10/Intel, and
the behavior is the same.  below is the FC7 output.

phoenix% /opt/gcc-4.4.0/bin/g++ -v -save-temps -c bug.C
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/gcc-4.4.0
--with-mpfr=/opt/mpfr-2.4.1
Thread model: posix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic'
 /opt/rw/gcc-4.4.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -E
-quiet -v -iprefix
/opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/ -D_GNU_SOURCE
bug.C -mtune=generic -fpch-preprocess -o bug.ii
ignoring nonexistent directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0"
ignoring duplicate directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/x86_64-unknown-linux-gnu"
ignoring duplicate directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward"
ignoring duplicate directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include"
ignoring duplicate directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed"
ignoring nonexistent directory
"/opt/rw/gcc-4.4.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0

/opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/x86_64-unknown-linux-gnu

/opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
 /opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include
 /opt/rw/gcc-4.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed
 /usr/local/include
 /opt/rw/gcc-4.4.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic'
 /opt/rw/gcc-4.4.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus
-fpreprocessed bug.ii -quiet -dumpbase bug.C -mtune=generic -auxbase bug
-version -o bug.s
GNU C++ (GCC) version 4.4.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0, GMP version 4.1.4, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b0ba9d2a53d0754610d55da75a5fe542
[wait 6 minutes]
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See  for instructions.

system type:

phoenix% uname -a
Linux phoenix 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux

source file:

phoenix% cat bug.C
class C;
   
C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(
// (40 nested unclosed constructor parentheses)

expected behavior:

bug.C:2: error: expected unqualified-id at end of input
bug.C:2: error: expected `)' at end of input

actual behavior:

compiler runs for a long time, filling memory, until killed by OS.

it seems to be a recursion problem.  the code "class C; C(" fails
immediately.
every additional nesting of unclosed parentheses doubles the compile
time (and
the memory used) until finally with enough unclosed nestings, memory is
exhausted
and the OS kills the compiler process.

however, it is specific to constructors.  this code fails immediately:
> int f(int);
>
f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(


-- 
   Summary: cc1plus exhausts memory with deeply nested unclosed
constructor parens
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cbm at whatexit dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknow

gcc4.4 problem

[Jean-François Mertens]

Hi,

The following program compiles fine with all compilers I know of
(a.o., Apple's gcc4.0 and gcc4.2, GNU gcc4.3 ...), and fails with gcc4.4
(it comes from a saclib routine, after having used --save-temps
and some grepping to remove all macros and typedefs)  :

_
#include 
extern int *MMAPMON (int m, int *A);
extern void MMAPREM (int m, int *A, int *B);

int *MMAPGCD(p,A,B)
  int p,*A,*B;
{
  int *A1,*A2,*t,*C,m,n;

  if (((A[-1]) == 0 && (A[0]) == 0)) {
  C = MMAPMON(p,B);
  goto Return; }
  if (((B[-1]) == 0 && (B[0]) == 0)) {
  C = MMAPMON(p,A);
  goto Return; }

  m = (A[-1]);
  n = (B[-1]);
  if (m >= n) {
  A1 = MMAPMON(p,A);
  A2 = MMAPMON(p,B); }
  else {
  A1 = MMAPMON(p,B);
  A2 = MMAPMON(p,A); }
  do {
  MMAPREM(p,A1,A2);
  t = A1;
  A1 = A2;
  A2 = t; }
  while (!((A2[-1]) == 0 && (A2[0]) == 0));
  C = MMAPMON(p,A1);

  free(((A1)-1));
  free(((A2)-1));

Return:
  return(C);
}
__

# gcc-4 -c foo.c -O2 -Wall -Wextra -Wstrict-prototypes -Wstrict- 
aliasing=2
/Users/jfm/Desktop/saclib_fail.c:6: warning: function declaration  
isn't a prototype

cc1(72244) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

cc1: out of memory allocating 248 bytes after a total of 0 bytes
___
with -O1 or -Os , no problem.
With gcc or gcc-4.2, or fink's gcc43 pkg, also no problem,
even with "-O3 -fstrict-aliasing"
_

JF Mertens

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2009-05-01 
14:06 ---
Java has always been broken at -m64 on ppc-darwin since no one has ever ported
ffi to work on ppc64 for darwin.


-- 


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

[Bug c++/39992] cc1plus exhausts memory with deeply nested unclosed constructor parens

[cbm at whatexit dot org]

--- Comment #1 from cbm at whatexit dot org  2009-05-01 14:08 ---
... rather,
> int f(int);
> int 
> x=f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(0
fails immediately.


-- 


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2009-05-01 14:08 ---
(In reply to comment #4)
> (In reply to comment #3)
> 
> I couldn't find any other gmp or mpfr in the system.
> Also tried using the system's ld and as (both version 2.11.2) but the same
> error pops up (see below).
> Using ps ax I checked that the right versions of ld and as are used while
> compiling.
> 
> Any other idea on what to try?


 /home2/gdb/local/src/gcc-4.1.2/configure --prefix=/home2/gdb/local/gcc-4.1.2
--enable-languages=c,fortran  --with-gmp=/home2/gdb/local/gmp-4.1.3
--with-mpfr=/home2/gdb/local/gmp-4.1.3
--with-as=/home2/gdb/local/binutils-2.18/bin/as
--with-ld=/home2/gdb/local/binutils-2.18/bin/ld

Argh, I got side track thinking this was a MPFR/MP installation
issue.  Please read http://gcc.gnu.org/install/

In particularly, you can't build gcc in its source directory.  Your
above configure command shows pilot error.


-- 


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

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #16 from dominiq at lps dot ens dot fr  2009-05-01 14:08 ---
> Java has always been broken at -m64 on ppc-darwin since no one has ever ported
> ffi to work on ppc64 for darwin.

This is precisely why I have tried the test without -m64.


-- 


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

[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)

[manu at gcc dot gnu dot org]

--- Comment #11 from manu at gcc dot gnu dot org  2009-05-01 14:37 ---
FIXED by Janis.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-05-01 14:49 ---
 I don't see this with a bootstrap that I was doing with r147003. 

 /home/ramana/build-combined-arm-gcc-20090430/./gcc/xgcc -v
Using built-in specs.
Target: armv5tel-unknown-linux-gnueabi
Configured with: ../trunk/configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 147003] (GCC)

though I do see a failure similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 while bootstrapping in
stage3.


-- 


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

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #17 from dominiq at lps dot ens dot fr  2009-05-01 14:50 ---
At revision 147032 on i686-apple-darwin9 the bootstrap still fails. Using the
built jc1 I get:

[ibook-dhum] bug/java_test% /opt/gcc/i686-darwin/gcc/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -quiet -mmacosx-version-min=10.5.6
-mtune=generic -O2 -Wno-deprecated -fencoding=UTF-8 -fbootstrap-classes -fjni
-findirect-dispatch -fno-indirect-classes -fno-common
-fbootclasspath=/opt/gcc/_gcc_clean/libjava/classpath/lib/
-fdump-tree-all-details
gnu/CORBA/Poa/gnuPOA.java: In class 'gnu.CORBA.Poa.gnuPOA$RefTemplate':
gnu/CORBA/Poa/gnuPOA.java: In constructor '(gnu.CORBA.Poa.gnuPOA)':
In file included from :0:
gnu/CORBA/Poa/gnuPOA.java:0: error: type mismatch in indirect reference
struct java.lang.String[]

void

# VUSE <.MEM_11>
#slot#8#31_225 = #ref#5#2_135->length;

gnu/CORBA/Poa/gnuPOA.java:0: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug middle-end/39579] [4.5 regression] revisions 145171/145172 caused 2 extra failures

[sje at cup dot hp dot com]

--- Comment #5 from sje at cup dot hp dot com  2009-05-01 14:52 ---
XFAILed on IA64 and SPARC because they do not support the required vector
instructions used by these tests.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[gustcr at yahoo dot com dot ar]

--- Comment #6 from gustcr at yahoo dot com dot ar  2009-05-01 14:57 ---
(In reply to comment #5)

Well... I already read the installation instructions and know them almost by
hard... and a bit more. At the web page it says:

"First, we highly recommend that GCC be built into a separate directory than
the sources which does not reside within the source tree"

And for this reason I have the source in:
/home2/gdb/local/src/gcc-4.4.0/
while I am building in:
/home2/gdb/local/gcc-4.4.0-obj
and the final install should go to:
/home2/gdb/local/gcc-4.4.0/

For my last trial, for instance, I used:
dirac:~/local/gcc-4.4.0-obj$ /home2/gdb/local/src/gcc-4.4.0/configure
--prefix=/home2/gdb/local/gcc-4.4.0 --enable-languages=c,fortran

I think this directory tree should be ok as no directory is in a subdirectory
of any other


-- 


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2009-05-01 15:04 
---
What's the content of your generated file kinds.h? (It's in the target
libgfortran directory)? I suspect that the generation of kinds.h fails but the
Makefile continues, and the content of kinds.h makes it error out at the next
use.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug fortran/37159] RANDOM_SEED: GET= check array size at compile time and respect -fdefault-integer-*

[fxcoudert at gcc dot gnu dot org]

--- Comment #15 from fxcoudert at gcc dot gnu dot org  2009-05-01 15:10 
---
Daniel, shouldn't this PR be closed?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug fortran/37159] RANDOM_SEED: GET= check array size at compile time and respect -fdefault-integer-*

[dfranke at gcc dot gnu dot org]

--- Comment #16 from dfranke at gcc dot gnu dot org  2009-05-01 15:21 
---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[gustcr at yahoo dot com dot ar]

--- Comment #8 from gustcr at yahoo dot com dot ar  2009-05-01 15:25 ---
I think that it fails in building libgfortran.h

This is the last part of the output:
.
make[4]: Leaving directory
`/home2/gdb/local/gcc-4.4.0-obj/i686-pc-linux-gnu/libssp'
make[3]: Leaving directory
`/home2/gdb/local/gcc-4.4.0-obj/i686-pc-linux-gnu/libssp'
make[2]: Leaving directory
`/home2/gdb/local/gcc-4.4.0-obj/i686-pc-linux-gnu/libssp'
Checking multilib configuration for libgfortran...
make[2]: Entering directory
`/home2/gdb/local/gcc-4.4.0-obj/i686-pc-linux-gnu/libgfortran'
make  all-am
make[3]: Entering directory
`/home2/gdb/local/gcc-4.4.0-obj/i686-pc-linux-gnu/libgfortran'
if /home2/gdb/local/bash-4.0/bin/bash ./libtool --tag=CC --mode=compile
/home2/gdb/local/gcc-4.4.0-obj/./gcc/xgcc
-B/home2/gdb/local/gcc-4.4.0-obj/./gcc/
-B/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/bin/
-B/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/lib/ -isystem
/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/include -isystem
/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/home2/gdb/local/src/gcc-4.4.0/libgfortran -I. 
-iquote/home2/gdb/local/src/gcc-4.4.0/libgfortran/io
-I/home2/gdb/local/src/gcc-4.4.0/libgfortran/../gcc
-I/home2/gdb/local/src/gcc-4.4.0/libgfortran/../gcc/config -I../.././gcc
-D_GNU_SOURCE  -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2   -MT
fmain.lo -MD -MP -MF ".deps/fmain.Tpo" -c -o fmain.lo
/home2/gdb/local/src/gcc-4.4.0/libgfortran/fmain.c; \
then mv -f ".deps/fmain.Tpo" ".deps/fmain.Plo"; else rm -f
".deps/fmain.Tpo"; exit 1; fi
libtool: compile:  /home2/gdb/local/gcc-4.4.0-obj/./gcc/xgcc
-B/home2/gdb/local/gcc-4.4.0-obj/./gcc/
-B/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/bin/
-B/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/lib/ -isystem
/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/include -isystem
/home2/gdb/local/gcc-4.4.0/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/home2/gdb/local/src/gcc-4.4.0/libgfortran -I.
-iquote/home2/gdb/local/src/gcc-4.4.0/libgfortran/io
-I/home2/gdb/local/src/gcc-4.4.0/libgfortran/../gcc
-I/home2/gdb/local/src/gcc-4.4.0/libgfortran/../gcc/config -I../.././gcc
-D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT
fmain.lo -MD -MP -MF .deps/fmain.Tpo -c
/home2/gdb/local/src/gcc-4.4.0/libgfortran/fmain.c  -fPIC -DPIC -o
.libs/fmain.o
In file included from
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:246,
 from /home2/gdb/local/src/gcc-4.4.0/libgfortran/fmain.c:1:
./kinds.h:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'float'
./kinds.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'double'
./kinds.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'long'
In file included from /home2/gdb/local/src/gcc-4.4.0/libgfortran/fmain.c:1:
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:332: error: expected
specifier-qualifier-list before 'GFC_COMPLEX_4'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:333: error: expected
specifier-qualifier-list before 'GFC_COMPLEX_8'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:335: error: expected
specifier-qualifier-list before 'GFC_COMPLEX_10'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:795: error: expected
'=', ',', ';', 'asm' or '__attribute__' before '*' token
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:796: error:
'internal_pack_c4' undeclared here (not in a function)
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:796: warning: type
defaults to 'int' in declaration of 'internal_pack_c4'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:798: error: expected
'=', ',', ';', 'asm' or '__attribute__' before '*' token
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:799: error:
'internal_pack_c8' undeclared here (not in a function)
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:799: warning: type
defaults to 'int' in declaration of 'internal_pack_c8'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:802: error: expected
'=', ',', ';', 'asm' or '__attribute__' before '*' token
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:803: error:
'internal_pack_c10' undeclared here (not in a function)
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:803: warning: type
defaults to 'int' in declaration of 'internal_pack_c10'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:844: warning: type
defaults to 'int' in declaration of 'GFC_COMPLEX_4'
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:844: error: expected
';', ',' or ')' before '*' token
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:845: error:
'internal_unpack_c4' undeclared here (not in a function)
/home2/gdb/local/src/gcc-4.4.0/libgfortran/libgfortran.h:845: warning: type

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[rearnsha at gcc dot gnu dot org]

--- Comment #3 from rearnsha at gcc dot gnu dot org  2009-05-01 15:30 
---
This smells like a memory corruption problem in the compiler...


-- 


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2009-05-01 15:44 
---
(In reply to comment #8)
> I think that it fails in building libgfortran.h

libgfortran.h is not "built", it's a source file.

There was one question only in my comment: What's the content of your generated
file kinds.h? You haven't answered.


-- 


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

[Bug bootstrap/39977] [4.5 Regression] r1467817 broke bootstrap on PA

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2009-05-01 15:54 ---
Looking at exp when we enter expand_expr_addr_expr_1 I see:

 
unit size 
align 64 symtab 0 alias set -1 canonical type 79eee690 precision 128
pointer_to_this >
visited var def_stmt D.1233_5 = -a.0_3;

version 5>

Am I right in assuming that an ssa_name should not be getting into this
routine?


-- 


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[gustcr at yahoo dot com dot ar]

--- Comment #10 from gustcr at yahoo dot com dot ar  2009-05-01 15:59 
---

dirac:~/local/gcc-4.4.0-obj$ cat ./i686-pc-linux-gnu/libgfortran/kinds.h
typedef int8_t GFC_INTEGER_1;
typedef uint8_t GFC_UINTEGER_1;
typedef GFC_INTEGER_1 GFC_LOGICAL_1;
#define HAVE_GFC_LOGICAL_1
#define HAVE_GFC_INTEGER_1

typedef int16_t GFC_INTEGER_2;
typedef uint16_t GFC_UINTEGER_2;
typedef GFC_INTEGER_2 GFC_LOGICAL_2;
#define HAVE_GFC_LOGICAL_2
#define HAVE_GFC_INTEGER_2

typedef int32_t GFC_INTEGER_4;
typedef uint32_t GFC_UINTEGER_4;
typedef GFC_INTEGER_4 GFC_LOGICAL_4;
#define HAVE_GFC_LOGICAL_4
#define HAVE_GFC_INTEGER_4

typedef int64_t GFC_INTEGER_8;
typedef uint64_t GFC_UINTEGER_8;
typedef GFC_INTEGER_8 GFC_LOGICAL_8;
#define HAVE_GFC_LOGICAL_8
#define HAVE_GFC_INTEGER_8

#define GFC_INTEGER_LARGEST GFC_INTEGER_8
#define GFC_UINTEGER_LARGEST GFC_UINTEGER_8
#define GFC_DEFAULT_CHAR 1

typedef float GFC_REAL_4;
typedef complex float GFC_COMPLEX_4;
#define HAVE_GFC_REAL_4
#define HAVE_GFC_COMPLEX_4
#define GFC_REAL_4_HUGE 3.40282347e38f
#define GFC_REAL_4_DIGITS 24
#define GFC_REAL_4_RADIX 2

typedef double GFC_REAL_8;
typedef complex double GFC_COMPLEX_8;
#define HAVE_GFC_REAL_8
#define HAVE_GFC_COMPLEX_8
#define GFC_REAL_8_HUGE 1.7976931348623157e308
#define GFC_REAL_8_DIGITS 53
#define GFC_REAL_8_RADIX 2

typedef long double GFC_REAL_10;
typedef complex long double GFC_COMPLEX_10;
#define HAVE_GFC_REAL_10
#define HAVE_GFC_COMPLEX_10
#define GFC_REAL_10_HUGE 1.18973149535723176502e4932l
#define GFC_REAL_10_DIGITS 64
#define GFC_REAL_10_RADIX 2

dirac:~/local/gcc-4.4.0-obj$


-- 


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #11 from fxcoudert at gcc dot gnu dot org  2009-05-01 16:12 
---
Oh, I think I see. Do you have a really old glibc? What happens if you use a
newer one?


-- 


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

[Bug c++/39993] New: missing diagnostic on conflicting exception specifications

[sebor at roguewave dot com]

As mentioned in this post:
http://gcc.gnu.org/ml/libstdc++/2009-05/msg0.html
gcc accepts the ill-formed code below. According to [except.spec], p2:

  If any declaration of a function has an exception-specification,
  all declarations, including the definition and an explicit
  specialization, of that function shall have an exception-
  specification with the same set of type-ids.

$ cat t.cpp && g++ -c -Wall -Wextra -pedantic t.cpp && echo FAIL
extern "C" void abort(void);
namespace std {
extern "C" void abort(void) throw();
}

namespace std {
extern "C" void abort(void) throw();
}
extern "C" void abort(void);
FAIL

See also bug 32081 and bug 24817 for similar problems in template code.


-- 
   Summary: missing diagnostic on conflicting exception
specifications
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug c++/39993] missing diagnostic on conflicting exception specifications

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid, diagnostic
   Last reconfirmed|-00-00 00:00:00 |2009-05-01 16:46:19
   date||


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

[Bug fortran/39971] kinds.h fails at building libgfortran

[gustcr at yahoo dot com dot ar]

--- Comment #12 from gustcr at yahoo dot com dot ar  2009-05-01 17:14 
---
Yes, glibc is old:


dirac:~/local/gcc-4.4.0-obj$ /lib/libc.so.6
GNU C Library stable release version 2.1.3, by Roland McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release).
Compiled on a Linux 2.2.19-6.2.0 system on 2001-12-08.
Available extensions:
GNU libio by Per Bothner
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
BIND-4.9.7-REL
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Glibc-2.0 compatibility add-on by Cristian Gafton 
linuxthreads-0.8 by Xavier Leroy
libthread_db work sponsored by Alpha Processor Inc
Report bugs using the `glibcbug' script to .


I compiled glibc-2.3.6, the last with support for the 2.4 kernel series (I
think) but don't know how to use it to compile gcc being a normal user (no root
privileges) without scrambling everything else. Any help on this direction?
Thanks


-- 


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

[Bug bootstrap/39977] [4.5 Regression] r1467817 broke bootstrap on PA

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2009-05-01 17:22 ---
That shouldn't happen yes.  We are trying to expand
  __fixunstfdi (D.1248_5)
As far as the gimple side is concerned this is a normal pass-by-value call
hence the SSA name therein is perfectly fine.  But it seems the setup for
this call transforms it into actually being passed by reference:

#6  0x005b0d41 in precompute_register_parameters (num_actuals=1,
args=0x7fff6340, reg_parm_seen=0x7fff654c)
at ../../gcc/gcc/calls.c:677
677 args[i].value = expand_normal (args[i].tree_value);
(gdb) p debug_generic_expr (args[i].tree_value)
&D.1248_5

That comes at a surprise for the expander because you can't take addresses
of SSA names as easily, the object therein needs to be marked as having the
address taken.  Even if we would handle SSA names like VAR_DECLs in
expand_expr_addr_expr_1 it wouldn't help.  Those are simply expanded and
then its expected that the returned thing is a MEM_P.  Which it normally
isn't for SSA names, it will be a pseudo reg, so the other assert would 
trigger:
  if (DECL_P (exp)
...
  result = expand_expr (exp, target, tmode,
modifier == EXPAND_INITIALIZER
? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS);

  /* If the DECL isn't in memory, then the DECL wasn't properly
 marked TREE_ADDRESSABLE, which will be either a front-end
 or a tree optimizer bug.  */
  gcc_assert (MEM_P (result));

I see code in initialize_argument_information (around calls.c:1072) which
reads as if it wants to deal with this issue, copying the real argument to
some temporary storage and passing the address of that temporary storage.

But it takes the shortcut route at calls.c:1061:

  if (call_from_thunk_p
  || (callee_copies
  && !TREE_ADDRESSABLE (type)
  && (base = get_base_address (args[i].tree_value))
  && (!DECL_P (base) || MEM_P (DECL_RTL (base)
{
  /* We can't use sibcalls if a callee-copied argument is
 stored in the current function's frame.  */
  if (!call_from_thunk_p && DECL_P (base) && !TREE_STATIC (base))
*may_tailcall = false;

  args[i].tree_value = build_fold_addr_expr (args[i].tree_value);

It is taken because SSA-names are !DECL_P.  We probably have to handle SSA
names here as if they are DECLs with a REG_P DECL_RTL.  At least the patch
below will fix the compilation of the testcase, if you could give it a test
that would be nice:

Index: calls.c
===
--- calls.c (Revision 146955)
+++ calls.c (Arbeitskopie)
@@ -1054,6 +1054,7 @@ initialize_argument_information (int num
  || (callee_copies
  && !TREE_ADDRESSABLE (type)
  && (base = get_base_address (args[i].tree_value))
+ && TREE_CODE (base) != SSA_NAME
  && (!DECL_P (base) || MEM_P (DECL_RTL (base)
{
  /* We can't use sibcalls if a callee-copied argument is


-- 


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

[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.

[julian1844 at yahoo dot com]

--- Comment #11 from julian1844 at yahoo dot com  2009-05-01 17:26 ---
(In reply to comment #9, comment #10)
I did not build MinGW 4.3.0. I got it from the official MinGW site
(gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com
there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0
with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine with
OpenMP. They aren't present on the official MinGW site. Why?

> (In reply to comment #6)
> > (In reply to comment #4)
> > > Your libpthreads is doing something wrong.
> > > Re. comment 5
> > The command was actually
> > gcc -fopemnp test.c -lgomp -o test.exe
> > 
> 
> That command works for me with gcc 4.3.4, 4.4.0 and trunk
> In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn 
> resolves
> the pthread imports from PTHREADGCE2.DLL, which is distributed by the
> pthreads-win32 project
> http://sources.redhat.com/pthreads-win32/
> 
> My version of 4.3.4 has local mods.  I'm not sure if the shared libgomp build
> was standard then.
> 
> How did you build gcc-4.3.0?  You need to add  --enable-libgomp to configure
> and ensure that libpthread.a (note spelling) can be found.
> 
> Danny
> 


-- 


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

[Bug fortran/39994] New: Bounds checking (-fcheck=bounds): "A = [ constructor ]" does not work

[burnus at gcc dot gnu dot org]

There are currently no checks for LHS = RHS where RHS is an array constructor,
if -fbounds-check / -fcheck=bounds is used. (Neither is it detected by NAG f95,
ifort, g95.)

Example:

integer :: a(2), b(5), i
b = 0
i = 2
a = [1, 2, b(1:i)] ! RHS too many items
i = 1
a = [ b(1:i)] ! RHS too few items
end


-- 
   Summary: Bounds checking (-fcheck=bounds): "A = [ constructor ]"
does not work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 27766
 nThis:


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

[Bug fortran/39995] New: Open MP compile fails with "internal compiler error"

[mmsussman at gmail dot com]

The following error occurs on more than one system with more than one version
of the compiler!

I am running Ubuntu 8.04.
The output of uname -a is:
Linux ozhp 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009 i686 GNU/Linux

Command line: and its output:
\gfortran -v -fopenmp simple.f90 -o junk
Driving: gfortran -v -fopenmp simple.f90 -o junk -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
 /usr/lib/gcc/i486-linux-gnu/4.2.4/f951 simple.f90 -quiet -dumpbase simple.f90
-mtune=generic -auxbase simple -version -fopenmp -fstack-protector -I
/usr/lib/gcc/i486-linux-gnu/4.2.4/finclude -o /tmp/ccYjCwtk.s
GNU F95 version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
simple.f90: In function ‘MAIN__’:
simple.f90:42: internal compiler error: in extract_omp_for_data, at
omp-low.c:161
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

The problem seems to be associated with one line in the contain-ed subroutine
"display".  The offending line is noted by a comment.  The subroutine is never
called.

There is just this one file, named "simple.f90".

program life
implicit none
integer, parameter :: r8=selected_real_kind(14),N=20,M=40,screen=6,esc=27
integer, parameter :: steps=100
logical, parameter :: doDisplay=.false.
integer :: i,j,step,neighbors,ip1,im1,jp1,jm1,numGliders
character(len=1) :: blank=' ',mark='X'
character(len=1) :: world(0:N-1,0:M-1)
integer  :: iworld(0:N-1,0:M-1)

! initialize (vector statement)
world(:,:)=blank
! set up a glider
numGliders=0
DO j=1,M-4,5
  DO i=0,N-4,5
world(i:i+2,j-1)=mark
world(i,j)=mark
world(i+1,j+1)=mark
numGliders=numGliders+1
  ENDDO
ENDDO

where(world==mark)
  iworld=1
elsewhere
  iworld=0
endwhere
  print *,'starting with ',numGliders,' gliders.'

do step=1,steps
  world=blank
  !$omp parallel do private(i,jm1,jp1,im1,ip1,neighbors)
  do j=M-1,0,-1
jm1=modulo(j-1,M)
jp1=modulo(j+1,M)
do i=N-1,0,-1
  im1=modulo(i-1,N)
  ip1=modulo(i+1,N)

  neighbors= iworld(im1,jm1)+iworld(im1,j)+iworld(im1,jp1) &
  &+ iworld(i,jm1)  +iworld(i,jp1) &
  &+ iworld(ip1,jm1)+iworld(ip1,j)+iworld(ip1,jp1)
  if(iworld(i,j)==0) then
if(neighbors==3)world(i,j)=mark
  else
if( neighbors==2 .or. neighbors==3 )world(i,j)=mark
  endif
enddo
  enddo
  !$omp end parallel do
  where(world==mark)
iworld=1
  elsewhere
iworld=0
  endwhere
enddo

  print *,'   ended with ',numGliders,' gliders after',steps,' steps.'

CONTAINS

SUBROUTINE display(A)
IMPLICIT NONE
INTEGER,INTENT(IN) :: A(:,:)
CHARACTER(LEN=40)  :: fmt
CHARACTER(LEN=1),ALLOCATABLE :: Acharac(:,:)

DO i=M,1,-1
! comment out the following statement and the program compiles
  WRITE(screen,fmt)i-1,(Acharac(i,j),j=1,N)
ENDDO

END SUBROUTINE display

end program life


-- 
   Summary: Open MP compile fails with "internal compiler error"
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmsussman at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug fortran/39995] Open MP compile fails with "internal compiler error"

[mmsussman at gmail dot com]

--- Comment #1 from mmsussman at gmail dot com  2009-05-01 18:26 ---
Created an attachment (id=17789)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view)
copy of original source code.


-- 


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

[Bug bootstrap/39977] [4.5 Regression] r1467817 broke bootstrap on PA

[sje at cup dot hp dot com]

--- Comment #5 from sje at cup dot hp dot com  2009-05-01 18:30 ---
The proposed patch fixed my bootstrap failure.  I haven't run the testsuite yet
to look for regressions but the bootstrap is working.


-- 


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

[Bug target/39986] decimal float constant is incorrect when cc1 is a 64-bit binary

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2009-05-01 18:57 ---
The problem is that in dfp.c, functions encode_decimal* and decode_decimal* use
memcpy from a 32-bit int to a long for 32 bits.  This works fine with -32 where
long is 32 bits, but not for -m64 where long is 32 bits.  I assume that it
magically works fine on little-endian systems like x86_64.

This is not a regression, just a horrible wrong-code bug.

I'm testing a patch.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |janis at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-01 18:57:58
   date||


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

[Bug target/39986] decimal float constant is incorrect when cc1 is a 64-bit binary

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-05-01 19:03 ---
D'oh, I of course meant that long is 32-bits when GCC is build with default
-m32 and that long is 64-bits when GCC is built with default -m64; the host
size of long, not the target size.


-- 


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

[Bug fortran/39996] New: Double typing of function results not detected

[burnus at gcc dot gnu dot org]

Found at c.l.f where Giorgio Pastore reported it.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a48b6b038baabd90

gfortran -std=f95 does not detect the following:

  interface
 function square (x) result (s)
 real,intent (in) ::x
 real ::s
 end function square
  end interface

  real :: square ! << Wrong!

ifort prints:
error #6409: This name has already been used as an external procedure name.  
[SQUARE]
 real :: square

And NAG f95:
Error: hjff.f90, line 24: Multiply defined symbol SQUARE
   detected at ::@SQUARE
Error: hjff.f90, line 24: Duplicate type declaration for SQUARE
   detected at ::@SQUARE


-- 
   Summary: Double typing of function results not detected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/39995] Open MP compile fails with "internal compiler error"

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2009-05-01 19:29 ---
(In reply to comment #1)
> Created an attachment (id=17789)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view) [edit]
> copy of original source code.
> 

Works for me with

REMOVE:kargl[208] gfc43 --version
GNU Fortran (GCC) 4.3.3 20081120 (prerelease)
REMOVE:kargl[209] gfc4x --version
GNU Fortran (GCC) 4.5.0 20090426 (experimental) [trunk revision 140508]

What 'other versions of the compiler' does it fail with?


-- 


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

[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.

[dannysmith at users dot sourceforge dot net]

--- Comment #12 from dannysmith at users dot sourceforge dot net  
2009-05-01 19:48 ---
(In reply to comment #11)
> (In reply to comment #9, comment #10)
> I did not build MinGW 4.3.0. I got it from the official MinGW site
> (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com
> there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0
> with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine 
> with
> OpenMP. 

Its a shame that www.equation.com doesn't tell us how to obtain their source
code for the gcc, gdb ands make binaries.


> They aren't present on the official MinGW site. Why?

No one has had put them there.
Danny
> 


-- 


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

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2009-05-01 19:54 
---
Hm, with a cross configured like

configure --disable-nls --enable-languages=java --target=i686-apple-darwin9

and make all-gcc I just get

gcc$ ./jc1 -quiet
~/src/trunk/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -quiet -mmacosx-version-min=10.5.6
-mtune=generic -O2 -Wno-deprecated -fencoding=UTF-8 -fbootstrap-classes -fjni
-findirect-dispatch -fno-indirect-classes -fno-common
-fbootclasspath=~/src/trunk/libjava/classpath/lib 
Segmentation fault

:/

So I still cannot reproduce this.  The segfault happens because the FE
endlessly recurses in

#295 0x080ddae8 in layout_class_methods (this_class=0xb7761a8c)
at /home/richard/src/trunk/gcc/java/class.c:2559
2559layout_class_methods (super_class);
(gdb) 
#296 0x080ddae8 in layout_class_methods (this_class=0xb7761a8c)
at /home/richard/src/trunk/gcc/java/class.c:2559
2559layout_class_methods (super_class);
...


-- 


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

[Bug middle-end/39983] ICE: type mismatch in address expression

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-01 19:56 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-01 19:56:53
   date||


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

[Bug bootstrap/39977] [4.5 Regression] r1467817 broke bootstrap on PA

[sje at cup dot hp dot com]

--- Comment #6 from sje at cup dot hp dot com  2009-05-01 20:01 ---
I finished testing and it looks OK.  The failures that I see also appear on
other platforms (hppa64 and ia64) so I think the patch is good.

FAIL: libgomp.c++/task-4.C  -O  (internal compiler error)
FAIL: libgomp.c++/task-4.C  -O  (test for excess errors)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors)
FAIL: gcc.dg/torture/pr26565.c  -O1  execution test
FAIL: gcc.dg/torture/pr26565.c  -O2  execution test
FAIL: gcc.dg/torture/pr26565.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/pr26565.c  -O3 -g  execution test
FAIL: gcc.dg/torture/pr26565.c  -Os  execution test
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
FAIL: gcc.dg/pthread-init-2.c (test for excess errors)


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-01 20:01 ---
Which pass? p *pass in frame 20 should tell you.


-- 


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

[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-01 20:03 ---
*** Bug 39980 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug c++/39980] C++ ICE in tsubst

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-01 20:03 ---


*** This bug has been marked as a duplicate of 39754 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-05-01 20:07 ---
> :
>   # crkveuk_lsm.686_3635 = PHI 
>   # cikve_lsm.685_3640 = PHI 
>   # crkveuk_lsm.686_3564 = PHI 
> 
> Interesting, I wonder if that causes expand SSA to go crazy or do we go into
> closed loop form on purpose now.

Huh.  We should definitely get rid of these degenerate PHIs before expanding
(and call cfgcleanup which then may merge the blocks).


-- 


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

[Bug fortran/39997] New: Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

This is a tracking bug. It partially applies directly and partially for the
almost ready proc-pointer components patch.

I first ask ask comp.lang.fortran, but Richard Maine's reply was that he sees
the problem but feels he cannot answer it:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a48b6b038baabd90

I then asked at the J3 mailing list:

http://j3-fortran.org/pipermail/j3/2009-May/002736.html


-- 
   Summary: Procedure(), pointer  & implicit typing: rejects-valid /
accepts-invalid?
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2009-05-01 20:32 ---
I'm not in my office where the box is, however, I believe the ICE occurs in
stage2.


-- 


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

[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-01 20:34 ---
We can't perform loop store sinking as in and res alias.  And our other
store sinking pass is just too stupid for this case as we have a missed
CSE opportunity for the address stored to:

  D.1243_8 = *D.1242_7;
  if (D.1243_8 != 0)
goto ;
  else
goto ;

:
  D.1246_12 = res_11(D) + D.1241_5;
  *D.1246_12 = 4660;
  goto ;

:
  D.1246_15 = res_11(D) + D.1241_5;
  *D.1246_15 = 39030;

but this is the usual missing code hoisting.


-- 


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

[Bug fortran/39995] Open MP compile fails with "internal compiler error"

[msussman at verizon dot net]

--- Comment #3 from msussman at verizon dot net  2009-05-01 21:39 ---
Subject: Re:  Open MP compile fails with "internal
compiler error"

On Fri, 2009-05-01 at 19:29 +, kargl at gcc dot gnu dot org wrote:
> 
> --- Comment #2 from kargl at gcc dot gnu dot org  2009-05-01 19:29 ---
> (In reply to comment #1)
> > Created an attachment (id=17789)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view) [edit]
> > copy of original source code.
> > 
> 
> Works for me with
> 
> REMOVE:kargl[208] gfc43 --version
> GNU Fortran (GCC) 4.3.3 20081120 (prerelease)
> REMOVE:kargl[209] gfc4x --version
> GNU Fortran (GCC) 4.5.0 20090426 (experimental) [trunk revision 140508]
> 
> What 'other versions of the compiler' does it fail with?
> 
I am sorry, I should have specified:

gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)

This is running on a system at the Pittsburgh Supercomputer Center
(warhol.psc.edu) and I am not sure what the Linux release is.

[Please excuse me if I have responded to the wrong address, this is the
first time I have used bugzilla.]


-- 


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

[Bug fortran/39998] New: Procedure Pointer Assignments: Statement Functions & Internal Functions

[janus at gcc dot gnu dot org]

According to the following passage of the Fortran 2003 standard, statement
functions and internal functions are forbidden in procedure pointer
assignments:

C727 (R742) A procedure-name shall be the name of an external, module, or dummy
procedure, a specific intrinsic function listed in 13.6 and not marked with a
bullet (•), or a procedure pointer.

Test cases:

f(x) = x**2
procedure(), pointer :: p
p => f
print *, p(4.0)
end

**

 procedure(), pointer :: p
 p => sub
contains
 subroutine sub
 end subroutine sub
end

**

Internal functions, however, are valid in Fortran 2008.

Thanks to Tobias for reporting this.


-- 
   Summary: Procedure Pointer Assignments: Statement Functions &
Internal Functions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug fortran/39995] Open MP compile fails with "internal compiler error"

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-05-01 21:50 ---
(In reply to comment #3)> 
> On Fri, 2009-05-01 at 19:29 +, kargl at gcc dot gnu dot org wrote:
> > 
> > > Created an attachment (id=17789)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view) [edit]
> >  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view)
> > > copy of original source code.
> > > 
> > 
> > Works for me with
> > 
> > REMOVE:kargl[208] gfc43 --version
> > GNU Fortran (GCC) 4.3.3 20081120 (prerelease)
> > REMOVE:kargl[209] gfc4x --version
> > GNU Fortran (GCC) 4.5.0 20090426 (experimental) [trunk revision 140508]
> > 
> > What 'other versions of the compiler' does it fail with?
> > 
> I am sorry, I should have specified:
> 
> gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
> 
> This is running on a system at the Pittsburgh Supercomputer Center
> (warhol.psc.edu) and I am not sure what the Linux release is.

You should ask the PSC to upgrade to at least the latest 4.3.x
release and preferably to the new 4.4.0 release.  Too many bugs
and features have been added to list here.


-- 


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

[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2009-05-01 21:51 ---
Crossjumping does nothing, because there is nothing to crossjump anymore at
that point.  The two stores have been replaced with one and a conditional set:

- in .ce1 (ifcvt1) we haven't converted to a conditional set two stores
- in .ce2 there is a conditional set to a reg and only one store

The conditional set is to a reg (r = in[i] ? 0x1234 : 0x9876).

Anwyay, ce2 is *after* auto-inc-dec.  We would probably optimize this if you'd
run auto-inc-dec after ce2.  I don't know why this transformation is not
already done in ce1.


-- 


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

[Bug c/39983] ICE: type mismatch in address expression

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-01 21:13 ---
FE problem.  In

  extern const int b[1];
  static const int * const c[] = { b };

b decays to type int * instead of const int *.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |c


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

[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2009-05-01 22:27 ---
FWIW, early crossjumping (after ce1) doesn't work either.

The code before trying to crossjump looks like this:

   44 pc={(cc:CC=0x0)?L50:pc}
  REG_DEAD: cc:CC
  REG_BR_PROB: 0x1388
   45 NOTE_INSN_BASIC_BLOCK
   46 r170:SI=0x1234
   47 [r168:SI+r164:SI]=r170:SI
  REG_DEAD: r170:SI
  REG_EQUAL: 0x1234
L50:
   51 NOTE_INSN_BASIC_BLOCK
   52 r171:SI=0x9876
   53 [r168:SI+r164:SI]=r171:SI
  REG_DEAD: r171:SI
  REG_EQUAL: 0x1234
L54:
   55 NOTE_INSN_BASIC_BLOCK
   56 r162:SI=r162:SI+0x1
   57 r164:SI=r164:SI+0x4

Note that we're in cfglayout mode: we fall through to insn 55 from insn 53 and
insn 47 too.

The reason that crossjumping fails, is the difference in input registers (r170
and r171), i.e. the usual problem with the RTL crossjumping pass.

The reason why I keep coming back to crossjumping, is that I am 99% sure we
would have an autoincrement if we crossjumped the two stores.


-- 


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

[Bug c/39999] New: gcc 4.4.0 compiles in infinite loop

[howarth at nitro dot med dot uc dot edu]

The following code...

#include 
extern int *MMAPMON (int m, int *A);
extern void MMAPREM (int m, int *A, int *B);


int *MMAPGCD(p,A,B)
  int p,*A,*B;
{
  int *A1,*A2,*t,*C,m,n;


  if (((A[-1]) == 0 && (A[0]) == 0)) {
  C = MMAPMON(p,B);
  goto Return; }
  if (((B[-1]) == 0 && (B[0]) == 0)) {
  C = MMAPMON(p,A);
  goto Return; }


  m = (A[-1]);
  n = (B[-1]);
  if (m >= n) {
  A1 = MMAPMON(p,A);
  A2 = MMAPMON(p,B); }
  else {
  A1 = MMAPMON(p,B);
  A2 = MMAPMON(p,A); }
  do {
  MMAPREM(p,A1,A2);
  t = A1;
  A1 = A2;
  A2 = t; }
  while (!((A2[-1]) == 0 && (A2[0]) == 0));
  C = MMAPMON(p,A1);


  free(((A1)-1));
  free(((A2)-1));


Return:
  return(C);
}

hangs the gcc 4.4.0 and gcc-4_4-branch gcc compiler at -O2 when compiled
with...

gcc-4 -c foo.c -O2 -Wall -Wextra -Wstrict-prototypes -Wstrict- aliasing=2

The problem is observed on i686-apple-darwin9, x86_64-apple-darwin10 and
x86_64-redhat-linux. On x86_64-apple-darwin10, sampling during the hang
shows...

Sampling process 30978 for 1 seconds with 1 millisecond of run time between
samp
les
Sampling completed, processing symbols...
Analysis of sampling cc1 (pid 30978) every 1 millisecond
Call graph:
852 Thread_2d07
  852 start
852 toplev_main
  852 c_write_global_declarations
852 cgraph_optimize
  852 cgraph_expand_function
852 tree_rest_of_compilation
  852 execute_pass_list
852 execute_pass_list
  852 execute_one_pass
852 do_pre
  852 execute_pre
850 compute_antic
  359 phi_translate_set
88 sorted_array_from_bitmap_set
  76 sorted_array_from_bitmap_set
  6 bitmap_bit_p
6 bitmap_bit_p
  6 vec_heap_o_reserve_1
6 xrealloc
  4 xrealloc
  2 malloc
2 malloc_zone_malloc
  2 szone_malloc
2 szone_malloc
58 bitmap_insert_into_set_1
  36 htab_find_slot_with_hash
17 vn_nary_op_eq
  11 types_compatible_p
8 useless_type_conversion_p
  4 get_alias_set
4 get_alias_set
  4 useless_type_conversion_p
3 types_compatible_p
  3 expressions_equal_p
3 expressions_equal_p
  3 vn_nary_op_eq
15 htab_find_slot_with_hash
4 pre_expr_eq
  4 pre_expr_eq
  7 bitmap_set_bit
4 bitmap_set_bit
2 bitmap_element_link
  2 bitmap_element_link
1 bitmap_element_allocate
  1 bitmap_element_allocate
  6 bitmap_insert_into_set_1
  4 iterative_hash_hashval_t
4 iterative_hash_hashval_t
  2 get_expr_value_id
2 get_expr_value_id
  2 htab_find_slot
2 pre_expr_hash
  2 pre_expr_hash
  1 value_id_constant_p
1 bitmap_bit_p
  1 bitmap_bit_p
54 phi_translate_1
  35 htab_find_slot_with_hash
16 htab_find_slot_with_hash
11 vn_nary_op_eq
  8 types_compatible_p
6 useless_type_conversion_p
  4 useless_type_conversion_p
  2 get_alias_set
2 get_alias_set
2 types_compatible_p
  2 vn_nary_op_eq
  1 expressions_equal_p
1 expressions_equal_p
 

[Bug middle-end/39999] gcc 4.4.0 compiles in infinite loop

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-01 22:49 ---
So GCC hangs and not the compiled code?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


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

[Bug c++/40000] New: [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks, can't you make it better?

[pinskia at gcc dot gnu dot org]

+++ This bug was initially created as a clone of Bug #5 +++

[C89 regression] C++ has too much stuff.  Make it smaller.

Release:
C++98


-- 
   Summary: [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks,
can't you make it better?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid, accepts-invalid, missed-optimization,
documentation, diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
 BugsThisDependsOn: 5


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

[Bug c++/40000] [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks, can't you make it better?

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-01 22:51 ---


*** This bug has been marked as a duplicate of 5 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/5] [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks, can't you make it better?

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2009-05-01 22:51 
---
*** Bug 4 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug c++/40000] [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks, can't you make it better?

[fang at csl dot cornell dot edu]

--- Comment #2 from fang at csl dot cornell dot edu  2009-05-01 22:57 
---

Congratulations, winner!
You are the 40,000th visitor!
Click here to claim your prize!


(or just mark as a dup of pr3 :P)  Woo-hoo!


-- 


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

[Bug middle-end/39999] gcc 4.4.0 compiles in infinite loop

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-05-01 
23:00 ---
On Linux and Darwin, it seems to be constantly allocating memory and never
finishes the compilation (at least over 10+ minutes). The example code compiles
instantly at -O1. I've not discovered any -O2 switches that can be disabled
which would eliminate the problem.


-- 


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

[Bug regression/40001] New: [4.5 Regression] r1467817 broke libgloss build for SPU

[tsmigiel at gcc dot gnu dot org]

The following test case, simplified from newlib's libgloss/spu/sbrk.c, breaks a
combined SPU build.  This test case works if sp_r1 is declared globally.  

It fails at the new assert in cfgexpand.c:expand_one_var() which tests
DECL_HARD_REGISTER.

void *
sbrk (unsigned int increment)
{
  volatile register
__attribute__ ((__spu_vector__)) unsigned int sp_r1 __asm__ ("1");
  unsigned int sps;

  sps = __builtin_spu_extract (sp_r1, 0);
  if (sps - 4096 >= increment)
return 0;
  else
return ((void *) -1);
}


-- 
   Summary: [4.5 Regression] r1467817 broke libgloss build for SPU
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsmigiel at gcc dot gnu dot org
GCC target triplet: spu-*-*


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

[Bug java/39940] [4.5 Regression] Bootstrap failure in libjava on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #19 from dominiq at lps dot ens dot fr  2009-05-01 23:09 ---
The ICE is also produced by prev-gcc/jc1

[ibook-dhum] bug/java_test% /opt/gcc/i686-darwin/prev-gcc/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -quiet -mmacosx-version-min=10.5.6
-mtune=generic -O2 -Wno-deprecated -fencoding=UTF-8 -fbootstrap-classes -fjni
-findirect-dispatch -fno-indirect-classes -fno-common
-fbootclasspath=/opt/gcc/_gcc_clean/libjava/classpath/lib/
-fdump-tree-all-details
gnu/CORBA/Poa/gnuPOA.java: In class 'gnu.CORBA.Poa.gnuPOA$RefTemplate':
gnu/CORBA/Poa/gnuPOA.java: In constructor '(gnu.CORBA.Poa.gnuPOA)':
In file included from :0:
gnu/CORBA/Poa/gnuPOA.java:0: error: type mismatch in indirect reference
struct java.lang.String[]

void

# VUSE <.MEM_11>
#slot#8#31_225 = #ref#5#2_135->length;

gnu/CORBA/Poa/gnuPOA.java:0: internal compiler error: verify_stmts failed


-- 


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

[Bug testsuite/40002] New: Testsuite not finding libc headers with cross builds and only previous version of GCC installed

[pinskia at gcc dot gnu dot org]

I have built a 4.4.0 version of GCC and built newlib with that version and
installed it in say /MYPREFIX and then go and try to build 4.5.0.  I then build
GCC with the same /MYPREFIX but not a combined build, the testsuite is not able
to find the libc headers.

I don't know if this a regression because this is the first time I hit it and I
just happened to build 4.5 and was getting many failures this way.

An example of a failure is:
Executing on host: /home/apinski/src/local/gcc/objdir-spu/gcc/xgcc
-B/home/apinski/src/local/gcc/objdir-spu/gcc/   -O0  -w -c  -o 990625-1.o
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/990625-1.c   
(timeout = 300)
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/990625-1.c:2:
fatal error: string.h: No such file or directory^M
compilation terminated.^Mcompiler exited with status 1
output is:
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/990625-1.c:2:
fatal error: string.h: No such file or directory^Mcompilation terminated.^M

FAIL: gcc.c-torture/compile/990625-1.c  -O0  (test for excess errors)Excess
errors:


-- 
   Summary: Testsuite not finding libc headers with cross builds and
only previous version of GCC installed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug regression/40001] [4.5 Regression] r146817 broke libgloss build for SPU

[matz at gcc dot gnu dot org]

--- Comment #1 from matz at gcc dot gnu dot org  2009-05-02 02:34 ---
The assert triggers because of a real pre-existing bug.  local variables
with DECL_HARD_REGISTER set must not be put into SSA form.  is_gimple_reg
has to return false for them.  It doesn't anymore since some changes by richi
(CCed), I think.

Te update_address_taken pass sets DECL_GIMPLE_REG_P on the sp_r1 variable.
This is because of the special handling of vector modes.  But it doesn't take
into account variables which can't be gimple_reg for other reasons than simply
being of wrong type.

I think the 2009-03-31 change in is_gimple_reg that moved the DECL_GIMPLE_REG_P
handling earlier might be the cause.  But fixing it there
probably is not enough, it's better to not set DECL_GIMPLE_REG_P at all
on this VAR_DECL.

The same is true for volatile decl (in this example it has a hardreg _and_
is volatile even), which also seems to be ignored in the address_taken
pass.

This whole business of special-casing COMPLEX_TYPE and VECTOR_TYPE regarding
gimple regs seems highly dubious to me.  The different places setting this
flag freely use a random mixture of tests on
  !TREE_THIS_VOLATILE (t)
and/or
  (TREE_CODE (t) == VAR_DECL && !DECL_HARD_REGISTER (t))
and/or
  !needs_to_live_in_memory (t))
or sometimes nothing at all.  In fact at least all three of these tests
are required everywhere, except where it's clear that we just created a 
completely new temporary.

Meanwhile the immediate problem can be fixed by the below patch:

Index: tree-ssa.c
===
--- tree-ssa.c  (Revision 147044)
+++ tree-ssa.c  (Arbeitskopie)
@@ -1573,7 +1573,10 @@ execute_update_addresses_taken (bool do_
if (!DECL_GIMPLE_REG_P (var)
&& !bitmap_bit_p (not_reg_needs, DECL_UID (var))
&& (TREE_CODE (TREE_TYPE (var)) == COMPLEX_TYPE
-   || TREE_CODE (TREE_TYPE (var)) == VECTOR_TYPE))
+   || TREE_CODE (TREE_TYPE (var)) == VECTOR_TYPE)
+   && !TREE_THIS_VOLATILE (var)
+   && (TREE_CODE (var) == VAR_DECL && !DECL_HARD_REGISTER (var))
+   && !needs_to_live_in_memory (var))
  {
DECL_GIMPLE_REG_P (var) = 1;
mark_sym_for_renaming (var);


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
Summary|[4.5 Regression] r1467817   |[4.5 Regression] r146817
   |broke libgloss build for SPU|broke libgloss build for SPU


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

[Bug c/40003] New: apparent spurious uninitialized read from r147052 on integer code

[regehr at cs dot utah dot edu]

See below.  The output at -O0 looks good.  At -O3 the wrong result is printed
and valgrind reports a read of uninitialized memory.

reg...@john-home:~/volatile/tmp160$ current-gcc -O0 -Wall small.c -o small
reg...@john-home:~/volatile/tmp160$ valgrind ./small
==26152== Memcheck, a memory error detector.
==26152== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==26152== Using LibVEX rev 1804, a library for dynamic binary translation.
==26152== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==26152== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==26152== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==26152== For more details, rerun with: -v
==26152== 
checksum = 0
==26152== 
==26152== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==26152== malloc/free: in use at exit: 0 bytes in 0 blocks.
==26152== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==26152== For counts of detected errors, rerun with: -v
==26152== All heap blocks were freed -- no leaks are possible.
reg...@john-home:~/volatile/tmp160$ current-gcc -O3 -Wall small.c -o small
reg...@john-home:~/volatile/tmp160$ valgrind ./small
==26158== Memcheck, a memory error detector.
==26158== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==26158== Using LibVEX rev 1804, a library for dynamic binary translation.
==26158== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==26158== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==26158== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==26158== For more details, rerun with: -v
==26158== 
==26158== Use of uninitialised value of size 4
==26158==at 0x8048553: main (in /home/regehr/volatile/tmp160/small)
checksum = E9
==26158== 
==26158== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1)
==26158== malloc/free: in use at exit: 0 bytes in 0 blocks.
==26158== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==26158== For counts of detected errors, rerun with: -v
==26158== All heap blocks were freed -- no leaks are possible.
reg...@john-home:~/volatile/tmp160$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r147052-install
--program-prefix=r147052- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090502 (experimental) (GCC) 
reg...@john-home:~/volatile/tmp160$ cat small.c
#include 
#include 

uint8_t crc32_tab[256];
uint32_t crc32_context;

#define safe_mod_macro_int16_t_s_s(si1,si2) \
  (int16_t)(si2)) == ((int16_t)0)) || int16_t)(si1)) == (INT16_MIN)) &&
(((int16_t)(si2)) == ((int16_t)-1 \
  ? ((int16_t)(si1)) \
  : (((int16_t)(si1)) % ((int16_t)(si2

static int16_t
safe_mod_func_int16_t_s_s (int16_t _si1, int16_t _si2)
{
  return safe_mod_macro_int16_t_s_s(_si1,_si2);
}

#define safe_mod_macro_int64_t_s_s(si1,si2) \
  (int64_t)(si2)) == ((int64_t)0)) || int64_t)(si1)) == (INT64_MIN)) &&
(((int64_t)(si2)) == ((int64_t)-1 \
  ? ((int64_t)(si1)) \
  : (((int64_t)(si1)) % ((int64_t)(si2

static int64_t
safe_mod_func_int64_t_s_s (int64_t _si1, int64_t _si2)
{
  return safe_mod_macro_int64_t_s_s(_si1,_si2);
}

static void 
crc32_gentab (void)
{
uint32_t crc;
const uint32_t poly = 0xEDB88320UL;
int i, j;

for (i = 0; i < 256; i++) {
crc = i;
for (j = 8; j > 0; j--) {
if (crc & 1) {
crc = (crc >> 1) ^ poly;
} else {
crc >>= 1;
}
}
crc32_tab[i] = crc;
}
}

static void 
crc32_byte (uint8_t b) {
crc32_context = 
((crc32_context >> 8) & 0x00FF) ^ 
crc32_tab[(crc32_context ^ b) & 0xFF];
}

static void 
crc32_8bytes (uint64_t val)
{
crc32_byte ((val>>0) & 0xff);
crc32_byte ((val>>8) & 0xff);
crc32_byte ((val>>16) & 0xff);
crc32_byte ((val>>24) & 0xff);
crc32_byte ((val>>32) & 0xff);
crc32_byte ((val>>40) & 0xff);
crc32_byte ((val>>48) & 0xff);
crc32_byte ((val>>56) & 0xff);
}

static inline void
platform_main_end(uint32_t crc)
{
printf ("checksum = %X\n", crc);
}

int8_t g_3 = 1;
volatile uint8_t g_98;
uint8_t g_99;

int32_t func_10 (int32_t p_11);
int32_t func_10 (int32_t p_11)
{
  return g_99;
}

int64_t func_4 (void);
int64_t func_4 (void)
{
  if (safe_mod_func_int16_t_s_s
  (((safe_mod_func_int64_t_s_s (1, g_3)) == g_3), func_10 (1)))
g_98;
  else
return g_98;
  return 1;
}

int main (void)
{
  crc32_gentab ();
  func_4 ();
  crc32_8bytes (g_99);
  platform_main_end (crc32_context);
  return 0;
}


-- 
   Summary: apparent spurious uninitialized read from r147052 on
integer code
   Product: gcc
   Version: unknown
Status

[Bug c/40003] apparent spurious uninitialized read from r147052 on integer code

[regehr at cs dot utah dot edu]

--- Comment #1 from regehr at cs dot utah dot edu  2009-05-02 05:47 ---
Created an attachment (id=17790)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17790&action=view)
preprocessed failure-inducing input


-- 


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