[Bug c++/41985] New: Internal compiler error reported.

[philippe dot hoogvorst at neuf dot fr]

=
>uname -a
Linux saturne 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 i686 GNU/Linux
=
>cat check-pshuf.cpp
typedef unsigned __attribute__((vector_size(16),aligned(16))) v4ui ;
int main()
{

v4ui A ; unsigned *a = ((unsigned *)(&A)) ;
v4ui S ; unsigned *s = ((unsigned *)(&S)) ;

asm( "pshufd   $0x00,%1,%0" : "=x"(A) : "g"(S) );

asm( "pshufd   $0x55,%1,%&" : "=x"(A) : "g"(S) );


}
=
>g++ -msse2  -v -save-temps check-pshuf.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-5'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-5) 
COLLECT_GCC_OPTIONS='-msse2' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.4/cc1plus -E -quiet -v -D_GNU_SOURCE
check-pshuf.cpp -msse2 -mtune=generic -fpch-preprocess -o check-pshuf.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.4/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.3
 /usr/include/c++/4.3/i486-linux-gnu
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.4/include
 /usr/lib/gcc/i486-linux-gnu/4.3.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-msse2' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.4/cc1plus -fpreprocessed check-pshuf.ii -quiet
-dumpbase check-pshuf.cpp -msse2 -mtune=generic -auxbase check-pshuf -version
-o check-pshuf.s
GNU C++ (Debian 4.3.4-5) version 4.3.4 (i486-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.1, MPFR version
2.4.1-p2.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64379
Compiler executable checksum: 1f1d2eae96d81d3f1eb06cc899abe620
check-pshuf.cpp: In function 'int main()':
check-pshuf.cpp:13: internal compiler error: in get_some_local_dynamic_name, at
config/i386/i386.c:8778
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
=


-- 
   Summary: Internal compiler error reported.
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot hoogvorst at neuf dot fr
 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=41985

[Bug c++/41986] New: incorrect execution via addition of -finline-functions

[tim dot dawborn at gmail dot com]

Compiling with "-Wall -O2" results in the correct execution of this code.
Compiling with "-Wall -O2 -finline-functions" with the code as attached, causes
the assertion to fail, which should not happen. However, if you uncomment
either of the std::cout lines in Decoder.cc or DecoderDerivs.cc and recompile
with "-Wall -O2 -finline-functions", the assertion does not fail. It appears if
you force the any of the "node" variables to be read, the assertion will not
fail (the correct execution).


-- 
   Summary: incorrect execution via addition of -finline-functions
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim dot dawborn at gmail dot com


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

[Bug c++/41986] incorrect execution via addition of -finline-functions

[tim dot dawborn at gmail dot com]

--- Comment #1 from tim dot dawborn at gmail dot com  2009-11-08 09:45 
---
Created an attachment (id=18992)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18992&action=view)
the code required to reproduce the bug

