[Bug debug/48928] [4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:113 with -O -g and decimal float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48928
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10
06:05:23 UTC ---
Author: jakub
Date: Tue May 10 06:05:20 2011
New Revision: 173606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173606
Log:
PR debug/48928
* dfp.c (decimal_to_decnumber): Handle conversion from
dconst{1,2,m1,half}.
* gcc.dg/dfp/pr48928.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr48928.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dfp.c
trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48794] [4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 06:08:23 UTC --- Author: jakub Date: Tue May 10 06:08:18 2011 New Revision: 173607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173607 Log: PR tree-optimization/48611 PR tree-optimization/48794 * tree-eh.c (remove_unreachable_handlers): Don't remove regions referenced from RESX or EH_DISPATCH arguments. * gfortran.dg/gomp/pr48611.f90: New test. * gfortran.dg/gomp/pr48794.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr48611.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr48794.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug tree-optimization/48611] [4.6/4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48611 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 06:08:23 UTC --- Author: jakub Date: Tue May 10 06:08:18 2011 New Revision: 173607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173607 Log: PR tree-optimization/48611 PR tree-optimization/48794 * tree-eh.c (remove_unreachable_handlers): Don't remove regions referenced from RESX or EH_DISPATCH arguments. * gfortran.dg/gomp/pr48611.f90: New test. * gfortran.dg/gomp/pr48794.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr48611.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr48794.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug debug/48928] [4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:113 with -O -g and decimal float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48928 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 06:20:37 UTC --- Fixed.
[Bug tree-optimization/48794] [4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 06:21:34 UTC --- Fixed.
[Bug tree-optimization/48611] [4.6/4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48611 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 06:32:04 UTC --- Author: jakub Date: Tue May 10 06:31:59 2011 New Revision: 173608 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173608 Log: PR tree-optimization/48611 PR tree-optimization/48794 * tree-eh.c (remove_unreachable_handlers): Don't remove regions referenced from RESX or EH_DISPATCH arguments. * gfortran.dg/gomp/pr48611.f90: New test. * gfortran.dg/gomp/pr48794.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/gomp/pr48611.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/gomp/pr48794.f90 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-eh.c
[Bug tree-optimization/48794] [4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 06:32:04 UTC --- Author: jakub Date: Tue May 10 06:31:59 2011 New Revision: 173608 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173608 Log: PR tree-optimization/48611 PR tree-optimization/48794 * tree-eh.c (remove_unreachable_handlers): Don't remove regions referenced from RESX or EH_DISPATCH arguments. * gfortran.dg/gomp/pr48611.f90: New test. * gfortran.dg/gomp/pr48794.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/gomp/pr48611.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/gomp/pr48794.f90 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-eh.c
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from fabien at gcc dot gnu.org 2011-05-10 08:15:17 UTC --- (In reply to comment #6) Thanks, Fabien! N.B. the svn commit message should be the ChangeLog entry (look at the svn log for any file to see what's normally done) Oups, sorry. I would be careful next time.
[Bug tree-optimization/48837] [4.4/4.5/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 08:45:56 UTC --- Author: jakub Date: Tue May 10 08:45:50 2011 New Revision: 173610 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173610 Log: Backported from mainline 2011-05-07 Zdenek Dvorak o...@ucw.cz PR tree-optimization/48837 * tree-tailcall.c (tree_optimize_tail_calls_1): Do not mark tailcalls when accumulator transformation is performed. * gcc.dg/pr48837.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr48837.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-tailcall.c
[Bug tree-optimization/48837] [4.4/4.5/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 08:47:12 UTC --- Author: jakub Date: Tue May 10 08:47:09 2011 New Revision: 173611 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173611 Log: Backported from mainline 2011-05-07 Zdenek Dvorak o...@ucw.cz PR tree-optimization/48837 * tree-tailcall.c (tree_optimize_tail_calls_1): Do not mark tailcalls when accumulator transformation is performed. * gcc.dg/pr48837.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr48837.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-tailcall.c
[Bug ada/48942] [gcc-4.6.0] opt.adb compiled error while multilib enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48942 ray linn ray_linn at hotmail dot com changed: What|Removed |Added Version|unknown |4.6.0 Severity|normal |major
[Bug ada/48943] New: [gcc-4.6.0] opt.adb compiled error while multilib enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48943 Summary: [gcc-4.6.0] opt.adb compiled error while multilib enabled Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: ray_l...@hotmail.com I am using MinGW (GCC-4.5.2 i686-pc-mingw32) to compiled a 64bit ada from GCC-4.6.0。 the configure command is as following: mkdir gcc-build cd gcc-build ../gcc-4.6.0/configure --target=x86_64-w64-mingw32 --enable-targets=all --enable-multilib --enable-64bit --prefix=/mingw32 --with-sysroot=/mingw32 --disable-shared --enable-static --enable-version-specific-runtime-libs --with-dwarf2 --enable-fully-dynamic-string --enable-languages=c,ada --disable-libgomp --enable-libada then: make all-gcc make install-gcc sucesss, no problem. make all-target-libgcc make install-target-libgcc ---sucess, lib32 and lib64 installed. make all-target-libada make install-target-libada --- sucess, lib32 and lib64 installed but when i running make all-gnattools , the compile stop with the following error: # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ CC=gcc CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes LDFLAGS=-Wl,--stack,12582912 ADAFLA GS=-gnatpg -gnata ADA_CFLAGS= INCLUDES=-I. -I.. -I../.. -I/home/beta/gcc-4.6 .0/gcc/ada -I/home/beta/gcc-4.6.0/gcc/config -I/home/beta/gcc-4.6.0/gcc/../inclu de -I/home/beta/gcc-4.6.0/gcc ADA_INCLUDES=-ID:/mingw/lib/gcc/mingw32/4.5.2/ad alib/../adainclude -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc -4.6.0/gcc/ada exeext=.exe fsrcdir=/home/beta/gcc-4.6.0/gcc srcdir=/home/b eta/gcc-4.6.0/gcc GNATMAKE=gnatmake GNATLINK=gnatlink GNATBIND=gnatbind TOOLSCASE=cross LIBGNAT= INCLUDES= \ gnatmake-re gnatlink-re make[2]: Entering directory `/home/beta/gcc-build/gcc/ada/tools' gnatmake -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude -ID:/mingw/lib/gc c/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada -u sdefault --GCC=gc c gnatmake: objects up to date. gnatmake -c -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude -ID:/mingw/lib /gcc/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada gnatmake --GCC=gc c -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmis sing-prototypes -gnatpg -gnata gcc -c -I.\ -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude -ID:/mingw/lib /gcc/mingw32/4.5.2/adalib/ -I. -IC:/msys/1.0/home/beta/gcc-4.6.0/gcc/ada -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot otypes -gnatpg -gnata -I- C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb opt.ads:120:11: warning: unrecognized pragma Ordered opt.ads:1393:11: warning: unrecognized pragma Ordered gnatmake: C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb compilation error make[2]: *** [gnatmake-re] Error 4 make[2]: Leaving directory `/home/beta/gcc-build/gcc/ada/tools' make[1]: *** [gnattools-cross] Error 2 make[1]: Leaving directory `/home/beta/gcc-build/gnattools' make: *** [all-gnattools] Error 2 I am not familiar with ada, could someone help me to check this problem. if any logs is needed just let me know.
[Bug tree-optimization/48837] [4.4/4.5/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 08:45:09 UTC --- Author: jakub Date: Tue May 10 08:45:00 2011 New Revision: 173609 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173609 Log: Backported from mainline 2011-05-07 Zdenek Dvorak o...@ucw.cz PR tree-optimization/48837 * tree-tailcall.c (tree_optimize_tail_calls_1): Do not mark tailcalls when accumulator transformation is performed. * gcc.dg/pr48837.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48837.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-tailcall.c
[Bug ada/48942] New: [gcc-4.6.0] opt.adb compiled error while multilib enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48942 Summary: [gcc-4.6.0] opt.adb compiled error while multilib enabled Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: ray_l...@hotmail.com I am using MinGW (GCC-4.5.2 i686-pc-mingw32) to compiled a 64bit ada from GCC-4.6.0。 the configure command is as following: mkdir gcc-build cd gcc-build ../gcc-4.6.0/configure --target=x86_64-w64-mingw32 --enable-targets=all --enable-multilib --enable-64bit --prefix=/mingw32 --with-sysroot=/mingw32 --disable-shared --enable-static --enable-version-specific-runtime-libs --with-dwarf2 --enable-fully-dynamic-string --enable-languages=c,ada --disable-libgomp --enable-libada then: make all-gcc make install-gcc sucesss, no problem. make all-target-libgcc make install-target-libgcc ---sucess, lib32 and lib64 installed. make all-target-libada make install-target-libada --- sucess, lib32 and lib64 installed but when i running make all-gnattools , the compile stop with the following error: # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ CC=gcc CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes LDFLAGS=-Wl,--stack,12582912 ADAFLA GS=-gnatpg -gnata ADA_CFLAGS= INCLUDES=-I. -I.. -I../.. -I/home/beta/gcc-4.6 .0/gcc/ada -I/home/beta/gcc-4.6.0/gcc/config -I/home/beta/gcc-4.6.0/gcc/../inclu de -I/home/beta/gcc-4.6.0/gcc ADA_INCLUDES=-ID:/mingw/lib/gcc/mingw32/4.5.2/ad alib/../adainclude -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc -4.6.0/gcc/ada exeext=.exe fsrcdir=/home/beta/gcc-4.6.0/gcc srcdir=/home/b eta/gcc-4.6.0/gcc GNATMAKE=gnatmake GNATLINK=gnatlink GNATBIND=gnatbind TOOLSCASE=cross LIBGNAT= INCLUDES= \ gnatmake-re gnatlink-re make[2]: Entering directory `/home/beta/gcc-build/gcc/ada/tools' gnatmake -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude -ID:/mingw/lib/gc c/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada -u sdefault --GCC=gc c gnatmake: objects up to date. gnatmake -c -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude -ID:/mingw/lib /gcc/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada gnatmake --GCC=gc c -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmis sing-prototypes -gnatpg -gnata gcc -c -I.\ -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude -ID:/mingw/lib /gcc/mingw32/4.5.2/adalib/ -I. -IC:/msys/1.0/home/beta/gcc-4.6.0/gcc/ada -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot otypes -gnatpg -gnata -I- C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb opt.ads:120:11: warning: unrecognized pragma Ordered opt.ads:1393:11: warning: unrecognized pragma Ordered gnatmake: C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb compilation error make[2]: *** [gnatmake-re] Error 4 make[2]: Leaving directory `/home/beta/gcc-build/gcc/ada/tools' make[1]: *** [gnattools-cross] Error 2 make[1]: Leaving directory `/home/beta/gcc-build/gnattools' make: *** [all-gnattools] Error 2 I am not familiar with ada, could someone help me to check this problem. if any logs is needed just let me know.
[Bug tree-optimization/48837] [4.4/4.5/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 08:49:41 UTC --- Fixed.
[Bug ada/48942] [gcc-4.6.0] opt.adb compiled error while multilib enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48942 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-05-10 09:18:43 UTC --- *** Bug 48943 has been marked as a duplicate of this bug. ***
[Bug libffi/48944] New: build error: libffi has not been ported to avr-unknown-none.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944 Summary: build error: libffi has not been ported to avr-unknown-none. Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org gcc from current trunk (SVN 173608) configured: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared --enable-languages=c,c++ runs into following bug during build: configure: error: libffi has not been ported to avr-unknown-none. make[1]: *** [configure-target-libffi] Fehler 1 make[1]: Leaving directory `/local/gnu/build/gcc-4.7-avr' make: *** [all] Fehler 2
[Bug c++/48940] GCC fails to issue expected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48940 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-10 09:08:39 UTC --- I assume you're talking about binding the A to a B object without an accessible copy constructor? That was the subject of a Defect Report against C++03 so has been fixed in G++, therefore not a bug. No temporary is created, so no copy constructor is needed http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#589
[Bug ada/32164] [4.3/4.6/4.7 Regression] ICE when renaming predefined = and /=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164 --- Comment #10 from Ludovic Brenta ludo...@ludovic-brenta.org 2011-05-10 08:48:53 UTC --- (In reply to comment #9) This works with 4.4.x and 4.5.x: pak1.ads:2:09: prefix of Unrestricted_Access attribute cannot be intrinsic I wouldn't qualify this as working. The test program does not use Unrestricted_Access and I think it is legal, so GCC should not reject it. I think this is in fact another bug which hides PR32164.
[Bug libffi/48944] build error: libffi has not been ported to avr-unknown-none.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P2 Host||i586-suse-linux Build||i586-suse-linux Severity|normal |blocker
[Bug ada/48942] [gcc-4.6.0] opt.adb compiled error while multilib enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48942 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2011-05-10 09:24:52 UTC --- You need a newer host compiler to build Ada as a cross compiler. Generally the host compiler should be the same version, see the installation instructions.
[Bug driver/44273] Using -save-temps and @file should also save the intermediate @file used by the driver.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44273 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ibolton at gcc dot gnu.org Resolution||WONTFIX --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-10 09:38:15 UTC --- This can be achieved by specifying -Wl,-debug, so the behaviour of --save-temps does not need to change.
[Bug c++/48940] GCC fails to issue expected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48940 --- Comment #2 from Zachary Vance vanceza at gmail dot com 2011-05-10 09:48:47 UTC --- Sorry to be cryptic as to the part of the standard I was talking about. Yes, I was referring to report 391/589. Yes, I agree that g++ should not issue an error for this file running in C++03 mode. What I am filing a bug about is that g++ used to issue an error running in C++98 mode, and now g++ does not issue an error running in C++98 mode. I claim that it should issue an error, because I understood issue the defect reports only to affect the C++03 standardization. Is this correct?
[Bug ada/48943] [gcc-4.6.0] opt.adb compiled error while multilib enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48943 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-05-10 09:18:42 UTC --- . *** This bug has been marked as a duplicate of bug 48942 ***
[Bug fortran/38199] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #13 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-10
09:41:08 UTC ---
Here's something for formatted writes; consider the write-many.f (from some
other PR, I'm too lazy to check which now)
program main
open(10,status='SCRATCH')
a = 0.3858204
do i=1,100
a = a + 0.4761748164
write(10, '(G12.5)'),a
end do
end program main
Profiling this with 'perf' shows the top offenders as
# Overhead Command
Shared Object Symbol
# ..
. ..
#
21.56% write-many /lib/libc-2.11.1.so
[.] __mpn_divrem
14.72% write-many /lib/libc-2.11.1.so
[.] ___printf_fp
13.42% write-many /lib/libc-2.11.1.so
[.] hack_digit.15661
7.75% write-many /lib/libc-2.11.1.so
[.] __GI_vfprintf
3.81% write-many
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0 [.]
output_float.isra.7.constprop.16
2.81% write-many
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0 [.]
write_float
2.38% write-many /lib/libc-2.11.1.so
[.] _IO_default_xsputn_internal
2.10% write-many
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0 [.]
data_transfer_init
1.96% write-many
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0 [.]
formatted_transfer
1.37% write-many
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0 [.]
next_format0
That is, most of the time seems to be spent somewhere related to the libc
formatting (as we're using snprintf to convert the real numbers to ascii).
Next, consider
#include stdio.h
#include stdlib.h
int main(int argc, char *argv[])
{
int ndigits = atoi(argv[1]);
printf(Doing test with %d digits\n, ndigits);
size_t bufsz = ndigits + 9;
char *buf = malloc(bufsz);
for (int i = 0; i 1000; i++)
snprintf(buf, bufsz, %#-.*e, ndigits, 1./3);
printf(%s\n, buf);
return 0;
}
$ time ./snprintfbench 0
Doing test with 0 digits
3.e-01
real0m2.608s
user0m2.610s
sys 0m0.000s
$ time ./snprintfbench 20
Doing test with 20 digits
3.33314830e-01
real0m4.746s
user0m4.740s
sys 0m0.010s
$ time ./snprintfbench 40
Doing test with 40 digits
3.3331482961625624739099293947e-01
real0m6.362s
user0m6.360s
sys 0m0.000s
$ time ./snprintfbench 60
Doing test with 60 digits
3.33314829616256247390992939472198486328125000e-01
real0m8.155s
user0m8.160s
sys 0m0.000s
That is, while there is a constant cost for snprintf(), each additional digit
increases the time approximately linearly.
Now, in io/write_float.def we always convert with a constant 41 digits (when
REAL(16) is available). Instead, we could first figure out how many digits we
need, and only then call snprintf(), generating only as many digits as needed.
Or as many as requested + 1, if the user has chosen a non-default rounding
mode, that is we need an extra digit in order to do the rounding in that case.
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.10 09:51:19 Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-10 09:51:19 UTC --- Oops, indeed. Thanks.
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-05-10 09:57:55 UTC --- I have come around on this issue (and the color output). I now think it would be useful to have an extra verbose mode. It is clear it won't be implemented by existing GCC devs and probably it won't be accepted in mainline GCC, so it will have to be a plugin. The first step is to have a significant number of verbose descriptions. I have started a list but it needs a lot more contributions: http://gcc.gnu.org/wiki/VerboseDiagnostics The second step would be to enable plugins to intercept warning/error messages and add their own actions (in this case, just printing the verbose output). Even if nobody bothers to finish this second step, the list itself would be helpful.
[Bug c++/48945] New: [C++0x] static constexpr member function cannot be defined out-of class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48945
Summary: [C++0x] static constexpr member function cannot be
defined out-of class
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code:
//---
struct A {
static constexpr bool is();
};
constexpr bool A::is() { return true; }
//---
error: static member function 'constexpr bool A::is() const' declared with
type qualifiers
According to 7.1.5 [dcl.constexpr] p. 1
If any declaration of a function or function template has constexpr specifier,
then all its declarations shall contain the constexpr specifier.
the constexpr specifier is required as part of the function definition and the
code should be accepted. It seems that gcc incorrectly attempts to reapply a
const-qualifier to the static member.
[Bug fortran/48946] New: [OOP] Deferred Overloaded Assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48946 Summary: [OOP] Deferred Overloaded Assignment Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid, wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org The FE wrongly resolves the operator, leading to wrong code in the sense that the linker cannot find the symbol: undefined reference to `assign_interface_' Reported by Andrew Baldwin and reported to work with XLF and NAG. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/32602f115b24e19d Test case: module foo_module implicit none type, abstract :: foo contains procedure (assign_interface), deferred :: assign generic :: assignment(=) = assign end type abstract interface subroutine assign_interface(lhs,rhs) import :: foo class(foo), intent(inout) :: lhs class(foo), intent(in) :: rhs end subroutine end interface end module module bar_module use foo_module implicit none type, extends(foo) :: bar real :: x contains procedure :: assign = assign_bar end type contains subroutine assign_bar(lhs,rhs) class(bar), intent(inout) :: lhs class(foo), intent(in) :: rhs select type(rhs) type is (bar) lhs%x = rhs%x end select end subroutine end module program main use foo_module use bar_module implicit none type(bar) :: one, two one%x = 1 two%x = 2 one = two end program
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-10 10:09:15 UTC --- Things go wrong well before check_return_expr: in cp_parser_lambda_body, cp_parser_expression returns error_mark_node.
[Bug c++/48940] GCC fails to issue expected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48940 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-10 10:07:53 UTC --- (In reply to comment #2) Sorry to be cryptic as to the part of the standard I was talking about. Yes, I was referring to report 391/589. Yes, I agree that g++ should not issue an error for this file running in C++03 mode. (I assume you mean C++0x here) DR 391 was resolved in 2005 and G++'s behaviour was changed intentionally, see PR 25950 What I am filing a bug about is that g++ used to issue an error running in C++98 mode, and now g++ does not issue an error running in C++98 mode. I claim that it should issue an error, because I understood issue the defect reports only to affect the C++03 standardization. Is this correct? Technically yes, but the intent of the committee is that it should work, and implementing that is more useful for users. Does it actually serve any advantage to reject the code, other than strict conformance? With extended SFINAE in C++0x you could make use of it, but the code is valid in C++0x, and extended SFINAE isn't part of C++98. There are lots of DRs that G++ implements, counter to the exact wording in C++98 or C++03. Jason, as the author of the fix for PR 25950, do you have an opinion?
[Bug c++/48940] GCC fails to issue expected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48940 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 10:07:16 UTC --- No, -std=c++98 and -std=c++03 are aliases, both described as: Conform to the ISO 1998 C++ standard revised by the 2003 technical corrigendum
[Bug debug/48670] [4.6 regression] explosion in time and stack usage when using -ggdb on a class with many members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 10:34:52 UTC --- Anyway, most likely PR48190, i.e. http://gcc.gnu.org/viewcvs?view=revisionrevision=171655
[Bug libffi/48944] build error: libffi has not been ported to avr-unknown-none.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-10 10:30:05 UTC --- Sounds like some of the toplevel configure re-org may have caused this? C and C++ should not result in libffi being built (I think).
[Bug lto/48938] [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48938 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Depends on||48246 Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-10 10:32:06 UTC --- I think we have a dup for this. On the 4.6 branch I fixed this by turning the assert into a checking-assert. Thus, this seems related to PR48246.
[Bug c++/48940] GCC fails to issue expected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48940 --- Comment #5 from Zachary Vance vanceza at gmail dot com 2011-05-10 10:27:08 UTC --- As long as folks are aware of this behavior and consider it proper, I personally have no objection. I don't see any large benefit from changing it; I was just confused when other people couldn't reproduce the error my compiler was giving.
[Bug lto/48725] 4.6.0 fails to link p7zip 9.20.1 with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48725 --- Comment #6 from Vadim Markovtsev gmarkhor at gmail dot com 2011-05-10 11:01:14 UTC --- (In reply to comment #5) (In reply to comment #4) Does it work with BFD linker in CVS? I will check that out tomorrow. Sorry for such a delay, I checked out binutils from CVS on May, 10. p7zip is built flawlessly with the BFD linker. The gold linker (when building with LTO) fails the same way.
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-10 11:10:21 UTC --- I found where exactly things go wrong first: in cp_make_fname_decl, current_binding_level-kind is sk_function_parms, thus error_mark_node is returned. In the aforementioned case of f(), it's sk_block, makes sense. Jason, any tip about this meaningless binding level?
[Bug lto/48947] New: 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 Summary: 4.6.0 fails to link ffmpeg with LTO and gold Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: gmark...@gmail.com I am trying to make ffmpeg snapshot. I configure ffmpeg with the following line: ../configure --enable-shared --cc='gcc -flto -fuse-linker-plugin -fPIC' --prefix=/home/markhor/ffmpeg/install --arch=x86_64 It fails to build with LDlibavcodec/libavcodec.so.53 ffmpeg/libavcodec/jpegls.h:46:0: warning: type of ‘ff_log2_run’ does not match original declaration [enabled by default] ffmpeg/libavcodec/jpegls.h:46:0: warning: type of ‘ff_log2_run’ does not match original declaration [enabled by default] ffmpeg/libavcodec/bitstream.c:35:15: note: previously declared here x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans3.ltrans.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans10.ltrans.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans16.ltrans.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans21.ltrans.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC collect2: ld returned 1 exit status --cc='gcc -flto -fPIC' fails the same way. Snapshot is successfully built without LTO with the BFD linker.
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-10
10:54:31 UTC ---
More debugging: fname_decl, called by finish_fname, returns error_mark_node,
whereas it doesn't for, eg, 'const char* f() { return __func__; }'. Note the
argument to finish_fname is completely similar in the two cases.
[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 11:37:33 UTC --- Started with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=17
[Bug middle-end/18041] OR of two single-bit bitfields is inefficient
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18041 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-10 11:38:50 UTC --- With a patch I have we now optimize at the tree level to bb 2: D.2686_2 = b_1(D)-bit0; D.2688_4 = b_1(D)-bit1; D.2693_10 = D.2688_4 ^ D.2686_2; b_1(D)-bit0 = D.2693_10; return; and with bitfield lowering applied to bb 2: BF.0_2 = MEM[(struct B *)b_1(D)]; D.2694_6 = BF.0_2 1; D.2701_18 = D.2694_6 ^ BF.0_2; D.2696_12 = BF.0_2 4294967294; D.2697_13 = D.2701_18 1; BF.2_14 = D.2697_13 | D.2696_12; MEM[(struct B *)b_1(D)] = BF.2_14; return;
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-10 11:42:41 UTC --- A do_pushlevel(sk_block) missing?
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 12:15:55 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=167697
[Bug target/48896] avr.o warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48896 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-10 12:16:15 UTC --- Author: gjl Date: Tue May 10 12:16:09 2011 New Revision: 173617 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173617 Log: PR target/48896 * config/avr/avr.c (avr_ret_register): Return unsigned int instead of int. (avr_function_value): Mark fn_decl_or_type as unused, don't pass it to avr_libcall_value. avr_expand_builtin): Use EXPAND_NORMAL as arg 4 in calls to expand_expr. (avr_expand_binop_builtin): Ditto. (avr_expand_unop_builtin): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 11:46:34 UTC --- *.asmcons is identical in between r171110 and r17, *.ira already looks wrong (no setting of %rax to 24+.LPBX1, or changing the (%rax) address to 24+.LPBX1).
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.10 12:06:14 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-10 12:06:14 UTC --- Please make sure the ffmpeg makefiles properly pass compiler options, including -fPIC, to the gcc driver used at link time. It looks like it does not do so (especially using libtool or cmake may have issues here).
[Bug target/48896] avr.o warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48896 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-10 12:23:47 UTC --- Closed as of respective patch. However, I do not see the C++ warnings argument 4 of ‘expand_expr’ is invalid in C++ [-Werror=c++-compat] even though -Wc++-compat is on: gcc -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc.gnu.org/trunk/gcc -I../../../gcc.gnu.org/trunk/gcc/. -I../../../gcc.gnu.org/trunk/gcc/../include -I../../../gcc.gnu.org/trunk/gcc/../libcpp/include -I/mnt/nfs/home/georg/gnu/build/gcc-4.6-avr/./gmp -I/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/gmp -I/mnt/nfs/home/georg/gnu/build/gcc-4.6-avr/./mpfr -I/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/mpfr -I/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/mpc/src -I../../../gcc.gnu.org/trunk/gcc/../libdecnumber -I../../../gcc.gnu.org/trunk/gcc/../libdecnumber/dpd -I../libdecnumber\ ../../../gcc.gnu.org/trunk/gcc/config/avr/avr.c -o avr.o The build compiler I use identifies itself as: Using built-in specs. Target: i586-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=i586-suse-linux Thread model: posix gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) Is there anything broken in that version?
[Bug fortran/48889] [4.6/4.7 Regression] f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48889 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Attachment #24205|application/octet-stream|text/plain mime type|| --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-10 12:35:23 UTC --- Comment on attachment 24205 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24205 Small test exhibiting the problem. Works: 4.6.0 2010-09-28 r164677 Fails: 4.6.0 2010-11-27 r167218
[Bug c++/48948] New: [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
Summary: [C++0x] constexpr friend function cannot be defined
in-class
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
the line marked with #:
//---
struct B {
friend constexpr int f(B) { return 0; } // #
};
//---
error: invalid type for parameter 1 of constexpr function 'constexpr int
f(B)'
This code should be accepted.
The same problem occurs with friend operators, like this case
friend constexpr int operator+(B) { return 0; }
within B resulting in:
error: invalid type for parameter 1 of constexpr function 'constexpr int
operator+(B)'
It seems to me that this defect is *not* a dup of bug 48945, where the compiler
incorrectly attempts to add a const-qualifier to a static member function. I
can only assume that the compiler considers the argument as incomplete and thus
not being a valid literal type, because other non-friend constexpr functions
don't cause such problems, but I'm not sure.
Finally, the problem does not occur, if the friend function is defined
out-of-class, like so:
class C {
friend constexpr int g(C);
};
constexpr int g(C) { return 0; }
[Bug target/48896] avr.o warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48896 Eric Weddington eric.weddington at atmel dot com changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-10 12:53:07 UTC --- Status: I have managed to eliminate the OUTPUT_FLOAT_G macro completely and all floating point operations. What remains is to adjust the trailing blanks. The patch is simple looking once you get there, though a bit subtle to sort out initially, especially when I get only 20 or 30 minute intervals to work on this every two or three days. ;) Stay tuned.
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10
13:08:31 UTC ---
Further reduced testcase for -O3 -g:
void
foo (double x, int y, double *__restrict z, double *__restrict w)
{
while (y--)
*z++ = (*w++ = 0) * x;
}
[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law law at redhat dot com 2011-05-10 13:13:33 UTC --- Thanks. I'm more than happy to take it from here...
[Bug fortran/48889] [4.6/4.7 Regression] f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48889 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org, mikael at gcc dot ||gnu.org Target Milestone|--- |4.6.1 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-10 13:47:15 UTC --- Works:2010-11-09 r166519 Fails:2010-11-09 r166520 that's the commit http://gcc.gnu.org/viewcvs?root=gccview=revrev=166520 2010-11-09 Jerry DeLisle jvdeli...@gcc.gnu.org Mikael Morin mik...@gcc.gnu.org PR fortran/46331 * intrinsic.c: Correctly set the pure attributes for intrinsic functions. * expr.c (check_specification_function): Remove this function and move its code into gfc_is_constant_expr. (gfc_is_constant_expr): Change the order of checks by checking for non-constant arguments first. Then, check for initialization functions, followed by intrinsics.
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-10 14:29:32 UTC --- First of all, it surprises me that tree-loop-distribution.c and stmts_from_loop don't do anything special about debug stmts, I'd say stmts_from_loop should ignore debug stmts like it ignores GIMPLE_LABELs and generate_loops_for_partition and generate_builtin match that, the first by keeping all DEBUG stmts in all loops and generate_builtin to just ignore them. Otherwise I think we risk -fcompare-debug failures. The second problem is in generate_loops_for_partition, it wants to remove all stmts that are not in that partition, and going in the order of stmts queued from stmts_from_loop, by walking the loop bbs sequentially and first going through not marked phis, removing each of them, then going through stmts from first to last in the bb, again removing unneeded stmts. insert_debug_temp_for_var_def though assumes I think that within one bb stmts are removed from the end towards beginning and that bbs are traversed during removal in the right order according to dominator info. Not sure what we want to do there, perhaps reset all the debug stmts that use values set by stmts that are not in the current partition? Alex, any ideas? In particular, the problematic DEBUG stmt uses a SSA_NAME which is not in partition bitmap, whose definition is a PHI node result again not in the partition, and where one of the PHI arguments again uses the SSA_NAME also used in the DEBUG stmt.
[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC||schaub.johannes at
||googlemail dot com
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 14:49:18 UTC ---
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
the line marked with #:
//---
struct B {
friend constexpr int f(B) { return 0; } // #
};
//---
error: invalid type for parameter 1 of constexpr function 'constexpr int
f(B)'
This code should be accepted.
The same problem occurs with friend operators, like this case
friend constexpr int operator+(B) { return 0; }
within B resulting in:
error: invalid type for parameter 1 of constexpr function 'constexpr int
operator+(B)'
Well, class B is incomplete in the parameter type list of f. The spec allows
B to be incomplete for that parameter type (8.3.5p9), but it doesn't say
anything what that means for determining whether or not the parameter has
literal class type (several of the bullets of 3.9p10 require a complete class
type to be checked). I don't know whether an implementation is supposed to
reject the code, or supposed to wait until B is complete. Same would apply for
non-static member functions.
Any hints?
[Bug libffi/48944] build error: libffi has not been ported to avr-unknown-none.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-05-10 15:10:57 UTC --- When I configure for this target I get: *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgomp target-libssp target-libiberty target-libstdc++-v3 gnattools target-libada target-libgfortran target-libgo target-libffi target-zlib target-libjava target-libobjc target-boehm-gc (Any other directories should still work fine.) and then the generated Makefile contains: TARGET_CONFIGDIRS = libgcc libquadmath Do you get some different list of unsupported directories (not including libffi) and of directories to build (including libffi), or do you get the same lists that I do but still find it tries to build libffi later?
[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48159 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.0 |4.6.1
[Bug c/48949] New: gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949
Summary: gcc-4.6.0 regression with complex.h on
i386-pc-solaris2.10
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mariah.le...@gmail.com
/* gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
% gcc -c foo.c
foo.c: In function ‘foo’:
foo.c:5:11: error: ‘_Imaginary_I’ undeclared (first use in this function)
foo.c:5:11: note: each undeclared identifier is reported only once for each
function it appears in
%
% gcc-4.5.1 -c foo.c
%
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.0/x86_64-SunOS-core2/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /usr/local/gcc-4.6.0/src/gcc-4.6.0/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.21/x86_64-SunOS-gccc-4.5.1/bin/as --with-gnu-ld
--with-ld=/usr/local/binutils-2.21/x86_64-SunOS-gccc-4.5.1/bin/ld
--with-gmp=/usr/local/mpir-2.3.0/x86_64-SunOS-core2-gcc-4.5.1-abi32
--with-mpfr=/usr/local/mpfr-3.0.0/x86_64-SunOS-core2-mpir-2.3.0-gcc-4.5.1-abi32
--with-mpc=/usr/local/mpc-0.9/x86_64-SunOS-core2-mpir-2.3.0-mpfr-3.0.0-gcc-4.5.1-abi32
--prefix=/usr/local/gcc-4.6.0/x86_64-SunOS-core2
Thread model: posix
gcc version 4.6.0 (GCC)
%
*/
#include complex.h
double _Complex
foo () {
return I;
}
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 --- Comment #8 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2011-05-10 15:42:54 UTC --- Thanks! Is this patch ok for the 4.6 branch too? If you don't have time to backport it, I can.
[Bug c/48949] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 Mariah Lenox mariah.lenox at gmail dot com changed: What|Removed |Added Target||i386-pc-solaris2.10 Known to work||4.5.1 Host||i386-pc-solaris2.10 Known to fail||4.6.0 Build||i386-pc-solaris2.10 Severity|normal |critical --- Comment #1 from Mariah Lenox mariah.lenox at gmail dot com 2011-05-10 15:37:00 UTC --- Found while trying to compile mpc-0.9 with gcc-4.6.0.
[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Component|c |target Target Milestone|--- |4.6.1 Summary|gcc-4.6.0 regression with |[4.6/4.7 Regression] |complex.h on|gcc-4.6.0 regression with |i386-pc-solaris2.10 |complex.h on ||i386-pc-solaris2.10 --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-05-10 15:57:13 UTC --- I can't confirm whether this problem exists or is a regression, but if it does then it's a fixincludes bug since fixincludes (fix solaris_complex) is supposed to make the system complex.h header suitable for GCC.
[Bug libfortran/48950] New: a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 Summary: a patch from 4.4.x not backported to 4.3.x Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sl...@blue.cft.edu.pl Quantum Espresso 4.3 compiled with gfortran 4.3.5 (and with the 4.3 snapshot I tried) fails reading a data file. The same issue was present in the 4.4.x series, but this has been fixed in rev 147887. As the 4.3.x series are still maintained (and used, e.g., in Cygwin), I would like to ask about backporting to 4.3.x. If you are willing to take care of this, please let me know how to help. It is not clear to me to what extent I can mix libgfortran from different versions of GCC.
[Bug c/48951] New: probably, it is a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48951
Summary: probably, it is a bug.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ufo008...@163.com
I have written a program.I have use long long a type variable and scanf(%lld)
for input，but when i compare it with a int type one, the Conditional expression
is wrong.thanks for your reply.
My code is:
#include stdio.h
int main()
{
int i;
long long n;
scanf(%lld, n);
printf(\n);
printf(%lld\n, n);
i = 4;
printf(%d\n, (long long)i n);
printf(\n);
n = (long long)1;
printf(%lld\n, n);
printf(%d\n, (long long)i n);
}
[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |law at redhat dot com
|gnu.org |
--- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-05-10 15:52:15
UTC ---
We have a block-local equivalence between a pseudo and a memory location:
(insn 86 85 87 9 (set (reg/f:DI 0 ax [113])
(const:DI (plus:DI (symbol_ref:DI (*.LPBX1) [flags 0x2] var_decl
0x77dec3c0 *.LPBX1)
(const_int 8 [0x8] 62 {*movdi_internal_rex64}
(expr_list:REG_EQUIV (const:DI (plus:DI (symbol_ref:DI (*.LPBX1) [flags
0x2] var_decl 0x77dec3c0 *.LPBX1)
(const_int 8 [0x8])))
(nil)))
(insn 87 86 88 9 (set (reg:DI 114 [ *.LPBX1+8 ])
(mem/s/j/c:DI (reg/f:DI 0 ax [113]) [0 *.LPBX1+8 S8 A64])) 62
{*movdi_internal_rex64}
(expr_list:REG_DEAD (reg/f:DI 0 ax [113])
(expr_list:REG_EQUIV (mem/s/j/c:DI (reg/f:DI 0 ax [113]) [0 *.LPBX1+8
S8 A64])
(nil
(insn 88 87 91 9 (parallel [
(set (reg:DI 2 cx [orig:95 *.LPBX1_I_lsm.5 ] [95])
(plus:DI (reg:DI 114 [ *.LPBX1+8 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 253 {*adddi_1}
(expr_list:REG_DEAD (reg:DI 114 [ *.LPBX1+8 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (plus:DI (mem/s/j/c:DI (const:DI (plus:DI
(symbol_ref:DI (*.LPBX1) [flags 0x2] var_decl 0x77dec3c0 *.LPBX1)
(const_int 8 [0x8]))) [0 *.LPBX1+8 S8 A64])
(const_int 1 [0x1]))
(nil)
reg114 is marked as equivalent to (mem (reg 113)); reg114 does not get a hard
reg. As usual, reload deletes the insn that creates the equivalence between
reg114 and its memory location (insn 87). delete_dead_insn decides to peek at
insn86 and decides that insn86 is dead as well, which removes the
initialization of reg113.
Later reg114 is replaced with its equivalent memory location which results in
an uninitialized reference to reg113 and reading from an invalid memory
location and the segfault.
What's interesting here is delete_dead_insn's behavior -- it's been like this
since circa 1991, well before we ran any kind of real dead code elimination
after reload. The solution *may* be to remove the recursion in
delete_dead_insn. I'm still investigating.
[Bug lto/48952] New: ICE in inline_merge_summary during linux kernel LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952 Summary: ICE in inline_merge_summary during linux kernel LTO build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org When running a Linux kernel LTO build with recent mainline (gcc version 4.7.0 20110510 (experimental) (GCC)) I get a segfault during the final lto-wpa phase In gdb I get Program received signal SIGSEGV, Segmentation fault. inline_merge_summary (edge=0x7f1ce05d90d0) at ../../gcc/gcc/ipa-inline-analysis.c:2025 2025 ipa_get_cs_argument_count (IPA_EDGE_REF (edge (gdb) bt #0 inline_merge_summary (edge=0x7f1ce05d90d0) at ../../gcc/gcc/ipa-inline-analysis.c:2025 #1 0x0085b079 in inline_call (e=0x7f1ce05d90d0, update_original=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/ipa-inline-transform.c:185 #2 0x00854561 in inline_small_functions () at ../../gcc/gcc/ipa-inline.c:1451 #3 ipa_inline () at ../../gcc/gcc/ipa-inline.c:1643 #4 0x0063c509 in execute_one_pass (pass=0xfff720) at ../../gcc/gcc/passes.c:1556 #5 0x0063cbca in execute_ipa_pass_list (pass=0xfff720) at ../../gcc/gcc/passes.c:1922 #6 0x0049ffe5 in do_whole_program_analysis () at ../../gcc/gcc/lto/lto.c:2517 #7 lto_main () at ../../gcc/gcc/lto/lto.c:2629 #8 0x006ccc4a in compile_file (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:570 #9 do_compile (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:1928 #10 toplev_main (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:2000 #11 0x003bc6e1ee5d in __libc_start_main (main=0x4a29e0 main, argc=16, ubp_av=0x7fff62bc8e28, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fff62bc8e18) at libc-start.c:226 #12 0x00486f99 in _start () (gdb) The input files are very large. I can supply them on demand. They also require special binutils currently (HJ's latest version)
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 --- Comment #9 from fabien at gcc dot gnu.org 2011-05-10 16:27:42 UTC --- (In reply to comment #8) Thanks! Is this patch ok for the 4.6 branch too? Yes, as it is a 4.6 regression, and Jason also approved it for 4.6. If you don't have time to backport it, I can. I was planning to backport it this evening, thanks.
[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-05-10 16:33:39 UTC ---
(In reply to comment #1)
I don't think that this is intended, but I would like to await feedback from
the developer group before submitting a corresponding core issue. IMO there are
some core wordings in regard to type completeness that are not intended to be
read strictly, e.g. 3.2 p.4
— a function with a return type or argument type of type T is defined (3.1)
[..]
can be read to disallow any of the following function definitions:
struct A {
A f(A a) { return a; }
friend A g(A a) { return a; }
};
I haven't seen a compiler who rejects this code, because they all contribute
more weight to 9.2 p.2. In regard to constexpr functions the clear intention is
that these can be forward-declared and are only required to be completely
defined, if used in a manner that requires a constant expression. The example
in 7.1.5 with the constexpr function small and it's usage in the constexpr
constructor of pixel make this intention very clear. Now to me, the 3.2 p.4
requirement was always supposed to be interpreted as complete as it would be
required to be complete within the function body for both function parameters
and function return types within this function definition, so I don't see any
reason why the compiler needs to validate the constraints on literal types at
the point where the class type is still incomplete and *does* not need to be
complete.
If the gcc developer feedback indeed points to an intended conservative reading
of 3.2 p.4 for constexpr functions as in this example I will surely require to
open a core issue for this situation, because this severely constraints
constexpr function definitions within classes. In this case a simple workaround
is to replace the by-value parameter by by-reference, but the need for such
a change looks like an artifact to me. It seems to me that both functions f()
and g() defined in class A above could be constexpr functions.
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-10 16:28:25 UTC --- It is not clear to me to what extent I can mix libgfortran from different versions of GCC. In principle, the libgfortran is downward compatible - as long as the library version remains the same: - GCC 4.1 has libgfortran.so.1 - GCC 4.2 has libgfortran.so.2 - GCC 4.3/4.4/4.5/4.6/4.7 have libgfortran.so.3 Thus, a program compiled with 4.3 should work with libgfortran 4.3/4.4/4.5/4.6/4.7, a program compiled with 4.4 should work with libgfortran 4.4/4.5/4.6/4.7 etc. As the 4.3.x series are still maintained (and used, e.g., in Cygwin), I would like to ask about backporting to 4.3.x. The commit is: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00864.html That's a rather huge patch, which completely modifies the I/O system and fixes the bugs PR 22423, PR 25561, PR 37754, PR 38654, PR 38668, PR 39664, PR 39665, PR 39667, PR 39702, PR 39709 and PR 39782. As the patch is rather large, I don't think it makes sense to backport it. The chance that something breaks is rather high compared to the benefit. Especially, as it does not seem to be a simple regression fix. I am also not sure that how likely it is that the patch ends up in some vendor version - I think most vendors try to be very conservative with old versions and rather add technical previews than modifying the old version. Regarding Cygwin: The last version I have seen was 4.5.0, cf. http://ftp.gwdg.de/pub/linux/sources.redhat.com/cygwin/release/gcc4/ Though, admittedly, Cygwin seems to still maintain 4.3.x (file modification date 22 March 2011); however, the file name gcc4-4.3.4-4.tar.bz2 indicates that it is based on 4.3.4, which was released 2009-08-04. Thus, they do not include the fixes of 4.3.5 released 2010-05-22 - nor changes which were committed afterwards to the branch. (Actually, I also do not understand why they have only 4.5.0 and not the .1, .2 or .3 release - usually, the .1 release is a bit more stable/better tested than the .0 release.) For frequent/nightly GCC builds, see also http://gcc.gnu.org/wiki/GFortranBinaries
[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952 --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-10 16:37:17 UTC --- Some more information from gdb. So it follows some pointer in the VEC that is NULL (gdb) p edge $1 = (struct cgraph_edge *) 0x7f1ce05d90d0 (gdb) p edge-uid $2 = 38701 (gdb) disp/3i $pc 1: x/3i $pc = 0x859bdc inline_merge_summary+188: mov0x8(%rbx,%rdx,1),%ecx 0x859be0 inline_merge_summary+192: test %ecx,%ecx 0x859be2 inline_merge_summary+194: je 0x859cdb inline_merge_summary+443 (gdb) p $rbx $3 = 0 (gdb) p $rdx $4 = 619216 (gdb)
[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #3 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 16:46:18 UTC ---
(In reply to comment #2)
(In reply to comment #1)
I don't think that this is intended, but I would like to await feedback from
the developer group before submitting a corresponding core issue. IMO there
are
some core wordings in regard to type completeness that are not intended to be
read strictly, e.g. 3.2 p.4
— a function with a return type or argument type of type T is defined (3.1)
[..]
can be read to disallow any of the following function definitions:
struct A {
A f(A a) { return a; }
friend A g(A a) { return a; }
};
I haven't seen a compiler who rejects this code, because they all contribute
more weight to 9.2 p.2.
Within A a (the parameters) and within A f / A g (the return types), the
class A is incomplete. Only within the function bodies, the class A is complete
by 9.2p2.
The compilers accept that code because of 8.3.5p9. 3.2 p4 is a non-normative
big note, which can impossibly achieve the precision of covering every detail.
It only provides a rough description.
[Bug lto/48938] [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48938 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2011-05-10 16:40:46 UTC --- Thanks for the reply. You are right, the assert described in PR48246 is at the same place. However, I have 4.6 configured with --enable-checking=yes,rtl,df - so checking_assert() should be triggered.
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-10 16:39:28 UTC --- 4.4 is available in cygwin. Just search through the setup and you will see it listed with 4.4 appended to the name, something like gfortran-4.4.
[Bug c/48951] probably, it is a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48951 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.10 16:53:39 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-10 16:53:39 UTC --- (gcc 3.4.2 is ancient, even if there is a bug noone will fix it in that version) what is the program's input? what is its output? what output are you expecting?
[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 16:59:50 UTC ---
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
the line marked with #:
//---
struct B {
friend constexpr int f(B) { return 0; } // #
};
//---
error: invalid type for parameter 1 of constexpr function 'constexpr int
f(B)'
This code should be accepted.
I remember that Gaby (I hope I remember correctly, hehe) argued that the body
of f is late-parsed. Hence, the argument, until after the end of definition
of B, f is only considered declared but not defined.
I don't share that view though. That view is an implementation detail. In the
language, the function marked by # is defined as soon as its body has been
completely seen. If something else is intended, the specification needs to be
explicit about this. Unless I've missed the text, it is not explicit about
that.
[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 17:07:30 UTC ---
(In reply to comment #4)
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code
at
the line marked with #:
//---
struct B {
friend constexpr int f(B) { return 0; } // #
};
//---
error: invalid type for parameter 1 of constexpr function 'constexpr int
f(B)'
This code should be accepted.
I remember that Gaby (I hope I remember correctly, hehe) argued that the body
of f is late-parsed. Hence, the argument, until after the end of definition
of B, f is only considered declared but not defined.
Consider also this, which I think demonstrates that position:
struct A {
struct B;
void f(B) { }
struct B { };
};
I think this is ill-formed by the spec, because B is incomplete in f's
parameter and f is defined at that point. And this is not one of the contexts
that B is allowed to be incomplete by 8.3.5p9.
However, clang, gcc and comeau online all accept this. Apparently, they
consider f only declared and not defined.
I would be glad if someone points me to the rule that says that f is only
considered defined at the closing } of A though.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-10 17:16:47 UTC --- Way to go! I'll be happy to test.
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-10 17:12:30 UTC --- I am mistaken. However you can get fairly recent Cygwin (or MingW): http://gcc.gnu.org/wiki/GFortranBinaries
[Bug target/48857] V2DI arguments are not passed like other vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48857 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org 2011-05-10 17:21:48 UTC --- Fixed in subversion revision 173624.
[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #6 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 17:20:31 UTC ---
(In reply to comment #4)
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code
at
the line marked with #:
//---
struct B {
friend constexpr int f(B) { return 0; } // #
};
//---
error: invalid type for parameter 1 of constexpr function 'constexpr int
f(B)'
This code should be accepted.
I remember that Gaby (I hope I remember correctly, hehe) argued that the body
of f is late-parsed. Hence, the argument, until after the end of definition
of B, f is only considered declared but not defined.
I don't share that view though. That view is an implementation detail. In the
language, the function marked by # is defined as soon as its body has been
completely seen. If something else is intended, the specification needs to be
explicit about this. Unless I've missed the text, it is not explicit about
that.
But I can live with that. Having remembered the intent as described, I see that
the friend function you already showed is valid, because when the body is late
parsed, and the function is then considered defined only when the enclosing
class is complete, it makes sense. I wouldn't intuitively get to this result
though, but I think it's an interpretation I can live with!
I'm sorry for that load of nonsense in the comment boxes. I promise this is the
last comment in this row of this PR! :)
[Bug c/48951] probably, it is a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48951 --- Comment #2 from ufo008ahw ufo008ahw at 163 dot com 2011-05-10 17:26:31 UTC --- (In reply to comment #1) (gcc 3.4.2 is ancient, even if there is a bug noone will fix it in that version) what is the program's input? what is its output? what output are you expecting? input is 1。 output is: 1 1 1 1 0 expected output is: 1 1 0 1 0 so, the difference is forth line.
[Bug middle-end/48953] New: [4.7 Regression] ICE: verify_gimple failed: type mismatch in array reference with -flto and struct with vararray
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48953
Summary: [4.7 Regression] ICE: verify_gimple failed: type
mismatch in array reference with -flto and struct with
vararray
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 24219
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24219
reduced testcase
Compiler output:
$ gcc -O -flto -fno-tree-dce testcase.c
In file included from :0:0:
testcase.c: In function 'main':
testcase.c:11:5: error: type mismatch in array reference
struct S
struct S
# .MEM_11 = VDEF .MEM_10
MEM[(struct S[2] *)s.1_7][0]{lb: 0 sz: 12}.value = 0;
testcase.c:11:5: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status
Tested revisions:
r173586 - crash
4.6 r173059 - OK (yes,rtl,df checking)
[Bug target/48495] ICE in in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48495 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org 2011-05-10 17:23:35 UTC --- The fix for 48857 (subversion id 173624) is believed to fix this bug as well.
[Bug middle-end/48954] New: [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48954 Summary: [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24220 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24220 reduced testcase Compiler output (run under valgrind): $ g++ -O2 -flto -fno-early-inlining -fkeep-inline-functions testcase.C ==3584== ==3584== Invalid read of size 8 ==3584==at 0x507DE6: bitmap_count_bits (bitmap.c:719) ==3584==by 0x7491C2: output_cgraph (lto-cgraph.c:1591) ==3584==by 0x759C91: lto_output (lto-streamer-out.c:) ==3584==by 0x7940E2: ipa_write_optimization_summaries_1 (passes.c:1760) ==3584==by 0x794C2F: ipa_write_optimization_summaries (passes.c:1806) ==3584==by 0x4F59DA: lto_main (lto.c:1996) ==3584==by 0x880F69: toplev_main (toplev.c:570) ==3584==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so) ==3584== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3584== lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r173586 - crash 4.6 r173059 - OK (yes,rtl,df checking)
[Bug c/48951] probably, it is a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-10 17:47:04 UTC --- So, your expectations are wrong, because of course 4 1 is false, thus 0 as an integer.
[Bug c++/48736] [C++0x] ICE during list-initialization with variadics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48736 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-05-10 17:58:41 UTC --- Author: jason Date: Tue May 10 17:58:38 2011 New Revision: 173627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173627 Log: PR c++/48736 * pt.c (tsubst_copy_and_build): Handle substitution of a pack expansion producing another expansion. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic108.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48930] [C++0x] Invalid implicitly declared default c'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-05-10 17:58:49 UTC --- Author: jason Date: Tue May 10 17:58:46 2011 New Revision: 173628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173628 Log: PR c++/48930 * class.c (type_build_ctor_call): New. * cp-tree.h: Declare it. * decl.c (check_initializer): Use it instead of TYPE_NEEDS_CONSTRUCTING. * init.c (build_value_init, build_value_init_noctor): Likewise. (perform_member_init, expand_aggr_init_1, build_new_1): Likewise. (build_vec_init): Likewise. * typeck2.c (process_init_constructor_array): Likewise. (process_init_constructor_record): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash7.C
[Bug rtl-optimization/48374] ICE: in single_succ_edge, at basic-block.h:562 with -fselective-scheduling2 and __builtin_unreachable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48374 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2011-05-10 18:05:57 UTC --- Thanks for the suggestion, Andrey. Using lower values for --param max-sched-extend-regions-iters might reduce the compilation time in some cases. I tested your patch on top of r173588 and it fixes the ICE on all testcases I have.
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-10 18:16:41 UTC --- (In reply to comment #2) 4.4 is available in cygwin. Just search through the setup and you will see it listed with 4.4 appended to the name, something like gfortran-4.4. (In reply to comment #3) I am mistaken. As written in comment 1, there are official GCC 4.5.0 binaries. I do not know how they integrate into the package manager of Cygwin, but one can at least download them from the official FTP server. I wouldn't be surprised if those will install the compiler as gfortran-4.5. As libgfortran of GCC 4.5 is backward compatible with GCC 4.3/4.4, you could consider to just install the newer library. But you could also use the newer version of the compiler. For the new features, cf. http://gcc.gnu.org/wiki/GFortran#news
[Bug c/48951] probably, it is a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48951 --- Comment #4 from ufo008ahw ufo008ahw at 163 dot com 2011-05-10 18:11:04 UTC --- (In reply to comment #3) So, your expectations are wrong, because of course 4 1 is false, thus 0 as an integer. ?? my expectation is (4 1) output 0. but program output 1
[Bug c/48951] probably, it is a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48951 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-10 18:33:13 UTC --- it works correctly for me you need to provide the What we need info requested at http://gcc.gnu.org/bugs/ (no need for preprocessed source) and try with a current version of the compiler
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 --- Comment #5 from Cezary Sliwa sliwa at blue dot cft.edu.pl 2011-05-10 19:08:34 UTC --- OK, if everything is backported you get the current version... I agree this does not make sense. But this has a maintained status, which gives people a false sense of security. You build all the libraries, then the application does not work. It rather could be nice to take a look what had been wrong in the old version, and I don't know how to do it (as you mentioned the patch is large). Cygwin has 4.5 as a test version, installing it takes a click. But still, it is a test version. Nightly build of gfortran did not work for me (it failed to compile LAPACK if I remember correctly).
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 --- Comment #6 from Cezary Sliwa sliwa at blue dot cft.edu.pl 2011-05-10 19:11:22 UTC --- PS. The gfortran version of ACML 4.4.0 appears to be built with 4.3.x.
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-10 19:23:57 UTC --- 4.5 may be a test version as far as Cygwin folks downstream of us, but 4.5 and 4.6 are Released and perfectly useable from our view from here. Both are better than any of the older versions as far as we know. (ie many bugs fixed since) I hope that you can upgarde to a more current version.
[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48950 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||WONTFIX --- Comment #8 from kargl at gcc dot gnu.org 2011-05-10 20:03:46 UTC --- (In reply to comment #5) OK, if everything is backported you get the current version... I agree this does not make sense. But this has a maintained status, which gives people a false sense of security. Given Tobias's comment 1, which indicates that this would be a large intrusive patch with the potential of causing other problems, and given the limited available resources (gfortran developers and hours in a day), I'll suggest that you may have an unrealistic expectation of the word maintained.
[Bug fortran/48955] New: [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 Summary: [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org, tkoe...@gcc.gnu.org As reported on IRC. The following program should print: -10. -20. -20. -10. 10. 20. 20. 10. -10. -20. -20. -10. 10. 20. 20. 10. It does so with gfortran 4.3.4, 4.4.0, 4.5.3, ifort, NAG. However, using gfortran 4.6.0, 4.7.0 (and for that matter 4.1.2) the first line is wrong: -10. -20. -25. -17.5000 6.2500 18.1250 24.0625 10. -10. -20. -20. -10. 10. 20. 20. 10. program ala implicit none integer, parameter :: n = 8 real, dimension(n) :: v0, v1 v0 = [-10.0, -10., -10., -10., 10., 10., 10., 10.] v1 = v0 v1(2:n-1) = 0.5*(v1(1:n-2) + v1(3:n) + 2.0*v1(2:n-1)) write(*,'(8(F8.4,1X))') v1 v1 = v0 v1(2:n-1) = 0.5*(v0(1:n-2) + v0(3:n) + 2.0*v0(2:n-1)) write(*,'(8(F8.4,1X))') v1 end program ala First regression hunting shows: Works: 2010-07-16-r162255 Fails: 2010-08-28-r163612
[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-10 20:49:28 UTC --- I uploaded a (large) test case to http://firstfloor.org/~andi/lto-kernel.tar.bz2 Run R2 in the directory after pointing the script to the right gcc binary.
[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Known to work||4.3.4, 4.4.0, 4.5.3 Target Milestone|--- |4.6.1 Known to fail||4.1.2, 4.6.0, 4.7.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-10 21:10:10 UTC --- Works: 2010-08-02 r162824 cca7236e5fabb3791d494683d1f53f3c09d545e5 Fails: 2010-08-02 r162829 644e9dad11b9ba317bd11726569b5d8bc648950f Thus, the culprit is: New Revision: 162829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162829 2010-08-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * depencency.c (gfc_dep_resolver): Fix logic for when a loop can be reversed. 2010-08-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * gfortran.dg/dependency_29.f90: New test.
[Bug c++/48736] [C++0x] ICE during list-initialization with variadics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48736 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-10 21:13:17 UTC --- Fixed.
