[Bug c++/54101] Using std::declval for types without a default constructor and with a deleted copy constructor errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54101 --- Comment #1 from Marc Glisse 2012-07-27 06:04:09 UTC --- I don't think the issue is with declval, this is probably a dup of the PR saying that ?: has a wrong return type with g++ (can't find the number right now).
[Bug libgcj/54100] Problems building libjava on AIX 5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54100 --- Comment #1 from The Written Word 2012-07-27 04:24:59 UTC --- Tried building 4.7.1 on AIX 6.1 and 7.1 and get a similar error. $ cd /opt/build/china $ bzip2 -dc gcc-4.7.1.tar.bz2 | tar xf - $ mkdir gcc-4.7.1-o $ cd gcc-4.7.1-o $ CONFIG_SHELL=/opt/fsw/bash42/bin/bash /opt/build/china/gcc-4.7.1/configure --enable-nls --with-included-gettext --enable-libgcj --enable-shared --enable-threads --with-local-prefix=/opt/TWWfsw/gcc47 --with-gmp=/opt/TWWfsw/libgmp43 --with-mpfr=/opt/TWWfsw/libmpfr30 --with-mpc=/opt/TWWfsw/libmpc09 --enable-languages=c,c++,fortran,java --with-ecj-jar=/opt/TWWfsw/gcc47/lib/gcj/ecj.jar --with-gxx-include-dir=/opt/TWWfsw/gcc47/include/c++ --prefix=/opt/TWWfsw/gcc47 $ LDR_CNTRL=MAXDATA=0x7000 CONFIG_SHELL=/opt/fsw/bash42/bin/bash LIBPATH=/opt/TWWfsw/libgmp43:/opt/TWWfsw/libmpfr30:/opt/TWWfsw/libmpc09 gmake ... /opt/fsw/bash42/bin/bash ./libtool --tag=GCJ --mode=compile /opt/build/china/gcc-4.7.1-o/./gcc/gcj -B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.7.1-o/./gcc/ -B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/bin/ -B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/lib/ -isystem /opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/include -isystem /opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/sys-include -maix64 -fclasspath= -fbootclasspath=/opt/build/china/gcc-4.7.1/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -maix64 -c -o gnu/java/awt/color.lo -fsource-filename=/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/classpath/lib/classes -MT gnu/java/awt/color.lo -MD -MP -MF gnu/java/awt/color.deps @gnu/java/awt/color.list libtool: compile: /opt/build/china/gcc-4.7.1-o/./gcc/gcj -B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.7.1-o/./gcc/ -B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/bin/ -B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/lib/ -isystem /opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/include -isystem /opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/sys-include -maix64 -fclasspath= -fbootclasspath=/opt/build/china/gcc-4.7.1/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -maix64 -c -fsource-filename=/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/classpath/lib/classes -MT gnu/java/awt/color.lo -MD -MP -MF gnu/java/awt/color.deps @gnu/java/awt/color.list -o gnu/java/awt/.libs/color.o Assembler: /tmp//ccAWagdt.s: line 2049: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2051: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2053: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2057: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2059: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2061: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2069: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2071: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2075: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2081: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2083: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccAWagdt.s: line 2085: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. gmake[5]: *** [gnu/java/awt/color.lo] Error 1 gmake[5]: Leaving directory `/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/libjava' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/opt/build/china/gcc-4.7.1-o' gmake: *** [all] Error 2
[Bug target/54093] ICE in in extract_insn, at recog.c:2129
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54093 --- Comment #5 from Ryan Mansfield 2012-07-27 02:56:45 UTC --- (In reply to comment #4) > Created attachment 27877 [details] > proposed fix > > Please try out this patch. The patch resolves the ICEs, and I didn't see any others problems building a fairly large code. I didn't have a chance to run the gcc regression testsuite though.
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #20 from Chip Salzenberg 2012-07-27 01:00:14 UTC --- Are you talking to me? 'cause I was providing results for the patch already committed to svn, using the code in this very bug description.
[Bug libstdc++/54102] generated html vs. utf8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54102 Benjamin Kosnik changed: What|Removed |Added AssignedTo|unassigned at gcc dot |bkoz at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.2
[Bug libstdc++/54102] New: generated html vs. utf8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54102 Bug #: 54102 Summary: generated html vs. utf8 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@gcc.gnu.org this is just a reminder to fix up the geneated HTML pages. See: http://gcc.gnu.org/ml/gcc/2012-07/msg00224.html and See http://gcc.gnu.org/ml/gcc/2012-04/msg00597.html and http://gcc.gnu.org/ml/gcc/2012-06/msg00125.html
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #19 from Jonathan Wakely 2012-07-27 00:32:54 UTC --- Testcase please.
[Bug c++/54101] New: Using std::declval for types without a default constructor and with a deleted copy constructor errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54101
Bug #: 54101
Summary: Using std::declval for types without a default
constructor and with a deleted copy constructor
errors.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: supercilious.d...@gmail.com
GCC rejects code which using std::declval on some types. From what I can
understand from the C++11 standard, such uses of declval are legal inside
decltype.
Clang accepts this without error. GCC 4.7.1 (and the current 4.8 from the
master branch of the git repository today)
Example:
#include
class NonCopyable
{
public:
// Not default constructable.
NonCopyable ( int )
{
}
NonCopyable ( NonCopyable const& ) = delete;
};
int main ( void )
{
std::common_type::type t(0);
}
fails with:
In file included from
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/bits/move.h:57:0,
from
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/bits/stl_pair.h:61,
from
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/utility:72,
from gccbug.cxx:1:
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/type_traits: In
instantiation of 'struct std::common_type':
gccbug.cxx:16:45: required from here
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/type_traits:1786:29: error:
use of deleted function 'NonCopyable::NonCopyable(const NonCopyable&)'
{ typedef decltype(true ? declval<_Tp>() : declval<_Up>()) type; };
^
gccbug.cxx:10:5: error: declared here
NonCopyable ( NonCopyable const& ) = delete;
^
In file included from
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/bits/move.h:57:0,
from
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/bits/stl_pair.h:61,
from
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/utility:72,
from gccbug.cxx:1:
/home/user/install/VA-HEPHAESTUS/include/c++/4.8.0/type_traits:1786:29: error:
use of deleted function 'NonCopyable::NonCopyable(const NonCopyable&)'
{ typedef decltype(true ? declval<_Tp>() : declval<_Up>()) type; };
^
gccbug.cxx:10:5: error: declared here
NonCopyable ( NonCopyable const& ) = delete;
^
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #16 from Steven Bosscher 2012-07-26 23:52:32 UTC --- Patch post for r177658: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00353.html
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #15 from Steven Bosscher 2012-07-26 23:45:51 UTC --- (In reply to comment #14) > So either we revert the patch at > http://gcc.gnu.org/viewcvs?view=revision&revision=177658 or we add e.g. > clobbers of address register to the check patterns in ia64.md _and_ allow > limited instructions (e.g. ones writing to general or fp regs) for BE_IN_SPEC > speculation in ia64.c, i.e. to be moved up past a speculation check. I think reverting that patch is the right thing to do, iff it completely fixes this problem (i.e. no similar issues lurking...). It may be worth adding a FIXME note with a reference to this PR. Perhaps addressing this problem fully isn't on anyone's TODO list for the moment (ia64...) but if speculation becomes more important in future target then it's nice to know why things look the way they do in the compiler. The second option is more than minor surgery to the ia64 back end, and I think that's more trouble than it's worth at this point. If a bug like this can go undetected for such a long time (almost a year), then test coverage for the ia64 back end is... well... not perfect ;-)
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #18 from Chip Salzenberg 2012-07-26 23:38:34 UTC --- I couldn't say. I don't understand the issue, I'm just reporting results and deploying packages for my fellow devs.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #17 from Paolo Carlini 2012-07-26 22:55:15 UTC --- Because of more rehashing, unrelated to reserve, I suppose?
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #16 from Chip Salzenberg 2012-07-26 22:50:17 UTC --- In my tests, with this patch, 4.7.1 is about 10% slower than 4.6 ... a vast improvement but certainly not parity. ./bench46 1.75s user 0.82s system 99% cpu 2.577 total ./bench47 8.01s user 2.78s system 99% cpu 10.800 total ./bench47+patch 1.95s user 0.80s system 99% cpu 2.764 total
[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #9 from Steven Bosscher 2012-07-26 22:49:16 UTC --- (In reply to comment #8) > Now if we could somehow propagate &10 into the actual argument of the > call statement, IPA-CP should pick it up and propagate it into the > caller. Another alternative is to construct an aggregate jump > function for it when we have them. I'll keep this testcase in mind > when working on them. Shouldn't IPA-CP be able to do this already? It does appear to handle CONST_DECLs already...
[Bug gcov-profile/35568] missing gcov data spoils other files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35568
Steven Bosscher changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work||4.7.1, 4.8.0
Resolution||FIXED
Known to fail||4.6.3
--- Comment #3 from Steven Bosscher 2012-07-26
22:42:35 UTC ---
Hmpf, not very smart to test the system compiler, which was GCC 4.6.3...
GCC 4.7.1 and GCC 4.8.0 work:
+ rm -f gcov_test.gcda gcov_test.gcno
+ cat
+ ./xgcc --version
xgcc (GCC) 4.8.0 20120726 (experimental) [trunk revision 189890]
Copyright (C) 2012 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.
+ ./gcov --version
gcov (GCC) 4.8.0 20120726 (experimental) [trunk revision 189890]
Copyright (C) 2012 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.
+ ./xgcc -B. gcov_test.c -o gcov_test -fprofile-arcs -ftest-coverage
+ ./gcov_test
+ ./gcov gcov_test.c
File 'gcov_test.c'
Lines executed:100.00% of 2
Creating 'gcov_test.c.gcov'
+ cat gcov_test.c.gcov
-:0:Source:gcov_test.c
-:0:Graph:gcov_test.gcno
-:0:Data:gcov_test.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main()
-:2:{
1:3: return 0;
-:4:}
+ rm gcov_test.c.gcov
+ touch gcov_test2.c
+ ./gcov gcov_test.c gcov_test2.c
gcov_test2.gcno:cannot open notes file
File 'gcov_test.c'
Lines executed:100.00% of 2
Creating 'gcov_test.c.gcov'
Lines executed:100.00% of 2
+ cat gcov_test.c.gcov
-:0:Source:gcov_test.c
-:0:Programs:1
1:1:int main()
-:2:{
1:3: return 0;
-:4:}
Closing, as this is not a regression for GCC 4.6.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #15 from likan_999.student at sina dot com 2012-07-26 22:10:21 UTC --- Tried the patch and just as Dennis Lubert pointed out, the number of rehashes is not decreased. Is there any plan to fix this issue?
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #20 from dodji at seketeli dot org 2012-07-26 21:11:16 UTC --- "stevenb.gcc at gmail dot com" a écrit: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 > > --- Comment #19 from stevenb.gcc at gmail dot com com> 2012-07-26 19:44:59 UTC --- > Dodji, please see > http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01204.html Ah, right. I missed that patch. It all looks good to me. Thank you.
[Bug gcov-profile/35568] missing gcov data spoils other files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35568
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-07-26
CC||steven at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Steven Bosscher 2012-07-26
20:34:52 UTC ---
Still happens for:
"xgcc (GCC) 4.8.0 20120726 (experimental) [trunk revision 189887]"
$ sh -x foo.sh
+ cat
+ gcc gcov_test.c -o gcov_test -fprofile-arcs -ftest-coverage
+ ./gcov_test
+ gcov gcov_test.c
File 'gcov_test.c'
Lines executed:100.00% of 2
gcov_test.c:creating 'gcov_test.c.gcov'
+ cat gcov_test.c.gcov
-:0:Source:gcov_test.c
-:0:Graph:gcov_test.gcno
-:0:Data:gcov_test.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main()
-:2:{
1:3: return 0;
-:4:}
+ touch gcov_test2.c
+ gcov gcov_test.c gcov_test2.c
gcov_test2.gcno:cannot open graph file
File 'gcov_test.c'
No executable lines
gcov_test.c:creating 'gcov_test.c.gcov'
+ cat gcov_test.c.gcov
-:0:Source:gcov_test.c
-:0:Programs:1
-:1:int main()
-:2:{
-:3: return 0;
-:4:}
$
Mine.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528
--- Comment #5 from Michal Malecki 2012-07-26
20:18:36 UTC ---
Looks nice. Is that a big deal if you also make a standard [[noreturn]]
attribute simply an alias to [[gnu::noreturn]]? As far as I know the standard,
they should behave exactly the same way.
Another thing is that I think this should work, according to the standard:
void quit [[gnu::noreturn]] () { throw 0; }
And it doesn't with this patch. Of course, [[gnu::noreturn]] void quit()...
works and is more intuitive, but both are required by the standard. I guess the
difference is when you'd do this:
int quit [[noreturn]](), pass(); // pass does return!
while here both are noreturn:
[[noreturn]] int quit(), pass();
[Bug java/54100] New: Problems building libjava on AIX 5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54100 Bug #: 54100 Summary: Problems building libjava on AIX 5.2 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: bugzilla-...@thewrittenword.com Tried building gcc-4.6.3 with gcj on AIX 5.2 but it didn't work. $ cd /opt/build/china $ bzip2 -dc gcc-4.6.3.tar.bz2 | tar xf - $ mkdir gcc-4.6.3-o $ cd gcc-4.6.3-o $ CONFIG_SHELL=/opt/fsw/bash42/bin/bash /opt/build/china/gcc-4.6.3/configure CC=xlc --enable-nls --with-included-gettext --enable-libgcj --enable-shared --enable-threads --with-local-prefix=/opt/TWWfsw/gcc46 --with-gmp=/opt/TWWfsw/libgmp43 --with-mpfr=/opt/TWWfsw/libmpfr30 --with-mpc=/opt/TWWfsw/libmpc09 --enable-languages=c,c++,fortran,java --with-ecj-jar=/opt/TWWfsw/gcc46/lib/gcj/ecj.jar --with-gxx-include-dir=/opt/TWWfsw/gcc46/include/c++ --prefix=/opt/TWWfsw/gcc46 $ LDR_CNTRL=MAXDATA=0x7000 CONFIG_SHELL=/opt/fsw/bash42/bin/bash LIBPATH=/opt/TWWfsw/libgmp43:/opt/TWWfsw/libmpfr30:/opt/TWWfsw/libmpc09 gmake ... /opt/fsw/bash42/bin/bash ./libtool --tag=GCJ --mode=compile /opt/build/china/gcc-4.6.3-o/./gcc/gcj -B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.6.3-o/./gcc/ -B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/bin/ -B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/lib/ -isystem /opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/include -isystem /opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/sys-include -maix64 -fclasspath= -fbootclasspath=/opt/build/china/gcc-4.6.3/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -maix64 -c -o gnu/java/awt/peer.lo -fsource-filename=/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/classpath/lib/classes -MT gnu/java/awt/peer.lo -MD -MP -MF gnu/java/awt/peer.deps @gnu/java/awt/peer.list libtool: compile: /opt/build/china/gcc-4.6.3-o/./gcc/gcj -B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/ -B/opt/build/china/gcc-4.6.3-o/./gcc/ -B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/bin/ -B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/lib/ -isystem /opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/include -isystem /opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/sys-include -maix64 -fclasspath= -fbootclasspath=/opt/build/china/gcc-4.6.3/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -maix64 -c -fsource-filename=/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/classpath/lib/classes -MT gnu/java/awt/peer.lo -MD -MP -MF gnu/java/awt/peer.deps @gnu/java/awt/peer.list -o gnu/java/awt/.libs/peer.o Assembler: /tmp//ccSBHZ6k.s: line 5597: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. /tmp//ccSBHZ6k.s: line 5599: 1252-149 Instruction fsel is not implemented in the current assembly mode PPC64. gmake[5]: *** [gnu/java/awt/peer.lo] Error 1 gmake[5]: Leaving directory `/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/libjava' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/opt/build/china/gcc-4.6.3-o' gmake: *** [all] Error 2
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #19 from stevenb.gcc at gmail dot com 2012-07-26 19:44:59 UTC --- Dodji, please see http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01204.html
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #14 from Paolo Carlini 2012-07-26 17:36:28 UTC --- In any case, please add the testcase showing 4.5s vs 1.5s.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #18 from dodji at seketeli dot org 2012-07-26 17:18:34 UTC --- > --- Comment #13 from stevenb.gcc at gmail dot com com> 2012-07-24 10:03:05 UTC --- > On Tue, Jul 24, 2012 at 11:42 AM, rguenth at gcc dot gnu.org > wrote: >> The pointer to the array, but not the array elements. So it's pointless >> to know the length and >> >>souce_location * macro_locations; >> >> should still rewrite the pointer itself, no? > > Hmm. I'm not sure. Without the annotation, how does the PCH machinery > know how long that array is? OTOH there isn't anything else, other > than those dead loops, that looks at h.n_tokens. > > Perhaps there should be a warning from gengtype if the length > attribute is applied to a scalar type. As I said in a previous comment, I'd say no length attribute should even be needed here. In this particular case, no empty loop would have been generated in the first place. I would still apply the patch that you cooked (and mentioned in another comment) to be sure we don't get bitten by such empty loops being otherwise generated.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #17 from dodji at seketeli dot org 2012-07-26 17:15:43 UTC --- > --- Comment #14 from Paolo Carlini > 2012-07-24 10:13:24 UTC --- > Thanks Steven for looking into this! Indeed, thank you Steven!
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #16 from dodji at seketeli dot org
2012-07-26 17:15:15 UTC ---
"rguenth at gcc dot gnu.org" a écrit:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
>
> --- Comment #10 from Richard Guenther 2012-07-24
> 09:34:21 UTC ---
> Err, isn't the GTY annotation in
>
> as y1. x0 is the spelling location for the argument token "1",
> and x2 is the spelling location for the argument token "2". */
> source_location * GTY((length ("2 * %h.n_tokens"))) macro_locations;
>
> simply pointless?
In theory, I would say yes it should be pointless.
But in practise, it looks like the "gengtype code output system" needs a
length annotation for it because macro_location is a pointer to
something that is not a struct, basically.
Otherwise, calling gengtype on the resulting gtype.state yields:
gcc/fix-master/gcc/../libcpp/include/line-map.h:168: field
`(*x).info_ordinary.maps[i0].d.macro.macro_locations' is pointer to
unimplemented type
This is because with no annotation, the information for
"macro_locations" that we have in the generated gtype.state is:
(!pair "macro_locations"
(!type already_seen 6)
(!srcfileloc "../libcpp/include/line-map.h" 168)
nil)
With the gengtype length annotation, we have:
(!pair "macro_locations"
(!type already_seen 6)
(!srcfileloc "../libcpp/include/line-map.h" 168)
(!options
(!option length string "2 * %h.n_tokens")))
The important thing to notice there is that in the latest case, there is
a "length" option (or attribute) that is present in the description.
Then looking at the walk_type function in gengtype.c, we see:
case TYPE_POINTER:
{
...
if (!length)
{
if (!UNION_OR_STRUCT_P (t->u.p)
&& t->u.p->kind != TYPE_PARAM_STRUCT)
{
error_at_line (d->line,
"field `%s' is pointer to unimplemented type",
d->val);
break;
}
...
The 'length' variable not being set to zero there is a consequence of no
gengtype length annotation being present in the line-map.h source code.
So my question would be, why is gengtype forcing pointers to e.g,
scalars to have a length annotation?
If this wasn't the case, I think the expensive empty loops wouldn't be
generated in the first place, would they?
--- Comment #17 from dodji at seketeli dot org
2012-07-26 17:15:43 UTC ---
> --- Comment #14 from Paolo Carlini
> 2012-07-24 10:13:24 UTC ---
> Thanks Steven for looking into this!
Indeed, thank you Steven!
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #16 from dodji at seketeli dot org
2012-07-26 17:15:15 UTC ---
"rguenth at gcc dot gnu.org" a écrit:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
>
> --- Comment #10 from Richard Guenther 2012-07-24
> 09:34:21 UTC ---
> Err, isn't the GTY annotation in
>
> as y1. x0 is the spelling location for the argument token "1",
> and x2 is the spelling location for the argument token "2". */
> source_location * GTY((length ("2 * %h.n_tokens"))) macro_locations;
>
> simply pointless?
In theory, I would say yes it should be pointless.
But in practise, it looks like the "gengtype code output system" needs a
length annotation for it because macro_location is a pointer to
something that is not a struct, basically.
Otherwise, calling gengtype on the resulting gtype.state yields:
gcc/fix-master/gcc/../libcpp/include/line-map.h:168: field
`(*x).info_ordinary.maps[i0].d.macro.macro_locations' is pointer to
unimplemented type
This is because with no annotation, the information for
"macro_locations" that we have in the generated gtype.state is:
(!pair "macro_locations"
(!type already_seen 6)
(!srcfileloc "../libcpp/include/line-map.h" 168)
nil)
With the gengtype length annotation, we have:
(!pair "macro_locations"
(!type already_seen 6)
(!srcfileloc "../libcpp/include/line-map.h" 168)
(!options
(!option length string "2 * %h.n_tokens")))
The important thing to notice there is that in the latest case, there is
a "length" option (or attribute) that is present in the description.
Then looking at the walk_type function in gengtype.c, we see:
case TYPE_POINTER:
{
...
if (!length)
{
if (!UNION_OR_STRUCT_P (t->u.p)
&& t->u.p->kind != TYPE_PARAM_STRUCT)
{
error_at_line (d->line,
"field `%s' is pointer to unimplemented type",
d->val);
break;
}
...
The 'length' variable not being set to zero there is a consequence of no
gengtype length annotation being present in the line-map.h source code.
So my question would be, why is gengtype forcing pointers to e.g,
scalars to have a length annotation?
If this wasn't the case, I think the expensive empty loops wouldn't be
generated in the first place, would they?
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #15 from dodji at seketeli dot org 2012-07-26 16:30:33 UTC --- "paolo.carlini at oracle dot com" a écrit: > --- Comment #4 from Paolo Carlini > 2012-07-23 13:46:43 UTC --- > Dodji, just in case isn't clear already, this is the PR about > -ftrack-macro-expansion + PCHs which I mentioned in Prague... Woops, I am looking at this just now, sorry. Thank you Paolo for the head-up.
[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 --- Comment #6 from Markus Trippelsdorf 2012-07-26 16:13:33 UTC --- (In reply to comment #5) > is this same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53397 No. Monto Carlo is independent of FFT. I can confirm the huge drop of the FFT score with -march=amdfam10. (-flto doesn't help in this case.)
[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 Venkataramanan changed: What|Removed |Added CC||venkataramanan.kumar at amd ||dot com --- Comment #5 from Venkataramanan 2012-07-26 15:40:43 UTC --- is this same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53397
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 --- Comment #4 from Dodji Seketeli 2012-07-26 15:27:17 UTC --- A candidate implementation patch for this has been posted to http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01348.html @Joseph: Thank you for the note. I believe the patch handles this, unless I have forgotten things. @Michal Malecki / Jonathan Wakely The scoped attributes syntax [[gnu::priority(200)]] is now supported. The patch has put all the GNU attributes in the "gnu" namespace by default. So now whenever one writes __attribute__((priority(200))), the priority attribute is looked up from or put into the "gnu" namespace. We'll see what comes out of the discussion that arises from the patch submission.
[Bug fortran/54096] Type bound procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54096 --- Comment #8 from badass at vt dot edu 2012-07-26 15:24:29 UTC --- Thanks, will try with newer version of gcc on my end.
[Bug lto/54095] Unnecessary static variable renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095 Richard Guenther changed: What|Removed |Added Keywords||lto Blocks||43038 --- Comment #4 from Richard Guenther 2012-07-26 14:53:58 UTC --- PR43038 is related. We should be able to impose more constraints to the partitioning algorithm.
[Bug fortran/54096] Type bound procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54096 --- Comment #7 from Tobias Burnus 2012-07-26 14:52:33 UTC --- (In reply to comment #5) > Created attachment 27878 [details] > source code Compiles here (w/o errors) on x86-64-gnu-linux with gcc version 4.5.3 20110428 [gcc-4_5-branch revision 173117] (SUSE Linux) However, I do get a link error due to a mishandling of the virtual table in the compiler. (That's a bug in GCC 4.5 handling of polymorphic variables "CLASS".) Using GCC 4.6 or 4.8, it compiles and runs, complaining at run time that the input file could not be found. Thus, it seems as if you need at least 4.6.0 though newer 4.6 releases contain some other bugs fixes and 4.7 contains some extra fixes for polymorphism. See http://gcc.gnu.org/wiki/OOP for details. (And for an overview about new features http://gcc.gnu.org/wiki/GFortran#news )
[Bug lto/54095] Unnecessary static variable renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095 --- Comment #3 from Richard Guenther 2012-07-26 14:48:36 UTC --- Created attachment 27879 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27879 incomplete prototype patch Something like this. But I'll rather wait for the symtab reorg to reach cgraph/varpool_node_set (and for the partitioning rewrite to go in). The patch simply, at current lto_promote_cross_file_statics time (which can still alter the sets), does the mangling of statics. Which means it works at WPA time and thus will not work with -flto-partition=none. LTRANS file generation is confused because of conflicting section names if we try to postpone it to LTRANS phase. For -flto-partition=none we need a "simpler" hack elsewhere.
[Bug fortran/54096] Type bound procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54096 --- Comment #6 from badass at vt dot edu 2012-07-26 14:13:52 UTC --- Trying again. Source code attached.
[Bug fortran/54096] Type bound procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54096 --- Comment #5 from badass at vt dot edu 2012-07-26 14:10:30 UTC --- Created attachment 27878 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27878 source code all files are modules except for prg_fwb.f90. we believe the error segmentation fault has something to do with lines 166-167 of mod_io.f90
[Bug c/53418] [4.5 Regression] ICE at gimplify.c:7773
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53418 --- Comment #12 from joseph at codesourcery dot com 2012-07-26 14:09:07 UTC --- If something ICEs on current trunk it's clearly a different bug from this one, which is fixed, and so would need to be filed as a separate bug.
[Bug regression/54084] Bunch of fails for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Steven Bosscher 2012-07-26 13:24:03 UTC --- .
[Bug regression/54084] Bunch of fails for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084 --- Comment #8 from Steven Bosscher 2012-07-26 13:21:28 UTC --- Author: steven Date: Thu Jul 26 13:21:21 2012 New Revision: 189891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189891 Log: PR regression/54084 * sel-sched-ir.c (cmp_v_in_regset_pool): Clarify logic, fix pointer difference check. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c
[Bug target/54093] ICE in in extract_insn, at recog.c:2129
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54093 --- Comment #4 from Alan Modra 2012-07-26 13:16:23 UTC --- Created attachment 27877 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27877 proposed fix Please try out this patch.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #13 from François Dumont 2012-07-26 12:31:56 UTC --- Author: fdumont Date: Thu Jul 26 12:31:50 2012 New Revision: 189889 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189889 Log: 2012-07-26 François Dumont PR libstdc++/54075 * include/bits/hashtable.h (_Hashtable<>::_Hashtable(_InputIterator, _InputIterator, size_type, ...): Remove std::max usage to guarantee that hashtable state is consistent with hash policy state. (_Hashtable<>::rehash): Likewise. Set _M_prev_resize to 0 to avoid the hashtable shrinking on next insertion. * testsuite/23_containers/unordered_set/modifiers/reserve.cc: New. * testsuite/23_containers/unordered_multiset/modifiers/reserve.cc: New. * testsuite/23_containers/unordered_map/modifiers/reserve.cc: New. * testsuite/23_containers/unordered_multimap/modifiers/reserve.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_map/modifiers/reserve.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/modifiers/reserve.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/modifiers/reserve.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/reserve.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable.h
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #12 from Dennis Lubert 2012-07-26 12:30:00 UTC --- I can confirm that now the reserve works as I would expect it (causing no further rehashes). However the amount of rehashes done in the testcase is still 155 (needing 4.5s), while gcc 4.6 only needs 21 (needing 1.5s). Monitoring the bucket counts on resizes it seems that gcc 4.8 is now much more fine grained than gcc 4.6. I am unsure if this is expected, deliberate and/or a good idea.
[Bug regression/54084] Bunch of fails for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084
--- Comment #7 from Steven Bosscher 2012-07-26
12:08:31 UTC ---
This is the variant of the patch that I will commit after testing:
Index: sel-sched-ir.c
===
--- sel-sched-ir.c (revision 189887)
+++ sel-sched-ir.c (working copy)
@@ -954,7 +954,13 @@ return_regset_to_pool (regset rs)
static int
cmp_v_in_regset_pool (const void *x, const void *xx)
{
- return *((const regset *) x) - *((const regset *) xx);
+ uintptr_t r1 = (uintptr_t) *((const regset *) x);
+ uintptr_t r2 = (uintptr_t) *((const regset *) xx);
+ if (r1 > r2)
+return 1;
+ else if (r1 < r2)
+return -1;
+ gcc_unreachable ();
}
#endif
[Bug regression/54084] Bunch of fails for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084 Steven Bosscher changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Steven Bosscher 2012-07-26 11:59:39 UTC --- *** Bug 54099 has been marked as a duplicate of this bug. ***
[Bug middle-end/54099] [4.8 Regression] gfortran.dg/pr44691.f fails with ICE in free_regset_pool, at sel-sched-ir.c:994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54099 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Steven Bosscher 2012-07-26 11:59:39 UTC --- . *** This bug has been marked as a duplicate of bug 54084 ***
[Bug middle-end/54099] [4.8 Regression] gfortran.dg/pr44691.f fails with ICE in free_regset_pool, at sel-sched-ir.c:994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54099 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug tree-optimization/54098] [4.8 Regression] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54098 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2012-07-26 11:30:19 UTC --- Fixed.
[Bug c/53418] [4.5 Regression] ICE at gimplify.c:7773
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53418 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #11 from Mikael Pettersson 2012-07-26 11:10:13 UTC --- The new test case in #c10 ICEs gcc 4.8-20120722, 4.7-20120721, 4.6-20120720, and 4.5-20120628, but not gcc-4.4.7, for me on x86_64-linux.
[Bug middle-end/54099] New: [4.8 Regression] gfortran.dg/pr44691.f fails with ICE in free_regset_pool, at sel-sched-ir.c:994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54099 Bug #: 54099 Summary: [4.8 Regression] gfortran.dg/pr44691.f fails with ICE in free_regset_pool, at sel-sched-ir.c:994 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org I get the following failure on x86-64-gnu-linux: FAIL: gfortran.dg/pr44691.f -O (internal compiler error) FAIL: gfortran.dg/pr44691.f -O (test for excess errors) And running it manually, I get: $ gfortran -O2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops gfortran.dg/pr44691.f gfortran.dg/pr44691.f: In function ‘orien’: gfortran.dg/pr44691.f:39:0: internal compiler error: in free_regset_pool, at sel-sched-ir.c:994 Sometimes, I get the same failure for: FAIL: gfortran.dg/pr42294.f -O (internal compiler error) FAIL: gfortran.dg/pr42294.f -O (test for excess errors) but I cannot reproduce it at the moment. However, both failures can be seen at http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02161.html Looking at the test results, no failure occurs for: http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02099.html 4.8.0 20120724 [trunk revision 189815] (GCC) on x86_64-unknown-linux-gnu but it does starting from http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02109.html 4.8.0 20120724 [trunk revision 189820] (GCC) on x86_64-unknown-linux-gnu
[Bug tree-optimization/54098] [4.8 Regression] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54098 --- Comment #2 from Richard Guenther 2012-07-26 10:25:21 UTC --- Author: rguenth Date: Thu Jul 26 10:25:15 2012 New Revision: 189885 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189885 Log: 2012-07-26 Richard Guenther PR tree-optimization/54098 * tree-vrp.c (vrp_visit_phi_node): Iterate once more if the original range was UNDEFINED. * gcc.dg/torture/pr54098.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr54098.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c/53418] [4.5 Regression] ICE at gimplify.c:7773
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53418
--- Comment #10 from Antoine Balestrat 2012-07-26
10:23:43 UTC ---
This simple testcase appears to trigger the same ICE :
$ cat ice.c
void f(void)
{
0 || 0 / 0 ? : 0;
}
$ gcc -w ice.c
ice.c: In function ‘f’:
ice.c:3:12: internal compiler error: in gimplify_expr, at gimplify.c:7790
0 || 0 / 0 ? : 0;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
I'm using GCC 4.8.0 20120725.
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #9 from Richard Guenther 2012-07-26 10:18:55 UTC --- (In reply to comment #8) > (In reply to comment #7) > > so it would be still worthwhile to pursue your patch if it does not have > > negative effects elsewhere. We should be able to fix the induction code > > to handle this case. > > Regarding negative (or positive) impact with regards to performance: That's > difficult to test :-( > > However, with the patch, f951 stops with the following ICE > internal compiler error: in free_regset_pool, at sel-sched-ir.c:994 > with gfortran.dg/pr42294.f and gfortran.dg/pr44691.f. That's a pre-existing issue on current trunk, unrelated to the patch.
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #8 from Tobias Burnus 2012-07-26 09:58:41 UTC --- (In reply to comment #7) > so it would be still worthwhile to pursue your patch if it does not have > negative effects elsewhere. We should be able to fix the induction code > to handle this case. Regarding negative (or positive) impact with regards to performance: That's difficult to test :-( However, with the patch, f951 stops with the following ICE internal compiler error: in free_regset_pool, at sel-sched-ir.c:994 with gfortran.dg/pr42294.f and gfortran.dg/pr44691.f.
[Bug fortran/44354] implied do loop with its own variable name as upper bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
Known to fail||
--- Comment #25 from Mikael Morin 2012-07-26
09:04:09 UTC ---
The code in comment 0 now gives the expected output:
1 2 3 4 5
It is accepted by default with a warning.
It is rejected with -std=f{95,2003,2008}.
Thus, (finally) fixed for 4.8.0.
[Bug tree-optimization/54094] [4.8 regression] ICE in graphite-dependences.c:320 : isl_constraint.c:497: position out of bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54094 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/54098] [4.8 Regression] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54098
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-07-26
Target Milestone|--- |4.8.0
Summary|[tree-vrp] ICE on valid |[4.8 Regression] ICE on
|code|valid code
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2012-07-26
09:00:10 UTC ---
Confirmed, mine.
Program received signal SIGSEGV, Segmentation fault.
0x00e03ca0 in compare_values_warnv (val1=0x0, val2=0x770bef00,
strict_overflow_p=0x7fffd83b "")
at /space/rguenther/src/svn/trunk/gcc/tree-vrp.c:1148
1148 gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1))
(gdb) p val1
$1 = (tree) 0x0
lhs_vr is undefined in vrp_visit_phi_node at
7671 if (edges > 0
7672 && gimple_phi_num_args (phi) > 1
7673 && edges == old_edges)
7674{
7675 int cmp_min = compare_values (lhs_vr->min, vr_result.min);
7676 int cmp_max = compare_values (lhs_vr->max, vr_result.max);
[Bug fortran/44354] implied do loop with its own variable name as upper bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354 --- Comment #24 from Mikael Morin 2012-07-26 08:54:02 UTC --- Author: mikael Date: Thu Jul 26 08:53:56 2012 New Revision: 189883 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189883 Log: fortran/ PR fortran/44354 * trans-array.c (gfc_trans_array_constructor_value): Evaluate the iteration bounds before the inner variable shadows the outer. testsuite/ PR fortran/44354 * gfortran.dg/array_constructor_39.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_39.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug other/54030] make install does not honor --program-prefix/--program-suffix for 'gcc' (AVR build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54030 Georg-Johann Lay changed: What|Removed |Added Keywords||build Target|AVR (maybe other) | Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-26 CC||gjl at gcc dot gnu.org, ||mikestump at comcast dot ||net Ever Confirmed|0 |1 --- Comment #2 from Georg-Johann Lay 2012-07-26 08:48:05 UTC --- Patch proposed here: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00905.html
[Bug fortran/44354] implied do loop with its own variable name as upper bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354 --- Comment #23 from Mikael Morin 2012-07-26 08:47:42 UTC --- Author: mikael Date: Thu Jul 26 08:47:33 2012 New Revision: 189882 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189882 Log: fortran/ PR fortran/44354 * array.c (sought_symbol): New variable. (expr_is_sought_symbol_ref, find_symbol_in_expr): New functions. (resolve_array_list): Check for references to the induction variable in the iteration bounds and issue a diagnostic if some are found. testsuite/ PR fortran/44354 * gfortran.dg/array_constructor_38.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_38.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug lto/54095] Unnecessary static variable renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-26 CC||hubicka at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-07-26 08:46:04 UTC --- Confirmed. My overall plan was to delay assigning an assembler name (or just delay the mangling) until LTRANS phase where we will know if partitioning resulted in a conflict of two static decls from different TUs. It's been on my todo list for some time ... ;) Btw, this re-naming also confuses debugging - you can no longer do (gdb) p foo but have to do (gdb) p foo.2353.2353 ugh. Note that you'll not be able to rely on statics not being renamed apart from when you use 1to1 partitioning (well, hopefully - I think we still pull in inlines which might pull in conflicts).
[Bug regression/54084] Bunch of fails for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54084 --- Comment #5 from Igor Zamyatin 2012-07-26 08:44:01 UTC --- Looks like r189812 fixed some failures but not all of them. Patch from comment 2 fixes all problems
[Bug fortran/54096] Type bound procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54096 --- Comment #4 from Tobias Burnus 2012-07-26 08:43:48 UTC --- (In reply to comment #3) > Sorry about that, I though i had included the source code. I'm working > on getting an updated compiler, but IT here is being difficult and I could > take a day. Thanks for the help, source code is attached. Seemingly, the mail interface of GCC's Bugzilla doesn't handle attachments. Thus, please use the web interface to attach the file. Thanks!
[Bug tree-optimization/54098] New: [tree-vrp] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54098
Bug #: 54098
Summary: [tree-vrp] ICE on valid code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhr...@newmail.ru
Created attachment 27876
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27876
Preprocessed minimized testcase.
gcc 4.8 revision 188728 and later segfaults on 64bit Linux while compiling the
attached code with -march=nocona.
$ gcc -Wall -O2 -march=nocona -c foo-small.c
foo-small.c: In function 'pbus_size_mem':
foo-small.c:35:6: internal compiler error: Segmentation fault
void pbus_size_mem(struct pci_bus *bus, unsigned long mask, unsigned long
type, unsigned long long min_size, unsigned long long add_size, void
*realloc_head) {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gcc --version
gcc (GCC) 4.8.0 20120618 (experimental)
Copyright (C) 2012 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.
gcc configured with "--disable-bootstrap --enable-languages=c,c++"
4.6.3 works ok. 4.8 trunk up to revision 188727 also works ok.
[Bug target/53735] thumb1 spill failure with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53735
zhenqiang.chen at linaro dot org changed:
What|Removed |Added
CC||zhenqiang.chen at linaro
||dot org
--- Comment #4 from zhenqiang.chen at linaro dot org 2012-07-26 07:50:25 UTC ---
Root cause: r8-r11 is not available for THUMB1 with -Os.
In function arm_conditional_register_usage (arm.c), you can find the code
if (TARGET_THUMB1 && optimize_size)
{
/* When optimizing for size on Thumb-1, it's better not
to use the HI regs, because of the overhead of
stacking them. */
for (regno = FIRST_HI_REGNUM;
regno <= LAST_HI_REGNUM; ++regno)
fixed_regs[regno] = call_used_regs[regno] = 1;
}
If removing the code, the result is OK (r8 is used).
