[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
David Stone changed:
What|Removed |Added
CC||DeusExSophismata at gmail
||dot com
--- Comment #10 from David Stone 2012-03-24
06:52:04 UTC ---
Simple self-contained test case:
unsigned f (int x) {
return (x >= 0) ? x : -x;
}
int main () {
return 0;
}
It seems like we could at least add a simple improvement that just checks for
simple comparisons to 0. That probably catches most code (I often do one set of
calculations for non-negative values, and another set for negative values) and
avoids a lot of problems of trying to track complex calculations for the
signedness of the result. I wouldn't be perfect, but it would be better than it
currently is.
Being able to detect cases like this is also an optimization opportunity,
because division with positive integers is simpler than division with negative
integers, for example. We could reuse code that detects that optimization
opportunity for this warning.
[Bug target/52698] New: -maddress-mode=long doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52698
Bug #: 52698
Summary: -maddress-mode=long doesn't work
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: x86-64
[hjl@gnu-mic-2 gcc]$ cat /tmp/x.c
extern void abort (void);
static __thread unsigned char foo [32]
__attribute__ ((tls_model ("initial-exec"), aligned (sizeof (void *;
void
test2 (void)
{
unsigned int s;
for (s = 0; s < sizeof (foo); ++s)
{
if (foo [s] != s)
abort ();
foo [s] = sizeof (foo) - s;
}
}
[hjl@gnu-mic-2 gcc]$ ./xgcc -B./ -mx32 -O2 -S /tmp/x.c -maddress-mode=long
/tmp/x.c: In function \u2018test2\u2019:
/tmp/x.c:14:1: error: insn does not satisfy its constraints:
(insn 52 78 53 5 (set (mem/j:QI (plus:DI (plus:DI (reg:DI 37 r8)
(reg:DI 38 r9))
(reg:DI 2 cx [orig:98 D.1709 ] [98])) [0 foo S1 A8])
(reg:QI 1 dx [100])) /tmp/x.c:12 66 {*movqi_internal}
(nil))
/tmp/x.c:14:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[hjl@gnu-mic-2 gcc]$ ./xgcc -B./ -mx32 -O2 -S /tmp/x.c -maddress-mode=short
[hjl@gnu-mic-2 gcc]$
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631
--- Comment #6 from Andrew Pinski 2012-03-24
03:21:29 UTC ---
Here is the simpler patch:
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 185559)
+++ tree-ssa-sccvn.c(working copy)
@@ -3295,6 +3295,17 @@ visit_use (tree use)
}
else
{
+ /* First try to lookup the simplified expression. */
+ if (simplified && valid_gimple_rhs_p (simplified))
+ {
+ tree result = vn_nary_op_lookup (simplified, NULL);
+ if (result)
+ {
+ changed = set_ssa_val_to (lhs, result);
+ goto done;
+ }
+ }
+ /* Otherwise visit the original statement. */
switch (get_gimple_rhs_class (code))
{
case GIMPLE_UNARY_RHS:
CUT -
ChangeLog:
* tree-ssa-sccvn.c (visit_use): Before looking up the original statement, try
looking up the simplified expression.
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 --- Comment #5 from Andrew Pinski 2012-03-24 03:10:37 UTC --- Ok, I have a patch which only tries to looking up the simplified expression and then if we find it, use it, otherwise use the original expression. I now understand why this makes a difference (for FRE it does not though).
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 --- Comment #7 from Martin Jambor 2012-03-24 00:51:38 UTC --- Created attachment 26971 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26971 Proposed untested fix I'm currently bootstrapping and testing this patch.
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-24 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Martin Jambor 2012-03-24 00:50:09 UTC --- Right, sorry, the square brackets of MEM_REF made me feel the array reference was still there even though it actually disappears. When I realized that, analyzing the issue was actually easy.
[Bug c++/52697] New: -Wsign-conversion warns for obviously correct code with implicit promotion to int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52697
Bug #: 52697
Summary: -Wsign-conversion warns for obviously correct code
with implicit promotion to int
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deusexsophism...@gmail.com
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
// test.cpp
unsigned f (unsigned short a) {
return (a) ? a : 0;
}
int main () {
return 0;
}
// command line
$ g++ test.cpp -Wsign-conversion
test.cpp: In function ‘unsigned int f(int)’:
test.cpp:2:25: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
What I find interesting is the wide array of code that does not trigger a
warning. None of the following definitions of f() cause a warning:
unsigned f (unsigned short a) {
return (a) ? a : a;
}
unsigned f (unsigned short a) {
return (a) ? a : 0u;
}
unsigned f (unsigned short a) {
return (true) ? a : 0;
}
unsigned f (unsigned short a) {
return (false) ? a : 0;
}
It seems that there is some sort of error in the implicit conversion to int for
certain types of arithmetic.
This may be related to PR 38470
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470)
[Bug libgcj/52694] [4.8 regression] bootstrap failure: libjava/java/io/natVMConsole.cc:35:20: error: 'IUCL C' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52694 Dominique d'Humieres changed: What|Removed |Added CC||gandalf at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres 2012-03-23 23:12:03 UTC --- CCed Andrew Hughes.
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 --- Comment #3 from Andrew Pinski 2012-03-23 23:04:28 UTC --- >--enable-bootstrap \ Can you try without that?
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 --- Comment #5 from Andrew Pinski 2012-03-23 23:00:47 UTC --- Wait a minute, value = stack.l[D.4470_102]; With value_77 = MEM[(struct exprList_s *)&stack]; value$u_620 = MEM[(struct exprList_s *)&stack].u; Where is D.4470_102 being taken into account? I don't see it in the dumps.
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot
|gnu.org |com
Target Milestone|--- |4.8.0
--- Comment #8 from Paolo Carlini 2012-03-23
22:48:59 UTC ---
The latter issue could be addressed by something like:
Index: decl.c
===
--- decl.c(revision 185715)
+++ decl.c(working copy)
@@ -1136,7 +1136,10 @@ check_redeclaration_exception_specification (tree
if ((pedantic || ! DECL_IN_SYSTEM_HEADER (old_decl))
&& ! DECL_IS_BUILTIN (old_decl)
&& flag_exceptions
- && !comp_except_specs (new_exceptions, old_exceptions, ce_normal))
+ && !comp_except_specs (new_exceptions, old_exceptions, ce_normal)
+ && !(DECL_DESTRUCTOR_P (new_decl)
+ && cxx_dialect >= cxx0x
+ && !new_exceptions && TYPE_NOEXCEPT_P (old_type)))
{
error ("declaration of %qF has a different exception specifier",
new_decl);
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 --- Comment #4 from Martin Jambor 2012-03-23 22:45:47 UTC --- OTOH, I can confirm that the problematic variable is value, just not SRAing that one makes the testcase to return 120. (In the same function, SRA creates replacements also for stack and fifo variables and that thus seems fine.)
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 Martin Jambor changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor 2012-03-23 22:30:08 UTC --- (In reply to comment #0) > With the attach testcase, SRA does the following replacement which seems > wrong: > value = stack.l[D.4470_102]; > With > value_77 = MEM[(struct exprList_s *)&stack]; > value$u_620 = MEM[(struct exprList_s *)&stack].u; > It is confusing but I do not think it is wrong. When you disable the special handling of enumeral types in analyze_access_subtree, you get (in this case IMHO equivalent): value$type_621 = MEM[(struct exprList_s *)&stack].type; value$u_622 = MEM[(struct exprList_s *)&stack].u; which is exactly what we'd expect when breaking value into the two components it consists of. And the testcase still fails. It is equivalent because the first MEM_REF is of type unsigned int, whereas the second one loads the whole structure and then there's a COMPONENT_REF to load only the second integer from it.
[Bug regression/52696] New: [4.6 Regression]: g++.dg/tree-ssa/pr44706.C scan-tree-dump-not fnsplit "Splitting function"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52696 Bug #: 52696 Summary: [4.6 Regression]: g++.dg/tree-ssa/pr44706.C scan-tree-dump-not fnsplit "Splitting function" Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: hubi...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 185724:185740 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc46/gcc/gcc/testsuite/g++.dg/dg.exp ... ... FAIL: g++.dg/tree-ssa/pr44706.C scan-tree-dump-not fnsplit "Splitting function" The message in g++.log indicates that a log-entry from an optimizaton pass is missing; something didn't happen. Maybe it's just the test-case that needs updating, though that's only an uninitiated guess: spawn /tmp/hpautotest-gcc46/cris-elf/gccobj/gcc/testsuite/g++/../../g++ -B/tmp/hpautotest-gcc46/cris-elf/gccobj/gcc/testsuite/g++/../../ /tmp/hpautotest-gcc46/gcc/gcc/testsuite/g++.dg/tree-ssa/pr44706.C -nostdinc++ -I/tmp/hpautotest-gcc46/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc46/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc46/gcc/libstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc46/gcc/libstdc++-v3/include/backward -I/tmp/hpautotest-gcc46/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O3 -fdump-tree-fnsplit -S -isystem /tmp/hpautotest-gcc46/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc46/gcc/newlib/libc/include -o pr44706.s PASS: g++.dg/tree-ssa/pr44706.C (test for excess errors) FAIL: g++.dg/tree-ssa/pr44706.C scan-tree-dump-not fnsplit "Splitting function" Author of the only suspect patch in the revision range CC:ed.
[Bug libgcj/52694] [4.8 regression] bootstrap failure: libjava/java/io/natVMConsole.cc:35:20: error: 'IUCL C' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52694 --- Comment #3 from Gerald Pfeifer 2012-03-23 22:27:22 UTC --- > grep -r IUCLC /usr/local/include/ /usr/include | wc -l 0
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 --- Comment #2 from ncahill_alt at yahoo dot com 2012-03-23 22:23:19 UTC --- Sorry, i686-pc-linux-gnu, I think that is the target. This is the configure command: ../gcc-4.7.0/configure \ --enable-bootstrap \ --disable-libada \ --disable-ld \ --disable-gold \ --enable-lto \ --enable-libssp \ \ --prefix=/usr \ --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0 \ --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include \ --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0 \ --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man \ --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info \ --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4 \ --host=i686-pc-linux-gnu \ --build=i686-pc-linux-gnu \ --disable-altivec \ --disable-fixed-point \ --without-ppl \ --without-cloog \ --enable-nls \ --without-included-gettext \ --with-system-zlib \ --disable-werror \ --enable-secureplt \ --disable-multilib \ --enable-libmudflap \ --disable-libgomp \ --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python \ --enable-checking=release \ --disable-libgcj \ --enable-languages=c,c++,fortran,lto \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-clocale=gnu \ --with-bugurl=http://bugs.gentoo.org/ Thank you.
[Bug libgcj/52694] [4.8 regression] bootstrap failure: libjava/java/io/natVMConsole.cc:35:20: error: 'IUCL C' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52694 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-23 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-03-23 21:37:58 UTC --- Confirmed on x86_64-apple-darwin10.
[Bug bootstrap/52674] [4.7 regression] segfault during profiled LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674 --- Comment #3 from Eric Botcazou 2012-03-23 21:30:26 UTC --- > I was doing profiledbootstrap with the bootstrap-lto config on x64 just fine > until about 6 weeks ago. The speedup in the resulting binary was notable, and > was very useful to have for my shorter gcc build iterations where I use > --disable-bootstrap. If it's not supposed to work, then configure should not > allow it IMO. The speedup comes the profiled bootstrap, LTO doesn't add much. The average user isn't supposed to use --with-build-config, it's mainly for GCC developers. > If you can recommend an intermediate make target I can use to make the > iteration time shorter, I can try and debug this issue further on my own and > report back. I can't figure out how to capture the resulting binary that > crashes, since the source isn't listed in the config.log when it fails, so any > help on that front would be appreciated. Right, debugging LTO is a pain. Do not waste your time on this I'd say, just do a simple profiled bootstrap.
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 --- Comment #1 from Andrew Pinski 2012-03-23 21:25:11 UTC --- What is the target which you are using?
[Bug libgcj/52694] [4.8 regression] bootstrap failure: libjava/java/io/natVMConsole.cc:35:20: error: 'IUCL C' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52694 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libgcj/52694] [4.8 regression] bootstrap failure: libjava/java/io/natVMConsole.cc:35:20: error: 'IUCL C' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52694 --- Comment #1 from Andrew Pinski 2012-03-23 21:23:41 UTC --- This part of the code is not part of classpath so changed the components.
[Bug libitm/52695] New: libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 Bug #: 52695 Summary: libitm/config/x86/cacheline.h: '__m64' does not name a type Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com While building gcc 4.7.0, libitm fails with this error: In file included from ../../../gcc-4.7.0/libitm/libitm_i.h:85:0, from ../../../gcc-4.7.0/libitm/aatree.cc:28: ../../../gcc-4.7.0/libitm/config/x86/cacheline.h:55:3: error: '__m64' does not name a type A possible fix is to add #include to cacheline.h, which seems to be the desired intent. This was built with gcc 4.6.2, from the gcc-4.7.0.tar.bz2 as released on ftp.gnu.org. The error occured right at the end, after the bootstrap process was successful. Thank you. Neil.
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #4 from Markus Trippelsdorf 2012-03-23 21:18:19 UTC --- Please run: $ nm /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a | grep GLIBCXX_3.4.14 and paste the output here.
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 --- Comment #2 from Andrew Pinski 2012-03-23 20:55:42 UTC --- The correct output should be 120 which is what happens at -O0.
[Bug middle-end/52693] Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 --- Comment #1 from Andrew Pinski 2012-03-23 20:51:40 UTC --- Created attachment 26970 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26970 Testcase
[Bug middle-end/52693] New: Wrong code with SRA and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693 Bug #: 52693 Summary: Wrong code with SRA and arrays Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org With the attach testcase, SRA does the following replacement which seems wrong: value = stack.l[D.4470_102]; With value_77 = MEM[(struct exprList_s *)&stack]; value$u_620 = MEM[(struct exprList_s *)&stack].u; At -O1.
[Bug target/52692] [avr]: Add support for avr-specific built-ins + LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-23 CC||flamorce at videotron dot ||ca AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.1 Ever Confirmed|0 |1 Severity|normal |enhancement
[Bug target/52692] New: [avr]: Add support for avr-specific built-ins + LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692
Bug #: 52692
Summary: [avr]: Add support for avr-specific built-ins + LTO
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr
Implement TARGET_BUILTIN_DECL so that the following works:
int main (void)
{
__builtin_avr_delay_cycles (1000);
return 0;
}
Currently, this prints
$ avr-gcc main.c -S -flto
main.c:7:1: sorry, unimplemented: tree bytecode streams do not support machine
specific builtin functions on this target
[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076 --- Comment #32 from Matt Hargett 2012-03-23 20:30:17 UTC --- Richard, if nothing's come to mind by now for the 4.6 branch, can this be closed? I'd like to see it fixed, of course, but so long as it still works in 4.7.0 and there's a test in the suite that verifies as such, let's move on :)
[Bug bootstrap/52674] [4.7 regression] segfault during profiled LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674 --- Comment #2 from Matt Hargett 2012-03-23 20:26:44 UTC --- I was doing profiledbootstrap with the bootstrap-lto config on x64 just fine until about 6 weeks ago. The speedup in the resulting binary was notable, and was very useful to have for my shorter gcc build iterations where I use --disable-bootstrap. If it's not supposed to work, then configure should not allow it IMO. If you can recommend an intermediate make target I can use to make the iteration time shorter, I can try and debug this issue further on my own and report back. I can't figure out how to capture the resulting binary that crashes, since the source isn't listed in the config.log when it fails, so any help on that front would be appreciated.
[Bug c++/52672] internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:6766
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52672 --- Comment #3 from Meador Inge 2012-03-23 20:21:06 UTC --- Testing a patch now.
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #3 from Jens Maurer 2012-03-23 20:14:33 UTC --- In case it matters, here's the "configure" info etc: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7.0/configure -enable-languages=c,c++ --prefix=/usr/local --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-lto Thread model: posix gcc version 4.7.0 (GCC)
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #2 from Jens Maurer 2012-03-23 20:13:11 UTC --- $ find /usr/lib -name "libstdc++.a" /usr/lib/gcc/x86_64-linux-gnu/4.6/32/libstdc++.a /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a /usr/lib/gcc/x86_64-linux-gnu/4.5/libstdc++.a However, these old libstdc++.a files are NOT used: g++ -Wl,--verbose x.cc -static-libstdc++ GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 ... attempt to open /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbegin.o succeeded /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbegin.o attempt to open /home/jmaurer/tmp/cc0s7Nqc.o succeeded /home/jmaurer/tmp/cc0s7Nqc.o attempt to open /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/libstdc++.a failed attempt to open /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a succeeded (/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a)globals_io.o ... The libstdc++.a file used is the one installed today: $ ls -lL /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a -rw-r--r-- 1 root root 16227426 2012-03-23 13:31 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a
[Bug middle-end/52690] ICE after bootstrap comparison in libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52690 --- Comment #2 from David Fang 2012-03-23 19:58:55 UTC --- Created attachment 26969 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26969 preprocessed source generated by: /Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc \ -B/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc -nostdinc++ \ -L/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/src \ -L/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/src/.libs \ -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/bin/ \ -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/lib/ \ -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/include \ -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/sys-include \ -DHAVE_CONFIG_H -I. -I../../../gcc-4.7.0/libjava -I./include -I./gcj \ -I../../../gcc-4.7.0/libjava \ -Iinclude -I../../../gcc-4.7.0/libjava/include \ -I../../../gcc-4.7.0/libjava/classpath/include \ -Iclasspath/include -I../../../gcc-4.7.0/libjava/classpath/native/fdlibm \ -I../../../gcc-4.7.0/libjava/../boehm-gc/include -I../boehm-gc/include \ -I../../../gcc-4.7.0/libjava/libltdl -I../../../gcc-4.7.0/libjava/libltdl \ -I../../../gcc-4.7.0/libjava/.././libjava/../libgcc \ -I../../../gcc-4.7.0/libjava/../libffi/include \ -I../libffi/include -I/sw/include -fno-rtti -fnon-call-exceptions \ -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 \ -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/sw/lib/gcc4.7\" \ -DTOOLEXECLIBDIR=\"/sw/lib/gcc4.7/lib\" \ -DJAVA_HOME=\"/sw/lib/gcc4.7\" \ -DBOOT_CLASS_PATH=\"/sw/lib/gcc4.7/share/java/libgcj-4.7.0.jar\" \ -DJAVA_EXT_DIRS=\"/sw/lib/gcc4.7/share/java/ext\" \ -DGCJ_ENDORSED_DIRS=\"/sw/lib/gcc4.7/share/java/gcj-endorsed\" \ -DGCJ_VERSIONED_LIBDIR=\"/sw/lib/gcc4.7/lib/gcj-4.7.0-13\" \ -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"/sw/lib/gcc4.7/share/java/ecj.jar\" \ -DLIBGCJ_DEFAULT_DATABASE=\"/sw/lib/gcc4.7/lib/gcj-4.7.0-13/classmap.db\" \ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.7.0-13/classmap.db\" \ -fwrapv -g -O2 -MT interpret.lo -MD -MP -MF .deps/interpret.Tpo \ -c ../../../gcc-4.7.0/libjava/interpret.cc -fno-common -DPIC -o .libs/interpret.o \ -save-temps Oddly, when I generated it this time by hand (with -save-temps), the command completed successfully. Nondeterminism??
[Bug c++/52683] assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683 --- Comment #6 from Daniel Krügler 2012-03-23 19:41:03 UTC --- (In reply to comment #4) > > static_assert( is_assignable::value, "not assignable" ); // pass > > This works because this corresponds to assigning an int rvalue to an int. " This works because this corresponds to assigning an int rvalue to an int lvalue."
[Bug c++/52683] assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683 Petr Ovtchenkov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Petr Ovtchenkov 2012-03-23 19:35:48 UTC --- Thanks! Summary for history: Fail as expected: static_assert( is_assignable::value, "not assignable" ); (left side is rvalue) Pass, as expected: static_assert( is_assignable::value, "not assignable" ); (rvalues of classes can act as lvalues when they call a member function) Note: behavior was changed since gcc 4.5.x.
[Bug target/49740] [4.7 Regression] powerpc native bootstrap with -O3 produces "Bootstrap comparison failure!"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740 Douglas Mencken changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|INVALID |WORKSFORME --- Comment #7 from Douglas Mencken 2012-03-23 18:46:48 UTC --- Currently, it works well. Bug can be closed as WORKSFORME or such.
[Bug c++/52683] assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #4 from Daniel Krügler
2012-03-23 18:44:47 UTC ---
(In reply to comment #3)
> I'm agree. But if you remove all tests with is_assignable2, still remains
> problem with int:
>
> ...
> struct QQ
> {
> int v;
> };
>
> ...
>
> static_assert( is_assignable::value, "not assignable" ); // <
> fail!
This is to be expected, because is_assignable is the most general assignable
trait. Your compile-time query is equivalent to asking whether the expression
12 = 13;
is well-formed. Use std::is_assignable::value to test for assigning
an int rvalue to a mutable int lvalue. Or even better, use
std::is_copy_assignable
> static_assert( is_assignable::value, "not assignable" ); // pass
This works because this corresponds to assigning an int rvalue to an int.
> static_assert( is_assignable::value, "not assignable" ); // pass
This is to be expected, because rvalues of classes can act as lvalues when they
call a member function.
> static_assert( is_assignable::value, "not assignable" ); // < pass!
Same thing as with WW.
> static_assert( is_assignable::value, "not assignable" ); // pass
Also valid, you try to assign an rvalue of Q to a mutable lvalue.
I see no defects here.
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043
--- Comment #7 from Paolo Carlini 2012-03-23
18:17:56 UTC ---
This doesn't compile, for example:
struct B
{
~B();
};
B::~B() { }
[Bug middle-end/52690] ICE after bootstrap comparison in libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52690 Andrew Pinski changed: What|Removed |Added Keywords||build Component|java|middle-end --- Comment #1 from Andrew Pinski 2012-03-23 18:15:23 UTC --- The code where the ICE is is C++ code. Can you attach the preprocessed source?
[Bug c/52691] New: va_start to builtin_next_arg optimization lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52691 Bug #: 52691 Summary: va_start to builtin_next_arg optimization lost Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org In the commit below, the following edit was made which inverted the sense of the test, preventing the optimization from applying when it should. A ! must be inserted before builtin_decl_explicit_p. diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c index e207e23..31c31c1 100644 --- a/gcc/tree-ssa-ccp.c +++ b/gcc/tree-ssa-ccp.c @@ -2175,7 +2175,7 @@ optimize_stdarg_builtin (gimple call) case BUILT_IN_VA_START: if (!va_list_simple_ptr || targetm.expand_builtin_va_start != NULL - || built_in_decls[BUILT_IN_NEXT_ARG] == NULL) + || builtin_decl_explicit_p (BUILT_IN_NEXT_ARG)) return NULL_TREE; if (gimple_call_num_args (call) != 2) commit b9a1687032fc1afb5f4e9d8dfa775a134abe21ba Author: meissner Date: Tue Oct 11 19:55:09 2011 + Convert standard builtin functions from being arrays to using a functional interface git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@179820 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug java/52690] New: ICE after bootstrap comparison in libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52690 Bug #: 52690 Summary: ICE after bootstrap comparison in libjava Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: f...@csl.cornell.edu On a powerpc-darwin8 bootstrap of release-4.7.0, after stage 3 comparison, during libjava: configured with: ../gcc-4.7.0/configure --prefix=/sw AS=odas AS_FOR_TARGET=odas NM_FOR_TARGET=odnm LD_FOR_TARGET=odld AR_FOR_TARGET=oda r LIPO_FOR_TARGET=odlipo OBJDUMP_FOR_TARGET=odobjdump RANLIB_FOR_TARGET=odranlib STRIP_FOR_TARGET=odstrip --prefix=/sw/l ib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java -- with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/ usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-cloog-backend=isl --with-dwarf2 --disa ble-libjava-multilib --disable-libquadmath ... depbase=`echo interpret.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CXX --mode=compile /Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc/xgcc - shared-libgcc -B/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc -nostdinc++ -L/Volumes/Isolde/fink.build/gc c47-4.7.0-1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/src -L/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_ objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/bin/ -B/sw/lib/gcc4 .7/powerpc-apple-darwin8.11.0/lib/ -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/include -isystem /sw/lib/gcc4.7/po werpc-apple-darwin8.11.0/sys-include-DHAVE_CONFIG_H -I. -I../../../gcc-4.7.0/libjava -I./include -I./gcj -I../../.. /gcc-4.7.0/libjava -Iinclude -I../../../gcc-4.7.0/libjava/include -I../../../gcc-4.7.0/libjava/classpath/include -Iclass path/include -I../../../gcc-4.7.0/libjava/classpath/native/fdlibm -I../../../gcc-4.7.0/libjava/../boehm-gc/include -I../ boehm-gc/include -I../../../gcc-4.7.0/libjava/libltdl -I../../../gcc-4.7.0/libjava/libltdl -I../../../gcc-4.7.0/libjava /.././libjava/../libgcc -I../../../gcc-4.7.0/libjava/../libffi/include -I../libffi/include -I/sw/include -fno-rtti -fno n-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX="\ "/sw/lib/gcc4.7\"" -DTOOLEXECLIBDIR="\"/sw/lib/gcc4.7/lib\"" -DJAVA_HOME="\"/sw/lib/gcc4.7\"" -DBOOT_CLASS_PATH="\"/sw/l ib/gcc4.7/share/java/libgcj-4.7.0.jar\"" -DJAVA_EXT_DIRS="\"/sw/lib/gcc4.7/share/java/ext\"" -DGCJ_ENDORSED_DIRS="\"/sw/ lib/gcc4.7/share/java/gcj-endorsed\"" -DGCJ_VERSIONED_LIBDIR="\"/sw/lib/gcc4.7/lib/gcj-4.7.0-13\"" -DPATH_SEPARATOR="\": \"" -DECJ_JAR_FILE="\"/sw/lib/gcc4.7/share/java/ecj.jar\"" -DLIBGCJ_DEFAULT_DATABASE="\"/sw/lib/gcc4.7/lib/gcj-4.7.0-13/ classmap.db\"" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.7.0-13/classmap.db\"" -fwrapv -g -O2 -MT interpret.lo -MD -M P -MF $depbase.Tpo -c -o interpret.lo ../../../gcc-4.7.0/libjava/interpret.cc &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc -B/Volumes/Isolde/fi nk.build/gcc47-4.7.0-1/darwin_objdir/./gcc -nostdinc++ -L/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/powerpc- apple-darwin8.11.0/libstdc++-v3/src -L/Volumes/Isolde/fink.build/gcc47-4.7.0-1/darwin_objdir/powerpc-apple-darwin8.11.0/ libstdc++-v3/src/.libs -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/bin/ -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/lib/ -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/include -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/sys-inclu de -DHAVE_CONFIG_H -I. -I../../../gcc-4.7.0/libjava -I./include -I./gcj -I../../../gcc-4.7.0/libjava -Iinclude -I../../. ./gcc-4.7.0/libjava/include -I../../../gcc-4.7.0/libjava/classpath/include -Iclasspath/include -I../../../gcc-4.7.0/libj ava/classpath/native/fdlibm -I../../../gcc-4.7.0/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../gcc-4.7.0/ libjava/libltdl -I../../../gcc-4.7.0/libjava/libltdl -I../../../gcc-4.7.0/libjava/.././libjava/../libgcc -I../../../gcc- 4.7.0/libjava/../libffi/include -I../libffi/include -I/sw/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifie rs -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/sw/lib/gcc4.7\" -DTOOLEXECLIBDIR=\"/sw/l ib/gcc4.7/lib\" -DJAVA_HOME=\"/sw/lib/gcc4.7\" -DBOOT_CLASS_PATH=\"/sw/lib/gcc4.7/share/java/libgcj-4.7.0.jar\" -DJAVA_E XT_DIRS=\"/sw/lib/gcc4.7/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/sw/lib/gcc4.7/share/java/gcj-endorsed\" -DGCJ_VERSIONED _LIBDIR=\"/sw/lib/gcc4.7/lib/gcj-4.7.0-13\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"/sw/lib/gcc4.7/share/java/ecj.jar\" -DLIBG
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-23
Ever Confirmed|0 |1
--- Comment #6 from Paolo Carlini 2012-03-23
17:59:05 UTC ---
I'm making some progress understanding these parts of the front-end.
For example the following trivial patchlet passes the testcase ;) But,
seriously, I'm not sure whether we really need a full fledged
build_exception_variant, whether we have to do something about LAZY_* things,
and much, much, more.
Index: class.c
===
--- class.c (revision 185722)
+++ class.c (working copy)
@@ -1001,6 +1001,10 @@ add_method (tree type, tree method, tree using_dec
"destructor",
type);
}
+ else if (cxx_dialect >= cxx0x
+ && !TYPE_RAISES_EXCEPTIONS (TREE_TYPE (method)))
+ TREE_TYPE (method) = build_exception_variant (TREE_TYPE (method),
+ noexcept_true_spec);
}
else
{
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 giulianodammando at libero dot it changed: What|Removed |Added CC||giulianodammando at libero ||dot it --- Comment #1 from giulianodammando at libero dot it 2012-03-23 17:30:36 UTC --- Confirmed on g++-mp-4.7
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf 2012-03-23 17:30:11 UTC --- Looks like you have an old stale version in your path somewhere. What does: $ find /usr/lib -name "libstdc++.a" show?
[Bug libstdc++/52689] New: static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
Bug #: 52689
Summary: static linking with libstdc++ fails
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
$ cat x.cc
#include
int main()
{
std::cout << "hello\n";
}
$ gcc x.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
/usr/bin/ld: a.out: No symbol version section for versioned symbol
`_ZSt15future_category@@GLIBCXX_3.4.14'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
or
$ g++ x.cc -static-libstdc++
/usr/bin/ld: a.out: No symbol version section for versioned symbol
`_ZSt15future_category@@GLIBCXX_3.4.14'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810
[Bug c++/52688] New: static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688
Bug #: 52688
Summary: static local variable can accessed from local class of
function template
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sir_nawaz...@yahoo.com
As per the C++ specification, static local variable can be accessed from local
class of function template, but GCC 4.6.1 gives error for the following
code-snippet:
template
T f()
{
static const double staticLocalVariable = 100.0;
struct local
{
static double f() { return staticLocalVariable; }
};
return T(local::f());
}
int main() {
std::cout << f() << std::endl;
}
While gcc-4.5.1 compiles fine this code, gcc-4.6.1 gives error, saying:
undefined reference to `staticLocalVariable'
[Bug lto/52687] New: [LTO] undefined vtable in dynamic library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52687
Bug #: 52687
Summary: [LTO] undefined vtable in dynamic library
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dim...@gmail.com
GCC trunk [trunk revision 185738], Fedora 16/x64
$ cat foo.cpp
class foo {
virtual void bar();
virtual ~foo() {}
};
$ g++ -flto -c foo.cpp -o foo.o && g++ -shared foo.o -flto -o libfoo.so && nm
-D -C -u libfoo.so foo.o | grep foo
libfoo.so:
U vtable for foo
foo.o:
nm: foo.o: No symbols
native F16/x64 gcc-4.6.3 do the same
[Bug c++/52672] internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:6766
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52672 --- Comment #2 from Meador Inge 2012-03-23 16:44:06 UTC --- Even smaller repro: constexpr unsigned long a = *((int*)(*((int*)0x0)));
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #13 from Michael Haubenwallner 2012-03-23 16:39:53 UTC --- Hmm, err, A and B aren't created at the same time by libtool. Instead, this table really should include static-only libs too: (S)tatic: libNAME.a(static.o) (A)ix:libNAME.a(libNAME.so.1) (B)roken: libNAME.so (L)inux: libNAME.so.1(shr.o) | (default:yes) | (default:yes) | (default:no) | (default:"") | | enable-static | enable-shared | enable-aix-svr4 | LDFLAGS| --+--+---+---+-+--+ 1 | S: yes | no| irrelevant| irrelevant | 2 | A : yes | yes | no | "" | 3 | S B : yes | yes | no | "-brtl"| 4 | B : no| yes | no | "-brtl"| 5 | A L : yes | yes |compat | irrelevant | 6 | S L : yes | yes | yes | irrelevant | 7 |L : no| yes | yes | irrelevant | --+--+---+---+-+--+ Besides shared and/or static, package managers would have a choice of three: 1 and 2: traditional AIX only (3 and 4: broken) 5 : SVR4 with compatibility to traditional AIX 6 and 7: SVR4 only But - first of all: Besides those administrative issues, do you see any technical issue why Import Files cannot be used this way for filename-based versioning over the traditional onefile-membername-based versioning?
[Bug tree-optimization/52633] [4.7 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633 Ulrich Weigand changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-23 CC||uweigand at gcc dot gnu.org AssignedTo|unassigned at gcc dot |uweigand at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #22 from Michael Meissner 2012-03-23 16:16:46 UTC --- Author: meissner Date: Fri Mar 23 16:16:38 2012 New Revision: 185743 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185743 Log: 2012-03-23 Michael Meissner Backported from mainline 2012-03-06 Michael Meissner PR target/50310 * config/rs6000/vector.md (vector_uneq): Add support for UNEQ, LTGT, ORDERED, and UNORDERED IEEE vector comparisons. (vector_ltgt): Likewise. (vector_ordered): Likewise. (vector_unordered): Likewise. * config/rs6000/rs6000.c (rs6000_emit_vector_compare_inner): Likewise. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_7-branch/gcc/config/rs6000/vector.md
[Bug middle-end/23830] inline optimization possibility - reorder compilation step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23830 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka 2012-03-23 15:38:32 UTC --- Inline predicates handle this case for both ipa-constant propagation and inliner. We will now work out that y-prec-x_prec and x_prec-y_prec will be constant and that the conditionals will be decided at compile time. We now inline ChangePrecision at -Os. We however still won't get that y_prec>x_prec can be resolved at compile time. Only tests comparing with constants. BB 2 predicate:(true) if (y_prec_2(D) > x_prec_3(D)) freq:1.00 size: 2 time: 2 Accounting size:2.00, time:2.00 on new predicate:(op2 changed || op1 changed) BB 3 predicate:(true) D.1717_4 = y_prec_2(D) - x_prec_3(D); freq:0.39 size: 1 time: 1 Accounting size:1.00, time:0.39 on predicate:(op2 changed || op1 changed) D.1716_6 = x_5(D) << D.1717_4; freq:0.39 size: 1 time: 1 Accounting size:1.00, time:0.39 on new predicate:(op2 changed || op1 changed || op0 changed) BB 4 predicate:(true) if (y_prec_2(D) < x_prec_3(D)) freq:0.61 size: 2 time: 2 Accounting size:2.00, time:1.22 on predicate:(op2 changed || op1 changed) BB 5 predicate:(true) D.1720_7 = x_prec_3(D) - y_prec_2(D); freq:0.37 size: 1 time: 1 Accounting size:1.00, time:0.37 on predicate:(op2 changed || op1 changed) D.1716_8 = x_5(D) >> D.1720_7; freq:0.37 size: 1 time: 1 Accounting size:1.00, time:0.37 on predicate:(op2 changed || op1 changed || op0 changed) BB 6 predicate:(true) return D.1716_1; freq:1.00 size: 1 time: 2 Will be eliminated by inlining Accounting size:1.00, time:2.00 on predicate:(not inlined) Considering changePrecision.constprop.0 with 5 size to be inlined into t in t.c:12 Estimated growth after inlined into all is -8 insns. Estimated badness is -1073741827, frequency 1.00. Badness calculation for t -> changePrecision.constprop.0 size growth -3, time growth -12 -1073741827: Growth -3 <= 0 Accounting size:2.00, time:0.76 on new predicate:(op0 changed)
[Bug tree-optimization/52686] SLP crashes with WIDEN_LSHIFT_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686 Ulrich Weigand changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-23 Ever Confirmed|0 |1 --- Comment #1 from Ulrich Weigand 2012-03-23 15:38:43 UTC --- It seems the root cause of all the memory problems is that vect_get_smallest_scalar_type neglects to handle WIDEN_LSHIFT_EXPR, which causes the SLP pass to mis-compute the number of statements needed to vectorize the expression.
[Bug tree-optimization/52686] SLP crashes with WIDEN_LSHIFT_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686 --- Comment #2 from Ulrich Weigand 2012-03-23 15:42:00 UTC --- Created attachment 26968 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26968 Handle WIDEN_LSHIFT_EXPR in vect_get_smallest_scalar_type The attached patch fixes the ICEs for me.
[Bug tree-optimization/52686] New: SLP crashes with WIDEN_LSHIFT_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52686
Bug #: 52686
Summary: SLP crashes with WIDEN_LSHIFT_EXPR
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
When building the following test case:
unsigned int output[4];
void test (unsigned short *p)
{
unsigned int x = *p;
if (x)
{
output[0] = x << 1;
output[1] = x << 1;
output[2] = x << 1;
output[3] = x << 1;
}
}
GCC crashes with various symptoms (segmentation fault if checking is disabled;
assertion failures along the lines of "vector VEC(tree,base) index domain
error, in vect_create_vectorized_promotion_stmts at tree-vect-stmts.c:2130" if
checking is enabled) when building on ARM with -O1 -ftree-vectorize -mfpu=neon
-mfloat-abi=softfp.
[Bug bootstrap/52674] [4.7 regression] segfault during profiled LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-23 CC||ebotcazou at gcc dot ||gnu.org Summary|[4.7 regression]|[4.7 regression] segfault |profiledbootstrap-lean |during profiled LTO |fails on Debian/SPARC with |bootstrap |segfault during | |intl/configure | Ever Confirmed|0 |1 Build||sparc-*-linux-gnu --- Comment #1 from Eric Botcazou 2012-03-23 15:33:49 UTC --- I'd simply avoid mixing LTO bootstrap and profiled bootstrap if I were you... I guess nobody will really be interested in debugging this, as debugging LTO is kind of a nightmare on machines that aren't lightning fast. You're alone here.
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|NEW Known to work|| AssignedTo|hubicka at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #33 from Jan Hubicka 2012-03-23 14:51:20 UTC --- Unassinging. Solved in 4.6+; no plans to backport this to 4.5.
[Bug middle-end/48600] [4.6 Regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 --- Comment #20 from Jan Hubicka 2012-03-23 14:22:35 UTC --- Author: hubicka Date: Fri Mar 23 14:22:24 2012 New Revision: 185739 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185739 Log: Backport from mainline PR middle-end/48600 * predict.c (predict_paths_for_bb): Prevent looping. (predict_paths_leading_to_edge, predict_paths_leading_to): Update. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/predict.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/48600] [4.6 Regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #21 from Jan Hubicka 2012-03-23 14:23:23 UTC --- Fixed.
[Bug c++/52683] assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
--- Comment #3 from Petr Ovtchenkov
2012-03-23 13:54:23 UTC ---
> W::operator= is an overloaded function, operator=(const W&) and
> operator=(W&&)
>
> decltype cannot work, because an overload set is not a type
I'm agree. But if you remove all tests with is_assignable2, still remains
problem with int:
...
struct QQ
{
int v;
};
...
static_assert( is_assignable::value, "not assignable" ); // <
fail!
static_assert( is_assignable::value, "not assignable" ); // pass
...
static_assert( is_assignable::value, "not assignable" ); // pass
...
static_assert( is_assignable::value, "not assignable" ); // < pass!
static_assert( is_assignable::value, "not assignable" ); // pass
[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680 --- Comment #3 from Paolo Carlini 2012-03-23 13:34:31 UTC --- Should be in the *library* configure docs, no? Anyway, looking forward, now that glibc is maintained in a slightly different way we should probably reconsider whether we could do better about this, in terms of defaults, etc. By the way, on Linux, I normally build with --enable-libstdcxx-time=rt
[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681 --- Comment #3 from Paolo Carlini 2012-03-23 13:29:38 UTC --- Probably, something in the docs could be also useful.
[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680 --- Comment #2 from Matt Kline 2012-03-23 13:19:44 UTC --- Thanks for shedding some light on this. Is there a reason that --enable-libstdccxx-time isn't shown on http://gcc.gnu.org/install/configure.html?
[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681 --- Comment #2 from Matt Kline 2012-03-23 13:16:23 UTC --- Would it be possible to at least make the exception that is being thrown more descriptive? I had guessed that some kind of compile-time warning might be impossible, but my main concern is that the exception that gets thrown offers little insight on what the problem might be.
[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680 --- Comment #1 from Jonathan Wakely 2012-03-23 12:45:48 UTC --- Don't define that manually, you should configure gcc with --enable-libstdccxx-time instead. We need to revisit the configure tests for nanosleep and sched_yield, as they are always available on some platforms, so we might be able to make --enable-libstdcxx-time the default, or make the configure checks more finegrained.
[Bug c++/52683] assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683 --- Comment #2 from Jonathan Wakely 2012-03-23 12:43:15 UTC --- (In reply to comment #0) > Assignment operator not detected via declval<>() for POD types. W::operator= is an overloaded function, operator=(const W&) and operator=(W&&) decltype cannot work, because an overload set is not a type
[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681 Jonathan Wakely changed: What|Removed |Added Severity|minor |enhancement --- Comment #1 from Jonathan Wakely 2012-03-23 12:31:38 UTC --- The problem is that not all targets need -pthread, or some which do need it spell it differently, and not all platforms define _REENTRANT when the option is used, so there's no reliable way to do what you're asking for.
[Bug tree-optimization/52678] [4.7 Regression] internal compiler error: in vect_update_ivs_after_vectorizer, at tree-vect-loop-manip.c:1842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52678 --- Comment #6 from Richard Guenther 2012-03-23 11:34:37 UTC --- Author: rguenth Date: Fri Mar 23 11:34:32 2012 New Revision: 185734 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185734 Log: 2012-03-23 Richard Guenther PR tree-optimization/52678 * tree-vectorizer.h (struct _stmt_vec_info): Add loop_phi_evolution_part member. (STMT_VINFO_LOOP_PHI_EVOLUTION_PART): New define. * tree-vect-loop.c (vect_analyze_scalar_cycles_1): Initialize STMT_VINFO_LOOP_PHI_EVOLUTION_PART. * tree-vect-loop-manip.c (vect_update_ivs_after_vectorizer): Use the cached evolution part and the PHI nodes value from the loop preheader edge instead of re-analyzing the evolution. * gfortran.dg/pr52678.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr52678.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/52678] [4.7 Regression] internal compiler error: in vect_update_ivs_after_vectorizer, at tree-vect-loop-manip.c:1842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52678 Richard Guenther changed: What|Removed |Added Known to work||4.6.3 Target Milestone|--- |4.7.1 Summary|internal compiler error: in |[4.7 Regression] internal |vect_update_ivs_after_vecto |compiler error: in |rizer, at |vect_update_ivs_after_vecto |tree-vect-loop-manip.c:1842 |rizer, at ||tree-vect-loop-manip.c:1842 --- Comment #5 from Richard Guenther 2012-03-23 11:34:10 UTC --- Fixed on trunk sofar. Works on the 4.6 branch for me (well, the reduced testcase at least). Queued for backporting at some point.
[Bug c++/52685] New: [4.7/4.8 Regression] ICE in copy_binfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52685
Bug #: 52685
Summary: [4.7/4.8 Regression] ICE in copy_binfo
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: fab...@gcc.gnu.org, ja...@gcc.gnu.org
template
struct A
{
template
struct B : public A >
{
struct C : public B
{
};
};
};
ICEs starting with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184328
[Bug target/25967] Add attribute naked for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 Bryan O'Donoghue changed: What|Removed |Added CC||bryan.odonoghue at linux ||dot intel.com --- Comment #8 from Bryan O'Donoghue 2012-03-23 11:25:19 UTC --- Guys. I'd like to add to the calls for __attribute__((naked)) to be implemented on x86. For the case of interrupts particularly, naked attribute would allow us to control the procedure prologue and epilogue more effectively and hence have less code and fewer cycles in order to service an IRQ on x86, which is clearly a good thing for everybody. attribute naked is a highly useful and widely used gcc extension on ARM and all of the valid use-cases for naked on ARM are also valid reasons on x86. Particularly with attribute naked on x86 we could write a C function and stuff that directly into an interrupt gate - using macros for procedure prologue/epilogue as necessary for interrupts or exceptions (which have different stack arrangements on x86). Most OS implementations have 256 separate functions as some sort of macro generated assembly - specifically to put into the interrupt gate. These entry/exit functions then typically go to a lookup table and call into the 'real' interrupt handler. That long process of indirection (and the unnecessary stub functions for the interrupt gate) could be gotten rid of, if gcc would implement naked attribute on x86, in the same fashion as on ARM. Basically the developer should have the same freedom to implement solutions as appropriate on x86 as on ARM.
[Bug c++/52685] [4.7/4.8 Regression] ICE in copy_binfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52685 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.7.1
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Version|4.6.4 |4.7.1 Resolution||FIXED --- Comment #18 from Paolo Carlini 2012-03-23 11:03:59 UTC --- Should be fixed mainline and 4.7.1.
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #6 from Laurent Aflonsi 2012-03-23 11:06:57 UTC --- Sorry for the late answer (sickness). Well, In fact there are 2 things in the atexit list : 1) The destruction of the "list_type" global variable. Destructor is : "std::list > >::~list()" => This one is registered in atexit list by the __static_initialization_and_destruction_0() because it is a global variable. 2) The destruction of the mt_allocator itself "(anonymous namespace)::__freelist::~__freelist()" => This one is registered in atexit list during the main() execution. when first using the mt_allocator (first called get_freelist()) The above 2 destructors are registered in atexit list in this order (1 then 2). Then, they are invoked in the reverse order (2 then 1). The freelist is first destroyed (where i proposed to add zeroing), followed by the destruction of the list_type that invokes _M_get_thread_id() : __gnu_cxx::__pool::_M_get_thread_id () __gnu_cxx::__pool::_M_reclaim_block () __gnu_cxx::__mt_alloc, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate(std::_List_node*, unsigned long) () std::_List_base > >::_M_put_node(std::_List_node*) () std::_List_base > >::_M_clear() () std::_List_base > >::~_List_base() () std::list > >::~list() () exit () Jakub, do you think this order of destruction is not justified ? Do you see another solution than the one i proposed ? Thanks very much. Laurent
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #17 from paolo at gcc dot gnu.org 2012-03-23 11:01:01 UTC --- Author: paolo Date: Fri Mar 23 11:00:54 2012 New Revision: 185733 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185733 Log: 2012-03-23 Paweł Sikora PR libstdc++/52540 * include/Makefile.am (c++config.h): Fix sed rule to not break the _GLIBCXX_EXTERN_TEMPLATE redefinition. * include/Makefile.in: Regenerate. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_7-branch/libstdc++-v3/include/Makefile.in
[Bug middle-end/52649] internal compiler error: in predict_paths_for_bb, at predict.c:1812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52649 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jan Hubicka 2012-03-23 10:49:37 UTC --- This is dup. *** This bug has been marked as a duplicate of bug 48600 ***
[Bug middle-end/48600] [4.6 Regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 Jan Hubicka changed: What|Removed |Added CC||deepu.sarmatian at gmail ||dot com --- Comment #19 from Jan Hubicka 2012-03-23 10:49:37 UTC --- *** Bug 52649 has been marked as a duplicate of this bug. ***
[Bug middle-end/52649] internal compiler error: in predict_paths_for_bb, at predict.c:1812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52649 Richard Guenther changed: What|Removed |Added Attachment #26939|0 |1 is obsolete|| --- Comment #3 from Richard Guenther 2012-03-23 10:42:41 UTC --- Created attachment 26967 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26967 kill previous attachment
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #12 from Michael Haubenwallner 2012-03-23 10:29:15 UTC --- (In reply to comment #11) > Give package managers another choice how to build the packages, out of: > A: libNAME.a(libNAME.so.1) (libtool default) > B: libNAME.so (supported by libtool) > C: libNAME.so.1(shr.o) (new) > Using autoconf+libtool, the variants could be selected using: > A: default (same as --disable-aix-svr4) Err, aix-svr4 chooses between B or C only, so this should read: A: default > A B : LDFLAGS=-Wl,-brtl > B : LDFLAGS=-Wl,-brtl --disable-static > A C: --enable-aix-svr4 > C: --enable-aix-svr4 --disable-static
[Bug tree-optimization/52678] internal compiler error: in vect_update_ivs_after_vectorizer, at tree-vect-loop-manip.c:1842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52678 --- Comment #4 from Richard Guenther 2012-03-23 10:19:53 UTC --- Created attachment 26966 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26966 patch No, in fact, generating the _prologue_ loop adjusts the original PHI node from openad_symbol_188_2 = PHI <0(2), openad_symbol_188_42(4)> to openad_symbol_188_2 = PHI and we _do_ analyze that original loop PHI. But now fail to. One solution would be to delay peeling for the prologue loop after we peeled the epilogue loop - but that has quite some fallout. Another solution would be to save the scalar evolution result, but we explicitely free it after the first peeling (because obviously while the evolution part of openad_symbol_188_2 is still correct, it's initial value is not). So the correct thing seems to be to preserve the evolution part and simply take the initial value from the PHI operand.
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #11 from Michael Haubenwallner 2012-03-23 09:31:41 UTC --- Unless IBM does, I don't want to change any default here, nor force anyone to use -brtl. What I'm after is: Give package managers another choice how to build the packages, out of: A: libNAME.a(libNAME.so.1) (libtool default) B: libNAME.so (supported by libtool) C: libNAME.so.1(shr.o) (new) Using autoconf+libtool, the variants could be selected using: A: default (same as --disable-aix-svr4) A B : LDFLAGS=-Wl,-brtl B : LDFLAGS=-Wl,-brtl --disable-static A C: --enable-aix-svr4 C: --enable-aix-svr4 --disable-static (*able-aix-svr4 feels more correct than *able-aix-soname) For the FLOSS developers: Most of them don't care AIX (among others) at all. However, they use libtool (or something else) that allows them to not care. For XLC: There is nothing specific to GCC, Import Files work with XLC too, and I don't want to change anything within collect2 or GNU-ld - just the build-scripts (libtool&co). For multilib: I've seen package managers building a package twice, and merge both "(libNAME.so.1)" into "libNAME.a". This works for A as well as C, but does not work for B. (In reply to comment #10) > An additional problem is Binutils "strip" command does not support the -e/-E > command line option to set F_LOADONLY. This should be fixed anyway.
[Bug tree-optimization/52678] internal compiler error: in vect_update_ivs_after_vectorizer, at tree-vect-loop-manip.c:1842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52678 --- Comment #3 from Richard Guenther 2012-03-23 09:29:07 UTC --- The issue is that for an induction variable i in long i; for (i = 0; i < 15; i = (int) i + 1) ; we know its evolution if we know the number of iterations which we know because we know its initial value. For the epilogue loop though we then see (after deciding to vectorize) for (; i < n; i = (int) i + 1) ; where we neither see the lower nor upper bound and due to the truncation we cannot analyze its evolution anymore. The issue is, of course, that we only need the evolution part and that this evolution part does not change from the initial scalar loop, so we could just use that which we could analyze easily. But we choose to re-analyze the epilogue loop :(
[Bug tree-optimization/52678] internal compiler error: in vect_update_ivs_after_vectorizer, at tree-vect-loop-manip.c:1842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52678 --- Comment #2 from Richard Guenther 2012-03-23 09:06:32 UTC --- I can reproduce the ICE, it's one of the more fragile areas of the vectorizer... Reduced testcase, ICEs at -O -ftree-vectorize -ffixed-form: SUBROUTINE OpenAD_set_ref_state(DRF, RHOFACF, RHOFACC) real(8) DRF(1 : 15) real(8) RHOFACF(1 : 16) real(8) RHOFACC(1 : 15) integer, dimension(:), allocatable :: oad_it integer :: oad_it_ptr INTEGER(8) OpenAD_Symbol_188 INTEGER(4) K OpenAD_Symbol_188 = 0 DO K = 2, 15, 1 RHOFACF(INT(K)) = ((RHOFACC(K) * DRF(K + (-1)) + RHOFACC(K + + (-1)) * DRF(K)) /(DRF(K) + DRF(K + (-1 OpenAD_Symbol_188 = (INT(OpenAD_Symbol_188) + INT(1)) END DO oad_it(oad_it_ptr) = OpenAD_Symbol_188 end subroutine OpenAD_set_ref_state
[Bug target/52684] glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 davem at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-23 Ever Confirmed|0 |1
[Bug target/52684] New: glibc long double math tests fail on sparc 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 Bug #: 52684 Summary: glibc long double math tests fail on sparc 64-bit Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@gcc.gnu.org When built with gcc-4.7, several glibc long double math tests fail on 64-bit sparc. This might be more fallout from the rewrite of the sparc movcc patterns, but that's just a hunch.
[Bug tree-optimization/52638] [4.8 Regression] ice in build_vector_from_val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52638 --- Comment #5 from Richard Guenther 2012-03-23 08:33:03 UTC --- Author: rguenth Date: Fri Mar 23 08:32:47 2012 New Revision: 185727 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185727 Log: 2012-03-23 Richard Guenther PR tree-optimization/52638 * g++.dg/torture/pr52638.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr52638.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52638] [4.8 Regression] ice in build_vector_from_val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52638 Richard Guenther changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #4 from Richard Guenther 2012-03-23 08:30:24 UTC --- *** Bug 52677 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/52677] [4.8 Regression] ICE: in build_vector_from_val, at tree.c:1386 with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52677 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther 2012-03-23 08:30:24 UTC --- Dup of 52638. I'm adding the testcase. *** This bug has been marked as a duplicate of bug 52638 ***
[Bug c/52682] [patch] gcc-4.7.0/gcc/c-family/c-lex.c doesn't compile with old C compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52682 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2012-03-23 08:19:32 UTC --- Fixed.
[Bug c/52682] [patch] gcc-4.7.0/gcc/c-family/c-lex.c doesn't compile with old C compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52682 --- Comment #1 from Richard Guenther 2012-03-23 08:19:19 UTC --- Author: rguenth Date: Fri Mar 23 08:19:08 2012 New Revision: 185726 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185726 Log: 2012-03-23 William Bader PR c/52682 * c-lex.c (c_lex_with_flags): Avoid declarations after stmts. Modified: branches/gcc-4_7-branch/gcc/c-family/ChangeLog branches/gcc-4_7-branch/gcc/c-family/c-lex.c
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #20 from Ralph Loader 2012-03-23 07:54:51 UTC --- Re comment 12 - as someone who regularly needs to understand gcc diagnostics, I disagree completely. Understanding a failure to look something up, the single most important thing to know is the key being looked up, and in this case the key is the function/operator name and the argument types. gcc used to output that information, and removing that was a regression, completely independently of whether the current diagnostics make any sense. Given that no significant progress has been made with fixing the current diagnostics in nearly a decade, it is puzzling to me why the obvious & simple fix of reverting to the previous, useful, diagnostics, has not been made.
[Bug c++/52683] assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683 --- Comment #1 from Petr Ovtchenkov 2012-03-23 07:37:57 UTC --- Created attachment 26965 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26965 test case test case. -std=gnu++0x required.
[Bug c++/52683] New: assignment operator not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683 Bug #: 52683 Summary: assignment operator not detected Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: abominable-snow...@yandex.ru Assignment operator not detected via declval<>() for POD types. Testcase in attach. It work as expected for gcc 4.5.2, but not work for gcc 4.6.3: $ x86_64-unknown-linux-gnu-gcc-4.5.2 -c -std=gnu++0x test.cc $ c++ -c -std=gnu++0x test.cc test.cc: In function 'void f()': test.cc:71:3: error: static assertion failed: "not assignable" test.cc:77:3: error: static assertion failed: "not assignable" $ c++ --version c++ (GCC) 4.6.3 Copyright (C) 2011 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.
[Bug tree-optimization/52678] internal compiler error: in vect_update_ivs_after_vectorizer, at tree-vect-loop-manip.c:1842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52678 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-03-23 07:06:43 UTC --- I will have a look.
[Bug tree-optimization/52677] [4.8 Regression] ICE: in build_vector_from_val, at tree.c:1386 with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52677 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-03-23 07:05:59 UTC --- Mine.
[Bug bootstrap/52674] [4.7 regression] profiledbootstrap-lean fails on Debian/SPARC with segfault during intl/configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.1
