[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- Comment #14 from burnus at gcc dot gnu dot org 2008-06-08 07:49 --- Subject: Bug 35830 Author: burnus Date: Sun Jun 8 07:48:53 2008 New Revision: 136554 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136554 Log: 2008-06-08 Tobias Burnus [EMAIL PROTECTED] PR fortran/35830 * resolve.c (resolve_symbol): Copy more attributes for PROCEDUREs with interfaces. 2008-06-08 Tobias Burnus [EMAIL PROTECTED] PR fortran/35830 * proc_decl_13.f90: New. * proc_decl_14.f90: New. * proc_decl_15.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_13.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_14.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- Comment #15 from burnus at gcc dot gnu dot org 2008-06-08 07:50 --- FIXED on the trunk (4.4.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/36463] New: [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
On i686-apple-darwin9 with revision 136554, I get the following ICEs on the codes from pr35971 and the two codes from http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4 (see pr36322): pr35971.f90: In function 'gp': pr35971.f90:46: internal compiler error: in expand_expr_real_1, at expr.c:7264 This ICEs replace the errors: pr35971.f90:46.25: gp = get_funloc(make_mess,aux) 1 Error: Type/rank mismatch in argument 'x' at (1) pr35971.f90:82.16: use other_fun 1 Fatal Error: Can't open module file 'other_fun.mod' for reading at (1): No such file or directory -- Summary: [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=36463
[Bug fortran/36462] KIND argument in INDEX results in wrong code
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-08 11:20 --- Note: Initially found by James Van Buskirk: http://groups.google.com/group/comp.lang.fortran/msg/e90575a5a6a50e35 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-06-08 01:22:20 |2008-06-08 11:20:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
[Bug c++/36464] New: Segfault when using precompiled headers
To be honest, I don't know what some of these bug fields mean (triplet??), so if you need more info please let me know. I am trying to use precompiled headers to speed up my development time when using wx-widgets. All of my source files crash when attempting to compile any of them Header file --- $cat wxprec-proxy.h #ifndef WXPREC_PROXY_H #define WXPREC_PROXY_H //This file is a workaround to a bug as //described in GCC bugzilla (id 13675) //BUG: #including a precompiled header more than once in the same unit fails #include wxprec.h #endif --- $cat wxprec.h #include wx/wx.h #include wx/image.h --- The segfault happens *every time* I use precompiled headers (I haven't tested between source files yet) wx-config output: $wx-config --cflags -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread uname output: Linux thebox 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT 2008 i686 athlon i386 GNU/Linux wxsimple header: $ cat wxsimple.h #infdef WXSIMPLE_H #define WXSIMPLE_H #include wxprec-proxy.h #endif wxsimple source: $ cat wxsimple.cpp #include wxsimple.h gcc output: gcc -c -Wall --ansi -Wno-deprecated --verbose -save-temps -g -DDEBUG `wx-config --cflags` -o wxsimple.o wxsimple.cpp Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) COLLECT_GCC_OPTIONS='-c' '-Wall' '-ansi' '-Wno-deprecated' '-v' '-save-temps' '-g' '-DDEBUG' '-I/usr/lib/wx/include/gtk2-unicode-release-2.8' '-I/usr/include/wx-2.8' '-D_FILE_OFFSET_BITS=64' '-D_LARGE_FILES' '-D__WXGTK__' '-pthread' '-o' 'wxsimple.o' '-mtune=generic' /usr/libexec/gcc/i386-redhat-linux/4.3.0/cc1plus -E -quiet -v -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_GNU_SOURCE -D_REENTRANT -DDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ wxsimple.cpp -mtune=generic -ansi -Wall -Wno-deprecated -fworking-directory -fpch-preprocess -o wxsimple.ii ignoring nonexistent directory /usr/lib/gcc/i386-redhat-linux/4.3.0/include-fixed ignoring nonexistent directory /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../i386-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/wx/include/gtk2-unicode-release-2.8 /usr/include/wx-2.8 /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0 /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/i386-redhat-linux /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward /usr/local/include /usr/lib/gcc/i386-redhat-linux/4.3.0/include /usr/include End of search list. In file included from wxsimple.cpp:2: wxsimple.h:1:2: error: invalid preprocessing directive #infdef wxprec-proxy.h:13:2: error: #endif without #if In file included from built-in:0: built-in:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. -- Summary: Segfault when using precompiled headers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mycae at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36464
[Bug c++/36464] Segfault when using precompiled headers
--- Comment #1 from mycae at yahoo dot com 2008-06-08 11:29 --- It still crashes when I write my code properly too. $ gcc -c -Wall --ansi -Wno-deprecated --verbose -save-temps -g -DDEBUG `wx-config --cflags` -o wxsimple.o wxsimple.cpp Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) COLLECT_GCC_OPTIONS='-c' '-Wall' '-ansi' '-Wno-deprecated' '-v' '-save-temps' '-g' '-DDEBUG' '-I/usr/lib/wx/include/gtk2-unicode-release-2.8' '-I/usr/include/wx-2.8' '-D_FILE_OFFSET_BITS=64' '-D_LARGE_FILES' '-D__WXGTK__' '-pthread' '-o' 'wxsimple.o' '-mtune=generic' /usr/libexec/gcc/i386-redhat-linux/4.3.0/cc1plus -E -quiet -v -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_GNU_SOURCE -D_REENTRANT -DDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ wxsimple.cpp -mtune=generic -ansi -Wall -Wno-deprecated -fworking-directory -fpch-preprocess -o wxsimple.ii ignoring nonexistent directory /usr/lib/gcc/i386-redhat-linux/4.3.0/include-fixed ignoring nonexistent directory /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../i386-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/wx/include/gtk2-unicode-release-2.8 /usr/include/wx-2.8 /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0 /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/i386-redhat-linux /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward /usr/local/include /usr/lib/gcc/i386-redhat-linux/4.3.0/include /usr/include End of search list. In file included from built-in:0: built-in:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36464
[Bug fortran/36465] New: Compilation crashes and asks me to submit a bug report
There is a simulation code that I am trying to make run faster by trying several compile optimization flags. It also uses OpenMP to utilize multiple cores. Today I got this: Driving: /home/nimar/opt/gcc-4.3.0/bin/gfortran -v -save-temps -I/home/nimar/opt/gcc-4.3.0/include -O3 -fimplicit-none -fopenmp -ftree-parallelize-loops=4 -funroll-all-loops -msse4a -march=native -fipa-pta -fipa-cp -funroll-loops -fprefetch-loop-arrays -funit-at-a-time -combine Bed_ini.f -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/nimar/build/gcc-4.3.0/configure --prefix=/home/nimar/opt/gcc-4.3.0 --with-gmp=/home/nimar/opt/gcc-4.3.0 --with-mpfr=/home/nimar/opt/gcc-4.3.0 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I/home/nimar/opt/gcc-4.3.0/include' '-O3' '-fimplicit-none' '-fopenmp' '-ftree-parallelize-loops=4' '-funroll-all-loops' '-msse4a' '-fipa-pta' '-fipa-cp' '-funroll-loops' '-fprefetch-loop-arrays' '-funit-at-a-time' '-combine' '-shared-libgcc' '-pthread' /home/nimar/opt/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 Bed_ini.f -ffixed-form -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 -mtune=core2 -quiet -dumpbase Bed_ini.f -msse4a -auxbase Bed_ini -O3 -version -fimplicit-none -fopenmp -ftree-parallelize-loops=4 -funroll-all-loops -fipa-pta -fipa-cp -funroll-loops -fprefetch-loop-arrays -funit-at-a-time -I/home/nimar/opt/gcc-4.3.0/include -fintrinsic-modules-path /home/nimar/opt/gcc-4.3.0/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o Bed_ini.s GNU F95 (GCC) version 4.3.0 (i686-pc-linux-gnu) compiled by GNU C version 4.3.0, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Bed_ini.f: In function pr9_bed: Bed_ini.f:206: internal compiler error: in get_smt_for, at tree-ssa-alias.c:3203 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I use a Makefile, but I got the same when trying: /home/nimar/opt/gcc-4.3.0/bin/gfortran -v -save-temps -I/home/nimar/opt/gcc-4.3.0/include -O3 -fimplicit-none -fopenmp -ftree-parallelize-loops=4 -funroll-all-loops -msse4a -march=native -fipa-pta -fipa-cp -funroll-loops -fprefetch-loop-arrays -funit-at-a-time -combine Bed_ini.f I am running ubuntu 8.04, x86 on a core2quad, and I compiled gcc-4.3.0 myself (along with gmp and mpfr). I have never come across sth like that before, so please tell me If I need to submit sth more. I hope these help. -- Summary: Compilation crashes and asks me to submit a bug report Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pattakosn at yahoo dot com GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36465
[Bug fortran/36459] Wrong interface use for PROCEDURE(abstr.interface_name)
--- Comment #4 from janus at gcc dot gnu dot org 2008-06-08 11:56 --- Subject: Bug 36459 Author: janus Date: Sun Jun 8 11:55:41 2008 New Revision: 136555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136555 Log: 2008-06-08 Janus Weil [EMAIL PROTECTED] PR fortran/36459 * decl.c (match_procedure_decl): Correctly recognize if the interface is an intrinsic procedure. 2008-06-08 Janus Weil [EMAIL PROTECTED] PR fortran/36459 * gfortran.dg/proc_decl_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36459
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #1 from dominiq at lps dot ens dot fr 2008-06-08 12:01 --- The code in comment #1 of PR35971 compiles without error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/36465] Compilation crashes and asks me to submit a bug report
--- Comment #1 from pattakosn at yahoo dot com 2008-06-08 12:05 --- Created an attachment (id=15729) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15729action=view) The source code and the generated .s file This is the source file that crashes and the .s file that is generated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36465
[Bug fortran/36459] Wrong interface use for PROCEDURE
--- Comment #5 from janus at gcc dot gnu dot org 2008-06-08 12:16 --- Fixed in rev 136555. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Wrong interface use for |Wrong interface use for |PROCEDURE(abstr.interface_n|PROCEDURE |ame)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36459
[Bug middle-end/36465] Compilation crashes and asks me to submit a bug report
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36465
[Bug middle-end/36465] Compilation crashes and asks me to submit a bug report
--- Comment #2 from pattakosn at yahoo dot com 2008-06-08 13:49 --- I downloaded and compiled 4.3.1 which seems to work well. However I also downloaded the latest snapshot (4.4-20080606) and I get an other bug : Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/nimar/build/2/gcc-4.4-20080606/configure --prefix=/home/nimar/opt/gcc-4.4-20080606 --with-gmp=/home/nimar/opt/gcc-4.4-20080606 --with-mpfr=/home/nimar/opt/gcc-4.4-20080606 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080606 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I/home/nimar/opt/gcc-4.4-20080606/include' '-O3' '-fimplicit-none' '-fopenmp' '-ftree-parallelize-loops=4' '-funroll-all-loops' '-msse4a' '-fipa-pta' '-fipa-cp' '-funroll-loops' '-fprefetch-loop-arrays' '-funit-at-a-time' '-combine' '-c' '-pthread' /home/nimar/opt/gcc-4.4-20080606/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 main3.f -ffixed-form -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=core2 -quiet -dumpbase main3.f -msse4a -auxbase main3 -O3 -version -fimplicit-none -fopenmp -ftree-parallelize-loops=4 -funroll-all-loops -fipa-pta -fipa-cp -funroll-loops -fprefetch-loop-arrays -funit-at-a-time -I/home/nimar/opt/gcc-4.4-20080606/include -fintrinsic-modules-path /home/nimar/opt/gcc-4.4-20080606/lib/gcc/i686-pc-linux-gnu/4.4.0/finclude -o main3.s GNU Fortran (GCC) version 4.4.0 20080606 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.4.0 20080606 (experimental), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 main3.f: In function MAIN__.omp_fn.0: main3.f:390: error: stmt (0xb7d02410) marked modified after optimization pass: omp_get_thread_num (); main3.f:390: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compile line was: /home/nimar/opt/gcc-4.4-20080606/bin/gfortran -v -save-temps -I/home/nimar/opt/gcc-4.4-20080606/include -O3 -fimplicit-none -fopenmp -ftree-parallelize-loops=4 -funroll-all-loops -msse4a -march=native -fipa-pta -fipa-cp -funroll-loops -fprefetch-loop-arrays -funit-at-a-time -combine main3.f -c The files i uploaded are no more relevant to this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36465
[Bug middle-end/36465] Compilation crashes and asks me to submit a bug report
--- Comment #3 from pattakosn at yahoo dot com 2008-06-08 14:06 --- Created an attachment (id=15730) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15730action=view) the file that the latest gfortran (4.4-20080606) fails to compile and the produced .s file This is the file relevant to the second bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36465
[Bug middle-end/36465] Compilation crashes and asks me to submit a bug report
--- Comment #4 from pattakosn at yahoo dot com 2008-06-08 14:10 --- (In reply to comment #2) I downloaded and compiled 4.3.1 which seems to work well. I am sorry, maybe I was not clear. I meant that I downloaded and compiled 4.3.1 and 4.4-20080606 and then gfortran 4.3.1 compiles my source without any failures, and the produced executable seems to run correctly. The new bug regards the latest snapshot which fails to compile my source. The files I submitted first are no longer relevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36465
[Bug middle-end/36465] Compilation crashes and asks me to submit a bug report
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-08 14:12 --- fipa-pta is known to be broken, don't use it. *** This bug has been marked as a duplicate of 29212 *** -- 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=36465
[Bug tree-optimization/29212] ICE with -fipa-pta
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-06-08 14:12 --- *** Bug 36465 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pattakosn at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
[Bug target/36466] New: internal compiler error: in choose_reload_regs, at reload1.c:6190
gcc fails to build the attached testcase with optimization levels above -O0. The problem occurs with all versions from the gcc 4.x branch. Versions gcc 3.x do not expose the problem. Note that the ICE occurs on both old-ABI and EABI. Using built-in specs. Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.0-5' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --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.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.3.1 20080523 (prerelease) (Debian 4.3.0-5) -- Summary: internal compiler error: in choose_reload_regs, at reload1.c:6190 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aurelien at aurel32 dot net GCC build triplet: arm-linux-gnueabi GCC host triplet: arm-linux-gnueabi GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466
[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190
--- Comment #1 from aurelien at aurel32 dot net 2008-06-08 14:31 --- Created an attachment (id=15731) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15731action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466
[Bug c++/35602] Bogus warning with -Wsign-conversion
--- Comment #3 from manu at gcc dot gnu dot org 2008-06-08 15:36 ---
Confirmed.
The relevant gimple dump is:
int main(int, const char* const*) (D.2050, D.2051)
{
struct stringD.2032[0] * retval.0D.2067;
struct stringD.2032[0] * D.2055;
struct stringD.2032[0] * D.2056;
long intD.5 D.2057;
struct stringD.2032 * D.2070;
struct stringD.2032 * retval.1D.2071;
struct stringD.2032 * D.2061;
struct stringD.2032 * D.2062;
long intD.5 D.2063;
long intD.5 D.2072;
long unsigned intD.7 D.2073;
intD.2 D.2076;
struct stringD.2032 * x.2D.2081;
[/home/manuel/src/pr35602.C : 27] {
struct stringD.2032 xD.2054[0][0];
struct stringD.2032 yD.2060[0];
intD.2 zD.2066[0][0];
[/home/manuel/src/pr35602.C : 17] D.2055 = xD.2054[0];
[/home/manuel/src/pr35602.C : 17] D.2056 = D.2055;
[/home/manuel/src/pr35602.C : 17] D.2057 = -1;
[/home/manuel/src/pr35602.C : 17] try
{
}
catch
{
[/home/manuel/src/pr35602.C : 17] {
register struct stringD.2032 * D.2058;
[/home/manuel/src/pr35602.C : 17] if (D.2055 != 0B)
{
[/home/manuel/src/pr35602.C : 17] D.2058 = (*D.2055)[0];
D.2068:;
[/home/manuel/src/pr35602.C : 17] D.2070 = (*D.2055)[0];
[/home/manuel/src/pr35602.C : 17] if (D.2058 == D.2070)
{
[/home/manuel/src/pr35602.C : 17] goto D.2069;
}
else
{
}
[/home/manuel/src/pr35602.C : 17] D.2058 = D.2058 + -1;
[/home/manuel/src/pr35602.C : 17] __comp_dtor (D.2058);
[/home/manuel/src/pr35602.C : 17] goto D.2068;
D.2069:;
}
else
{
}
}
}
[/home/manuel/src/pr35602.C : 17] retval.0D.2067 = D.2055;
However, the warning seems to be given by some bit_not_expr applied to long
int, whose result is implicitly converted to unsigned long. I don't know why
that is done at all.
Also, I can't see how to dump that code and check what is going on here.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-06-08 15:36:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35602
[Bug c++/35602] Bogus warning with -Wsign-conversion
--- Comment #4 from manu at gcc dot gnu dot org 2008-06-08 15:37 --- Not target/host specific. -- manu at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|alphaev56-unknown-linux-gnu | GCC host triplet|alphaev56-unknown-linux-gnu | GCC target triplet|alphaev56-unknown-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35602
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-08 15:45 --- (In reply to comment #8) HJ, are you willing to prepare and test a patch? Many thanks in advance. Sorry, I may not have time for it in the near future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug target/36424] avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization
--- Comment #3 from aesok at gcc dot gnu dot org 2008-06-08 16:08 --- Subject: Bug 36424 Author: aesok Date: Sun Jun 8 16:08:08 2008 New Revision: 136562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136562 Log: PR target/36424 * config/avr/avr.h (HARD_REGNO_RENAME_OK): Define. * config/avr/avr.c (avr_hard_regno_rename_ok): New function. * config/avr/avr-protos.h (avr_hard_regno_rename_ok): New prototype. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36424
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-06-08 16:15 ---
Subject: Bug 36218
Author: jsm28
Date: Sun Jun 8 16:14:33 2008
New Revision: 136563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136563
Log:
PR tree-optimization/36218
* Makefile.def (flags_to_pass): Add LDFLAGS_FOR_BUILD.
* Makefile.tpl (EXTRA_BUILD_FLAGS): Define.
(all prefix=build-): Pass them to build-system sub-makes.
* Makefile.in: Regenerate.
config:
* config/mh-mingw (LDFLAGS): Define.
gcc:
* configure.ac: Use LDFLAGS=${LDFLAGS_FOR_BUILD} when running
configure for the build system.
(BUILD_LDFLAGS): Define.
* configure: Regenerate.
* Makefile.in (BUILD_LDFLAGS): Define to @[EMAIL PROTECTED]
Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/config/ChangeLog
trunk/config/mh-mingw
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-06-08 16:37 --- Note that a native build should be done to verify that my patch increases the stack limit enough to fix this bug, before marking it fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug c/35635] -Wconversion problematic with bitfields
--- Comment #1 from manu at gcc dot gnu dot org 2008-06-08 16:45 --- Confirmed. Notes: foo.x = bar != 0; // only warns in C, not in C++. foo.x = bar != 0 ? 1 : 0; // warning is not a problem of bitfields but for every conditional expression, the following also warns short x = (bar != 0) ? 1 : 0; // conversion to short int from int may alter its value To fix the two last warnings, we need to look into the arguments of the conditional expression. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-08 16:45:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35635
[Bug c/35635] -Wconversion problematic with bitfields
--- Comment #2 from manu at gcc dot gnu dot org 2008-06-08 16:50 --- In C++ we have: ne_expr 0x2b627f00 type boolean_type 0x2b4fb9c0 bool public unsigned QI size integer_cst 0x2b4e87b0 constant invariant 8 unit size integer_cst 0x2b4e87e0 constant invariant 1 align 8 symtab 0 alias set -1 canonical type 0x2b4fb9c0 precision 1 min integer_cst 0x2b4e8cc0 0 max integer_cst 0x2b4e8d20 1 In C we have: ne_expr 0x2b4c4240 type integer_type 0x2b4f8540 int public SI size integer_cst 0x2b4e8a80 constant invariant 32 unit size integer_cst 0x2b4e86f0 constant invariant 4 align 32 symtab 0 alias set -1 canonical type 0x2b4f8540 precision 32 min integer_cst 0x2b4e89f0 -2147483648 max integer_cst 0x2b4e8a20 214748364\ 7 pointer_to_this pointer_type 0x2b507b40 Is there are reason for not using boolean_type internally for boolean expressions even in C? A quick hack would be to check the expression and if it boolean, just consider that the expression type is boolean_type. I have seen other bug elsewhere where not using boolean_type causes trouble... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35635
[Bug c++/36461] [c++0x] Exception throws don't use rvalue reference constructors
--- Comment #1 from s_gccbugzilla at nedprod dot com 2008-06-08 17:07 --- Created an attachment (id=15732) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15732action=view) Test Case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
[Bug c++/36461] [c++0x] Exception throws don't use rvalue reference constructors
--- Comment #2 from s_gccbugzilla at nedprod dot com 2008-06-08 17:19
---
This problem actually seems to be one of subclassing: child class rvalue
constructors invoke base class lvalue constructors!!!
I have attached an example. As is, it compiles and works. If however you throw
a Thing2 instead of Thing, you get:
[EMAIL PROTECTED]:~/Tornado/Tn/TClient/TnFOX$ g++ -o TestCPP0x -std=c++0x
TestCPP0x.cpp
TestCPP0x.cpp: In copy constructor Thing2::Thing2(const Thing2):
TestCPP0x.cpp:9: error: Thing::Thing(const Thing) is private
TestCPP0x.cpp:12: error: within this context
TestCPP0x.cpp: In function Thing2 f(bool):
TestCPP0x.cpp:23: note: synthesized method Thing2::Thing2(const Thing2)
first required here
This is despite that Thing2 defines no constructors at all apart from the
default. Ok, so I tried manually disabling the lvalue constructor in Thing2
like this:
class Thing2 : public Thing {
public:
Thing2() { }
Thing2(Thing2 o) : Thing(o) { }
private:
Thing2(const Thing2);
};
... and now I get:
[EMAIL PROTECTED]:~/Tornado/Tn/TClient/TnFOX$ g++ -o TestCPP0x -std=c++0x
TestCPP0x.cpp
TestCPP0x.cpp: In constructor Thing2::Thing2(Thing2):
TestCPP0x.cpp:9: error: Thing::Thing(const Thing) is private
TestCPP0x.cpp:15: error: within this context
In other words, the rvalue constructor in Thing2 is trying to invoke the lvalue
constructor in Thing!!! This is surely utterly wrong unless Thing has no rvalue
constructor. Our Thing class has the lvalue disabled and rvalue enabled, so GCC
is surely making a big mistake.
This is the shortest example of what went wrong with my exception throwing
problem.
There's an additional problem. If I don't specify any constructors at all for
Thing2 apart the default constructor, GCC /should/ generate synthesised ones
based on what's available in the parent classes. Unfortunately, GCC is ignoring
that the lvalue constructor has been disabled and tries to generate a lvalue
constructor anyway which is obviously doomed to failure.
GCC 3.4.1 just went into the Ubuntu repositories, so I'll try that next.
Niall
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
[Bug c++/36461] [c++0x] Exception throws don't use rvalue reference constructors
--- Comment #3 from s_gccbugzilla at nedprod dot com 2008-06-08 17:19 --- Created an attachment (id=15733) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15733action=view) Failing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
[Bug c/35701] Quieten -Wconversion warnings
--- Comment #1 from manu at gcc dot gnu dot org 2008-06-08 17:25 --- Ideally, one could just do: msp-small = (unsigned int:1) sm; Meanwhile, we will need to check that when converting to p bits that the mask is less than 2^p - 1. I wonder if we already have a function to do that. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-08 17:25:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35701
[Bug c/34389] -Wconversion produces wrong warning
--- Comment #10 from manu at gcc dot gnu dot org 2008-06-08 17:30 ---
(In reply to comment #9)
Does the patch also fix the warning for conditional expressions? For example:
short f(int cond, short x, short y)
{
return cond ? x : y;
}
No, that is a completely different issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
[Bug c/35701] Quieten -Wconversion warnings
--- Comment #2 from manu at gcc dot gnu dot org 2008-06-08 17:32 --- Anyway, this won't work at all until bug 34389 is fixed because fold with convert each operand to the target type before considering the bit_and_expr. -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34389 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35701
[Bug target/36424] avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization
--- Comment #4 from eric dot weddington at atmel dot com 2008-06-08 17:32 --- Fixed for 4.4.0. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36424
[Bug target/36467] New: [avr] Missed optimization with pointer arithmetic and mul*
From AVR Freaks forum: http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=453770#453770 Adding an offset to a pointer to a structure. If the structure size is 16, the generated code is a loop with shifts. If the structure size is 17, the generated code uses MUL* instructions and generates shorter code than when the size is 16. Command lines: avr-gcc -save-temps -Os -mmcu=atmega32 -c test.c -o test.o avr-gcc -save-temps -Os -mmcu=atmega32 -c test2.c -o test2.o See the code generation of funct(). Test cases to follow... -- Summary: [avr] Missed optimization with pointer arithmetic and mul* Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric dot weddington at atmel dot com GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
[Bug target/36467] [avr] Missed optimization with pointer arithmetic and mul*
--- Comment #1 from eric dot weddington at atmel dot com 2008-06-08 17:57 --- Created an attachment (id=15734) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15734action=view) Test case with structure size == 16. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
[Bug target/36467] [avr] Missed optimization with pointer arithmetic and mul*
--- Comment #2 from eric dot weddington at atmel dot com 2008-06-08 17:58 --- Created an attachment (id=15735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15735action=view) Test case with structure size == 17. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
[Bug target/36467] [avr] Missed optimization with pointer arithmetic and mul*
--- Comment #3 from eric dot weddington at atmel dot com 2008-06-08 18:08 --- Generated code when structure size is 16 (test.i): funct: /* prologue: function */ /* frame size = 0 */ lds r24,head mov r30,r24 clr r31 sbrc r30,7 com r31 ldi r24,4 1: lsl r30 rol r31 dec r24 brne 1b subi r30,lo8(-(qq)) sbci r31,hi8(-(qq)) ld r24,Z sbrc r24,1 std Z+1,__zero_reg__ .L3: ret Generated code when structure size is 17 (test2.i): funct: /* prologue: function */ /* frame size = 0 */ lds r24,head ldi r25,lo8(17) muls r24,r25 movw r30,r0 clr r1 subi r30,lo8(-(qq)) sbci r31,hi8(-(qq)) ld r24,Z sbrc r24,1 std Z+1,__zero_reg__ .L3: ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
[Bug target/36467] [avr] Missed optimization with pointer arithmetic and mul*
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-06-08 18:20 --- It makes sense in one respect We don't have fast shift by 4 bits and code defaults to loop for Os. Seems we should be selective as MUL is indeed shorter. Though I think gcc may be confused by our poor cost data and perhaps was alsp mislead into using shift instead of MUL. -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-08 18:20:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
[Bug c/36468] New: [LTO] ICE in force_decl_die, at dwarf2out.c:13976
$ /there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -c regex.i -o regex.o -Wall -std=gnu99 -Os -Wfatal-errors -flto -v Using built-in specs. Target: i686-linux-uclibc Configured with: /there.pentium4/toolchain_build_i686/gcc-4.4.0/configure --prefix=/there.pentium4/build_i686/staging_dir/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i686-linux-uclibc --enable-languages=c --with-sysroot=/there.pentium4/toolchain_build_i686/uClibc_dev/ --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-shared --with-gmp=/there.pentium4/toolchain_build_i686/gmp --with-mpfr=/there.pentium4/toolchain_build_i686/mpfr --disable-nls --enable-threads --disable-multilib --with-arch=pentium4 --with-tune=pentium4 --disable-libgomp --enable-libssp --without-headers Thread model: posix gcc version 4.4.0 20080529 (experimental) (lto merged with rev 136135) GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4139f7e5db3f96a1b8979facab41fd1d regex.i:10708: internal compiler error: in force_decl_die, at dwarf2out.c:13976 Please submit a full bug report, reducing. -- Summary: [LTO] ICE in force_decl_die, at dwarf2out.c:13976 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36468
[Bug libgomp/36469] New: bootstrap broken on HPUX PA
The build of libgomp fails due to the use of strtoull in env.c
HPUX-PA does not know about this function, officially. On 32-bit the function
is available but not headerwise. On 64-bit this function is not available at
all.
The following snippet added to env.c cures the issue:
Index: env.c
===
--- env.c (revision 136534)
+++ env.c (working copy)
@@ -47,6 +47,11 @@
#include limits.h
#include errno.h
+#if (defined(__hpux__) defined(__LP64__))
+#define strtoull strtoul
+#elif (defined(__hpux__) !defined(__LP64__))
+#define strtoull __strtoull
+#endif
struct gomp_task_icv gomp_global_icv = {
.nthreads_var = 1,
But I do not know if this is the right(tm) way to handle such cases or if you
prefer a configure magic part. Other libs as libstdc++ use special includes.
And I do not have a configure magic at hand.
Tests with the above in progress, on 32 and 64-bit.
Comments?
--
Summary: bootstrap broken on HPUX PA
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andreast at gcc dot gnu dot org
GCC build triplet: hppa*-hp-hpux11.11
GCC host triplet: hppa*-hp-hpux11.11
GCC target triplet: hppa*-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36469
[Bug libgomp/36469] bootstrap broken on HPUX PA
-- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-08 19:25:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36469
[Bug target/30047] Corrupt return value in specific context
--- Comment #1 from gcc at david dot osborn dot name 2008-06-08 19:55 --- Created an attachment (id=15736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15736action=view) reduced testcase This bug still exists in GCC 4.3.1. I've narrowed it down to line 183 in bits/basic_ios.tcc where it says: extern template class basic_ioschar; If you comment out this line, the code produces the correct result (12345). Otherwise it produced zero consistently. The attached testcase leaves a lot out of the iostream classes, so it may be technically invalid. But it yields that same results as the previous testcase, as well as with respect to the extern template line. Also, the std::vector in the original testcase can be replaced by an empty class with an explicit destructor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30047
[Bug c/36468] [LTO] ICE in force_decl_die, at dwarf2out.c:13976
--- Comment #1 from aldot at gcc dot gnu dot org 2008-06-08 20:00 --- Created an attachment (id=15737) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15737action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36468
[Bug target/30047] Corrupt return value in specific context
--- Comment #2 from gcc at david dot osborn dot name 2008-06-08 20:01 --- Created an attachment (id=15738) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15738action=view) compiler output This shows bad code being generated. The return value (12345) gets pushed into eax on line 77, and then is subsequently overwritten for a call to __Unwind_SjLj_Unregister. Line 85 was added by me to show how to recover the return value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30047
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #9 from mark at codesourcery dot com 2008-06-08 20:23 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
How does gcc search the right paths when GCC_EXEC_PREFIX points
to non-existent directory because gcc isn't installed? Even if
there is a GCC_EXEC_PREFIX directory, it could be a very old
gcc installation and you may search very old files, instead of
the current ones, which are just built, but not installed yet.
I don't remember all of the details of these changes.
However, the compiler historically searched the configured libdir no
matter what. This problem with having random old stuff in the place
where you're going to be installing the new compiler is not new. People
wanted that behavior for in-tree testing so that if you've already put a
new libc in libdir the compiler you're testing can find it.
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs make check
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #10 from hjl dot tools at gmail dot com 2008-06-08 20:45
---
(In reply to comment #9)
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
How does gcc search the right paths when GCC_EXEC_PREFIX points
to non-existent directory because gcc isn't installed? Even if
there is a GCC_EXEC_PREFIX directory, it could be a very old
gcc installation and you may search very old files, instead of
the current ones, which are just built, but not installed yet.
I don't remember all of the details of these changes.
However, the compiler historically searched the configured libdir no
matter what. This problem with having random old stuff in the place
where you're going to be installing the new compiler is not new. People
wanted that behavior for in-tree testing so that if you've already put a
new libc in libdir the compiler you're testing can find it.
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs make check
Can't we at least test if $(libdir)/gcc/ exists before setting it
blindly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #11 from mark at codesourcery dot com 2008-06-08 21:12 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs make check
Can't we at least test if $(libdir)/gcc/ exists before setting it
blindly?
That seems like it might work.
What is the effective default value of GCC_EXEC_PREFIX for the compiler
being tested if we don't set the variable?
Also, have you tested my suggested change to HOSTCC? If HOSTCC is
another GCC then any environment variables that affect the compiler
we're trying to test will also affect HOSTCC. It seems to me that the
best way to avoid that causing problems is to make sure that HOSTCC
sets/unsets the environment variables it needs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c++/35242] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #4 from paolo at gcc dot gnu dot org 2008-06-08 21:26 --- Subject: Bug 35242 Author: paolo Date: Sun Jun 8 21:25:49 2008 New Revision: 136569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136569 Log: /cp 2008-06-08 Paolo Carlini [EMAIL PROTECTED] PR c++/35242 * pt.c (maybe_process_partial_specialization): Check the tree returned by push_template_decl for error_mark_node. * parser.c (cp_parser_class_head): Likewise, check the tree returned by the latter. /testsuite 2008-06-08 Paolo Carlini [EMAIL PROTECTED] PR c++/35242 * g++.dg/cpp0x/vt-35242.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-35242.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35242
[Bug c++/35242] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #5 from paolo dot carlini at oracle dot com 2008-06-08 21:28 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with invalid specialization |invalid specialization of |of variadic template|variadic template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35242
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-08 22:54
---
(In reply to comment #11)
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs make check
Do you have an example to show it doesn't work if
GCC_EXEC_PREFIX isn't set. From what I can tell,
for most people, GCC_EXEC_PREFIX is equivalent to
unset since GCC_EXEC_PREFIX points to nowhere.
make check works for them, myself included. That
means that gcc testsuite can test uninstalled gcc
without setting GCC_EXEC_PREFIX. Isuggest we don't
set it and watch for fallout. We can investigate and
fix the problem when we get bug reports. Those bugs can
be assigned to me and I will fix them.
Can't we at least test if $(libdir)/gcc/ exists before setting it
blindly?
That seems like it might work.
What is the effective default value of GCC_EXEC_PREFIX for the compiler
being tested if we don't set the variable?
build_diretory/gcc/../lib/gcc/
which doesn't exist, at least for my build.
Also, have you tested my suggested change to HOSTCC? If HOSTCC is
another GCC then any environment variables that affect the compiler
we're trying to test will also affect HOSTCC. It seems to me that the
best way to avoid that causing problems is to make sure that HOSTCC
sets/unsets the environment variables it needs.
That means we have to do it whenever HOSTCC is used, including new
and old tests. I don't think it is the right fix, given that no one
has shown GCC_EXEC_PREFIX really has to be set here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #13 from mark at codesourcery dot com 2008-06-09 00:05 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs make check
Do you have an example to show it doesn't work if
GCC_EXEC_PREFIX isn't set.
Yes -- the scenario you quote above. If you want to remove the setting
of GCC_EXEC_PREFIX, you need to explain how that is going to work.
That means we have to do it whenever HOSTCC is used, including new
and old tests. I don't think it is the right fix, given that no one
has shown GCC_EXEC_PREFIX really has to be set here.
In order to properly control the test environment for the compiler just
built, all environment variables used by the compiler being tested
should be explicitly set or cleared. Otherwise, the behavior of the
tests will depend on things set in the user's environment, possibly for
their /usr/bin/gcc, which clearly makes no sense.
Unless you can find a way to localize those environment changes only to
the tested compiler (by setting/restoring them around every call to the
compiler being tested for example), HOSTCC must set/clear all the
environment variables that it uses.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #14 from hjl dot tools at gmail dot com 2008-06-09 02:28
---
(In reply to comment #13)
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs make check
Do you have an example to show it doesn't work if
GCC_EXEC_PREFIX isn't set.
Yes -- the scenario you quote above. If you want to remove the setting
of GCC_EXEC_PREFIX, you need to explain how that is going to work.
Is 3-stage bootstrap used here? How does stage 1/2/3 compilers
find those libraries and header files?
That means we have to do it whenever HOSTCC is used, including new
and old tests. I don't think it is the right fix, given that no one
has shown GCC_EXEC_PREFIX really has to be set here.
In order to properly control the test environment for the compiler just
built, all environment variables used by the compiler being tested
should be explicitly set or cleared. Otherwise, the behavior of the
tests will depend on things set in the user's environment, possibly for
their /usr/bin/gcc, which clearly makes no sense.
Will setting GCC_EXEC_PREFIX not test the just built files, but those
under GCC_EXEC_PREFIX instead?
Unless you can find a way to localize those environment changes only to
the tested compiler (by setting/restoring them around every call to the
compiler being tested for example), HOSTCC must set/clear all the
environment variables that it uses.
Doesn't it make a very hard requirement for HOSTCC? You may clear
all all environment variables for gcc 4.3 today. Someone may add a new
variable later to gcc 4.5. Then you have to go back to change all
HOSTCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c/36470] New: sizeof UTF-32 is 2 on AVR
AVR fails gcc.dg/utf32-1.c execution test.
As AVR has 16 bit int, I tried fixing this by using unsigned long for char_32.
This failed, I was surprised to find this is apparently due to incorrect size
of UTF-32 characters so that:
sizeof (U'\0')
sizeof (U'\u2029')
sizeof (U'\U00064321')
all give value of 2.
So it would seem size has been set as sizeof(int) perhaps?
I can assign 32 bit values ok - just that sizeof says they are only 16 bits.
The modified testcase using 32 bit char_32t compiles to abort(), so I figure
its not a target issue.
/** Change this to unsigned long for AVR/
typedef unsigned int char32_t;
extern void abort (void);
char32_tc0 = U'a';
char32_tc1 = U'\0';
char32_tc2 = U'\u0024';
char32_tc3 = U'\u2029';
char32_tc4 = U'\U00064321';
#define A 0x0061
#define D 0x0024
#define X 0x2029
#define Y 0x00064321
int main ()
{
if (sizeof (U'a') != sizeof (char32_t))
abort ();
if (sizeof (U'\0') != sizeof (char32_t))
abort ();
if (sizeof (U'\u0024') != sizeof (char32_t))
abort ();
if (sizeof (U'\u2029') != sizeof (char32_t))
abort ();
if (sizeof (U'\U00064321') != sizeof (char32_t))
abort ();
if (c0 != A)
abort ();
if (c1 != 0x)
abort ();
if (c2 != D)
abort ();
if (c3 != X)
abort ();
if (c4 != Y)
abort ();
}
--
Summary: sizeof UTF-32 is 2 on AVR
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
GCC host triplet: i686-pc-cygwin
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug libgomp/36471] New: omp_get_ancestor_thread_num_8 has no implicit type.
compiling trunk version 136578 failed. my $FFLAGS includes -fimplicit-none. omp_lib.f90:268.10: function omp_get_ancestor_thread_num_8 (level) 1 Error: Symbol 'omp_get_ancestor_thread_num_8' at (1) has no IMPLICIT type omp_lib.f90:281.10: function omp_get_team_size_8 (level) 1 Error: Symbol 'omp_get_team_size_8' at (1) has no IMPLICIT type make[4]: *** [omp_lib.mod] Error 1 make[4]: Leaving directory `/mnt/userfile/gcc/i95/i686-pc-linux-gnu/libgomp' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/userfile/gcc/i95/i686-pc-linux-gnu/libgomp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/userfile/gcc/i95/i686-pc-linux-gnu/libgomp' make[1]: *** [all-target-libgomp] Error 2 make[1]: Leaving directory `/mnt/userfile/gcc/i95' make: *** [all] Error 2 -- Summary: omp_get_ancestor_thread_num_8 has no implicit type. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com 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=36471
