[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 jimis jimis at gmx dot net changed: What|Removed |Added Attachment #27335|0 |1 is obsolete|| --- Comment #5 from jimis jimis at gmx dot net 2012-05-08 06:37:21 UTC --- Created attachment 27338 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27338 guard.cc compile error
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #6 from jimis jimis at gmx dot net 2012-05-08 06:38:08 UTC --- Created attachment 27339 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27339 preprocessed source
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #7 from jimis jimis at gmx dot net 2012-05-08 06:38:45 UTC --- Parallel compilation confused me, the error is for guard.cc, see the attached log plus the preprocessed source.
[Bug target/53271] powerpc-eabispe build fails with ice on unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53271 --- Comment #1 from Alan Modra amodra at gmail dot com 2012-05-08 06:43:15 UTC --- Created attachment 27340 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27340 proposed patch
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #5 from Mario Baumann mario-baumann at web dot de 2012-05-08 06:48:38 UTC --- I've finished the bi-section - revision 187053 caused the problem. I'm trying to produce a testcase ...
[Bug c++/53274] New: /*struct*/ S (__cdecl * f)(); fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53274
Bug #: 53274
Summary: /*struct*/ S (__cdecl * f)(); fails to compile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sberg...@redhat.com
At least with g++ 4.7.0 --target=i686-w64-mingw32, the compilation unit
struct S { /*struct*/ S (__cdecl * f)(); };
fails with
test.cc:1:34: error: expected identifier before '*' token
test.cc:1:36: warning: '__cdecl__' attribute only applies to function types
[-Wattributes]
test.cc:1:39: error: 'S' declared as function returning a function
All errors and warnings go away when the /*struct*/ is commented in. (And
when removing the __cdecl, it compiles fine with and without the commented-in
struct.)
(This was originally reported to MinGW-w64 at
sourceforge.net/support/tracker.php?aid=3514133.)
[Bug c/53275] New: GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 Bug #: 53275 Summary: GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.si...@hotmail.com Compiling the testcode using gcc-4.4.4 32bit[configure and build it on this same machine sorlais sparc 10] on Sorlais10 Sparc machine. Following error received while compiling using gcc-4.4.4 ../prodStartLicTest/prodStartLicTest.h:643: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h:801: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h:802: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h:803: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h:804: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h: In member function 'int prodStartLicTest::verifyDecryptedText(char*)': ../prodStartLicTest/prodStartLicTest.h:1368: warning: cannot pass objects of non-POD type 'struct std::string' through '...'; call will abort at runtime ../prodStartLicTest/prodStartLicTest.h: In member function 'void prodStartLicTest::prodStartEnumTest(char*, const char*, int, SLIC_STATUS)': ../prodStartLicTest/prodStartLicTest.h:1516: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h: In member function 'void prodStartLicTest::prodStartEnumTest(char*, const char*, int, SLIC_STATUS, int, int)': ../prodStartLicTest/prodStartLicTest.h:1699: warning: deprecated conversion from string constant to 'char*' ../../../nobuilds/bin/fipsld -m32 -o sparc_SunOS_32/release/SuiteMain sparc_SunOS_32/release/SuiteMain.o -L/els/install/staf/lib -lSTAF -L../../../nobuilds/ lib/sparc_SunOS_32/release -lslic -lPoco -lopenssl -lm -lstdc++ ../SlicTestLib/sparc_SunOS_32/release/libSlicTest.a ../../../nobuilds/lib/sparc_SunOS_32/rele ase/libslic.a ../../../nobuilds/key/sparc_SunOS_32/release/slic_devkey.o -lsocket -lnsl Undefined first referenced symbol in file inet_aton ../../../nobuilds/lib/sparc_SunOS_32/release/libPoco.a(IPAddress.o) (symbol belongs to implicit dependency /usr/lib/libr esolv.so.2) sched_get_priority_max ../../../nobuilds/lib/sparc_SunOS_32/release/libPoco.a(Thread.o) sched_get_priority_min ../../../nobuilds/lib/sparc_SunOS_32/release/libPoco.a(Thread.o) ld: fatal: Symbol referencing errors. No output written to sparc_SunOS_32/release/SuiteMain collect2: ld returned 1 exit status make[3]: *** [sparc_SunOS_32/release/SuiteMain] Error 1 make[3]: Leaving directory `/trunk/qa/SuiteMain' make[2]: *** [all] Error 2 make[2]: Leaving directory `/trunk/qa/SuiteMain' make[1]: *** [all_subdirs] Error 1 make[1]: Leaving directory `/trunk/qa' make: *** [all] Error 2 please provide help to resolve the above error.
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #6 from Mario Baumann mario-baumann at web dot de 2012-05-08 07:54:22 UTC --- Created attachment 27341 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27341 c++ source Added testcase (needs include files from boost - http://sourceforge.net/projects/boost/files/boost/1.49.0/ - just extract any tarball). /app2/gcc/4.8.0-20120507-svn187053/x86_64/bin/g++ -v Using built-in specs. COLLECT_GCC=/app2/gcc/4.8.0-20120507-svn187053/x86_64/bin/g++ COLLECT_LTO_WRAPPER=/app2/gcc/4.8.0-20120507-svn187053/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/app2/gcc/4.8.0-20120507-svn187053/x86_64 --enable-languages=c,c++,fortran --disable-nls --with-gmp=/app2/gcc/4.8.0-20120507-svn187053/x86_64/aux --with-mpfr=/app2/gcc/4.8.0-20120507-svn187053/x86_64/aux --with-mpc=/app2/gcc/4.8.0-20120507-svn187053/x86_64/aux --with-ppl=/app2/gcc/4.8.0-20120507-svn187053/x86_64/aux --with-cloog=/app2/gcc/4.8.0-20120507-svn187053/x86_64/aux Thread model: posix gcc version 4.8.0 20120502 (experimental) (GCC) bad: g++ -Iboost_1_49_0/ -c foo.cpp -O2 -m64 bad: g++ -Iboost_1_49_0/ -c foo.cpp -O1 -m64 ok: g++ -Iboost_1_49_0/ -c foo.cpp -O0 -m64 ok: g++ -Iboost_1_49_0/ -c foo.cpp -O2 -m32 Mario.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #8 from Pawel Sikora pluto at agmk dot net 2012-05-08 07:54:18 UTC --- (In reply to comment #7) Good, good, thanks Francois, anybody willing to benchmark the more limited change? changing __glibcxx_check_heap_*pred* reduces timings for me from ~3.25 sec to 0.18sec (for 1 items in pqueue). tested on on intel core-i3-540 with: x86_64-gnu-linux-g++ pq.C -o pq -g2 -static -D_GLIBCXX_DEBUG -O2
[Bug target/53276] New: DWARF-2 line information truncated for MIPS16 thunks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53276
Bug #: 53276
Summary: DWARF-2 line information truncated for MIPS16 thunks
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ma...@linux-mips.org
Target: mips-sde-elf, mips-linux-gnu
Created attachment 27342
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27342
MIPS16: Fix truncated DWARF-2 line information
Recording the bug here so that it's not lost. This was originally reported
here:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01067.html
I have now regression-tested the fix proposed against 4.8.0 20120501, using the
mips-sde-elf target (thanks, Richard, for fixing it), for MIPS32 and MIPS16
multilibs, both endiannesses, with the gcc, g++, libstdc++ and gdb test suites.
I have tested a little-endian n64 MIPS64 multilib as well, but due to
limitations of my environment I could only cover gcc, g++ and libstdc++ test
suites (i.e. no gdb, and no big-endian testing either). All the tests were
successful.
Until recently MIPS16 thunks were not covered by any testing at all, this bug
could have only been triggered manually when doing actual debugging. I have
recently fixed numerous bugs in GDB related to MIPS16 thunk support and as a
part of that added a test case that verifies correct GDB support. GDB relies
on correct line information for function prologues and therefore this bug now
triggers in that test case.
You can restrict the GDB test suite to run gdb.arch/mips16-thunks.exp only to
save time if you want to verify correct support; that test case relies on
MIPS16 execution support in the target -- that includes a MIPS16 execution unit
in the processor used (note QEMU support may not necessarily be reliable enough
to run that test case; I don't know for sure) as well as in the environment
(that includes the rest of the toolchain, any libraries involved and the OS, as
may be necessary). If successful, the test case should score 140 passes.
The original report now follows, I have attached the original fix proposal for
easier retrieval as well.
--
From ma...@codesourcery.com Wed Dec 14 02:58:18 2011
Message-ID: alpine.deb.1.10.1112132001040.5...@tp.orcam.me.uk
Date: Wed, 14 Dec 2011 02:58:03 +
From: Maciej W. Rozycki ma...@codesourcery.com
To: gcc-patc...@gcc.gnu.org
Cc: Richard Sandiford rdsandif...@googlemail.com, Catherine Moore
c...@codesourcery.com
Subject: [PATCH] MIPS16: Fix truncated DWARF-2 line information
Hi,
I've noticed in the presence of a specific MIPS16 function thunk, GCC
fails to emit suitable DWARF-2 location directives, which in turn causes
DWARF-2 line records to provide truncated information. This is probably
best illustrated with an example.
Given the following source code:
$ cat sinfrob16.c
int i;
double sinfrob16(double d)
{
i++;
return d;
}
we get this:
$ mips-linux-gnu-gcc -mips16 -Wa,-call_nonpic -fPIC -G0 -g -S sinfrob16.c
$ cat sinfrob16.s
.section .mdebug.abi32
.previous
.gnu_attribute 4, 1
.abicalls
.text
$Ltext0:
.cfi_sections.debug_frame
.commi,4,4
.align2
.globlsinfrob16
$LFB0 = .
.file 1 sinfrob16.c
.loc 1 4 0
.cfi_startproc
# Stub function for sinfrob16 (double)
.section.mips16.fn.sinfrob16,ax,@progbits
.align2
.setnomips16
.ent__fn_stub_sinfrob16
.type__fn_stub_sinfrob16, @function
__fn_stub_sinfrob16:
.setnoreorder
.cpload$25
.setreorder
.reloc0,R_MIPS_NONE,sinfrob16
la$25,__fn_local_sinfrob16
mfc1$5,$f12
mfc1$4,$f13
jr$25
.end__fn_stub_sinfrob16
__fn_local_sinfrob16 = sinfrob16
.text
.setmips16
.entsinfrob16
.typesinfrob16, @function
sinfrob16:
.frame$17,8,$31# vars= 0, regs= 2/0, args= 0, gp= 0
.mask0x8002,-4
.fmask0x,0
li$2,%hi(_gp_disp)
addiu$3,$pc,%lo(_gp_disp)
sll$2,16
addu$2,$3
save8,$17,$31
$LCFI0 = .
.cfi_def_cfa_offset 8
.cfi_offset 31, -4
.cfi_offset 17, -8
move$17,$sp
$LCFI1 = .
.cfi_def_cfa_register 17
move$28,$2
.loc 1 5 0
move$2,$28
move$24,$2
.loc 1 4 0
sw$5,12($17)
sw$4,8($17)
.loc 1 5 0
move$3,$24
lw$2,%got(i)($3)
lw$2,0($2)
addiu$2,1
move$3,$24
lw$3,%got(i)($3)
move$24,$3
move$3,$24
sw$2,0($3)
.loc 1 6 0
lw$3,12($17)
lw$2,8($17)
move$25,$3
move$24,$2
move$3,$25
move$2,$24
move$25,$3
move$24,$2
.loc 1 7 0
move$3,$25
move
[Bug c/53277] New: Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
Bug #: 53277
Summary: Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and
4.7 but not in previous releases
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jgpall...@gmail.com
Hello:
In this example:
#includestdlib.h
#includestring.h
int main() {
strspn(hello,h);
return 0;
}
I obtain the warning:
test.c:4:5: warning: conversion to ‘size_t’ from ‘int’ may change the sign of
the result [-Wsign-conversion]
using the order:
gcc -Wall -Wextra -Wconversion -O test.c -o test
The warning appears with -O, -O1, -O2 and -O3, but not with -O0. The
warning appears in gcc 4.5, 4.6 and 4.7 but not in previous releases.
This behavior appears too if I do some assign:
#include string.h
#include stdio.h
#include stdlib.h
int main() {
size_t x;
x = strspn(hello,h);
printf(%zd\n, x);
return 0;
}
I think this is a bug
Cheers
[Bug bootstrap/53278] New: [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 Bug #: 53278 Summary: [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Created attachment 27343 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27343 Preprocessed source. ICEs with -O1 and above, but not with -Os. Attempting to bootstrap gcc-4.8-20120506 on armv5tel-linux fails with: /mnt/scratch/objdir48/./gcc/xgcc -B/mnt/scratch/objdir48/./gcc/ -B/mnt/scratch/install48/armv5tel-unknown-linux-gnueabi/bin/ -B/mnt/scratch/install48/armv5tel-unknown-linux-gnueabi/lib/ -isystem /mnt/scratch/install48/armv5tel-unknown-linux-gnueabi/include -isystem /mnt/scratch/install48/armv5tel-unknown-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../.././gcc -I/mnt/scratch/gcc-4.8-20120506/libgcc -I/mnt/scratch/gcc-4.8-20120506/libgcc/. -I/mnt/scratch/gcc-4.8-20120506/libgcc/../gcc -I/mnt/scratch/gcc-4.8-20120506/libgcc/../include -DHAVE_CC_TLS -o _mulvdi3.o -MT _mulvdi3.o -MD -MP -MF _mulvdi3.dep -DL_mulvdi3 -c /mnt/scratch/gcc-4.8-20120506/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /mnt/scratch/gcc-4.8-20120506/libgcc/libgcc2.c: In function '__mulvdi3': /mnt/scratch/gcc-4.8-20120506/libgcc/libgcc2.c:397:1: internal compiler error: in df_uses_record, at df-scan.c:3179 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_mulvdi3.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir48/armv5tel-unknown-linux-gnueabi/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 gcc-4.8-20120422 did bootstrap Ok, 4.8-20120429 failed due to breakage with the armhf dynamic linker changes. Configuration parameters: /mnt/scratch/gcc-4.8-20120506/configure --prefix=/mnt/scratch/install48 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran,ada --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale --build=armv5tel-unknown-linux-gnueabi --disable-plugin --disable-lto --disable-libmudflap --disable-build-poststage1-with-cxx
[Bug c/53275] GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||INVALID --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-08 09:01:23 UTC --- This doesn't look like a compiler issue, probably a missing library according to the error message.
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-08 09:18:01 UTC --- added your patch on top of c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib : (reconfigured) ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib CC=gcc CXX=g++ --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC) configured as above ad got ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [lto1] Error 1 make[3]: *** Waiting for unfinished jobs ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [cc1] Error 1 ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [cc1plus] Error 1 rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/data/newsoft/gcc-trunk' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/data/newsoft/gcc-trunk' make: *** [all] Error 2
[Bug bootstrap/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-08 CC||rsandifo at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-05-08 09:27:59 UTC --- the subreg splitting pass is generating concatn in the insn stream. The manual says this isn't allowed.
[Bug bootstrap/53279] New: [4.8 regression] error: 'convert_tree_comp_to_rtx' defined but not used [-Werror=unused-function] breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53279 Bug #: 53279 Summary: [4.8 regression] error: 'convert_tree_comp_to_rtx' defined but not used [-Werror=unused-function] breaks m68k-linux bootstrap Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Bootstrapping gcc-4.8-20120506 on m68k-linux fails with: /mnt/scratch/objdir48/./prev-gcc/xgcc -B/mnt/scratch/objdir48/./prev-gcc/ -B/mnt/scratch/install48/m68k-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/m68k-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/m68k-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install48/m68k-unknown-linux-gnu/include -isystem /mnt/scratch/install48/m68k-unknown-linux-gnu/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.8-20120506/gcc -I/mnt/scratch/gcc-4.8-20120506/gcc/. -I/mnt/scratch/gcc-4.8-20120506/gcc/../include -I/mnt/scratch/gcc-4.8-20120506/gcc/../libcpp/include -I/mnt/scratch/gcc-4.8-20120506/gcc/../libdecnumber -I/mnt/scratch/gcc-4.8-20120506/gcc/../libdecnumber/dpd -I../libdecnumber /mnt/scratch/gcc-4.8-20120506/gcc/expr.c -o expr.o /mnt/scratch/gcc-4.8-20120506/gcc/expr.c:2358:1: error: 'get_def_for_expr_class' defined but not used [-Werror=unused-function] get_def_for_expr_class (tree name, enum tree_code_class tclass) ^ /mnt/scratch/gcc-4.8-20120506/gcc/expr.c:7380:1: error: 'convert_tree_comp_to_rtx' defined but not used [-Werror=unused-function] convert_tree_comp_to_rtx (enum tree_code tcode, int unsignedp) ^ cc1: all warnings being treated as errors make[3]: *** [expr.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir48/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 gcc-4.8-20120429 did bootstrap Ok. Configuration parameters: /mnt/scratch/gcc-4.8-20120506/configure --prefix=/mnt/scratch/install48 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto --disable-multilib --disable-build-poststage1-with-cxx
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com | --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-08 09:40:23 UTC --- Thanks Pawel. Thus, Francois, I would suggest testing and, if everything goes well, checking-in the small change to mainline and 4.7.x, thus consider the issue resolved in terms of localized performance improvement. Further enhancements will be automatically part of the long term changes Francois is working on.
[Bug bootstrap/53279] [4.8 regression] error: 'convert_tree_comp_to_rtx' defined but not used [-Werror=unused-function] breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53279 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-05-08 09:56:01 UTC --- I believe the get_def_for_expr_class and convert_tree_comp_to_rtx functions should be #ifdef HAVE_conditional_move.
[Bug bootstrap/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/53279] [4.8 regression] error: 'convert_tree_comp_to_rtx' defined but not used [-Werror=unused-function] breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53279 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED CC||matz at gcc dot gnu.org Ever Confirmed|1 |0 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 10:09:49 UTC --- Oh well. Micha - can you investigate? Maybe we fail to properly garbage collect some stuff now?
[Bug lto/48724] Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-05-08 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 10:15:26 UTC --- Ok, you didn't state that Mozilla indeed sets MAKE to 'make -j'. Yes, if that happens there is a problem.
[Bug target/53268] [4.8 Regression] [SH] libstdc++-dg/conformance.exp failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53268 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/53262] ICE compiling busybox 1.19.3 with gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53262 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 10:16:41 UTC --- Fixed then.
[Bug target/44141] Redundant loads and stores generated for AMD bdver1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 10:17:18 UTC --- Which makes this a target bug then. Uros?
[Bug bootstrap/53280] New: s390 bootstrap failure since r186977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53280 Bug #: 53280 Summary: s390 bootstrap failure since r186977 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org SVN revision 186977 seem to have caused: In file included from /build/regtest/gcc-head-build/s390-ibm-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:68:0, from /build/regtest/gcc-head-build/s390-ibm-linux-gnu/libstdc++-v3/include/algorithm:63, from /build/regtest/gcc-head-build/s390-ibm-linux-gnu/libstdc++-v3/include/regex:38, from /build/regtest/gcc-head/libstdc++-v3/src/c++11/regex.cc:25: /build/regtest/gcc-head-build/s390-ibm-linux-gnu/libstdc++-v3/include/functional: In member function ‘std::__regex::_StateIdT std::__regex::_Nfa::_M_insert_accept()’: /build/regtest/gcc-head-build/s390-ibm-linux-gnu/libstdc++-v3/include/functional:2057:63: internal compiler error: tree check: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038 using _Requires = typename enable_if_Cond::value, _Tp::type; ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/53280] [4.8 Regression] s390 bootstrap failure since r186977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53280 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|s390 bootstrap failure |[4.8 Regression] s390 |since r186977 |bootstrap failure since ||r186977
[Bug target/44141] Redundant loads and stores generated for AMD bdver1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141 --- Comment #18 from Uros Bizjak ubizjak at gmail dot com 2012-05-08 10:32:33 UTC --- (In reply to comment #17) Which makes this a target bug then. Uros? Following the explanation in comment #16, I'd say so. Please note that we already implement the radical change, mentioned at the end of the comment, but for TARGET_AVX only (please see *movmode_internal patterns in config/i386/sse.md), and the less radical change with TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL in move patterns. As suggested, we will add T_S_P_S_I_O handling in movu patterns, avoiding mode changes entirely. Also, it looks that vector move patterns need some TLC.
[Bug rtl-optimization/53180] [4.8 Regression] Revision 186378 generates incorrect code for cpu2006 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180 --- Comment #1 from Bernd Schmidt bernds at gcc dot gnu.org 2012-05-08 10:35:21 UTC --- Created attachment 27344 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27344 Candidate patch I think I have a theory of what's going wrong. Can you test this patch?
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2012-05-04 00:00:00 |2012-05-08 AssignedTo|unassigned at gcc dot |matz at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #8 from Michael Matz matz at gcc dot gnu.org 2012-05-08 10:46:38 UTC --- Yep, mine.
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-08 12:03:55 UTC --- Ugh, remove_prop_source_from_use can remove stmts while prev iterator points to them. This has been buggy before, but didn't result in endless loop. I guess instead of using prev/prev_initialized, the loop could gimple_set_uid (stmt, 0) the stmts it is about to process and gimple_set_uid (stmt, 1) stmts that don't need to be processed again, then gsi = prev; could be just replaced by doing gsi_prev (gsi); enough times to reach start of bb or a stmt with uid 1.
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 12:09:05 UTC --- (In reply to comment #9) Ugh, remove_prop_source_from_use can remove stmts while prev iterator points to them. This has been buggy before, but didn't result in endless loop. I guess instead of using prev/prev_initialized, the loop could gimple_set_uid (stmt, 0) the stmts it is about to process and gimple_set_uid (stmt, 1) stmts that don't need to be processed again, then gsi = prev; could be just replaced by doing gsi_prev (gsi); enough times to reach start of bb or a stmt with uid 1. The other way is to try to get away without immediately removing propagated source stmts - the obvious downside is that transforms relying on single-use definitions will be confused by those dead uses (but the scheme how it works now is fragile anyway because we are not sure we visit the stmts in the correct order).
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #11 from Michael Matz matz at gcc dot gnu.org 2012-05-08 12:12:20 UTC --- (In reply to comment #9) I guess instead of using prev/prev_initialized, the loop could gimple_set_uid (stmt, 0) the stmts it is about to process and gimple_set_uid (stmt, 1) stmts that don't need to be processed again, then gsi = prev; could be just replaced by doing gsi_prev (gsi); enough times to reach start of bb or a stmt with uid 1. Yeah, something along these lines. If you get to that, please do, I can't care for this today.
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 12:12:42 UTC --- One way would be to have a queue of propagation sources to be removed and delay the removal until after we have processed the function (the basic block?). Then have a worklist of stmts to re-visit which we initialize from the uses of the stmts we remove. Or something like that ... or simply do not care (though we have a few testcases that depend on this I think)
[Bug c++/53226] memory consumption for heavy template instantiations increased massively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #13 from Michael Matz matz at gcc dot gnu.org 2012-05-08 13:19:42 UTC --- (In reply to comment #10) The other way is to try to get away without immediately removing propagated source stmts - the obvious downside is that transforms relying on single-use definitions will be confused by those dead uses Just for completeness: If we would simply NOP out the to-be-removed statements that would be taken care of. Additionally iterator copies to those non-removed stmts wouldn't break.
[Bug c++/53281] New: poor error message for calling a non-const method from a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281
Bug #: 53281
Summary: poor error message for calling a non-const method from
a const object
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
code
class Foo {
void bar1() {}
void bar2(Foo const foo) {
foo.bar1();
}
};
int main()
{
return 0;
}
/code
When this code is compiled with g++, the following error message is shown:
message
main.c++: In member function ‘const void Foo::bar2(const Foo)’:
main.c++:4:26: error: passing ‘const Foo’ as ‘this’ argument of ‘const void
Foo::bar1()’ discards qualifiers [-fpermissive]
/message
The error message is technically correct. Yet, it is too cryptic and a bit
unhelpful, to the point it may be considered that the point of this error
message is entirely missed.
As an alternative, it would be nice if g++ displayed an error message which
would actually be straight-forward and provided a clear description of the
problem at hand, such as trying to call a non-const method from a const
object.
[Bug c++/53281] poor error message for calling a non-const method from a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281
--- Comment #1 from Rui Maciel rui.maciel at gmail dot com 2012-05-08
13:27:24 UTC ---
The same suggestion applies to the cases where a non-const method is called
from a const method, such as in the example below:
code
class Foo {
void bar1() {}
void bar2() const {
bar1();
}
};
int main()
{
return 0;
}
/code
The same error message is returned:
message
main.c++: In member function ‘void Foo::bar2() const’:
main.c++:4:22: error: passing ‘const Foo’ as ‘this’ argument of ‘void
Foo::bar1()’ discards qualifiers [-fpermissive]
/message
[Bug c++/50359] poor error message for an undeclared identifier in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50359 --- Comment #2 from Rui Maciel rui.maciel at gmail dot com 2012-05-08 13:33:57 UTC --- This issue is still present in g++ 4.6.3.
[Bug c/50476] Warn of pointer set to object whose lifetime is limited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476 --- Comment #1 from Rui Maciel rui.maciel at gmail dot com 2012-05-08 13:35:33 UTC --- This issue is still present in gcc 4.6.3.
[Bug lto/53282] New: lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 Bug #: 53282 Summary: lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch Target: x86_64-unknown-linux-gnu Build: gcc-4_7-branch revision 187276 Created attachment 27345 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27345 directory containing three (very similar) real-life file after pre-compiler step in the following example (not much reduced from a real-life code) a symbol, very similar to others, is made hidden for no good reason. Apparently it also depends on the order of the input files… bzip2 -d ltobug3.tar.bz2 tar -xf ltobug3.tar cd ltobug3/ c++ -fvisibility-inlines-hidden -O2 -flto -shared -fPIC -o bha.so d1.cc d2.cc d3.cc ; nm -C bha.so | grep makeKey | grep -v type 4290 t _ZN3edm10eventsetup15heterocontainer7makeKeyI11DummyRecordNS0_19EventSetupRecordKeyEEET0_v.local.77.4195 4750 W edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKeyDummy2Record, edm::eventsetup::EventSetupRecordKey() 48a0 W edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKeyDepRecord, edm::eventsetup::EventSetupRecordKey() c++ -fvisibility-inlines-hidden -O2 -flto -shared -fPIC -o bha.so d2.cc d1.cc d3.cc ; nm -C bha.so | grep makeKey | grep -v type 48a0 W edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKeyDummyRecord, edm::eventsetup::EventSetupRecordKey() 4750 W edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKeyDummy2Record, edm::eventsetup::EventSetupRecordKey() 49f0 W edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKeyDepRecord, edm::eventsetup::EventSetupRecordKey()
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-08 13:51:34 UTC --- This has nothing to do with -fvisbility-inlines-hidden (well, that might be necessary to trigger it). LTO brings symbols local to ship them to multiple partitions and partition layout (unfortunately, but probably also unavoidably) depends on linker file order.
[Bug target/53283] New: [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283 Bug #: 53283 Summary: [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org, mikest...@comcast.net, tmsri...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 After revision 186789, the following tests are failing on x86_64-apple-darwin10: FAIL: gcc.dg/darwin-cfstring-1.c (test for errors, line 24) FAIL: gcc.dg/darwin-cfstring-1.c (test for errors, line 25) FAIL: gcc.dg/darwin-cfstring-1.c (test for excess errors) FAIL: gcc.dg/darwin-cfstring-2.c built-in function .* requires .* flag (test for errors, line 11) FAIL: gcc.dg/darwin-cfstring-2.c (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O0 (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O1 (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O2 (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -Os (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/darwin-cfstring-3.c -O2 -flto (test for excess errors) FAIL: gcc.target/i386/builtin_target.c (test for excess errors) FAIL: objc.dg/strings/const-cfstring-2.m -fnext-runtime (internal compiler error) FAIL: objc.dg/strings/const-cfstring-2.m -fnext-runtime (test for warnings, line 22) FAIL: objc.dg/strings/const-cfstring-2.m -fnext-runtime (test for warnings, line 23) FAIL: objc.dg/strings/const-cfstring-2.m -fnext-runtime (test for warnings, line 25) FAIL: objc.dg/strings/const-cfstring-2.m -fnext-runtime (test for warnings, line 26) FAIL: objc.dg/strings/const-cfstring-2.m -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O0 -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O1 -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O2 -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O3 -fomit-frame-pointer -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O3 -g -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -Os -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O2 -flto -flto-partition=none -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O2 -flto -fnext-runtime (test for excess errors) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (internal compiler error) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for errors, line 21) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for errors, line 22) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11 (internal compiler error) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11 (test for errors, line 21) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11 (test for errors, line 22) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O0 (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -O0 (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O1 (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -O1 (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O2 (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -O2 (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O3 -fomit-frame-pointer (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O3 -g (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -O3 -g (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -Os (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -Os (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O2 -flto -flto-partition=none (internal compiler error) FAIL: g++.dg/torture/darwin-cfstring-3.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/darwin-cfstring-3.C -O2 -flto (internal compiler error) FAIL:
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-08 14:01:27 UTC --- understood why it is related to the order of the input files. Still that particular symbol shall not be hidden. I've a library with 307 of those symbols, and lto hides only 7 of them!
[Bug target/53283] [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
Component|bootstrap |rtl-optimization
--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-08
14:03:37 UTC ---
Here's a reduced testcase from newlib where I hit the same issue.
struct _reent
{
int _errno;
};
typedef unsigned int wchar_t;
unsigned long long
_wcstoull_r(struct _reent *rptr , const wchar_t *nptr , wchar_t **endptr , int
base)
{
register const wchar_t *s = nptr;
register unsigned long long acc;
register int c;
register unsigned long long cutoff;
register int neg = 0, any, cutlim;
if(base 0
|| base == 1
|| base 36) {
return(0ULL);
}
if ((base == 0 || base == 16)
c == L'0' (*s == L'x' || *s == L'X')) {
c = s[1];
}
if (base == 0)
base = c == L'0' ? 8 : 10;
cutoff = (unsigned long long)(9223372036854775807LL * 2ULL + 1ULL) / (unsigned
long long)base;
for (acc = 0, any = 0;; c = *s++) {
if (iswdigit(c))
break;
if (any 0 || acc cutoff || (acc == cutoff c cutlim))
any = -1;
else {
acc += c;
}
}
if (any 0) {
rptr-_errno = 34;
} else if (neg)
acc = -acc;
}
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #18 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 14:05:56 UTC --- Created attachment 27346 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27346 one set of those checksum files. tar.gz'ed I think this one is from 4.6.1, make bootstrap4-lean
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #19 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 14:07:03 UTC --- Created attachment 27347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27347 another set of those checksum files. tar.gz'ed I think this one is from make bootstrap4
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #20 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 14:08:17 UTC --- Created attachment 27348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27348 3rd set of those checksum files. tar.gz'ed This one is from 4.6.2 (the other two from 4.6.1), just plain make.
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #21 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 14:15:52 UTC --- There are two curious things: 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is normal). 2. I did have a success with 4.6.1 (and I believe with both make/make bootstrap4 or 4-lean) a while ago, therefore I closed the bug. I did not install 4.6.1 at the time but stayed at 4.3.3 (mostly to test and verify the other issues), but now I cannot build 4.6.1 correctly again. The system has not been changed much since then, the only changes I can think of which is relevant is that I installed updated versions of the gcc dependencies (mpfr-3.1.0,mpc-0.9,gmp-5.0.5) from the most updated versions the last time I looked at gcc.
[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-05-08 14:27:43 UTC --- *** Bug 53280 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53280] [4.8 Regression] s390 bootstrap failure since r186977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53280 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-05-08 14:27:43 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53209 ***
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-05-08 14:56:18 UTC --- The patch below appears to trigger the issue but there's a fundamental question as to why lower-subreg generates concatns when the documentation suggests that concat and concatn should only be used in declarations but not in the insn stream. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00423.html
[Bug go/51874] Many libgo testsuite failures on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-05-08 15:08:13 UTC ---
--- Comment #16 from Ian Lance Taylor ian at airs dot com 2012-04-24
16:33:13 UTC ---
At some point, can you update this bug with the current set of test failures
using Go on Irix? No rush.
I've just finished a 4.7 branch bootstrap on IRIX. Test results are at
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00776.html
You can look at the complete build at
columba:/var/gcc/regression/gcc-4.7-branch/6.5-gcc/build.
There are two issues currently breaking the IRIX Go build:
* The configure test for libgo_cv_lib_setcontext_clobbers_tls currently
SEGVs in pthread_join; I don't really know why. I'm currently hacking
around this with the attached patch.
* The last bootstrap failed building libgo:
sysinfo.go:338:78: error: use of undefined type '_rtentry'
make[4]: *** [syscall/syscall.lo] Error 1
_rtentry is only used in
type _llinfo_arp struct { la_next *_llinfo_arp; la_prev *_llinfo_arp; la_rt
*_rtentry; la_hold *_mbuf; la_data *byte; la_asked int32; }
type _route struct { ro_rt *_rtentry; ro_dst _sockaddr; }
both of which seem to be unused otherwise. As another hack, I've
manually commented both lines to allow the bootstrap (which takes
ca. 36 hours) to complete.
After this, the majority of testcases (both gcc and libgo) fail with
throw: gogo setcontext returned
I haven't yet started to investigate what's going on.
Rainer
[Bug go/51874] Many libgo testsuite failures on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 --- Comment #18 from Rainer Orth ro at gcc dot gnu.org 2012-05-08 15:09:32 UTC --- Created attachment 27349 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27349 Hack to avoid IRIX 6.5 libgo_cv_lib_setcontext_clobbers_tls failure
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2012-05-08 15:20:06 UTC --- It appears to me that gcc61 is using the old linuxthreads implementation of pthreads. It may be necessary to use __GTHREAD_MUTEX_INIT_FUNCTION instead of __GTHREAD_MUTEX_INIT, etc, in ext/concurrence.h. This needs to be looked at by a c++ maintainer.
[Bug target/53272] wrong condition-codes for strict-low-part destination and small-integer source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53272 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 15:20:56 UTC --- Author: hp Date: Tue May 8 15:20:52 2012 New Revision: 187283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187283 Log: PR target/53272 * config/cris/cris.c (cris_normal_notice_update_cc): For TARGET_V32, when a constant source operand matches an I constraint, the no CC0 change applies to a register-destination only, not a strict_low_part-destination. Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/cris.c
[Bug target/53272] wrong condition-codes for strict-low-part destination and small-integer source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53272 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 15:21:55 UTC --- Author: hp Date: Tue May 8 15:21:50 2012 New Revision: 187284 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187284 Log: PR target/53272 * gcc.dg/torture/pr53272-1.c, gcc.dg/torture/pr53272-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53272-1.c trunk/gcc/testsuite/gcc.dg/torture/pr53272-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/53272] wrong condition-codes for strict-low-part destination and small-integer source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53272 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 15:27:08 UTC --- Author: hp Date: Tue May 8 15:27:03 2012 New Revision: 187285 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187285 Log: PR target/53272 * config/cris/cris.c (cris_normal_notice_update_cc): For TARGET_V32, when a constant source operand matches an I constraint, the no CC0 change applies to a register-destination only, not a strict_low_part-destination. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/cris/cris.c
[Bug c++/53261] [4.8 Regression] ICE in tree_strip_nop_conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53261 --- Comment #4 from dave.anglin at bell dot net 2012-05-08 15:26:51 UTC --- On 5/7/2012 12:25 PM, manu at gcc dot gnu.org wrote: Could you test on hppa? The patch fixes the compilation error. Actually, I am not sure whether if (!tem || integer_zerop (tem)) is even better. Dave
[Bug target/53272] wrong condition-codes for strict-low-part destination and small-integer source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53272 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 15:28:02 UTC --- Author: hp Date: Tue May 8 15:27:58 2012 New Revision: 187286 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187286 Log: PR target/53272 * gcc.dg/torture/pr53272-1.c, gcc.dg/torture/pr53272-2.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53272-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53272-2.c Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/53272] wrong condition-codes for strict-low-part destination and small-integer source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53272 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.2 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 15:35:20 UTC --- target-bug fixed, no further backports intended.
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-05-08 15:36:03 UTC --- --- Comment #21 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 14:15:52 UTC --- I think there was a misunderstanding: I specificially asked for the smallest of the differing .o files *other than cc1*-checksum.o* since the latter are expected to differ between stages. But for the moment, I think we can do with cc1-checksum.o alone. There are two curious things: 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is normal). That's certainly completely unexpected. I'd ask you to rebuild cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n cc1-checksum.o, then manually add -v -save-temps to the compilation line. Then attach a tarball with the .c and output files and the gcc -v output to see if there are any obvious diffences between the compilations. 2. I did have a success with 4.6.1 (and I believe with both make/make bootstrap4 or 4-lean) a while ago, therefore I closed the bug. I did not Please always try this with a plain make/make bootstrap. I don't currently want to debug issues which might be caused by non-default targets. I don't see why they should be, but please let us stay with the basics. install 4.6.1 at the time but stayed at 4.3.3 (mostly to test and verify the other issues), but now I cannot build 4.6.1 correctly again. The system has not been changed much since then, the only changes I can think of which is relevant is that I installed updated versions of the gcc dependencies (mpfr-3.1.0,mpc-0.9,gmp-5.0.5) from the most updated versions the last time I looked at gcc. This is certainly a problem: the installation guide states Several support libraries are necessary to build GCC, some are required, others optional. While any sufficiently new version of required tools usually work, library requirements are generally stricter. Newer versions may work in some cases, but it's safer to use the exact versions documented. We appreciate bug reports about problems with newer versions, though. The sentence about newer versions is there for a reason. In fact, on Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8. Before using *any* version of gmp/mpfr/mpc with gcc (or for any other purpose), make sure that they pass make check, as prominently stated in e.g. the gmp announcements. Rainer
[Bug target/53272] wrong condition-codes for strict-low-part destination and small-integer source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53272 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 15:37:20 UTC --- oops, have to actually change to resolved, fixed too.
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 Kenneth Zadeck zadeck at naturalbridge dot com changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com --- Comment #4 from Kenneth Zadeck zadeck at naturalbridge dot com 2012-05-08 15:43:37 UTC --- Ramana, I did not write this pass. I believe that iant did. he used concatn and concat as a temp marker in the rtl and if all went well, these are all removed before the pass finishes. Obviously something is no longer going well so we will have to look into it. Kenny
[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-05-08 15:54:15 UTC --- --- Comment #3 from Matt Hargett matt at use dot net 2012-04-23 22:19:35 UTC --- Can you please back port this to 4.6 as well? Running into this on Scientific Linux 6.1 on x64 with GCC 4.6 trunk and latest cloog-isl and ppl. Thanks! Why would this be relevant to Linux/x64? AFAIK use of LANGUAGE_C is a mips-only feature. Rainer
[Bug target/53250] [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250 --- Comment #7 from uros at gcc dot gnu.org 2012-05-08 16:01:59 UTC --- Author: uros Date: Tue May 8 16:01:54 2012 New Revision: 187289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187289 Log: PR target/53250 * config/i386/i386.c (ix86_set_reg_reg_cost): New function. (ix86_rtx_costs): Handle SET. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185 --- Comment #5 from Gary Funck gary at intrepid dot com 2012-05-08 16:01:50 UTC --- Ping. Is there an ETA for a fix for this bug? It is preventing us from being able to merge from the GCC trunk. Thanks.
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-08 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-08 16:02:36 UTC --- Can you attach the preprocessed source? I think the headers have a macro function for strspn .
[Bug target/53250] [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-05-08 16:05:40 UTC --- (In reply to comment #7) Author: uros Date: Tue May 8 16:01:54 2012 New Revision: 187289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187289 Log: PR target/53250 * config/i386/i386.c (ix86_set_reg_reg_cost): New function. (ix86_rtx_costs): Handle SET. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c Oops.
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 --- Comment #23 from Uros Bizjak ubizjak at gmail dot com 2012-05-08 16:10:07 UTC --- Author: uros Date: Tue May 8 16:01:54 2012 New Revision: 187289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187289 Log: PR target/53176 * config/i386/i386.c (ix86_set_reg_reg_cost): New function. (ix86_rtx_costs): Handle SET. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug middle-end/53279] [4.8 regression] error: 'convert_tree_comp_to_rtx' defined but not used [-Werror=unused-function] breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53279 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-08 Component|bootstrap |middle-end AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-08 16:18:26 UTC --- Really these #ifdef on the outside of a function call should be removed. I will go that route instead.
[Bug other/53284] New: Several libatomic tests fail on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53284 Bug #: 53284 Summary: Several libatomic tests fail on 32-bit Solaris/x86 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: r...@gcc.gnu.org Host: i386-pc-solaris2.9, i386-pc-solaris2.1[01] Target: i386-pc-solaris2.9, i386-pc-solaris2.1[01] Build: i386-pc-solaris2.9, i386-pc-solaris2.1[01] With the libatomic build problems on Solaris out of the way, there remain a couple of testsuite failures for the default 32-bit multilib: FAIL: libatomic.c/atomic-compare-exchange-4.c execution test FAIL: libatomic.c/atomic-exchange-4.c execution test FAIL: libatomic.c/atomic-load-4.c execution test FAIL: libatomic.c/atomic-op-4.c execution test FAIL: libatomic.c/atomic-store-4.c execution test FAIL: libatomic.c/generic-2.c execution test It seems all of them SEGV, e.g. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfef823f7 in libat_compare_exchange_8 (mptr=0x8049e68, eptr=0x8049e70, newval=18446744073709551615, smodel=5, fmodel=0) at /vol/gcc/src/hg/trunk/local/libatomic/cas_n.c:41 (gdb) where #0 0xfef823f7 in libat_compare_exchange_8 (mptr=0x8049e68, eptr=0x8049e70, newval=18446744073709551615, smodel=5, fmodel=0) at /vol/gcc/src/hg/trunk/local/libatomic/cas_n.c:41 #1 0xfef823fc in libat_compare_exchange_8 (mptr=0x8049e68, eptr=0x8049e70, newval=18446744073709551615, smodel=5, fmodel=0) at /vol/gcc/src/hg/trunk/local/libatomic/cas_n.c:41 #2 0xfef823fc in libat_compare_exchange_8 (mptr=0x8049e68, eptr=0x8049e70, newval=18446744073709551615, smodel=5, fmodel=0) at /vol/gcc/src/hg/trunk/local/libatomic/cas_n.c:41 #3 0xfef823fc in libat_compare_exchange_8 (mptr=0x8049e68, eptr=0x8049e70, newval=18446744073709551615, smodel=5, fmodel=0) at /vol/gcc/src/hg/trunk/local/libatomic/cas_n.c:41 #4 0xfef823fc in libat_compare_exchange_8 (mptr=0x8049e68, eptr=0x8049e70, newval=18446744073709551615, smodel=5, fmodel=0) at /vol/gcc/src/hg/trunk/local/libatomic/cas_n.c:41 Seems to be infinite recursion. Rainer
[Bug tree-optimization/53226] [4.8 Regression] Endless loop in forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Component|c++ |tree-optimization
Target Milestone|--- |4.8.0
Summary|memory consumption for |[4.8 Regression] Endless
|heavy template |loop in forwprop
|instantiations increased|
|massively |
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-08
16:20:50 UTC ---
Reduced testcase, not template heavy...:
/* PR tree-optimization/53226 */
void
foo (unsigned long *x, char y, char z)
{
int i;
for (i = y; i z; ++i)
{
unsigned long a = ((unsigned char) i) 63UL;
unsigned long b = 1ULL a;
*x |= b;
}
}
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-08 16:35:57 UTC --- LTO works in a way that it first collect whole program and promote all symbols that are not externally visible static. After doing whole program optimization the program is decomposed again into ltrans unit and compiled independently. Symbols used from multiple ltrans unit are made hidden, so the units can refer to it. In your program apparently only those few symbols are crossing boundary of ltrans. So this is really independent thing. You can try to compile with -flto-partition=none. It will take longer but should avoid the hidden symbols. File order independency of partitioning is possible, but I doubt it is desirable design goal. In fact keeping things approximately in the order it was passed to linker makes sense unless compiler knows better. Honza
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #15 from Sriraman Tallam tmsriram at google dot com 2012-05-08 17:09:43 UTC --- On Tue, May 8, 2012 at 2:18 AM, vincenzo.innocente at cern dot ch gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-08 09:18:01 UTC --- added your patch on top of c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib : (reconfigured) ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib CC=gcc CXX=g++ --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC) configured as above ad got ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [lto1] Error 1 make[3]: *** Waiting for unfinished jobs ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' Thanks, I will fix this asap. collect2: ld returned 1 exit status make[3]: *** [cc1] Error 1 ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [cc1plus] Error 1 rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/data/newsoft/gcc-trunk' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/data/newsoft/gcc-trunk' make: *** [all] Error 2 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug target/53283] [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283 Sriraman Tallam tmsriram at google dot com changed: What|Removed |Added CC||tmsriram at google dot com --- Comment #1 from Sriraman Tallam tmsriram at google dot com 2012-05-08 17:23:00 UTC --- The builtin_target.c failure on Darwin seems related to this: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00455.html
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #8 from Daniel Richard G. skunk at iskunk dot org 2012-05-08 18:18:04 UTC --- I did a non-bootstrap build to speed things up a bit. (The system already has GCC 4.5.2.) First: Your patch needs a couple of ;; sprinkled in there :-) Second: With the patch, after working around some unrelated integer-type issues, I get the following error: [...] Making all in include gmake[4]: Entering directory `/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include' mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch /tmp/gcc-4.7.0/_build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.7.0/_build/./gcc -nostdinc++ -L/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-x c++-header -nostdinc++ -g -O2 -I/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/tmp/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \ -o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:102:0: /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:62:13: error: '__gthread_cond_t' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:67:5: error: '__native_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:71:13: error: '__native_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:141:5: error: 'native_handle_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable: In member function 'std::cv_status std::condition_variable::__wait_until_impl(std::unique_lockstd::mutex, const std::chrono::time_point_Clock, _Duration)': /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:157:2: error: '__gthread_time_t' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:157:19: error: expected ';' before '__ts' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:163:28: error: '_M_cond' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:7: error: '__ts' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:11: error: there are no arguments to '__gthread_cond_timedwait' that depend on a template parameter, so a declaration of '__gthread_cond_timedwait' must be available [-fpermissive] /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:11: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) In file included from /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/future:41:0, from /tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:104: /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: At global scope: /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:63:13: error: '__gthread_t' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:70:7: error: 'native_handle_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:76:29: error: expected ')' before '__id' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:174:5: error: 'native_handle_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In constructor 'std::thread::id::id()': /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:73:23: error: class 'std::thread::id' does not have any field named '_M_thread' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In function 'bool std::operator==(std::thread::id, std::thread::id)': /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:36: error: 'class std::thread::id' has no member named '_M_thread' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:51: error: 'class std::thread::id' has no member named '_M_thread' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:60: error: '__gthread_equal' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In function 'bool std::operator(std::thread::id,
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-08 18:42:47 UTC --- My fault (again).
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-05-08 18:52:12 UTC --- trying 4.7.X instead it actually looks very reasonable now. Using -flto=jobserver -fuse-linker-plugin -ftime-report -O3 -march=native -ffast-math -g -ffree-form I get CP2K to build in 4min on a 32 cores server. The time report also looks OK. I'll close this PR as fixed (to issue with 4.8 is tracked in PR 45586).
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2012-05-07 00:00:00 |2012-05-08
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-05-08
18:59:00 UTC ---
(In reply to comment #8)
It appears to me that gcc61 is using the old linuxthreads
implementation of pthreads. It may be necessary to use
__GTHREAD_MUTEX_INIT_FUNCTION instead of __GTHREAD_MUTEX_INIT,
etc, in ext/concurrence.h.
from include/ext/concurrence.h:151-165 (trunk r187249):
public:
__mutex()
{
#if __GTHREADS
if (__gthread_active_p())
{
#if defined __GTHREAD_MUTEX_INIT
__gthread_mutex_t __tmp = __GTHREAD_MUTEX_INIT;
_M_mutex = __tmp;
#else
__GTHREAD_MUTEX_INIT_FUNCTION(_M_mutex);
#endif
}
#endif
}
[Bug rtl-optimization/53180] [4.8 Regression] Revision 186378 generates incorrect code for cpu2006 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |--- --- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org 2012-05-08 19:01:02 UTC --- (In reply to comment #1) Created attachment 27344 [details] Candidate patch I think I have a theory of what's going wrong. Can you test this patch? Yes, that patch fixes the problem. It also fixes benchmark h264ref which also started failing on the same revision.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2012-05-08 19:03:01 UTC --- From gcc61: $ /lib/libc-2.7.so GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.2. Compiled on a Linux 2.6.32-5-parisc system on 2011-01-07. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. Is that old a glibc still supported?
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #11 from dave.anglin at bell dot net 2012-05-08 19:23:48 UTC --- On 5/8/2012 3:03 PM, steven at gcc dot gnu.org wrote: Is that old a glibc still supported? The following still works except for libitm: dave@selway:/lib /lib/libc.so.6 GNU C Library stable release version 2.6.1 (20070803), by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for i686-suse-linux. Compiled by GNU CC version 4.2.1 (SUSE Linux). Compiled on a Linux 2.6.22 system on 2007-10-23. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson NoVersion patch for broken glibc 2.0 binaries Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. Note however that NPTL is being used instead of linuxthreads. I know parisc had switched to NPTL in Debian lenny. It's possible to update to unstable from lenny but it's a bit of work. Dave
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #10 from François Dumont fdumont at gcc dot gnu.org 2012-05-08 19:31:49 UTC --- Ok, I will submit a patch tomorrow generalizing usage of __gnu_debug::__base in debug macros.
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 --- Comment #11 from simon at pushface dot org 2012-05-08 20:01:50 UTC --- (In reply to comment #10) I'm wondering if you could add: # Work around PR50342 BOOT_CFLAGS += -D_FORTIFY_SOURCE=0 to config/mh-darwin and fix the issue. If so, I think that might be the best solution for now. I think this should be safe for ppc and older and newer OSes. If there comes a time when everything just works, the line can be removed later. Let me know. Tried that and it made no difference. This is in a 4.7.0 download. Should I have re-run any of the autoconf etc tools after changing mh-darwin? Or is it that the problem occurs during gcc/configure rather than in the compiler bootstrap?
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #23 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 20:48:25 UTC --- (In reply to comment #22) --- Comment #21 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-05-08 14:15:52 UTC --- I think there was a misunderstanding: I specificially asked for the smallest of the differing .o files *other than cc1*-checksum.o* since the latter are expected to differ between stages. But for the moment, I think we can do with cc1-checksum.o alone. Okay, sorry about that. There are two curious things: 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is normal). That's certainly completely unexpected. I'd ask you to rebuild cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n cc1-checksum.o, then manually add -v -save-temps to the compilation line. Then attach a tarball with the .c and output files and the gcc -v output to see if there are any obvious diffences between the compilations. I'll get round to it when I find some time to do so, soon. 2. I did have a success with 4.6.1 (and I believe with both make/make bootstrap4 or 4-lean) a while ago, therefore I closed the bug. I did not Please always try this with a plain make/make bootstrap. I don't currently want to debug issues which might be caused by non-default targets. I don't see why they should be, but please let us stay with the basics. Out of the three attachments, one is with plain make, the other two, one with bootstrap4 and bootstrap4-lean. (I think I tried them in the order of 4-lean, 4, plain - so you could see which is which from the time stamp). I know what you are saying, that's why I tried it simplier and simpler :-(. install 4.6.1 at the time but stayed at 4.3.3 (mostly to test and verify the other issues), but now I cannot build 4.6.1 correctly again. The system has not been changed much since then, the only changes I can think of which is relevant is that I installed updated versions of the gcc dependencies (mpfr-3.1.0,mpc-0.9,gmp-5.0.5) from the most updated versions the last time I looked at gcc. This is certainly a problem: the installation guide states Several support libraries are necessary to build GCC, some are required, others optional. While any sufficiently new version of required tools usually work, library requirements are generally stricter. Newer versions may work in some cases, but it's safer to use the exact versions documented. We appreciate bug reports about problems with newer versions, though. The sentence about newer versions is there for a reason. In fact, on Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8. Before using *any* version of gmp/mpfr/mpc with gcc (or for any other purpose), make sure that they pass make check, as prominently stated in e.g. the gmp announcements. Rainer Argh :-(. I did run make check on one of them (gmp?) because it says so at the end of make or 'make install', and it finished okay. I can certainly go back - if it is worthwhile. I'll try to re-do the checksum object files first.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #12 from John David Anglin danglin at gcc dot gnu.org 2012-05-08 20:50:01 UTC --- You might try configuring with --disable-libstdcxx-threads. It disables C++11 threads support.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #38 from Oleg Endo olegendo at gcc dot gnu.org 2012-05-08 21:36:35 UTC --- Author: olegendo Date: Tue May 8 21:36:30 2012 New Revision: 187298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187298 Log: PR target/51244 * config/sh/sh.md (*branch_true, *branch_false): New insns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-08 21:42:09 UTC --- Author: rsandifo Date: Tue May 8 21:42:03 2012 New Revision: 187299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187299 Log: gcc/ PR rtl-optimization/53278 * lower-subreg.c (decompose_multiword_subregs): Remove left-over speed_p code from earlier patch. Modified: trunk/gcc/ChangeLog trunk/gcc/lower-subreg.c
[Bug rtl-optimization/53278] [4.8 regression] internal compiler error: in df_uses_record, at df-scan.c:3179 when compiling libgcc2.c __mulvdi3 on armv5tel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-08 21:52:36 UTC --- Fixed.
[Bug c++/53261] [4.8 Regression] ICE in tree_strip_nop_conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53261 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-08 22:14:43 UTC --- Author: manu Date: Tue May 8 22:14:34 2012 New Revision: 187300 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187300 Log: 2012-05-09 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/53261 c-family/ * c-common.c (warn_logical_operator): Check that argument of integer_zerop is not NULL. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c
[Bug c++/53261] [4.8 Regression] ICE in tree_strip_nop_conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53261 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-08 22:18:47 UTC --- It should be fixed now.
[Bug other/53285] New: libibiberty's md5.c builds with warnings with 4.7 and trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53285 Bug #: 53285 Summary: libibiberty's md5.c builds with warnings with 4.7 and trunk Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org when libibiberty's md5.c is built using 4.7 or trunk on x86-linux, the following warning is emitted: md5.c: In function 'md5_finish_ctx': md5.c:119:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] *(md5_uint32 *) ctx-buffer[bytes + pad] = SWAP (ctx-total[0] 3); ^ md5.c:120:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] *(md5_uint32 *) ctx-buffer[bytes + pad + 4] = ^ afaics this is the only warning emitted when building libiberty when built with 4.7 or trunk.
[Bug driver/53286] New: [mingw] improve CreateProcess: No such file or directory error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53286 Bug #: 53286 Summary: [mingw] improve CreateProcess: No such file or directory error message Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com When running GCC on Windows (MinGW), a wide variety of configuration problems exhibit as a symptom the following error message: CreateProcess: No such file or directory For example, one gets this error when compiling a program if cc1plus.exe is missing or in the wrong directory. This error message is unhelpful because it does not say *which* file was not found; as a result, the underlying configuration problem is difficult to diagnose and resolve. Could this error message be modified to include the name of the file that was not found? For example: CreateProcess: cc1plus.exe: no such file or directory
[Bug other/53284] Several libatomic tests fail on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53284 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2012-05-08 22:39:35 UTC --- Can you investigate why configure decides that __atomic_compare_exchange_8 is implemented inline? That it isn't inline is obvious from the recursion. Was the configure change to CFLAGS in fact wrong?
[Bug libitm/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008
--- Comment #3 from Dave Boutcher daveboutcher at gmail dot com 2012-05-08
22:56:23 UTC ---
I just submitted a patch for this one (Issue 6201064)
(http://codereview.appspot.com/6201064/)
Patch included here just for fun:
Index: gcc/trans-mem.c
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index 24073fa..20ed5a0 100644
--- a/gcc/trans-mem.c
+++ b/gcc/trans-mem.c
@@ -4319,6 +4319,9 @@ ipa_tm_create_version_alias (struct cgraph_node *node,
void *data)
record_tm_clone_pair (old_decl, new_decl);
+ /* If someone refers to this function indirectly, mark it needed */
+ if (ipa_ref_list_first_refering (info-old_node-ref_list))
+ ipa_tm_mark_needed_node (info-old_node);
if (info-old_node-needed)
ipa_tm_mark_needed_node (new_node);
return false;
@@ -4372,6 +4375,10 @@ ipa_tm_create_version (struct cgraph_node *old_node)
record_tm_clone_pair (old_decl, new_decl);
cgraph_call_function_insertion_hooks (new_node);
+ /* If someone refers to this function indirectly, mark it needed */
+ if (ipa_ref_list_first_refering (old_node-ref_list))
+ ipa_tm_mark_needed_node (old_node);
+
if (old_node-needed)
ipa_tm_mark_needed_node (new_node);
@@ -4778,8 +4785,13 @@ ipa_tm_execute (void)
No need to do this if the function's address can't be taken. */
if (is_tm_pure (node-decl))
{
-if (!node-local.local)
+if (!node-local.local) {
record_tm_clone_pair (node-decl, node-decl);
+ /* if someone refers to this function other than as a call,
+ mark it needed */
+ if (ipa_ref_list_first_refering (node-ref_list))
+ ipa_tm_mark_needed_node (node);
+}
continue;
}
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 23:24:15 UTC --- Created attachment 27350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27350 preprocessed file with just the (previously) miscompiled function This is basically gcc.dg/torture/pr53272-1.c, here for completeness.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-08 23:41:41 UTC --- Created attachment 27351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27351 Like i2.i (attachment 27350) but with main and auxiliary functions, and always aborting This attachment was an edit-in-progress adding functions to make the test-case runnable, but with an error that isn't in gcc.dg/torture/pr53272-2.c: the foobar function always aborts, making the test-case always abort. This leads to different code being generated for the key function rtc_update_irq_enable. The difference seems to be the same as for calling an explicit or computed noreturn function, which would be an ok optimization if cross-function optimization was wanted. Changing the empty line in foobar to if (foo(x)) as in gcc.dg/torture/pr53272-2.c yields the expected same generated code as for i2.i. So, while it exposes an unwanted optimization, for this case it is benevolent; the goal was add framework to make the case runnable, not aborting. :) Though, I bet I can cook up a C++ case that throws (or C that rethrows) before the aborting call, and the code have the same unwanted difference in presence of the aborting foobar.
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-08 23:48:06 UTC --- You seem to be hitting the logic detecting functions executed just once and making them optimized for size rather than speed. Usual way to avoid it in the testsuite is to put a loop into main().
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Attachment #27351|application/octet-stream|text/plain mime type|| --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-09 00:01:56 UTC --- Comment on attachment 27351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27351 Like i2.i (attachment 27350) but with main and auxiliary functions, and always aborting Correcting type of attachment to text/plain.
