[Bug middle-end/56712] [4.6 Regression] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-03-26 06:13:55 UTC --- (In reply to comment #2) Works for me with 4.7/4.8/4.9, and 4.5 and older, but fails with 4.6. The bug was fixed for 4.7.0 by r180700; that change has no BZ PR entry, but the patch submission (http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02486.html) described a scenario involving cloned constructor functions much like this one. OK, confirmed. with this fix the bug went away in the test example and in the original more complex context.
[Bug middle-end/56712] [4.6 Regression] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-03-26 06:15:52 UTC --- Created attachment 29724 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29724 backport of the above mentioned fix
[Bug c++/56734] New: Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734
Bug #: 56734
Summary: Even simple exceptions cause a segmentation fault in
my build of gcc on Solaris 10.
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gi...@gmail.com
Created attachment 29725
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29725
The object containing the throw and the catch
gcc version 4.7.2 (GCC)
Target: sparc-sun-solaris2.10
Configured with: /proj/vobadm100/svn/gcc_4.7.2/configure \
--prefix /vobs/cello/cade_A_tools_gcc \
--with-gnu-as --with-as=/vobs/cello/cade_A_tools_utils/binutils/bin/as \
--with-gnu-ld --with-ld=/vobs/cello/cade_A_tools_utils/binutils/bin/ld \
--enable-threads --enable-languages=c,c++,java \
--with-gmp=/vobs/cello/cade_A_tools_utils/gmp \
--with-mpfr=/vobs/cello/cade_A_tools_utils/mpfr \
--with-mpc=/vobs/cello/cade_A_tools_utils/mpc \
--with-isl=/vobs/cello/cade_A_tools_utils/isl
The command line is:
$ ./CoreTest
Segmentation Fault
It runs a small test case reproducing the problem.
I attach the two preprocessed sources: Core.ii and CoreTest.ii.
Here is the stack trace produced by gdb:
Starting program: /home/emagiro/tmp/shex/CoreTest
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff35af84 in __frame_dummy_init_array_entry ()
from /vobs/cello/cade_struct/lib/libstdc++.so.6
(gdb) bt
#0 0xff35af84 in __frame_dummy_init_array_entry ()
from /vobs/cello/cade_struct/lib/libstdc++.so.6
#1 0xff2c8b48 in __cxxabiv1::__cxa_get_globals ()
at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_globals.cc:63
#2 0xff2c7a10 in __cxxabiv1::__cxa_allocate_exception (thrown_size=135552)
at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_alloc.cc:132
#3 0x00010acc in ThrowException () at Core.cc:7
#4 0x00010a90 in main () at CoreTest.cc:4
I put the main function itno a separate file, but you want only one
attachment...
The source is trivial anyway:
$ cat CoreTest.cc
#include Core.h
int main() {
ThrowException();
return 1;
}
[Bug c++/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #1 from Marc Girod marc.girod at gmail dot com 2013-03-26 07:53:46 UTC --- Created attachment 29726 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29726 the main function
[Bug c/50928] m32c ICE building RTEMS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
Ralf Corsepius corsepiu at gcc dot gnu.org changed:
What|Removed |Added
CC||corsepiu at gcc dot gnu.org
Known to work||4.7.2
Known to fail||4.8.0
--- Comment #4 from Ralf Corsepius corsepiu at gcc dot gnu.org 2013-03-26
08:30:02 UTC ---
This bug had vanished with gcc-4.7.2, but has returned with gcc-4.8.0:
/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/./gcc/
-nostdinc
-B/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/m32c-rtems4.11/newlib/
-isystem
/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/m32c-rtems4.11/newlib/targ-include
-isystem
/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/gcc-4.8.0/newlib/libc/include
-B/opt/rtems-4.11/m32c-rtems4.11/bin/ -B/opt/rtems-4.11/m32c-rtems4.11/lib/
-isystem /opt/rtems-4.11/m32c-rtems4.11/include -isystem
/opt/rtems-4.11/m32c-rtems4.11/sys-include-g -O2 -mcpu=m32cm -O2
-I../../../../gcc-4.8.0/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-4.8.0/libgcc
-I../../../../gcc-4.8.0/libgcc/. -I../../../../gcc-4.8.0/libgcc/../gcc
-I../../../../gcc-4.8.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
_ffsdi2.o -MT _ffsdi2.o -MD -MP -MF _ffsdi2.dep -DL_ffsdi2 -c
../../../../gcc-4.8.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-4.8.0/libgcc/libgcc2.c: In function '__ffssi2':
../../../../gcc-4.8.0/libgcc/libgcc2.c:522:1: error: unable to find a register
to spill in class 'A_REGS'
}
^
../../../../gcc-4.8.0/libgcc/libgcc2.c:522:1: error: this is the insn:
(insn 58 56 59 10 (set (reg:HI 0 r0 [orig:26 D.2817 ] [26])
(zero_extend:HI (mem/u/j:QI (plus:PSI (subreg:PSI (reg:SI 44 [ D.2818
]) 0)
(symbol_ref:PSI (__clz_tab) [flags 0x40] var_decl
0x7f55b9a14ab0 __clz_tab)) [0 __clz_tab S1 A8])))
../../../../gcc-4.8.0/libgcc/libgcc2.c:520 115 {zero_extendqihi2}
(expr_list:REG_DEAD (reg:SI 44 [ D.2818 ])
(nil)))
../../../../gcc-4.8.0/libgcc/libgcc2.c:522: confused by earlier errors, bailing
out
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu.org |dnovillo at gcc dot gnu.org --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 08:52:38 UTC --- Diego, can you please revert your change then on the trunk for now?
[Bug c++/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 09:09:18 UTC --- Works for me on Solaris 2.10/SPARC, gcc-4.7.2 configured w/ Sun not GNU binutils: g++ -O -c Core.ii g++ -O -c CoreTest.ii g++ Core.o CoreTest.o ./a.out Exception int caught For completeness: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/mikpe/pkgs/sol2-sparc64/gcc-4.7.2/libexec/gcc/sparc-sun-solaris2.10/4.7.2/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /tmp/mikpe/gcc-4.7.2/configure --prefix=/home/mikpe/pkgs/sol2-sparc64/gcc-4.7.2 --with-gmp=/home/mikpe/pkgs/sol2-sparc64/gmp-5.0.5 --with-mpfr=/home/mikpe/pkgs/sol2-sparc64/mpfr-3.1.1 --with-mpc=/home/mikpe/pkgs/sol2-sparc64/mpc-1.0.1 --disable-build-poststage1-with-cxx --disable-libquadmath --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-libgomp --enable-threads --enable-checking=release --enable-version-specific-runtime-libs --with-system-zlib --enable-languages=c,c++,ada --with-cpu=ultrasparc --without-cloog --without-ppl Thread model: posix gcc version 4.7.2 (GCC)
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 09:40:52 UTC --- Also reproducible for arm-linux-gnueabi: 4.8.0 ICEs, 4.7.2 and 4.6.3 don't.
[Bug fortran/56730] [Fortran 4.6, 4.7] ICE on (wrongly) referencing polymorphic array in allocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56730 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2013-03-26 09:43:20 UTC --- (In reply to comment #0) Current 4.8-branch and 4.9-trunk do not ICE. Unless it is a regression in 4.6/4.7, it will probably not be fixed on those branches.
[Bug fortran/56731] [4.7 Regression] ICE on (wrongly) referencing polymorphic array in select type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56731 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 CC||janus at gcc dot gnu.org Summary|[Fortran 4.7] ICE on|[4.7 Regression] ICE on |(wrongly) referencing |(wrongly) referencing |polymorphic array in select |polymorphic array in select |type|type Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2013-03-26 09:52:13 UTC --- I can confirm the ICE with 4.7. Trunk gives: select type(an = carr%c) 1 Error: Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute at (1) I have not checked 4.6.
[Bug target/49423] [4.6/4.7/4.8/4.9 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-26
10:03:51 UTC ---
Another testcase for -march=armv7-a -O2, ICEs with both trunk and 4.8 branch
(reduced from https://bugzilla.redhat.com/show_bug.cgi?id=927565 ):
const int a, b[4][256], c[4][256];
int
foo (unsigned *x)
{
unsigned d[9];
x[55] = c[0][d[7] 0xff] ^ c[3][d[7] 0xff];
d[0] = (b[0][d[7] 0xff] ^ b[1][(d[7] 16) 0xff] ^ b[2][d[7] 0xff] ^
b[3][d[7] 0xff]) ^ a;
x[48] = c[0][d[0] 0xff] ^ c[1][(d[0] 8) 0xff] ^ c[2][(d[0] 16)
0xff] ^ c[3][d[0] 24];
x[49] = c[0][d[1] 0xff] ^ c[1][(d[1] 8) 0xff] ^ c[2][d[1] 0xff] ^
c[3][d[1]];
d[4] = b[0][0xff] ^ b[1][8] ^ b[3][d[3] 24];
x[44] = c[0][d[4] 0xff] ^ c[1][(d[4] 8) 0xff] ^ c[2][(d[4] 16)
0xff] ^ c[3][d[4] 24];
d[5] ^= d[4];
x[45] = c[0][d[5] 0xff] ^ c[1][d[5]] ^ c[2][(d[5] 16) 0xff] ^
c[3][(d[5] 24) 0xff];
d[6] ^= d[5];
x[46] = c[0][d[6] 0xff] ^ c[3][d[6] 0xff];
d[7] ^= d[6];
x[47] = c[0][d[7]] ^ c[3][(d[7] 24) 0xff];
}
p debug_rtx (fix-insn)
(insn:TI 6 155 156 (set (reg:SI 5 r5 [orig:110 D.4236 ] [110])
(zero_extend:SI (mem/u/c:QI (symbol_ref/u:SI (*.LC0) [flags 0x2]) [0
S1 A8]))) rh927565.i:6 171 {*arm_zero_extendqisi2_v6}
(nil))
If the PR43137 changes removed the pool_range/neg_pool_range attributes from
the instructions incorrectly, can those be added? I mean, for ICE on valid
code with so many dups it is ridiculous to keep it unsolved for almost 3 years
now, out of which the bug is known for almost 2 years.
[Bug fortran/56731] [4.7 Regression] ICE on (wrongly) referencing polymorphic array in select type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56731 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 10:04:17 UTC --- AFAICT this has been fixed by revision 187192 (pr41600). I don't think this is a regression: I get the ICE for 4.5.3, 4.6.3, and 4.7.2 (CLASS is not part of 4.4). I don't know the best way to resolve this PR: WONTFIX or FIXED?
[Bug fortran/56731] [4.7 Regression] ICE on (wrongly) referencing polymorphic array in select type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56731 --- Comment #3 from janus at gcc dot gnu.org 2013-03-26 10:06:53 UTC --- (In reply to comment #2) I don't know the best way to resolve this PR: WONTFIX or FIXED? FIXED I would say (provided the behavior on trunk is ok).
[Bug fortran/56735] New: Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 Bug #: 56735 Summary: Namelist Read Error with question marks Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: madawilli...@gmail.com Hi, This is my first ever bug report so apologies if i miss some vital piece of information. I have some legacy code which compiles and runs with versions of gfortran up to 4.5. However after this the code compiles and runs but the namelist is not read correctly. There is no IO errors but non of the variables are set to their respective values. I have managed to narrow this down to the fact that the legacy namelist has question marks in the namelist file outside of any data block. Below is a very simple code and namelist which shows this. If you remove the question mark from the name list the values are set, otherwise they are not. -test.f PROGRAM TEST INTEGER int1,int2,int3 NAMELIST /temp/ int1,int2,int3 OPEN (53,FILE='test.nam',STATUS='OLD', IOSTAT=istat) READ (53,temp) WRITE(*, temp) PRINT*, istat END PROGRAM -test.nam ? $temp int1=1 int2=2 int3=3 $END I understand this might be non standard formatting for the namelist file, but as I said it works with gfortran 4.6 so seems like a regression.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #52 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 10:09:52 UTC --- (In reply to comment #51) (struct mem_ref): Replace mem member with ao_ref typed member. RTL gcse (-O2) suffers from the same slowness in its dependence tests. Caching ao_ref instead of just mem and alias-set in RTL mem-attrs would improve this tremendously. A quick try reveals that gengtype is not at all happy with including something in rtl.h though :/ Doing that (caching the ao_ref) doesn't help as much as it did on the GIMPLE level. The most time-consuming part of canon_true_dependence (which consumes 56% of compile-time) is find_base_term (37% of that 56%) followed by memrefs_conflict_p and only then (after caching ao_ref) rtx_refs_may_alias_p (18%). The find_base_term result is another thing that could be easily cached when doing dependence checks that repeatedly use one or another operand. For this testcase the most expensive caller is compute_transp. There is some obvious way to do less find_base_term calls in alias.c itself. I'm going to cleanup things there a bit.
[Bug tree-optimization/56270] [4.6 Regression] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3 Summary|[4.6/4.7 Regression] loop |[4.6 Regression] loop over |over array of struct float |array of struct float |causes compiler error: |causes compiler error: |segmentation fault |segmentation fault Known to fail||4.7.2 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 10:15:31 UTC --- Author: rguenth Date: Tue Mar 26 10:12:52 2013 New Revision: 197096 URL: http://gcc.gnu.org/viewcvs?rev=197096root=gccview=rev Log: 2013-03-26 Richard Biener rguent...@suse.de Backport from mainline 2013-03-13 Richard Biener rguent...@suse.de PR tree-optimization/56608 * tree-vect-slp.c (vect_schedule_slp): Do not remove scalar calls when vectorizing basic-blocks. * gcc.dg/vect/fast-math-bb-slp-call-3.c: New testcase. 2013-03-05 Richard Biener rguent...@suse.de PR tree-optimization/56270 * tree-vect-slp.c (vect_schedule_slp): Clear vectorized stmts of loads after scheduling an SLP instance. * gcc.dg/vect/slp-38.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/fast-math-bb-slp-call-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/slp-38.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/56608] [4.7 Regression] SLP seems to produce incorrect value with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56608 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.3 Resolution||FIXED Known to fail|4.7.3 |4.7.2 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 10:16:08 UTC --- Author: rguenth Date: Tue Mar 26 10:12:52 2013 New Revision: 197096 URL: http://gcc.gnu.org/viewcvs?rev=197096root=gccview=rev Log: 2013-03-26 Richard Biener rguent...@suse.de Backport from mainline 2013-03-13 Richard Biener rguent...@suse.de PR tree-optimization/56608 * tree-vect-slp.c (vect_schedule_slp): Do not remove scalar calls when vectorizing basic-blocks. * gcc.dg/vect/fast-math-bb-slp-call-3.c: New testcase. 2013-03-05 Richard Biener rguent...@suse.de PR tree-optimization/56270 * tree-vect-slp.c (vect_schedule_slp): Clear vectorized stmts of loads after scheduling an SLP instance. * gcc.dg/vect/slp-38.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/fast-math-bb-slp-call-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/slp-38.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-slp.c
[Bug fortran/56735] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 10:17:25 UTC --- It works for me (x86_64-apple-darwin10) from 4.4.6 up to the latest trunk (197095). On which platform do you see this problem (post the output of gfortran -v)?
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2013-03-26 10:18:00 UTC --- Unfortunately, Andrew Pinski's patch from PR debug/51471 doesn't help this time.
[Bug web/56736] New: Broken link in http://gcc.gnu.org/gcc-4.8/changes.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56736 Bug #: 56736 Summary: Broken link in http://gcc.gnu.org/gcc-4.8/changes.html Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: felix.gerzag...@gmail.com Hi, in the IA-32/x86-64 section I quote: Please refer to the user manual for the list of valid CPU names recognized. The link under the user manual words point to http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions which does no exists. By the way, the page http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html does not exists either.
[Bug c++/55951] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed|2013-01-28 00:00:00 |2013-03-26 0:00 CC||doko at gcc dot gnu.org Known to fail||4.7.3, 4.8.0 --- Comment #2 from Matthias Klose doko at gcc dot gnu.org 2013-03-26 10:23:48 UTC --- [forwarding from http://bugs.debian.org/703945] seen with current 4.7 and 4.8 branches. $ g++-4.8 -c -std=c++11 LiczbaTest.ii In file included from LiczbaTest.cpp:1:0: Liczba.hpp:33:45: internal compiler error: in check_array_designated_initializer, at cp/decl.c:4784 Please submit a full bug report,
[Bug middle-end/56712] [4.6 Regression] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 10:24:08 UTC --- (In reply to comment #5) Created attachment 29724 [details] backport of the above mentioned fix Don't base your backport on the original patch submission, base it on the actual commit, r180700. There are differences between the two.
[Bug c++/55951] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org 2013-03-26 10:24:14 UTC --- Created attachment 29727 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29727 preprocessed source
[Bug libstdc++/56733] src/c++98/mt_allocator.cc:620:3: ICE tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56733 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-26 10:26:04 UTC --- Note that essentially by definition an ICE per se cannot be a library issue.
[Bug fortran/56735] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #2 from Adam Williams madawilliams at gmail dot com 2013-03-26 10:26:43 UTC --- Hi Dominique Cheers for the quick response. Here is my gfortran -v info: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin11/4.6.2/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.6.2-RC-20111019/configure --prefix=/usr/local/gfortran --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 --enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin11 Thread model: posix gcc version 4.6.2 20111019 (prerelease) (GCC) With the question mark in the namelist file i get the following output: TEMP INT1= 17252416, INT2= 32767, INT3= 1589168960, / 0
[Bug fortran/56735] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org, tiloschwarz at gcc ||dot gnu.org --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 10:36:13 UTC --- OK, I did look enough to the output. With 4.6.3, I get TEMP INT1= 4160, INT2= 32767, INT3= 1606408400, / 0 and a lot of valgrind errors. With 4.7 up to trunk, I get TEMP INT1= 0, INT2= 0, INT3= 0, / 0 and valgrind complains about ==35182== Conditional jump or move depends on uninitialised value(s) ==35182==at 0x1000ED987: gfc_itoa (in /opt/gcc/gcc4.9w/lib/libgfortran.3.dylib) ==35182==by 0x10EB1: main (in ./a.out)
[Bug c++/55951] [4.8/4.9 Regression] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|ICE in |[4.8/4.9 Regression] ICE in |check_array_designated_init |check_array_designated_init |ializer, at cp/decl.c:4785 |ializer, at cp/decl.c:4785 Known to fail|4.7.3 |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-26 10:37:05 UTC --- On x86_64-linux, I can't confirm current 4_7-branch, neither stock 4.7.2.
[Bug web/56736] Broken link in http://gcc.gnu.org/gcc-4.8/changes.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56736 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-26 10:41:29 UTC --- The correct URL is http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #18 from Diego Novillo dnovillo at gcc dot gnu.org 2013-03-26 10:48:18 UTC --- Sure. But I'm not quite sure which change you are referring to. I see 2 related patches (well, 3 but one is the reversal of the first one). I suppose we are referring to rev 190487? commit 4b9beb88f5d49452a1fb25826c00cd81b7461b04 Author: dnovillo dnovillo@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Aug 17 15:37:57 2012 + 2012-08-17 Diego Novillo dnovi...@google.com PR bootstrap/54281 * configure.ac: Add libintl.h to AC_CHECK_HEADERS list. * config.in: Regenerate. * configure: Regenerate. * intl.h: Always include libintl.h if HAVE_LIBINTL_H is set.git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190487 138bc75d-0d04-0410-961f-82ee72b054a4 commit 2a02178fdd2f016404c835abe988c427207b3f5aAuthor: dnovillo dnovillo@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Aug 16 18:24:22 2012 + 2012-08-16 Diego Novillo dnovi...@google.com Revert PR bootstrap/54281 * double-int.h: Move including of gmp.h ...* system.h: ... here. * realmpfr.h: Do not include gmp.h. * tree-ssa-loop-niter.c: Do not include gmp.h. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190449 138bc75d-0d04-0410-961f-82ee72b054a4 commit f5d9dd2ea4fdacef34156ebc853cfeba4e6f301c Author: dnovillo dnovillo@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Aug 16 13:28:13 2012 + 2012-08-16 Diego Novillo dnovi...@google.com PR bootstrap/54281 * double-int.h: Move including of gmp.h ... * system.h: ... here.* realmpfr.h: Do not include gmp.h. * tree-ssa-loop-niter.c: Do not include gmp.h. fortran/ChangeLog * gfortran.h: Do not include gmp.h. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190444 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/55951] [4.8/4.9 Regression] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-26 10:56:53 UTC --- ce-index is a CONST_DECL in mainline and 4_8-branch, an Ok INTEGER_CST in 4_7-branch.
[Bug tree-optimization/56733] [4.9 regression] src/c++98/mt_allocator.cc:620:3: ICE tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_ty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56733 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target|hppa*-*-* | Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Component|libstdc++ |tree-optimization CC||law at gcc dot gnu.org, ||sch...@linux-m68k.org Host|hppa*-*-* | Ever Confirmed|0 |1 Summary|src/c++98/mt_allocator.cc:6 |[4.9 regression] |20:3: ICE tree check: |src/c++98/mt_allocator.cc:6 |expected integer_type or|20:3: ICE tree check: |enumeral_type or|expected integer_type or |boolean_type or real_type |enumeral_type or |or fixed_point_type, have |boolean_type or real_type |pointer_type in |or fixed_point_type, have |int_fits_type_p, at |pointer_type in |tree.c:8 325|int_fits_type_p, at ||tree.c:8 325 Build|hppa*-*-* | --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2013-03-26 11:01:09 UTC --- 5aa2495016c0a818687c144034572fe29406cd72 is the first bad commit commit 5aa2495016c0a818687c144034572fe29406cd72 Author: law law@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Mar 25 19:05:57 2013 + * tree-ssa-dom.c (record_equivalences_from_incoming_edge): Rework slightly to avoid creating and folding useless trees. Simplify slightly by restricting to INTEGER_CSTs and using int_fits_type_p. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197060 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/56733] [4.9 regression] src/c++98/mt_allocator.cc:620:3: ICE tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_ty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56733 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org 2013-03-26 11:10:50 UTC --- Probably fixed by: From 96a1fa3ac96f6b9339091249b40fd72783532397 Mon Sep 17 00:00:00 2001 From: law law@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue, 26 Mar 2013 04:00:20 + Subject: [PATCH] * tree-ssa-dom.c (record_equivalences_from_incoming_edge): Add missing check for INTEGRAL_TYPE_P that was missing due to checking in wrong version of prior patch. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197082 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/55951] [4.8/4.9 Regression] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-26 11:19:55 UTC --- Let's have a look.
[Bug fortran/56650] Odd error messages with C_SIZEOF for valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56650 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-26 11:22:54 UTC --- Probably due to not simplifying c_sizeof(), cf. PR 36437. Related PR46641 and PR45824
[Bug tree-optimization/56733] [4.9 regression] src/c++98/mt_allocator.cc:620:3: ICE tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_ty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56733 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2013-03-26 11:25:06 UTC --- It is.
[Bug libfortran/56737] New: Bizarre Hollerith edit descriptor errors (valgrind shows uninitialized value in libgfortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 Bug #: 56737 Summary: Bizarre Hollerith edit descriptor errors (valgrind shows uninitialized value in libgfortran) Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jonathan.h...@stfc.ac.uk Created attachment 29728 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29728 Code to reproduce bug With the code attached I get junk output in a real program. Simplified version below only shows errors under valgrind. Easy workaround by transforming code to modern Fortran that doesn't use the h edit descriptor. Yes, the byzantine subroutine hierarchy and unuser arguments appear to be required to reproduce the bug. Expected test-code behaviour: Should produce valgrind-clean code. Shuold perhaps warn that 'h' edit descriptor is obsolescent/deleted (in F95+). Expected real-code behaviour: Shouldn't produce garbage to output. Thanks, Jonathan. $gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-4ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-4ubuntu1) $gfortran -g -o gfort_bug gfort_bug.f90 valgrind ./gfort_bug ==8437== Memcheck, a memory error detector ==8437== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==8437== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==8437== Command: ./gfort_bug ==8437== fmt = ( 3(1H ),6h= ,a 12,i4,6h =) title1= end of level level =1 = end of level 1 = fmt = ( 3(1H ),6h= ,a 12,i4,6h =) title1= end of level level =1 ==8437== Conditional jump or move depends on uninitialised value(s) ==8437==at 0x4F0BB41: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==8437==by 0x400B51: __hsl_mc73_single_MOD_level_print (gfort_bug.f90:56) ==8437==by 0x400B93: __hsl_mc73_single_MOD_multilevel_eig (gfort_bug.f90:40) ==8437==by 0x400BB9: __hsl_mc73_single_MOD_fiedler_graph (gfort_bug.f90:33) ==8437==by 0x400BF9: __hsl_mc73_single_MOD_mc73_fiedler (gfort_bug.f90:17) ==8437==by 0x400C27: MAIN__ (gfort_bug.f90:71) ==8437==by 0x400C5D: main (gfort_bug.f90:62) ==8437== ==8437== Conditional jump or move depends on uninitialised value(s) ==8437==at 0x4F0BB1B: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==8437==by 0x400B51: __hsl_mc73_single_MOD_level_print (gfort_bug.f90:56) ==8437==by 0x400B93: __hsl_mc73_single_MOD_multilevel_eig (gfort_bug.f90:40) ==8437==by 0x400BB9: __hsl_mc73_single_MOD_fiedler_graph (gfort_bug.f90:33) ==8437==by 0x400BF9: __hsl_mc73_single_MOD_mc73_fiedler (gfort_bug.f90:17) ==8437==by 0x400C27: MAIN__ (gfort_bug.f90:71) ==8437==by 0x400C5D: main (gfort_bug.f90:62) ==8437== ==8437== Syscall param write(buf) points to uninitialised byte(s) ==8437==at 0x522C900: __write_nocancel (syscall-template.S:82) ==8437==by 0x4F0ECEC: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==8437==by 0x4F1540E: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==8437==by 0x4F0A726: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==8437==by 0x4F0B008: _gfortran_st_write_done (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==8437==by 0x400B60: __hsl_mc73_single_MOD_level_print (gfort_bug.f90:56) ==8437==by 0x400B93: __hsl_mc73_single_MOD_multilevel_eig (gfort_bug.f90:40) ==8437==by 0x400BB9: __hsl_mc73_single_MOD_fiedler_graph (gfort_bug.f90:33) ==8437==by 0x400BF9: __hsl_mc73_single_MOD_mc73_fiedler (gfort_bug.f90:17) ==8437==by 0x400C27: MAIN__ (gfort_bug.f90:71) ==8437==by 0x400C5D: main (gfort_bug.f90:62) ==8437== Address 0x5c4fc3a is 26 bytes inside a block of size 512 alloc'd ==8437==at 0x4C2B3F8: malloc (in
[Bug regression/56738] New: ICE in c-c++-common/torture/vshuf-v4di.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738 Bug #: 56738 Summary: ICE in c-c++-common/torture/vshuf-v4di.c Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: ktkac...@gcc.gnu.org CC: stevenb@gmail.com Target: arm-none-eabi Created attachment 29729 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29729 Preprocessed file Testcase ICEs on arm-none-eabi when compiled with -O1 (ICEs also with -O2 and -O3) In file included from vshuf-v4di.c:19:0: vshuf-main.inc: In function 'main': vshuf-main.inc:26:1: internal compiler error: in df_insn_delete, at df-scan.c:1162 } ^ 0x634b9c df_insn_delete(rtx_def*) $SOURCE/gcc/gcc/df-scan.c:1162 0x68b98a remove_insn(rtx_def*) $SOURCE/gcc/gcc/emit-rtl.c:4036 0x5f83be delete_insn(rtx_def*) $SOURCE/gcc/gcc/cfgrtl.c:167 0xd335b6 resolve_simple_move $SOURCE/gcc/gcc/lower-subreg.c:1072 0xd338b3 resolve_simple_move $SOURCE/gcc/gcc/lower-subreg.c:923 0xd34a13 decompose_multiword_subregs $SOURCE/gcc/gcc/lower-subreg.c:1563 0xd3528d rest_of_handle_lower_subreg2 $SOURCE/gcc/gcc/lower-subreg.c:1682 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Bisection shows it started with r196977 Cross compiler configured with: Target: arm-none-eabi Configured with: $SOURCE/gcc/configure --target=arm-none-eabi --prefix=$SOURCE/build/install --with-gmp=$SOURCE/build/host-tools --with-mpfr=$SOURCE/build/host-tools --with-mpc=$SOURCE/build/host-tools --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c --with-newlib --with-fpu=neon --with-float=hard --with-arch=armv7-a Thread model: single gcc version 4.9.0 20130322 (experimental) (unknown)
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Summary|Namelist Read Error with|[4.6/4.7/4.8/4.9 |question marks |Regression] Namelist Read ||Error with question marks Ever Confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 11:47:25 UTC --- AFAICT the first (bad) change (i.e., garbage with 4.6) is due to revision 168502 (pr47154). I'll investigate later for the change giving 0. I think you should clean your namelists to use standard conforming formats. Nevertheless gfortran should give the correct answer or reject the file.
[Bug regression/56738] ICE in c-c++-common/torture/vshuf-v4di.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug web/56736] Broken link in http://gcc.gnu.org/gcc-4.8/changes.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56736 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-26 11:56:04 UTC --- Though, of course, it is a bad idea to point to trunk onlinedocs which keeps changing. The link should point into gcc-4.8.0 onlinedocs instead, which isn't going to change anymore.
[Bug regression/56738] ICE in c-c++-common/torture/vshuf-v4di.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 11:57:58 UTC --- I see a similar error on powerpc-*-* (see http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02572.html ) for c-c++-common/torture/vshuf-v2di.c and g++.dg/torture/vshuf-v2di.C. Should I fill a new PR or extend this one to vshuf-v2di.c?
[Bug regression/56738] ICE in c-c++-common/torture/vshuf-v4di.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738 --- Comment #2 from ktkachov at gcc dot gnu.org 2013-03-26 12:07:07 UTC --- (In reply to comment #1) I see a similar error on powerpc-*-* (see http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02572.html ) for c-c++-common/torture/vshuf-v2di.c and g++.dg/torture/vshuf-v2di.C. Should I fill a new PR or extend this one to vshuf-v2di.c? Are you seeing the ICE at the same location? (df-scan.c). Also, from the testresults page you linked I don't see an ICE for -O2 or -O3. Do those run successfully? If you believe they are the same error I think you can add powerpc to the targets in this PR. Regards, Kyrill
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #5 from Adam Williams madawilliams at gmail dot com 2013-03-26 12:14:01 UTC --- Cheers Dominique, Unfortunately the code in question is ~25years old with an existing user base and the namelist is used to set a vast number of initial conditions for varying simulation runs. However, I will definitely suggest that we try move to a standard conforming namelist.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #5 from Kai Koehne kai.koehne at digia dot com 2013-03-26 12:26:04 UTC --- Can confirm that the patch fixes the issue when applied locally.
[Bug regression/56738] [4.9 Regression] ICE in c-c++-common/torture/vshuf-v4di.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|arm-none-eabi |arm-none-eabi powerpc-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Summary|ICE in |[4.9 Regression] ICE in |c-c++-common/torture/vshuf- |c-c++-common/torture/vshuf- |v4di.c |v4di.c Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 12:43:49 UTC --- Are you seeing the ICE at the same location? (df-scan.c). Yes: In file included from /opt/gcc/work/gcc/testsuite/g++.dg/torture/vshuf-v2di.C:18:0: /opt/gcc/work/gcc/testsuite/g++.dg/torture/vshuf-main.inc: In function 'int main()': /opt/gcc/work/gcc/testsuite/g++.dg/torture/vshuf-main.inc:29:1: internal compiler error: in df_insn_delete, at df-scan.c:1162 } Also, from the testresults page you linked I don't see an ICE for -O2 or -O3. Do those run successfully? Yes. The tests compile with revision 197004, but not with revision 197010. It is likely revision 197005.
[Bug libstdc++/56739] New: FreeBSD ia64: gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/mutex:781:41: internl compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56739
Bug #: 56739
Summary: FreeBSD ia64:
gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3
/include/mutex:781:41: internl compiler error:
Segmentation fault
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: me...@bristol.ac.uk
Building gcc-4.9-20130319 on FreeBSD 10.0-CURRENT #4 r248493 ia64:
/usr/bin/grep -E -v '^[ ]*#(#| |$)' libstdc++-symbols.ver.tmp | \
/usr/ports/lang/gcc49/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc49/work/build/./gcc/
-B/usr/loca/ia64-portbld-freebsd10.0/bin/
-B/usr/local/ia64-portbld-freebsd10.0/lib/ -isystem
/usr/local/ia64-ortbld-freebsd10.0/include -isystem
/usr/local/ia64-portbld-freebsd10.0/sys-include-E -P -inclue ../config.h -
libstdc++-symbols.ver || (rm -f libstdc++-symbols.ver ; exit 1)
rm -f libstdc++-symbols.ver.tmp
In file included from
/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/includ/future:39:0,
from
../../.././../gcc-4.9-20130319/libstdc++-v3/src/c++11/compatibility-thread-c+0x.cc:30:
/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/mutex:
In instantiaton of 'std::call_once(std::once_flag, _Callable, _Args ...)
[with _Callable = void
(std::__futre_base::_State_base::*)(std::functionstd::unique_ptrstd::__future_base::_Result_base,
std::__futre_base::_Result_base::_Deleter(), bool); _Args =
{std::__future_base::_State_base* const,
std:reference_wrapperstd::functionstd::unique_ptrstd::__future_base::_Result_base,
std::__future_bas::_Result_base::_Deleter() ,
std::reference_wrapperbool}]::__lambda0':
/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/mutex:782:32:
requred from 'struct std::call_once(std::once_flag, _Callable, _Args
...) [with _Callable = void
(td::__future_base::_State_base::*)(std::functionstd::unique_ptrstd::__future_base::_Result_base,
td::__future_base::_Result_base::_Deleter(), bool); _Args =
{std::__future_base::_State_base* cnst,
std::reference_wrapperstd::functionstd::unique_ptrstd::__future_base::_Result_base,
std::__uture_base::_Result_base::_Deleter() ,
std::reference_wrapperbool}]::__lambda0'
/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/mutex:782:22:
requred from 'void std::call_once(std::once_flag, _Callable, _Args ...)
[with _Callable = void
(st::__future_base::_State_base::*)(std::functionstd::unique_ptrstd::__future_base::_Result_base,
st::__future_base::_Result_base::_Deleter(), bool); _Args =
{std::__future_base::_State_base* cont,
std::reference_wrapperstd::functionstd::unique_ptrstd::__future_base::_Result_base,
std::__fuure_base::_Result_base::_Deleter() ,
std::reference_wrapperbool}]'
/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/future:358:23:
reqired from here
/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/mutex:781:41:
internl compiler error: Segmentation fault
std::forward_Args(__args)...);
^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gmake[6]: *** [compatibility-thread-c++0x.lo] Error 1
gmake[6]: Leaving directory
`/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3src'
gmake[5]: *** [all-recursive] Error 1
config.log:
http://seis.bris.ac.uk/~mexas/freebsd-ia64-gcc49-config.log
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 13:35:30 UTC --- Started with http://gcc.gnu.org/r188742 or http://gcc.gnu.org/r188743. With r188742 I get: In file included from ploaderhook.c:25:0: /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h: In function 'sprintf': /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h:304:1: error: unrecognizable insn: (jump_insn 23 22 24 2 (simple_return) /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h:304 -1 (nil) - simple_return) /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h:304:1: internal compiler error: in extract_insn, at recog.c:2130 Starting with r188743 I get: ploaderhook.c: In function 'plh_hook': ploaderhook.c:156:1: internal compiler error: in advance_target_bb, at sched-rgn.c:3466 r188741 was OK.
[Bug debug/56740] New: duplicat DW_TAG_const_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56740
Bug #: 56740
Summary: duplicat DW_TAG_const_type
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org
I used this source, from PR 55608:
static const char *a = opq;
static const char b[8] = rstuv;
static const char *c = b;
static const char *d = b + 3;
static const int e[] = { 1, 2, 3, 4 };
static int f[] = { 5, 6, 7 };
static const int *g = e;
static const int *h = e + 2;
static const int *i = f;
static const int *j = f + 2;
int
main ()
{
const char *p = abcd;
const char *q = efgh;
const char r[] = ijk\0lmn;
const char *s = r;
const char *t = b;
const int *u = e;
const int *v = e + 2;
const int *w = f;
const int *x = f + 2;
return 0;
}
I compiled this with gcc -g -O2, using git master gcc from
yesterday.
The DWARF contains some needless duplication:
1fd: Abbrev Number: 7 (DW_TAG_const_type)
fe DW_AT_type: 0xe6
112f: Abbrev Number: 7 (DW_TAG_const_type)
130 DW_AT_type: 0xe6
[Bug tree-optimization/56741] New: Why not to perform 128-bit vector iteration when vectorizing loop by 256-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56741 Bug #: 56741 Summary: Why not to perform 128-bit vector iteration when vectorizing loop by 256-bit Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: kirill.yuk...@intel.com Created attachment 29730 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29730 Reproducer Hi guys, Suppse we vectorize loop with AVX[2]. E.g.: do i=0..N-1, ++i stmt [i]; enddo If vectorization is allowed possible we'll have something like rem = N % VL /* VL is vector length. */ /* Vectorized loop. */ do i=0..N-rem-1, i+=VL v_stmt [i..i+VL]; enddo /* Remainder. */ do j=0..rem, ++j stmt [j+i]; enddo Remainder maybe unrolled, if allowed. For 128-bit vectors, we have remainder of 3 for floats and 1 for doubles maximum iterations. For 256-bit vectors this number of iterations is 7 and 3 correspondingly. Attached test shows 30% increase in instruction count because of loop remainder maximum iterations count. Why for AVX[2] not to add one iteration on 128-bit registers, having 3 and 1 iteration is remainder? Like this (necessary checks are omitted): rem_1 = N % VL1 /* VL1 is widest vector length - 256-bit. */ /* Vectorized loop. */ do i=0..N-rem_1-1, i+=VL1 v1_stmt[i..i+VL1]; /* Vectorized with 256-bit vector. */ enddo /* Additional iteration. */ v2_stmt [i..(i+VL2)]; /* Vectorized with 128-bit vector. */ rem_2 = rem_1-VL2; /* VL2 is narrow vector length - 128-bit. */ /* Remainder. */ do j=0..rem_2, ++j stmt[j+i]; enddo Here is how to reproduce: $ gcc -static -m64 -fstrict-aliasing -fno-prefetch-loop-arrays -Ofast -funroll-loops -fwhole-program -msse4 ./loop_vers.c -o loop_sse $ gcc -static -m64 -fstrict-aliasing -fno-prefetch-loop-arrays -Ofast -funroll-loops -fwhole-program -mavx ./loop_vers.c -o loop_avx $ sde -icount -- ./loop_sse 7 0.00$$ TID: 0 ICOUNT: 16001317 $ sde -icount -- ./loop_avx 7 0.00$$ TID: 0 ICOUNT: 20847322
[Bug tree-optimization/56741] Epilogue loop not partly vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56741 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Blocks||53947 Summary|Why not to perform 128-bit |Epilogue loop not partly |vector iteration when |vectorized |vectorizing loop by 256-bit | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 14:22:55 UTC --- Confirmed, but a very special case which will be difficult to handle. Note that we need to know enough about the number of iterations of the epilogue loop to make this even worthwhile (you'd peel a conditional execution of one 128-bit vectorized iteration).
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 Known to fail||4.8.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 14:23:57 UTC --- Thus, confirmed.
[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 CC||hubicka at gcc dot gnu.org Summary|[4.7/4.8] |Recursive call goes through |[missed-optimization] |the PLT unnecessarily |Recursive call goes through | |the PLT unnecessarily | Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 14:26:21 UTC --- Confirmed. We don't optimize callgraph cycles with one externally visible entry that way. And I believe we currently have no way of annotating a single call to resolve locally. Honza?
[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-26 14:27:03 UTC --- Confirmed.
[Bug c++/54359] [C++0x] decltype in member function's trailing return type when defined outside of class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54359 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.1 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-26 14:28:45 UTC --- Fixed for 4.8.1.
[Bug c++/56617] c++ compiler error when trying to build SuperCollider with nova-simd extension on arm ubuntu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56617 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-26 14:29:37 UTC --- I've not been able to reproduce this, and looking at your log, I see: c++: internal compiler error: Killed (program cc1plus) Which sounds like its been killed by the system, rather than hit a real internal fault. That makes me wonder if you've got enough memory for the compilation -- it certainly uses quite a lot on my board.
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.1 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2013-03-26 14:31:48 UTC --- Closing.
[Bug fortran/56649] ICE gfc_conv_structure with MERGE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56649 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-26 14:53:09 UTC --- Author: burnus Date: Tue Mar 26 14:51:56 2013 New Revision: 197109 URL: http://gcc.gnu.org/viewcvs?rev=197109root=gccview=rev Log: 2013-03-26 Tobias Burnus bur...@net-b.de PR fortran/56649 * simplify.c (gfc_simplify_merge): Simplify more. 2013-03-26 Tobias Burnus bur...@net-b.de PR fortran/56649 * gfortran.dg/merge_init_expr_2.f90: New. * gfortran.dg/merge_char_1.f90: Modify test to stay a run-time test. * gfortran.dg/merge_char_3.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/merge_init_expr_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/merge_char_1.f90 trunk/gcc/testsuite/gfortran.dg/merge_char_3.f90
[Bug fortran/56649] ICE gfc_conv_structure with MERGE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56649 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-26 14:53:24 UTC --- FIXED on the 4.9 trunk.
[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org 2013-03-26 14:58:07 UTC --- PR 56738 possible related? Similar ICE on arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738
[Bug bootstrap/56689] [4.9 Regression] internal compiler error: in get_loop_body, at cfgloop.c:841
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56689 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-03-26 15:08:33 UTC --- Patch fixes the problem for me. Thanks!
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2013-03-26 15:14:30 UTC --- Created attachment 29731 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29731 patch to add clobbers This patch adds the clobber assignments as Jakub suggested, but the back end isn't prepared for clobbers of things other than VAR_DECLs, so the test ICEs in gimplification. More back end work is needed.
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Attachment #29731|0 |1 is obsolete|| --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2013-03-26 15:20:10 UTC --- Created attachment 29732 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29732 clobber the whole object Actually, I guess he was suggesting clobbering all of *this, not just the vptrs, which makes sense since the object is dead at the end of its destructor. This patch still needs more back end work to be useful.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-26 15:20:34 UTC --- vectorizable_condition gets this stmt: patt_10 = i.1_17 == 0 ? 1 : 0; We can't do just if (TYPE_UNSIGNED (TREE_TYPE (vectype))) return false; which quashes the ICE because that prevents also vectorizing a lot of other things ...
[Bug c++/56742] New: Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
Bug #: 56742
Summary: Optimization bug lead to uncaught throw
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org
Target: x86_64-w64-mingw32, x86_64-pc-cygwin
Hi,
the following testcase:
#include string
static int main_worker(int argc)
{
std::string s[32]; // [31] = no segfault
if (argc 2)
throw 42;
return argc;
}
int main(int argc, char **argv)
{
try {
return main_worker(argc);
}
catch (int i) {
return i;
}
}
produces with optimization -O2 on execution the message:
terminate called after throwing an instance of 'int'
and abort gets called.
If compiled with optimization level -O1, execution works as expected.
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 Known to fail||4.8.0
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2013-03-26 16:03:04 UTC --- Created attachment 29733 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29733 Untested patch I was thinking about something like this. In 4.8, I added vec_cond_expr expansion when the condition is not a comparison but a signed integer. I didn't notice that the vectorizer was generating comparisons with an unsigned result. In 4.9 I added some folding of vec_cond_expr, which ended up folding the comparison to a constant (still unsigned) and now cannot be expanded. What I do in the patch is make the vectorizer generate a signed result. An alternative would be to change the decision that vec_cond_expr expects a signed first argument. Note as well that we reach expand with a vec_cond_expr with 3 constant arguments, so there is a missed optimization there.
[Bug target/55033] [4.6/4.7/4.8/4.9 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 --- Comment #5 from Joel Sherrill joel at gcc dot gnu.org 2013-03-26 16:11:46 UTC --- Per http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00970.html would it be OK to get this committed to the 4.8 branch and head?
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 --- Comment #3 from Jan Hubicka hubicka at ucw dot cz 2013-03-26 16:12:27 UTC --- Confirmed. We don't optimize callgraph cycles with one externally visible entry that way. And I believe we currently have no way of annotating a single call to resolve locally. Honza? The canonical way to do it is to create a static alias and the redirect call to the alias. We do that in FE for some specific examples (like thunks) but not in general. Doing so would indeed make sense. Honza
[Bug fortran/56743] New: Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 Bug #: 56743 Summary: Namelist bug with comment and no blank Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Reduced test case (inspired by the one in PR 56660), originally reported by Kai Gallmeister: integer :: value = 100 namelist /nml/ value write (*, nml=nml) open (99, file='nml.dat', status=replace) write(99,*) nml write(99,*) value=1!11 write(99,*) / rewind(99) read (99, nml=nml) write (*, nml=nml) close (99, status=delete) end Output with 4.3, 4.7 and trunk (haven't tried other versions): NML VALUE=100, / NML VALUE=100, / Expected output: NML VALUE=100, / NML VALUE= 1, / The fact that there is no blank between the number and the comment should not make any difference, right? Unfortunately it does ...
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-26 16:20:39 UTC --- (In reply to comment #6) Created attachment 29733 [details] Untested patch I was thinking about something like this. In 4.8, I added vec_cond_expr expansion when the condition is not a comparison but a signed integer. I didn't notice that the vectorizer was generating comparisons with an unsigned result. In 4.9 I added some folding of vec_cond_expr, which ended up folding the comparison to a constant (still unsigned) and now cannot be expanded. What I do in the patch is make the vectorizer generate a signed result. An alternative would be to change the decision that vec_cond_expr expects a signed first argument. Ah, yes, that's nice. Thanks for explanation. BTW, it passes make RUNTESTFLAGS=vect.exp check-gcc. Note as well that we reach expand with a vec_cond_expr with 3 constant arguments, so there is a missed optimization there. Yep. Maybe something for fold_ternary?
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 16:27:26 UTC --- Confirmed.
[Bug fortran/56744] New: [meta-bug] Namelist bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 Bug #: 56744 Summary: [meta-bug] Namelist bugs Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org
[Bug c++/55951] [4.8/4.9 Regression] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.8.1 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-26 16:50:29 UTC --- Fixed in mainline so far.
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-26 16:57:53 UTC --- Created attachment 29734 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29734 Draft patch (only for read_integer) Draft patch - fixes the issue of the test case, but one probably should do an audit of the whole file (list_read). For instance, using REAL instead of INTEGER in the test case also fails. One probably does not need to handle all CASE_SEPARATORS, but presumably a large number of those.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-26
17:05:12 UTC ---
Note it would need to be done with lots of care, because you can e.g. have
aliases to the function and in that case you should go through the PLT:
__attribute__((noinline, noclone))
void f(short b)
{
f(0);
}
static void g (short) __attribute__ ((alias (f)));
void
h ()
{
g (0);
}
Because the global scope f can be in different shared library, but if you call
h () and is defined only in this CU, you call this CU's f, no the globally
visible one.
[Bug fortran/56731] [4.7 Regression] ICE on (wrongly) referencing polymorphic array in select type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56731 --- Comment #4 from tiloschwarz at gcc dot gnu.org 2013-03-26 17:05:47 UTC --- (In reply to comment #2) AFAICT this has been fixed by revision 187192 (pr41600). I don't think this is a regression: I get the ICE for 4.5.3, 4.6.3, and 4.7.2 (CLASS is not part of 4.4). Interesting, I get no ICE with 4.6.3 (I used the installed compiler on Debian, maybe it is a somehow patched version? Probably a bad idea to use an installed compiler to test this ...): % uname -a Linux dellschleppa 3.2.0-4-686-pae #1 SMP Debian 3.2.39-2 i686 GNU/Linux % cat /etc/debian_version 7.0 % gfortran-4.6 -v polymorph2.f08 Driving: gfortran-4.6 -v polymorph2.f08 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/lib/gcc/i486-linux-gnu/4.6/f951 polymorph2.f08 -quiet -dumpbase polymorph2.f08 -mtune=generic -march=i586 -auxbase polymorph2 -version -fintrinsic-modules-path /usr/lib/gcc/i486-linux-gnu/4.6/finclude -o /tmp/ccUKC6Je.s GNU Fortran (Debian 4.6.3-14) version 4.6.3 (i486-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (Debian 4.6.3-14) version 4.6.3 (i486-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 polymorph2.f08:20.12: c = an 1 Error: Incompatible ranks 0 and 1 in assignment at (1)
[Bug rtl-optimization/56745] New: [4.8/4.9 Regression] ICE in merge_if_block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56745
Bug #: 56745
Summary: [4.8/4.9 Regression] ICE in merge_if_block
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
unsigned char a[6];
void
foo ()
{
int i;
for (i = 5; i = 0; i++)
{
if (++a[i] != 0)
break;
++a[i];
}
}
ICEs on arm-linux-gnueabi at -O2 with:
rh927931.i: In function ‘foo’:
rh927931.i:13:1: internal compiler error: in merge_if_block, at ifcvt.c:3188
}
^
0xcd8a6c merge_if_block
../../gcc/ifcvt.c:3187
0xcd8a6c cond_exec_process_if_block
../../gcc/ifcvt.c:706
0xcdc23e cond_exec_find_if_block
../../gcc/ifcvt.c:3578
0xcdc23e find_if_header
../../gcc/ifcvt.c:3261
0xcdc23e if_convert
../../gcc/ifcvt.c:4381
0xcdc438 rest_of_handle_if_after_reload
../../gcc/ifcvt.c:4527
, 4.7 didn't ICE.
[Bug rtl-optimization/56745] [4.8/4.9 Regression] ICE in merge_if_block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56745 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target||arm-linux-gnueabi Target Milestone|--- |4.8.1
[Bug c++/56746] New: 4.8 regression: increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 Bug #: 56746 Summary: 4.8 regression: increased memory usage when compiling C++ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com On my C++ project I have observed significant increased memory usage between GCC 4.6/4.7 and 4.8. Unfortunately I do not have a testcase, but compiling the test core.utility.functions.whereij.unit of my template-heavy project NT2 (https://github.com/MetaScale/nt2) gives the following results: g++-4.7 User time (seconds): 155.76 System time (seconds): 4.62 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:40.58 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2781396 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 121 Minor (reclaiming a frame) page faults: 726987 Voluntary context switches: 288 Involuntary context switches: 547 Swaps: 0 File system inputs: 31104 File system outputs: 15320 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 g++-4.8 User time (seconds): 155.13 System time (seconds): 6.50 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:41.68 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 3972292 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 1048923 Voluntary context switches: 11 Involuntary context switches: 576 Swaps: 0 File system inputs: 0 File system outputs: 12368 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 So it goes from 2.65GB to 3.79GB. Details of the versions used below. $ g++-4.7 -v Using built-in specs. COLLECT_GCC=g++-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) $ g++-4.8 -v Using built-in specs. COLLECT_GCC=g++-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.0-1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.0 (Debian 4.8.0-1)
[Bug c++/45282] wrong decltype result for .*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45282 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/16375] decltype in class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16375 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.4.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-26 18:12:15 UTC --- typeof is deprecated in favor of C++11 decltype. The first testcase works in 4.4 if you use decltype instead of typeof. The second testcase is ill-formed because there is no 'this' outside of a member function/non-static data member initializer.
[Bug c++/51157] [C++0x] decltype/typeof of template member with default template argument confuses g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51157 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-26 18:15:52 UTC --- We now give the correct error *.C:13:30: error: decltype cannot resolve address of overloaded function If you change decltype(Shellint::getId) a; to decltype(Shellint::getId) a; it will work.
[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2013-03-26 18:29:16 UTC --- The failure only occurs in 32 bit mode and would not have been seen by a default bootstrap on powerpc64-linux that did not run the testsuite in 32 bit mode. $ ./xgcc -B./ -O1 -m32 /home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c In file included from /home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c:15:0: /home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-main.inc: In function ‘main’: /home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-main.inc:26:1: internal compiler error: in df_insn_delete, at df-scan.c:1162 } ^ 0x1029cabb df_insn_delete(rtx_def*) /home/dje/src/gcc/gcc/df-scan.c:1162 0x1030d4b7 remove_insn(rtx_def*) /home/dje/src/gcc/gcc/emit-rtl.c:3972 0x102490b3 delete_insn(rtx_def*) /home/dje/src/gcc/gcc/cfgrtl.c:167 0x10af3c33 resolve_simple_move /home/dje/src/gcc/gcc/lower-subreg.c:1072 0x10af3a83 resolve_simple_move /home/dje/src/gcc/gcc/lower-subreg.c:923 0x10af4ca7 decompose_multiword_subregs /home/dje/src/gcc/gcc/lower-subreg.c:1563 0x10af57a3 rest_of_handle_lower_subreg2 /home/dje/src/gcc/gcc/lower-subreg.c:1682 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug lto/56700] Optimizing at compile and link result in different binary size than only optimizing at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56700 uran238 at web dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from uran238 at web dot de 2013-03-26 18:46:25 UTC --- where did you get this info from? From the man page: snip The only important thing to keep in mind is that to enable link-time optimizations the -flto flag needs to be passed to both the compile and the link commands. [...] Additionally, the optimization flags used to compile individual files are not necessarily related to those used at link time. For instance, gcc -c -O0 -flto foo.c gcc -c -O0 -flto bar.c gcc -o myprog -flto -O3 foo.o bar.o This produces individual object files with unoptimized assembler code, but the resulting binary myprog is optimized at -O3. If, instead, the final binary is generated without -flto, then myprog is not optimized. /snip Misleading at best. If the resulting binary is optimized at -O3, but that's not the same as optimizing the individual object files and the resulting binary at -O3, that's definitely worth mentioning. Please clarify that in the man page. It's not just me who concluded that wrong.
[Bug fortran/56730] [Fortran 4.6, 4.7] ICE on (wrongly) referencing polymorphic array in allocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56730
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-03-26
Ever Confirmed|0 |1
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26
19:14:56 UTC ---
The following comment has been mistakenly posted in pr56731#c3:
AFAICT this has been fixed by revision 187192 (pr41600). I don't think this is
a regression: I get the ICE for 4.5.3, 4.6.3, and 4.7.2 (CLASS is not part of
4.4).
I don't know the best way to resolve this PR: WONTFIX or FIXED?
Note that while r187192 contains many changes and does not look suitable for
backporting, the following patch
--- trunk/gcc/fortran/resolve.c2012/05/05 07:59:22187191
+++ trunk/gcc/fortran/resolve.c2012/05/05 08:49:43187192
@@ -4904,14 +4904,19 @@
{
/* F03:C614. */
if (ref-u.c.component-attr.pointer
- || ref-u.c.component-attr.proc_pointer)
+ || ref-u.c.component-attr.proc_pointer
+ || (ref-u.c.component-ts.type == BT_CLASS
+ CLASS_DATA (ref-u.c.component)-attr.pointer))
{
gfc_error (Component to the right of a part reference
with nonzero rank must not have the POINTER
attribute at %L, expr-where);
return FAILURE;
}
- else if (ref-u.c.component-attr.allocatable)
+ else if (ref-u.c.component-attr.allocatable
+|| (ref-u.c.component-ts.type == BT_CLASS
+ CLASS_DATA (ref-u.c.component)-attr.allocatable))
+
{
gfc_error (Component to the right of a part reference
with nonzero rank must not have the ALLOCATABLE
could cure the ICE for 4.7 (to be tested;-).
[Bug fortran/56731] [4.7 Regression] ICE on (wrongly) referencing polymorphic array in select type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56731 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-26 19:17:39 UTC --- AFAICT this has been fixed by revision 187192 (pr41600). I don't think this is a regression: I get the ICE for 4.5.3, 4.6.3, and 4.7.2 (CLASS is not part of 4.4). Interesting, I get no ICE with 4.6.3 (I used the installed compiler on Debian, maybe it is a somehow patched version? Probably a bad idea to use an installed compiler to test this ...): Sorry for the noise, the comment #3 was intended for pr56730. Indeed for this test I see the ICE for 4.7 only.
[Bug middle-end/56712] [4.6 Regression] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Attachment #29724|0 |1 is obsolete|| --- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-03-26 19:18:59 UTC --- Created attachment 29735 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29735 backport of commit r180700 in gcc-4.7 branch OK, now I see... I tested the new patch again. Everything looks good.
[Bug c++/56747] New: throw segfaults on 64bit Cygwin if -O2 (-freorder-blocks) is used with g++ 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56747
Bug #: 56747
Summary: throw segfaults on 64bit Cygwin if -O2
(-freorder-blocks) is used with g++ 4.8.0
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fra...@computer.org
The test program below segfaults during __cxa_throw if -O2 is used. The problem
is possibly related to generation of unwinding-information in conjunction with
-freorder-blocks optimization.
Testcase:
$ uname -srvmo
CYGWIN_NT-6.1 1.7.18(0.263/5/3) 2013-03-26 14:56 x86_64 Cygwin
$ g++ --version
g++ (GCC) 4.8.0
$ cat throw.cc
#include string
static int main_worker(int argc)
{
std::string s[32];
if (argc 2)
throw 42;
return argc;
}
int main(int argc, char **argv)
{
try {
return main_worker(argc);
}
catch (int i) {
return i;
}
}
$ g++ -O1 -o throw throw.cc
$ ./throw; echo $?
42
$ g++ -O2 -o throw throw.cc
$ ./throw; echo $?
Segmentation fault
139
$ g++ -O2 -fno-reorder-blocks -o throw throw.cc
$ ./throw; echo $?
42
$ g++ -O1 -freorder-blocks -g -o throw throw.cc
$ ./throw; echo $?
Segmentation fault
139
$ gdb throw
...
(gdb) r
Starting program: /tmp/throw/throw
[New Thread 4164.0xe58]
[New Thread 4164.0x7e8]
gdb: unknown target exception 0x20474343 at 0x7fefd7c9e5d
Program received signal ?, Unknown signal.
0x07fefd7c9e5d in RaiseException () from
/cygdrive/c/Windows/system32/KERNELBASE.dll
[Bug c++/51440] C++ compiler produces warning for an unnamed struct member: TYPE has a field FIELD whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51440 Martin Richtarsky gcc at martinien dot de changed: What|Removed |Added CC||gcc at martinien dot de --- Comment #3 from Martin Richtarsky gcc at martinien dot de 2013-03-26 20:06:11 UTC --- +1 for the ability to disable this warning. I am compiling a big project with gcc4.8 and this warning is triggered by a header file. Many of the cpp files that include the header are compiled with -Werror. Since I have no way to selectively disable this warning with pragmas in the header the only workaround is removing -Werror from all the cpp files that include the header. If there are any other solutions please let me know.
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||franke at computer dot org --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-26 20:11:28 UTC --- *** Bug 56747 has been marked as a duplicate of this bug. ***
[Bug c++/56747] throw segfaults on 64bit Cygwin if -O2 (-freorder-blocks) is used with g++ 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56747 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-26 20:11:28 UTC --- Dup of bug 56742. *** This bug has been marked as a duplicate of bug 56742 ***
[Bug lto/56700] Optimizing at compile and link result in different binary size than only optimizing at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56700 --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2013-03-26 20:12:42 UTC --- It's not just me who concluded that wrong. Bug 55102.
[Bug c++/51440] Improve message and add an option for warning for an unnamed struct member: TYPE has a field FIELD whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51440 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 CC||manu at gcc dot gnu.org Summary|C++ compiler produces |Improve message and add an |warning for an unnamed |option for warning for an |struct member: TYPE has a |unnamed struct member: TYPE |field FIELD whose type uses |has a field FIELD whose |the anonymous namespace |type uses the anonymous ||namespace Ever Confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-26 20:26:15 UTC --- (In reply to comment #3) +1 for the ability to disable this warning. 1) Invent a descriptive name for the warning, say bla 2) Add -Wbla to gcc/c-family/c.opt, document it in gcc/doc/invoke.texi 3) Change: decl2.c-2335 if (!in_main_input_context ()) decl2.c-2336- warning (0, \ decl2.c-2336+ warning (OPT_Wbla, \ decl2.c:2337:%qT has a field %qD whose type uses the anonymous namespace, decl2.c-2338 type, t); decl2.c-2339 } 4) bootstrap 5) run testsuite, fix failing tests, submit patch to gcc-patches, profit. + Bonus points for improving the message to explain user what is exactly the potential problem. ++ Extra bonus points if the explanation does not include the words internal linkage. (Note that you can do steps 1-4 in your own copy, but it will be broken again in the next release, so it is better to contribute your patch).
[Bug fortran/56748] New: STOP statement + array optional variable causes bogus uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56748 Bug #: 56748 Summary: STOP statement + array optional variable causes bogus uninitialized warning Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu Created attachment 29736 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29736 Sample code producing bogus warning In the attached code, compilation with the following args: gfortran -O2 -fcheck=all -Wall -c test_uninit.f90 ...produces the following warning: test_uninit.f90: In function ‘mysub’: test_uninit.f90:13:0: warning: ‘b.0’ may be used uninitialized in this function [-Wmaybe-uninitialized] print *, b ^ The warning goes away if any of the following modifications are made: *) any of the compilation flags is omitted *) the stop statement in the code is commented out *) the variable 'b' is made non-optional (and the PRESENT check is removed) *) the variable 'b' is made a scalar gfortran -v: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.8.0 20130314 (experimental) (GCC)
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.0 |4.7.3
[Bug lto/56700] Optimizing at compile and link result in different binary size than only optimizing at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56700 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-26 20:51:48 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55102 ***
[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||uran238 at web dot de --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-26 20:51:48 UTC --- *** Bug 56700 has been marked as a duplicate of this bug. ***
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-26 21:14:23
UTC ---
Hmm, yes indeed it is the -freorder-blocks option. One solution is to disallow
after reload for SEH-target to modify jumps.
The following patch fixes the issue for me.
Index: i386.c
===
--- i386.c (Revision 197118)
+++ i386.c (Arbeitskopie)
@@ -3941,6 +3941,19 @@
register_pass (insert_vzeroupper_info);
}
+/* Implement TARGET_CANNOT_MODIFY_JUMPS_P. */
+static bool
+ix86_cannot_modify_jumps_p (void)
+{
+ if (TARGET_SEH reload_completed
+ cfun)
+return true;
+ return false;
+}
+
+#undef TARGET_CANNOT_MODIFY_JUMPS_P
+#define TARGET_CANNOT_MODIFY_JUMPS_P ix86_cannot_modify_jumps_p
+
/* Update register usage after having seen the compiler flags. */
static void
[Bug libstdc++/56170] Extension debug_allocator seems non-compliant w.r.t. rebind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56170 --- Comment #9 from Ami Tavory atavory at gmail dot com 2013-03-26 21:40:03 UTC --- Great, many thanks!