$ tar -zxf test.tgz
$ cd test
$ make clean all
$ ./main
main: Decoder.cc:22: Node* Decoder::best_equiv(Node*): Assertion
`max_node->score == max_score' failed.
Aborted


-- 


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

[Bug c/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec

[brunorex at gmail dot com]

--- Comment #4 from brunorex at gmail dot com  2009-11-08 10:28 ---
Created an attachment (id=18993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18993&action=view)
preprocessed source


-- 


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

[Bug c/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec

[brunorex at gmail dot com]

--- Comment #5 from brunorex at gmail dot com  2009-11-08 10:29 ---
Preprocessed source added.

Got this but should be normal:
gcc.exe: warning: -pipe ignored because -save-temps specified


-- 


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

[Bug target/41985] Internal compiler error reported.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-08 11:31 ---
There's a typo here:

   asm( "pshufd   $0x55,%1,%&" : "=x"(A) : "g"(S) );

%& is not valid.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |target
 Ever Confirmed|0   |1
  GCC build triplet| i486-linux-gnu |i486-linux-gnu
   GCC host triplet| i486-linux-gnu |i486-linux-gnu
 GCC target triplet| i486-linux-gnu |i486-linux-gnu
   Keywords||ice-on-invalid-code
  Known to fail||4.3.4 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-11-08 11:31:23
   date||


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

[Bug c++/41986] incorrect execution via addition of -finline-functions

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-08 11:36 ---
You seem to run afoul generic floating point equality comparison issues.
best_score possibly modifies scores and calls back to best_equiv.  Roudning
issues with the accumulation can lead to the failure.

So, we need some analysis on your part to prove this is a bug with GCC,
we're not application debuggers ;)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-11-08 12:04 ---
I can't reproduce it on i?86-linux even before the PR41928 fix.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
  Component|c   |target
 Ever Confirmed|0   |1
 GCC target triplet||i386-pc-mingw32
   Last reconfirmed|-00-00 00:00:00 |2009-11-08 12:04:35
   date||


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

[Bug rtl-optimization/41928] [4.5 Regression] segfault at gcc/bitmap.c:297

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-11-08 12:10 ---
Subject: Bug 41928

Author: rguenth
Date: Sun Nov  8 12:10:32 2009
New Revision: 154008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154008
Log:
2009-11-08  Richard Guenther  

PR rtl-optimization/41928
* loop-invariant.c (free_loop_data): If we didn't allocate
loop data do not try to free it.

* gfortran.dg/pr41928.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr41928.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-invariant.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/41928] [4.5 Regression] segfault at gcc/bitmap.c:297

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-11-08 12:10 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/41985] Internal compiler error reported.

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-11-08 13:45 ---
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00432.html


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||11/msg00432.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-08 11:31:23 |2009-11-08 13:45:24
   date||


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

[Bug tree-optimization/41987] New: [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485

[jv244 at cam dot ac dot uk]

> gfortran  -c -O1 bug.f90
bug.f90: In function ‘__colvar_methods_MOD_qparm_colvar’:
bug.f90:13:0: internal compiler error: tree check: expected class ‘constant’,
have ‘binary’ (rdiv_expr) in build_complex, at tree.c:1485
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

> cat bug.f90 
MODULE colvar_methods
  INTEGER, PARAMETER :: dp=KIND(0.0d0)
CONTAINS
  SUBROUTINE qparm_colvar(colvar,cell,subsys,particles,error)
COMPLEX(KIND=dp) :: ylm, ylm_calc, ylm_calc2
DO ii=1,n_atoms_from
   DO m = 0, l 
  ylm = 0.0_dp
  nbond = 0
  ylm = ylm/nbond
   ENDDO
ENDDO
  END SUBROUTINE qparm_colvar
END MODULE colvar_methods


-- 
   Summary: [4.5 Regression] expected class ‘constant’, have
‘binary’ (rdiv_expr) in build_complex, at tree.c:1485
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug c++/41986] incorrect execution via addition of -finline-functions

[tim dot dawborn at gmail dot com]

--- Comment #3 from tim dot dawborn at gmail dot com  2009-11-08 14:15 
---
Thanks. Your comment sparked an idea. There is no bug in the logic of the
source code itself, nor should there be any floating point differences
anywhere. There should be no floating point differences as for every two
floating point variables $a$ and $b$ which are checked for equality, before the
check happens, $a$ will be assigned the value $b$. I've refined the code needed
to replicate down a lot and will repost the bug under a more suitable heading,
as it has nothing to do with inline-functions. Sorry to waste your time :) 

Summary:
Upon further inspection, the description of this ticket is not correct. Will
re-file bug under appropriate heading. 


-- 

tim dot dawborn at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug debug/41988] New: [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)

[dominiq at lps dot ens dot fr]

Since at least revision 152615, I see the following failures on
i686-apple-darwin9 in 32 bit mode (see
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00699.html):

Running target unix
FAIL: g++.dg/debug/anonunion1.C -gdwarf-2 -g1 (internal compiler error)
FAIL: g++.dg/debug/anonunion1.C -gdwarf-2 -g1 (test for excess errors)
...
FAIL: g++.dg/debug/vartrack1.C -gdwarf-2 -g1 -O3 (internal compiler error)
FAIL: g++.dg/debug/vartrack1.C -gdwarf-2 -g1 -O3 (test for excess errors)

The ICE is:

[ibook-dhum] f90/bug% g++45
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/debug/anonunion1.C -gdwarf-2 -g1
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/debug/anonunion1.C: In function
'foo()':
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/debug/anonunion1.C:14:1: internal
compiler error: in dwarf2out_frame_debug, at dwarf2out.c:2689

Note I don't see it on powerpc-apple-darwin9.


-- 
   Summary: [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1
(internal compiler error)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-08 14:55 ---
Works for me on i?86-linux, so which target and which revision?


-- 


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

[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-11-08 15:06 ---
I guess this could be related to the fact that MPC is not linked in. But here
is the info

> gfortran -O1 -v bug.f90
Driving: gfortran -O1 -v bug.f90 -lgfortran -lm -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
--with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto
--enable-plugins
Thread model: posix
gcc version 4.5.0 20091108 (experimental) [trunk revision 154009] (GCC) 
COLLECT_GCC_OPTIONS='-O1' '-v' '-shared-libgcc' '-mtune=generic'

/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
bug.f90 -quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -O1 -version
-fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude
-o /tmp/ccMPIOE5.s
GNU Fortran (GCC) version 4.5.0 20091108 (experimental) [trunk revision 154009]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036], GMP version 4.2.2, MPFR version 2.3.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.5.0 20091108 (experimental) [trunk revision 154009]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036], GMP version 4.2.2, MPFR version 2.3.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug.f90: In function ‘__colvar_methods_MOD_qparm_colvar’:
bug.f90:13:0: internal compiler error: tree check: expected class ‘constant’,
have ‘binary’ (rdiv_expr) in build_complex, at tree.c:1485
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 GCC target triplet||x86_64-unknown-linux-gnu


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

[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-11-08 17:03 ---
This was more likely caused by HJL's stack alignment patches based on the
context of the ICE.

I had also saw this the last time I ran the testsuite on x86-darwin.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-11-08 17:03:03
   date||


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

[Bug middle-end/41963] [4.5 Regression] 177.mesa in SPEC CPU 2K is miscompiled

[uros at gcc dot gnu dot org]

--- Comment #8 from uros at gcc dot gnu dot org  2009-11-08 18:10 ---
Subject: Bug 41963

Author: uros
Date: Sun Nov  8 18:10:10 2009
New Revision: 154011

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154011
Log:
Backport from mainline:
2009-11-06  Michael Matz  

PR middle-end/41963
* tree-ssa-math-opts.c (execute_cse_reciprocals): Check all uses
of a potential reciprocal to really be reciprocals.

testsuite/ChangeLog:

Backport from mainline:
2009-11-06  Michael Matz  

PR middle-end/41963
* gcc.target/i386/pr41963.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr41963.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-math-opts.c


-- 


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

[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-11-08 18:34 ---
Reduced test case.

SUBROUTINE qparm_colvar
  COMPLEX ylm
  ylm = 0
  nbond = 0
  ylm = ylm / nbond
END SUBROUTINE qparm_colvar

EMOVE:kargl[218] gfc4x -c -O -v jj.f90
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd9.0/4.5.0/lto-wrapper
Target: i386-unknown-freebsd9.0
Configured with: ../gcc4x/configure --prefix=/usr/home/kargl/work
--enable-languages=c,fortran
Thread model: posix
gcc version 4.5.0 20091014 (experimental) [trunk revision 140508] (GCC) 
COLLECT_GCC_OPTIONS='-static' '-c' '-O' '-v' '-mtune=i386'
 /usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd9.0/4.5.0/f951 jj.f90
-quiet -dumpbase jj.f90 -mtune=i386 -auxbase jj -O -version
-fintrinsic-modules-path
/usr/home/kargl/work/lib/gcc/i386-unknown-freebsd9.0/4.5.0/finclude -o
/tmp/ccke5ZjS.s
GNU Fortran (GCC) version 4.5.0 20091014 (experimental) [trunk revision 140508]
(i386-unknown-freebsd9.0)
compiled by GNU C version 4.5.0 20091014 (experimental) [trunk revision
140508], GMP version 4.3.1, MPFR version 2.4.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.5.0 20091014 (experimental) [trunk revision 140508]
(i386-unknown-freebsd9.0)
compiled by GNU C version 4.5.0 20091014 (experimental) [trunk revision
140508], GMP version 4.3.1, MPFR version 2.4.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
jj.f90: In function 'qparm_colvar_':
jj.f90:6:0: internal compiler error: tree check: expected class 'constant',
have 'binary' (rdiv_expr) in build_complex, at tree.c:1480
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug c/41989] New: Code optimized for AMD Geode is slower than generic

[rootkit85 at yahoo dot it]

I noticed that when compiling with -march=geode the code is actually slower
than the one generated with generic options (i386 or i686).
This happens with any program, not just with dhrystone

# CFLAGS='-march=i386' ./dry.c
Dhrystones per Second:  643501 

# CFLAGS='-march=i486' ./dry.c
Dhrystones per Second:  712251 

# CFLAGS='-march=i586' ./dry.c
Dhrystones per Second:  711238

# CFLAGS='-march=i686' ./dry.c
Dhrystones per Second:  878735

# CFLAGS='-march=geode' ./dry.c
Dhrystones per Second:  684932


-- 
   Summary: Code optimized for AMD Geode is slower than generic
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rootkit85 at yahoo dot it


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

[Bug c/41989] Code optimized for AMD Geode is slower than generic

[rootkit85 at yahoo dot it]

--- Comment #1 from rootkit85 at yahoo dot it  2009-11-08 18:51 ---
Created an attachment (id=18994)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18994&action=view)
the dhrystone benchmark


-- 


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

[Bug target/41989] Code optimized for AMD Geode is slower than generic

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-11-08 18:55 ---
On which Geode is this on?  Is this with the first generation Geode or the one
AMD made?  Because if it is the latter, it is not really a Geode but a k6/k7
based processor.  


-- 


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

[Bug target/41989] Code optimized for AMD Geode is slower than generic

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-11-08 19:00 ---
Try -march=native instead.


-- 


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

[Bug libstdc++/41622] [DR 1245] [c++0x] std::hash::operator() copies its argument

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-11-08 19:06 
---
DR submitted, preview here, will be in R68:

  http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1245

Actually, the proposed resolution at the moment lacks the adjustments to the
hash and hash bits, I'll make sure they are properly
dealt with. In any case, any help with the proposed wording is much
appreciated...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
Summary|[c++0x] |[DR 1245] [c++0x]
   |std::hash::oper|std::hash::oper
   |ator() copies its argument  |ator() copies its argument


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

[Bug libstdc++/41622] [DR 1245] [c++0x] std::hash::operator() copies its argument

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-08 19:07:16
   date||


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

[Bug libstdc++/41622] [DR 1245] [c++0x] std::hash::operator() copies its argument

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED


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

[Bug target/41989] Code optimized for AMD Geode is slower than generic

[rootkit85 at yahoo dot it]

--- Comment #4 from rootkit85 at yahoo dot it  2009-11-08 19:52 ---
# cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 10
model name  : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.060
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext
3dnowext 3dnow
bogomips: 996.12
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

# CFLAGS='-march=native' ./dry.c
Dhrystones per Second:  715308


-- 


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

Re: [Bug target/41989] Code optimized for AMD Geode is slower than generic

[Andrew Pinski]

Sent from my iPhone

On Nov 8, 2009, at 11:52 AM, "rootkit85 at yahoo dot it" > wrote:





--- Comment #4 from rootkit85 at yahoo dot it  2009-11-08 19:52  
---

# cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 10
model name  : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.060
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx  
mmxext

3dnowext 3dnow


Since it has cmov this is not a real geode :).



bogomips: 996.12
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

# CFLAGS='-march=native' ./dry.c
Dhrystones per Second:  715308


--


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

[Bug target/41989] Code optimized for AMD Geode is slower than generic

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2009-11-08 19:57 ---
Subject: Re:  Code optimized for AMD Geode is slower than generic



Sent from my iPhone

On Nov 8, 2009, at 11:52 AM, "rootkit85 at yahoo dot it"
 wrote:

>
>
> --- Comment #4 from rootkit85 at yahoo dot it  2009-11-08 19:52  
> ---
> # cat /proc/cpuinfo
> processor   : 0
> vendor_id   : AuthenticAMD
> cpu family  : 5
> model   : 10
> model name  : Geode(TM) Integrated Processor by AMD PCS
> stepping: 2
> cpu MHz : 498.060
> cache size  : 128 KB
> fdiv_bug: no
> hlt_bug : no
> f00f_bug: no
> coma_bug: no
> fpu : yes
> fpu_exception   : yes
> cpuid level : 1
> wp  : yes
> flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx  
> mmxext
> 3dnowext 3dnow

Since it has cmov this is not a real geode :).


> bogomips: 996.12
> clflush size: 32
> cache_alignment : 32
> address sizes   : 32 bits physical, 32 bits virtual
> power management:
>
> # CFLAGS='-march=native' ./dry.c
> Dhrystones per Second:  715308
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
>


-- 


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

[Bug c/41990] New: Incorrect stack setup on x86_64

[cube at cubidou dot net]

Provided a somewhat specific set of local variables, and as long as the code of
the function doesn't make any other function calls, gcc will decrease %rsp but
an incorrect and too small value.  This leads to local variables being
corrupted when the execution is interrupted;  this happens notably in the
kernel where interrupts use the stack of the thread they interrupted.

The file that I will hopefully be able to attach to that report demonstrates
the issue, if you look at the assembler output.  With the function call
commented out, gcc sets up the stack that way:

movq%rsp, %rbp
subq$152, %rsp

and later access one of the local variables with:

movl$0, -272(%rbp,%rax,4)

When the function call is uncommented, the subq instruction here will correctly
substract 272 to %rsp.

I've compiled a 4.4.2 for the sole purpose of doing this bug report;  NetBSD
comes with 4.1.3 and that's where the bug was initially spotted.


-- 
   Summary: Incorrect stack setup on x86_64
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cube at cubidou dot net
 GCC build triplet: x86_64-unknown-netbsd4.99.60
  GCC host triplet: x86_64-unknown-netbsd4.99.60
GCC target triplet: x86_64-unknown-netbsd4.99.60


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

--- Comment #1 from cube at cubidou dot net  2009-11-08 20:27 ---
Created an attachment (id=18995)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18995&action=view)
Test case

This very simple C file will expose the bug.  In the assembler output, see how
only 152 is substracted to %rsp when the space taken by the variables
themselves is already 268 bytes.  Uncommenting the function call will make gcc
compute the correct value.


-- 


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

Re: [Bug c/41990] New: Incorrect stack setup on x86_64

[Andrew Pinski]

The x86_64 abi includes a red zone. So I doubt this a bug in gcc  
unless netbsd's abi does not match what gcc does.


Sent from my iPhone

On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net" > wrote:


Provided a somewhat specific set of local variables, and as long as  
the code of
the function doesn't make any other function calls, gcc will  
decrease %rsp but

an incorrect and too small value.  This leads to local variables being
corrupted when the execution is interrupted;  this happens notably  
in the

kernel where interrupts use the stack of the thread they interrupted.

The file that I will hopefully be able to attach to that report  
demonstrates
the issue, if you look at the assembler output.  With the function  
call

commented out, gcc sets up the stack that way:

   movq%rsp, %rbp
   subq$152, %rsp

and later access one of the local variables with:

   movl$0, -272(%rbp,%rax,4)

When the function call is uncommented, the subq instruction here  
will correctly

substract 272 to %rsp.

I've compiled a 4.4.2 for the sole purpose of doing this bug  
report;  NetBSD

comes with 4.1.3 and that's where the bug was initially spotted.


--
  Summary: Incorrect stack setup on x86_64
  Product: gcc
  Version: 4.4.2
   Status: UNCONFIRMED
 Severity: major
 Priority: P3
Component: c
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: cube at cubidou dot net
GCC build triplet: x86_64-unknown-netbsd4.99.60
 GCC host triplet: x86_64-unknown-netbsd4.99.60
GCC target triplet: x86_64-unknown-netbsd4.99.60


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

[Bug c/41990] Incorrect stack setup on x86_64

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-11-08 20:29 ---
Subject: Re:   New: Incorrect stack setup on x86_64

The x86_64 abi includes a red zone. So I doubt this a bug in gcc  
unless netbsd's abi does not match what gcc does.

Sent from my iPhone

On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net"
 wrote:

> Provided a somewhat specific set of local variables, and as long as  
> the code of
> the function doesn't make any other function calls, gcc will  
> decrease %rsp but
> an incorrect and too small value.  This leads to local variables being
> corrupted when the execution is interrupted;  this happens notably  
> in the
> kernel where interrupts use the stack of the thread they interrupted.
>
> The file that I will hopefully be able to attach to that report  
> demonstrates
> the issue, if you look at the assembler output.  With the function  
> call
> commented out, gcc sets up the stack that way:
>
>movq%rsp, %rbp
>subq$152, %rsp
>
> and later access one of the local variables with:
>
>movl$0, -272(%rbp,%rax,4)
>
> When the function call is uncommented, the subq instruction here  
> will correctly
> substract 272 to %rsp.
>
> I've compiled a 4.4.2 for the sole purpose of doing this bug  
> report;  NetBSD
> comes with 4.1.3 and that's where the bug was initially spotted.
>
>
> -- 
>   Summary: Incorrect stack setup on x86_64
>   Product: gcc
>   Version: 4.4.2
>Status: UNCONFIRMED
>  Severity: major
>  Priority: P3
> Component: c
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: cube at cubidou dot net
> GCC build triplet: x86_64-unknown-netbsd4.99.60
>  GCC host triplet: x86_64-unknown-netbsd4.99.60
> GCC target triplet: x86_64-unknown-netbsd4.99.60
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
>


-- 


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

--- Comment #3 from cube at cubidou dot net  2009-11-08 20:37 ---
Subject: Re:  Incorrect stack setup on x86_64

On Sun, Nov 08, 2009 at 08:29:44PM -, pinskia at gmail dot com wrote:
> 
> 
> --- Comment #2 from pinskia at gmail dot com  2009-11-08 20:29 ---
> Subject: Re:   New: Incorrect stack setup on x86_64
> 
> The x86_64 abi includes a red zone. So I doubt this a bug in gcc  
> unless netbsd's abi does not match what gcc does.

152 is too small even for the total size of the local variables (268 in
the attached test case).  How a red zone can even be considered in that
case?

> On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net"
>   > wrote:
> 
> > Provided a somewhat specific set of local variables, and as long as  
> > the code of
> > the function doesn't make any other function calls, gcc will  
> > decrease %rsp but
> > an incorrect and too small value.  This leads to local variables being
> > corrupted when the execution is interrupted;  this happens notably  
> > in the
> > kernel where interrupts use the stack of the thread they interrupted.
> >
> > The file that I will hopefully be able to attach to that report  
> > demonstrates
> > the issue, if you look at the assembler output.  With the function  
> > call
> > commented out, gcc sets up the stack that way:
> >
> >movq%rsp, %rbp
> >subq$152, %rsp
> >
> > and later access one of the local variables with:
> >
> >movl$0, -272(%rbp,%rax,4)
> >
> > When the function call is uncommented, the subq instruction here  
> > will correctly
> > substract 272 to %rsp.
> >
> > I've compiled a 4.4.2 for the sole purpose of doing this bug  
> > report;  NetBSD
> > comes with 4.1.3 and that's where the bug was initially spotted.
> >
> >
> > -- 
> >   Summary: Incorrect stack setup on x86_64
> >   Product: gcc
> >   Version: 4.4.2
> >Status: UNCONFIRMED
> >  Severity: major
> >  Priority: P3
> > Component: c
> >AssignedTo: unassigned at gcc dot gnu dot org
> >ReportedBy: cube at cubidou dot net
> > GCC build triplet: x86_64-unknown-netbsd4.99.60
> >  GCC host triplet: x86_64-unknown-netbsd4.99.60
> > GCC target triplet: x86_64-unknown-netbsd4.99.60
> >
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
> >
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

--- Comment #4 from cube at cubidou dot net  2009-11-08 20:38 ---
Subject: Re:  Incorrect stack setup on x86_64

On Sun, Nov 08, 2009 at 08:37:25PM -, cube at cubidou dot net wrote:
[...]
> 152 is too small even for the total size of the local variables (268 in

I meant 260 here.


-- 


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

--- Comment #5 from cube at cubidou dot net  2009-11-08 20:56 ---
Ok, I get it now.  Not a gcc bug, we have to compile our kernel modules with
-fno-red-zone like the rest of the kernel.

Sorry for the noise.


-- 

cube at cubidou dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/41985] Internal compiler error reported.

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-11-08 21:13 ---
Subject: Bug 41985

Author: jakub
Date: Sun Nov  8 21:12:52 2009
New Revision: 154014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154014
Log:
PR target/41985
* config/i386/i386.c (get_some_local_dynamic_name): Don't assert
function contains at least one local dynamic name.
(print_operand) : Instead output operand lossage diagnostics
here if that happens.

* gcc.target/i386/pr41985.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr41985.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/41985] Internal compiler error reported.

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-11-08 21:15 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/37290] [4.4 Regression] Endless recursion in cse_cc_succs

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-11-08 22:27 ---
Subject: Bug 37290

Author: jason
Date: Sun Nov  8 22:27:39 2009
New Revision: 154018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154018
Log:
PR c++/37290
* pt.c (tsubst) [TYPEOF_TYPE]: Set cp_unevaluated_operand.

Added:
trunk/gcc/testsuite/g++.dg/ext/typeof11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/41989] Code optimized for AMD Geode is slower than generic

[rootkit85 at yahoo dot it]

--- Comment #6 from rootkit85 at yahoo dot it  2009-11-08 22:34 ---
(In reply to comment #5)
> Subject: Re:  Code optimized for AMD Geode is slower than generic
> 
> 
> 
> Sent from my iPhone
> 
> On Nov 8, 2009, at 11:52 AM, "rootkit85 at yahoo dot it"
>   > wrote:
> 
> >
> >
> > --- Comment #4 from rootkit85 at yahoo dot it  2009-11-08 19:52  
> > ---
> > # cat /proc/cpuinfo
> > processor   : 0
> > vendor_id   : AuthenticAMD
> > cpu family  : 5
> > model   : 10
> > model name  : Geode(TM) Integrated Processor by AMD PCS
> > stepping: 2
> > cpu MHz : 498.060
> > cache size  : 128 KB
> > fdiv_bug: no
> > hlt_bug : no
> > f00f_bug: no
> > coma_bug: no
> > fpu : yes
> > fpu_exception   : yes
> > cpuid level : 1
> > wp  : yes
> > flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx  
> > mmxext
> > 3dnowext 3dnow
> 
> Since it has cmov this is not a real geode :).

What has to do CMOV with Geode? It isn't an Athlon:

# CFLAGS='-march=k6' ./dry.c
Dhrystones per Second:  757576

# CFLAGS='-march=athlon' ./dry.c
Dhrystones per Second:  764526

# CFLAGS='-march=athlon-xp' ./dry.c
Dhrystones per Second:  758725


-- 


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

[Bug c++/40315] template instantiation fails when using const typename

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-11-08 23:06 ---
Actually, I'm not so sure:

template
struct A
{
  typedef A arr[3];
};

template
void f(const typename A::arr) { }

template void f(const A::arr); // #1

template 
struct B
{
  void g(T);
};

template 
void B::g(const T) { } // #2 

it seems to me that either #1 is well-formed, or #2 is, though it might make
sense to recompute the function type from the parameter type...in any case, I'm
opening a DR about this.


-- 


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

[Bug c++/37920] ICE (segv) with typename typeof in local struct

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-11-08 23:11 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/17910] wrong order of static initialization

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-11-08 23:24 ---
14.7.4.1 [temp.point] says:

...the point of instantiation for such a specialization immediately follows the
namespace scope declaration or definition that refers to the specialization.

So, the point of instantiation for B::B(), and thus for B::a, is
*after* the declaration of b, and therefore there's no reason to expect
B::a to be initialized before b.

If you need B::a to be initialized before b, you can provide an explicit
instantiation:

template A B::a;
B b;


-- 


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

[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-11-08 23:19 ---
(In reply to comment #2)
> I guess this could be related to the fact that MPC is not linked in. But here
> is the info

I think Joost is correct about the missing MPC library.  I just
installed MPC-0.8 and rebuilt gcc.  THe problem has disappeared.

Kaveh intends to make mpc a mandatory requirement before 4.5.0
is released.  Do we simply put his into a waiting status?  Note,
the problem does not appear on 4.4.x.


-- 


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

[Bug c++/10112] static data member is not correctly initialised

[jason at gcc dot gnu dot org]

--- Comment #16 from jason at gcc dot gnu dot org  2009-11-08 23:27 ---
It's not clear to me that there's anything to be fixed; the reduced testcase in
this PR works, and the testcase for 17910 seems to work the way the point of
instantiation rules say it ought to.  And people can always use explicit
instantiation directives to control order of initialization.


-- 


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

[Bug c++/40315] template instantiation fails when using const typename

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-11-08 23:32 ---
Created an attachment (id=18996)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18996&action=view)
patch

Here's a patch that fixes the testcase and passes regression testing, but I
don't think it's the right way to go.


-- 


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

[Bug c++/40315] template instantiation fails when using const typename

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-11-08 23:41 
---
Jason, the extra const in the library code is definitely unintended, I'm going
to remove it anyway.


-- 


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

[Bug java/41991] New: gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

[howarth at nitro dot med dot uc dot edu]

The gcj compiler in 4.4.x and gcc trunk segfaults when compiling sample java
code like...

public class testme { 
  public static void main(String args[]){ 
System.out.println("Hello"); 
  } 
} 

with "gcj --main=testme -O testme.java" with a failure of...

gcj: Internal error: Abort trap (program ecj1)
Please submit a full bug report.
See  for instructions.

This is for gcc built with...

../gcc-4.5-20091107/configure --prefix=/sw --prefix=/sw/lib/gcc4.5
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --with-arch=nocona --with-tune=generic
--build=i686-apple-darwin9 --host=i686-apple-darwin9
--target=i686-apple-darwin9

where ftp://sourceware.org/pub/java/ecj-latest.jar is used in the toplevel of
the gcc build to provide ecj1.


-- 
   Summary: gcj segfaults on i686-apple-darwin* and x86_64-apple-
darwin*
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686/x86_64-apple-darwin*
  GCC host triplet: i686/x86_64-apple-darwin*
GCC target triplet: i686/x86_64-apple-darwin*


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

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-11-09 
00:44 ---
A backtrace of the segfault under i686-apple-darwin10 for gcc trunk is...

gdb /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1
...
(gdb) r testme.java
-fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5
-ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccCFc8VX.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccBrG88S.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1
testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar
-fsource=1.5 -ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccCFc8VX.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccBrG88S.jar
Reading symbols for shared libraries .+. done

Program received signal SIGABRT, Aborted.
0x94cc2e42 in __kill ()
(gdb) bt
#0  0x94cc2e42 in __kill ()
#1  0x94cc2e34 in kill$UNIX2003 ()
#2  0x94d3523a in raise ()
#3  0x94d41679 in abort ()
#4  0x038de502 in _Jv_Throw (value=) at ../../../gcc-4.5-20091107/libjava/exception.cc:128
#5  0x039359bb in _ZN4java4lang5Class7forNameEJPS1_PNS0_6StringES2_
(className=, caller=) at Class.java:133
Previous frame inner to this frame (gdb could not unwind past this frame)

We don't seem to have any significant failures in the libjava testsuite for
i686-apple-darwin9/10 or x86_64-apple-darwin9/10 builds of gcc 4.4.2 or trunk
though. This problem seems unique to gcj and it is unclear if gcj is well
tested in the libjava testsuite.


-- 


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

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-11-09 
00:45 ---
(In reply to comment #1)
> A backtrace of the segfault under i686-apple-darwin10 for gcc trunk is...
> 

This should have read...

A backtrace of the segfault under i686-apple-darwin9 for gcc trunk is...


-- 


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

[Bug tree-optimization/41984] ICE from '-fno-exceptions -O -fprofile-arcs -fgraphite-identity'

[spop at gcc dot gnu dot org]

--- Comment #6 from spop at gcc dot gnu dot org  2009-11-09 01:09 ---
This works in the graphite branch that will be merged soon into trunk.

Sebastian


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41992] New: ICE on invalid dereferencing of void *

[mikulas at artax dot karlin dot mff dot cuni dot cz]

Hi

This piece of invalid code (the dereference shouldn't be there) triggers an
ICE. The crash happens on 4.3.2, 4.4.1 and 4.4.2. It happens with or without
optimizations.

static void MONITOR(void *ptr)
{
__asm__ volatile (" \n\
XORL%%ECX, %%ECX\n\
XORL%%EDX, %%EDX\n\
MONITOR \n\
"::"a"(*ptr):"cx","dx","cc","memory");
}

s.e: In function 'MONITOR':
s.e:7: warning: dereferencing 'void *' pointer
s.e:7: internal compiler error: in gimplify_expr, at gimplify.c:7074
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE on invalid dereferencing of void *
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/41993] New: [sh] ICE in create_pre_exit, at mode-switching.c:399

[iwamatsu at nigauri dot org]

Hi,
When I built gnustep-base, I got the following errors.
-
mframe.m:1250: warning: cast increases required alignment of target type
mframe.m: In function 'retframe_short':
mframe.m:863: internal compiler error: in create_pre_exit, at
mode-switching.c:399
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [obj/mframe.m.o] Error 1
-

And I tested following sample program with gcc HEAD of subversion.
-
$ cat a.c 
short retframe_short (void *rframe)
{
__builtin_return (rframe);
}
$ tools/bin/sh4-unknown-linux-gnu-gcc -c  a.c
a.c: In function 'retframe_short':
a.c:4: internal compiler error: in create_pre_exit, at mode-switching.c:399
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ tools/bin/sh4-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=tools/bin/sh4-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/yoshii/work/gcc/tools/libexec/gcc/sh4-unknown-linux-gnu/4.5.0/lto-wrapper
Target: sh4-unknown-linux-gnu
Configured with: /var/src/gcc/configure --build=x86_64-pc-linux-gnu
--target=sh4-unknown-linux-gnu --prefix=/home/yoshii/work/gcc/tools
--with-sysroot=/home/yoshii/work/gcc/sysroot --with-cpu=sh4a
--with-multilib-list=sh4a,sh4a-nofpu --disable-libgomp --disable-libmudflap
--enable-incomplete_targets --enable-libssp --enable-nls --enable-shared
--enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-c99
--enable-long-long --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20091109 (experimental) (GCC)
-

Best regards,
  Nobuhiro


-- 
   Summary: [sh] ICE in create_pre_exit, at mode-switching.c:399
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iwamatsu at nigauri dot org
GCC target triplet: sh4-unknown-linux-gnu


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

[Bug target/41989] Code optimized for AMD Geode is slower than generic

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-11-09 03:31 ---
-march=geode disables cmov because the real geode does not have cmov :).

This is why it is much slower.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/36503] x86 can use x >> -y for x >> 32-y

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2009-11-09 07:38 ---
(In reply to comment #5)
> bt with a memory object and a register index will _not_ truncate the argument:

Actually, we avoid bt with memory objects just because of this (handling of
memory op is not consistent with register op). Please look at i386.md.


-- 


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