[Bug fortran/51634] [OOP] ICE with polymorphic operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-19 08:13:13 UTC --- FIXED on the trunk (4.7). Thanks for the patch, Paul!
[Bug fortran/48426] [patch] Quad precision promotion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #21 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-19 08:14:31 UTC --- (In reply to comment #19) I may backport in a few days or close the PR as FIXED. I would prefer to not backport it.
[Bug fortran/51899] New: [4.7 Regression] libgfortran's chmod.c fails to build on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51899 Bug #: 51899 Summary: [4.7 Regression] libgfortran's chmod.c fails to build on MinGW Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org libgfortran fails to build on MinGW with the following error. It's a regression caused by the fix for PR 36755 / Rev. 183137. .deps/chmod.Tpo -c ../../../gcc-trunk/libgfortran/intrinsics/chmod.c -DDLL_EXPORT -DPIC -o .libs/chmod.o ../../../gcc-trunk/libgfortran/intrinsics/chmod.c: In function 'chmod_func': ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:92:7: warning: format '%o' expects argument of type 'unsigned int *', but argument 3 has type 'mode_t *' [-Wformat] ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:106:3: warning: implicit declaration of function 'umask' [-Wimplicit-f unction-declaration] ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:294:18: error: 'S_IRGRP' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:294:18: note: each undeclared identifier is reported only once for eac h function it appears in ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:296:18: error: 'S_IROTH' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:305:18: error: 'S_IWGRP' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:307:18: error: 'S_IWOTH' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:316:18: error: 'S_IXGRP' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:318:18: error: 'S_IXOTH' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:330:18: error: 'S_ISUID' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:332:18: error: 'S_ISGID' undeclared (first use in this function) ../../../gcc-trunk/libgfortran/intrinsics/chmod.c:420:17: error: 'S_ISVTX' undeclared (first use in this function)
[Bug rtl-optimization/51505] [4.5/4.6 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.0 Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] ICE: |ICE: in form_sum, at|in form_sum, at |reload.c:5349 with -O |reload.c:5349 with -O |--param max-cse-insns=1 |--param max-cse-insns=1 Known to fail|4.7.0 | --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 08:49:22 UTC --- Fixed on the trunk so far, thanks.
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 --- Comment #5 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-01-19 08:52:04 UTC --- As per #4, here's the convenience library approach. With this, libstdc++.so is composed of three convenience libraries: 1. libsupc++convenience.la 2. libstdc++98convenience.la 3. libstdc++11convenience.la This seems like it will work, but haven't reproduced this issue yet so can't tell for certain. I'm not exactly sure how to use these convenience libraries instead of libstdc++.a in the gcc build process. But perhaps somebody else can figure out that part
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 --- Comment #6 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-01-19 08:52:55 UTC --- Created attachment 26373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26373 libstdc++ binary composed from three convenience libraries
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 --- Comment #7 from Paolo Bonzini bonzini at gnu dot org 2012-01-19 08:59:02 UTC --- The convenience library can be linked with -L.../.libs -lsupc++convenience -lstdc++convenience98. But it really looks like you attached the wrong patch?
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Attachment #26373|0 |1 is obsolete|| --- Comment #8 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-01-19 09:08:12 UTC --- Created attachment 26374 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26374 full patch with src renames
[Bug fortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51899 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-19 AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug target/51106] [4.5/4.6/4.7 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #2 from Andrey Belevantsev abel at gcc dot gnu.org 2012-01-19
09:24:27 UTC ---
Well, the instantiate virtual regs pass just deletes the asm as having
impossible constraints and does not clean up cfg after itself. As the asm is
actually a jump in this case, everything blows up.
The trivial patch below makes this work for -O[012]. Any other places in
function.c need patching up? Jakub, what do you think?
diff --git a/gcc/function.c b/gcc/function.c
index fcb79f5..94e51f4 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -1737,7 +1737,7 @@ instantiate_virtual_regs_in_insn (rtx insn)
if (!check_asm_operands (PATTERN (insn)))
{
error_for_asm (insn, impossible constraint in %asm%);
- delete_insn (insn);
+ delete_insn_and_edges (insn);
}
}
else
[Bug middle-end/45472] [4.5/4.6/4.7 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472 --- Comment #18 from Andrey Belevantsev abel at gcc dot gnu.org 2012-01-19 09:28:56 UTC --- (In reply to comment #17) By the way I think we could get cases where the user wrote volatile in one case and non-volatile in another so fixing up the merging is still a good idea. Sure, but the comment 14 still applies -- I think that unless the middle-end will have the proper volatile semantics, it will be wrong to hide this issue in the scheduler, so I'm leaving this as it is for now.
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 --- Comment #13 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-01-19 09:34:07 UTC --- Created attachment 26375 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26375 libxul link error log BTW I've first observed this bug while building a PGO-LTO Firefox. The errors of the final libxul link are attached (unrelated warnings have been deleted). As you can see there are ~350 (closely related) errors altogether.
[Bug tree-optimization/37997] PHI translation does not simplify to non-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37997
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19
09:35:38 UTC ---
int foo (int i, int b)
{
int mask;
int result;
if (b)
mask = -1;
else
mask = 0;
result = result mask;
return result;
}
actually works if you do not have result used uninitialized on the
path that sets mask to -1:
int foo (int i, int b, int result)
{
int mask;
if (b)
mask = -1;
else
mask = 0;
result = result mask;
return result;
}
is optimized to
bb 2:
if (b_2(D) != 0)
goto bb 5;
else
goto bb 3;
bb 5:
pretmp.3_9 = result_5(D);
goto bb 4;
bb 3:
bb 4:
# mask_1 = PHI -1(5), 0(3)
# prephitmp.4_10 = PHI pretmp.3_9(5), 0(3)
result_6 = prephitmp.4_10;
return result_6;
Likewise it works for
int foo (int i, int b)
{
int mask;
int result;
if (b)
mask = -1;
else
mask = 0;
result = i + 1;
result = result mask;
return result;
}
if you avoid the same error. I don't think we want to consider
the uninitialized state of a variable to be available - we'd
insert obvious uninitialized uses and thus might expose them
to warnings.
[Bug tree-optimization/37997] PHI translation does not simplify to non-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37997 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 09:38:25 UTC --- Fixed.
[Bug tree-optimization/37997] PHI translation does not simplify to non-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37997 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 09:38:04 UTC --- Author: rguenth Date: Thu Jan 19 09:37:58 2012 New Revision: 183297 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183297 Log: 2012-01-19 Richard Guenther rguent...@suse.de PR tree-optimization/37997 * gcc.dg/tree-ssa/ssa-pre-28.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/51106] [4.5/4.6/4.7 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19
09:43:16 UTC ---
Shorter testcase for gcc.c-torture/compile/ :
int
foo (int x)
{
asm goto ( : : i (x) : : lab);
return 1;
lab:
return 0;
}
Yeah, I think delete_insn_and_edges is the right fix here. You might also add
into the testsuite:
int
bar (int x)
{
asm goto ( : : i (x) : : lab);
__builtin_unreachable ();
lab:
return 0;
}
(fortunately at this point the bb ending with the asm goto still has a fallthru
successor, otherwise purge_dead_edges wouldn't work).
[Bug c/51896] Should gcc warn if a variable initializer inside a switch statement is never used?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51896
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-19
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19
10:04:01 UTC ---
Confirmed. This is similar to
int
main(int argc, char *argv[])
{
goto _default;
{
int *b = (int*)0x;
_default:
printf(b is: %p\n, b);
}
return 0;
}
thus, when you jump across an init expression and still use the variable.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 10:06:38 UTC --- (In reply to comment #2) This starts with eipa_sra. It changes a S argument (which has TImode TYPE_MODE) into char [9] (with BLKmode)) and then on both caller and callee side we have on one side a BLKmode type and on the other side a BLKmode MEM_REF with pointer to TImode on the second MEM_REF operand. I wonder why it does this, instead of just using type S, and if it really has to for some reason, why it can't at least make sure it has the same TYPE_MODE. Changing a TImode argument to a BLKmode argument doesn't look at least like a good optimization. Or the bug is in the MEM_REF expansion, which expands a BLKmode MEM_REF into a TImode reg: bftype = TREE_TYPE (base); if (TYPE_MODE (TREE_TYPE (exp)) != BLKmode) bftype = TREE_TYPE (exp); return expand_expr (build3 (BIT_FIELD_REF, bftype, base, TYPE_SIZE (TREE_TYPE (exp)), bit_offset), target, tmode, modifier); base here is TImode (x PARM_DECL), but exp is BLKmode, so this returns a TImode pseudo. Shouldn't it store it into a BLKmode temporary and return that MEM instead? Using a BIT_FIELD_REF looked most convenient. Using extract_bit_field may also be an option (which I suppose is what the above ends up doing?)
[Bug c/51894] Fail to warn on likely precedence error in conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51894 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 Severity|minor |enhancement --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 10:10:54 UTC --- Confirmed.
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 10:11:49 UTC --- So, confirmed.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:16:07 UTC --- (In reply to comment #3) bftype = TREE_TYPE (base); if (TYPE_MODE (TREE_TYPE (exp)) != BLKmode) bftype = TREE_TYPE (exp); return expand_expr (build3 (BIT_FIELD_REF, bftype, base, TYPE_SIZE (TREE_TYPE (exp)), bit_offset), target, tmode, modifier); base here is TImode (x PARM_DECL), but exp is BLKmode, so this returns a TImode pseudo. Shouldn't it store it into a BLKmode temporary and return that MEM instead? Using a BIT_FIELD_REF looked most convenient. Using extract_bit_field may also be an option (which I suppose is what the above ends up doing?) I think if exp is BLKmode, then we don't want to do a BIT_FIELD_REF nor extract_bit_field. We IMHO need to store base into a temporary and just adjust the MEM. Or extract the bit field and then store it into a temporary and adjust, but the former looks easier.
[Bug c/51900] New: [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900
Bug #: 51900
Summary: [4.6 Regression] const variable initialization always
zero
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de
Host: mingw32
Target: mingw32
Build: mingw32
/* a.c */
#include a.h
const int myVar[3] = { 5, 6, 7 };
/* a.h */
#ifndef a_h
#define a_h
const int myVar[3];
#endif
/* main.c */
#include stdio.h
#include a.h
void main() {
int i;
for (i = 0; i 3; i++) printf(myVar[%i] = %i\n, i, myVar[i]);
fflush(stdout);
}
Result gcc 4.5.2:
myVar[0] = 5
myVar[1] = 6
myVar[2] = 7
Result gcc 4.6.2:
myVar[0] = 0
myVar[1] = 0
myVar[2] = 0
Configurations:
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw452\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw452/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --disable-nls --disable-shared --enable-static
--enable-libgcj --enable-libgomp --enable-lto --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--program-suffix= --build=mingw32 --enable-abi=32 --enable-checking=release
Thread model: win32
gcc version 4.5.2 (GCC)
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw462\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw462/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--disable-nls --disable-shared --enable-static --enable-libgcj --enable-libgomp
--enable-lto --with-dwarf2 --disable-win32-registry
--enable-version-specific-runtime-libs --build=mingw32 --enable-abi=32
--enable-checking=release --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
Compiled with:
CC = gcc
CFLAGS = -static -O2
LDFLAGS = -static
all: main.exe
.PHONY: clean
clean:
rm -f *.o
rm -f *.exe
main.exe: main.o a.o
$(CC) $(LDFLAGS) -o main.exe main.o a.o
main.o: main.c
$(CC) $(CFLAGS) -o main.o -c main.c
a.o: a.c
$(CC) $(CFLAGS) -o a.o -c a.c
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #36 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:43:58 UTC --- Author: jakub Date: Thu Jan 19 10:43:54 2012 New Revision: 183299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183299 Log: PR bootstrap/50237 * config/initfini-array.h: Guard content of the header with #ifdef HAVE_INITFINI_ARRAY. * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file. Add initfini-array.h to tm_file here. * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker test. * config.gcc: Don't add initfini-array.h to tm_file here. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/acinclude.m4 trunk/gcc/config.gcc trunk/gcc/config/initfini-array.h trunk/gcc/configure trunk/gcc/configure.ac
[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:46:35 UTC --- Author: jakub Date: Thu Jan 19 10:46:31 2012 New Revision: 183300 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183300 Log: PR libstdc++/51845 * include/bits/hashtable.h (_Hashtable::erase(const_iterator, const_iterator)): Also update _M_buckets[__n_bkt] if __is_bucket_begin. * testsuite/23_containers/unordered_multimap/erase/51845-multimap.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/erase/51845-multimap.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-19 10:47:45 UTC --- Please try the fix for PR middle-end/50325.
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:48:05 UTC --- Author: jakub Date: Thu Jan 19 10:47:59 2012 New Revision: 183301 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183301 Log: PR rtl-optimization/48496 * src/ia64/ffi.c (ffi_call): Fix up aliasing violations. Modified: trunk/libffi/ChangeLog trunk/libffi/src/ia64/ffi.c
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:50:13 UTC --- Rainer/Andrew, please test this in your configurations.
[Bug tree-optimization/51566] [4.7 Regression] ICE: verify_gimple in testsuite/g++.dg/ipa/iinline-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51566 --- Comment #2 from Greta Yorsh Greta.Yorsh at arm dot com 2012-01-19 10:50:09 UTC --- I did git bisect and it shows that the ICE disappears from r182403. Looks like the problem has been fixed by this patch: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01247.html It's a fix for PR51576, where the error message is similar to the error message we get here, before ICE: error: statement marked for throw, but doesn’t.
[Bug tree-optimization/51566] [4.7 Regression] ICE: verify_gimple in testsuite/g++.dg/ipa/iinline-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51566 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:53:32 UTC --- Fixed then, thanks for the info.
[Bug libstdc++/51845] [4.7 regression] 23_containers/unordered_multimap/erase/24061-multimap.cc segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:54:19 UTC --- Fixed.
[Bug libgcj/51901] New: [4.7 regression] java.security.Security.getProperty throws ExceptionInInitializerError
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51901 Bug #: 51901 Summary: [4.7 regression] java.security.Security.getProperty throws ExceptionInInitializerError Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: jojel...@gmail.com Host: i686-pc-cygwin Target: i686-pc-mingw32 Build: i686-pc-cygwin system property 'java.security.manager' is not defined. so ClassLoader doesn't initializes SecurityManager. $ ./gcj-dbtool.exe -n classmap.db Exception in thread main java.lang.ExceptionInInitializerError at java.lang.Class.initializeClass(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:803) at java.security.Security.getProperty(/tmp/gcc/libjava/classpath/java/security/Security.java:366) at java.net.ResolverCache.getTTL(/tmp/gcc/libjava/classpath/java/net/ResolverCache.java:90) at java.net.ResolverCache.clinit(/tmp/gcc/libjava/classpath/java/net/ResolverCache.java:77) at java.lang.Class.initializeClass(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:791) at java.net.ResolverCache.getHostByAddr(/tmp/gcc/libjava/classpath/java/net/ResolverCache.java:118) at java.net.InetAddress.internalGetCanonicalHostName(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:319) at java.net.InetAddress.getCanonicalHostName(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:334) at java.net.InetAddress.getHostName(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:307) at java.net.InetAddress.clinit(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:92) at java.lang.Class.initializeClass(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:791) at java.net.InetAddress.getLocalHost(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:612) at gnu.java.net.GetLocalHostAction.run(/tmp/gcc/libjava/classpath/gnu/java/net/GetLocalHostAction.java:57) at gnu.java.net.GetLocalHostAction.run(/tmp/gcc/libjava/classpath/gnu/java/net/GetLocalHostAction.java:1) at java.security.AccessController.doPrivileged(/tmp/gcc/libjava/classpath/java/security/AccessController.java:96) at gnu.java.net.protocol.ftp.FTPURLConnection.connect(/tmp/gcc/libjava/classpath/gnu/java/net/protocol/ftp/FTPURLConnection.java:117) at gnu.java.net.protocol.ftp.FTPURLConnection.getInputStream(/tmp/gcc/libjava/classpath/gnu/java/net/protocol/ftp/FTPURLConnection.java:165) at java.net.URL.openStream(/tmp/gcc/libjava/classpath/java/net/URL.java:737) at java.util.logging.LogManager.readConfiguration(/tmp/gcc/libjava/java/util/logging/LogManager.java:507) at java.util.logging.LogManager.initLogManager(/tmp/gcc/libjava/java/util/logging/LogManager.java:203) at java.util.logging.LogManager.getLogManager(/tmp/gcc/libjava/java/util/logging/LogManager.java:168) at java.util.logging.Logger.getLogger(/tmp/gcc/libjava/java/util/logging/Logger.java:276) at java.util.logging.Logger.getLogger(/tmp/gcc/libjava/java/util/logging/Logger.java:224) at java.util.logging.Logger$1.run(/tmp/gcc/libjava/java/util/logging/Logger.java:91) at java.security.AccessController.doPrivileged(/tmp/gcc/libjava/classpath/java/security/AccessController.java:96) at java.util.logging.Logger.clinit(/tmp/gcc/libjava/java/util/logging/Logger.java:86) at java.lang.Class.initializeClass(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:791) at java.util.logging.Logger.getLogger(/tmp/gcc/libjava/java/util/logging/Logger.java:224) at java.math.BigInteger.clinit(/tmp/gcc/libjava/classpath/java/math/BigInteger.java:67) at java.lang.Class.initializeClass(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:791) at gnu.gcj.runtime.PersistentByteMap.init(/tmp/gcc/libjava/gnu/gcj/runtime/PersistentByteMap.java:181) at gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(/tmp/gcc/libjava/gnu/gcj/runtime/PersistentByteMap.java:231) at gnu.gcj.tools.gcj_dbtool.Main.main(/tmp/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java:82) Caused by: java.lang.NullPointerException at java.net.ResolverCache.reap(/tmp/gcc/libjava/classpath/java/net/ResolverCache.java:221) at java.net.ResolverCache.get(/tmp/gcc/libjava/classpath/java/net/ResolverCache.java:192) at java.net.ResolverCache.getHostByName(/tmp/gcc/libjava/classpath/java/net/ResolverCache.java:152) at java.net.InetAddress.getAllByName(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:590) at java.net.InetAddress.getByName(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:550) at java.net.InetAddress.getLocalHost(/tmp/gcc/libjava/classpath/java/net/InetAddress.java:615) at
[Bug middle-end/50200] ICE: SIGSEGV in df_insn_refs_collect (df-scan.c:3405)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50200 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2012-01-19 11:03:26 UTC --- Created attachment 26376 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26376 testcase failing in r183270 Both testcases were reduced from testsuite/gcc.c-torture/execute/pr44575.c Compiler output: (-fno-tree-dominator-opts is no longer needed) $ gcc -O -fno-tree-ch -fno-tree-loop-optimize -funroll-loops --param=case-values-threshold=1 testcase2.c ==27252== Invalid read of size 8 ==27252==at 0x6E2984: df_insn_refs_collect(df_collection_rec*, basic_block_def*, df_insn_info*) (df-scan.c:3406) ==27252==by 0x6E34D9: df_insn_refs_verify(df_collection_rec*, basic_block_def*, rtx_def*, bool) (df-scan.c:4344) ==27252==by 0x6E382C: df_bb_verify(basic_block_def*) (df-scan.c:4393) ==27252==by 0x6E6077: df_scan_verify() (df-scan.c:4527) ==27252==by 0x6D00F8: df_verify() (df-core.c:1644) ==27252==by 0x6D0228: df_analyze() (df-core.c:1205) ==27252==by 0x112A969: rest_of_handle_initialize_regs() (init-regs.c:60) ==27252==by 0x8FAD84: execute_one_pass(opt_pass*) (passes.c:2081) ==27252==by 0x8FB144: execute_pass_list(opt_pass*) (passes.c:2136) ==27252==by 0x8FB156: execute_pass_list(opt_pass*) (passes.c:2137) ==27252==by 0xA5D25D: tree_rest_of_compilation(tree_node*) (tree-optimize.c:420) ==27252==by 0x6AFC39: cgraph_expand_function(cgraph_node*) (cgraphunit.c:1818) ==27252==by 0x6B1B0B: cgraph_optimize() (cgraphunit.c:1885) ==27252==by 0x6B2169: cgraph_finalize_compilation_unit() (cgraphunit.c:1327) ==27252==by 0x58F0BF: c_write_global_declarations() (c-decl.c:10030) ==27252==by 0x9EFD1B: toplev_main(int, char**) (toplev.c:573) ==27252==by 0x66E009C: (below main) (in /lib64/libc-2.13.so) ==27252== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==27252== testcase2.c: In function 'foo': testcase2.c:22:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. When -fno-web is added, it ICEs at a different place: $ gcc -O -fno-tree-ch -fno-tree-loop-optimize -funroll-loops --param=case-values-threshold=1 testcase2.c -fno-web testcase2.c: In function 'foo': testcase2.c:22:1: internal compiler error: in remove_insn, at emit-rtl.c:3980 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x125fac8 /mnt/svn/gcc-trunk/gcc/emit-rtl.c, line=3980, function=0x1260cc1 remove_insn) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898 #1 0x0073ef9c in remove_insn (insn=0x75bd0678) at /mnt/svn/gcc-trunk/gcc/emit-rtl.c:3980 #2 0x0069c221 in delete_insn (insn=0x75bd0678) at /mnt/svn/gcc-trunk/gcc/cfgrtl.c:145 #3 0x006a3548 in delete_insn_and_edges (insn=optimized out) at /mnt/svn/gcc-trunk/gcc/cfgrtl.c:209 #4 0x010d4f6a in delete_unmarked_insns () at /mnt/svn/gcc-trunk/gcc/dce.c:591 #5 0x010d7a99 in fast_dce (word_level=false) at /mnt/svn/gcc-trunk/gcc/dce.c:1038 #6 0x010d7d05 in rest_of_handle_fast_dce () at /mnt/svn/gcc-trunk/gcc/dce.c:1052 #7 0x010d84e9 in run_fast_df_dce () at /mnt/svn/gcc-trunk/gcc/dce.c:1100 #8 0x006d59f9 in df_lr_finalize (all_blocks=0x19f2208) at /mnt/svn/gcc-trunk/gcc/df-problems.c:1019 #9 0x006cf64a in df_analyze_problem (dflow=0x1942490, blocks_to_consider=0x19f2208, postorder=0x1a09db0, n_blocks=8) at /mnt/svn/gcc-trunk/gcc/df-core.c:1161 #10 0x006d02fa in df_analyze () at /mnt/svn/gcc-trunk/gcc/df-core.c:1252 #11 0x01127113 in if_convert () at /mnt/svn/gcc-trunk/gcc/ifcvt.c:4372 #12 0x01128b49 in rest_of_handle_if_after_combine () at /mnt/svn/gcc-trunk/gcc/ifcvt.c:4497 #13 0x008fad85 in execute_one_pass (pass=0x17ca060) at /mnt/svn/gcc-trunk/gcc/passes.c:2081 #14 0x008fb145 in execute_pass_list (pass=0x17ca060) at /mnt/svn/gcc-trunk/gcc/passes.c:2136 #15 0x008fb157 in execute_pass_list (pass=0x17c4f40) at /mnt/svn/gcc-trunk/gcc/passes.c:2137 #16 0x00a5d25e in tree_rest_of_compilation (fndecl=0x75ba6d00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:420 #17 0x006afc3a in cgraph_expand_function (node=0x75a976c0) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1818 #18 0x006b1b0c in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1885 #19 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2199 #20 0x006b216a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327 #21 0x0058f0c0 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:10030 #22 0x009efd1c in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:573 #23 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938 #24 toplev_main (argc=19, argv=0x7fffd7d8) at
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #37 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-19 11:03:58 UTC --- Regstrapped with the patch in comment #35. The patch fixes this PR without regression (down to 2 failures with some pending patches) and the tests for pr10901 pass with the different options I have tried. Thanks.
[Bug libmudflap/30994] App using Qt lib aborts immediately during startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30994 Axel Mueller aegges at web dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Axel Mueller aegges at web dot de 2012-01-19 11:12:21 UTC --- (In reply to comment #1) From the sound of it, libmudflap is not being initialized before QT is. QT is calling malloc in its initialization and malloc returns NULL. You are my hero I did not expect to get an answer after 5 years. And I did not expect to get a helpful answer. I changed to link order from LIBS = -lQtCore -lmudflapth to LIBS = -lmudflapth -lQtCore Thus mudflap is the last in the line and will get linked/loaded first. Now everything works as expected. Therefore, I will close this bug. Thank you very much. Just for the record. To use Mudflap with Qt you have to add the following lines to your .pro file (Qt project file): QMAKE_CXXFLAGS += -fmudflapth QMAKE_CFLAGS += -fmudflapth # do not use QMAKE_LIBS for mudflap; private libs will be loaded before Qt LIBS_PRIVATE += -lmudflapth
[Bug target/51900] [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-19 Component|c |target Target Milestone|--- |4.6.3 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 11:19:59 UTC --- This is a valid optimization if you build with -fno-common. Please make sure that -fcommon is in effect.
[Bug libgcj/51901] [4.7 regression] java.security.Security.getProperty throws ExceptionInInitializerError
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51901 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.7.0
[Bug libgcj/51901] [4.7 regression] java.security.Security.getProperty throws ExceptionInInitializerError
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51901 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 11:28:37 UTC --- Why the 4.7 regression tag? Does it work in 4.6? I think the amount of libgcj changes since 4.6 has been very small...
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 11:27:07 UTC --- With the ffi.c fix this should be P2-ish.
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #38 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 11:30:37 UTC --- If the insn pattern is #, then if no split pass splits it before final, during final it will be split anyway. So no idea why you play games with !optimize vs. optimize.
[Bug target/51900] [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-01-19 11:34:52 UTC --- I can reproduce with x86_64-w64-mingw32-gcc-4.6.2 on cygwin. Adding 'extern' to the declaration in the .h file fixes it.
[Bug target/51900] [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900 --- Comment #3 from Daniel Starke daniel.f.starke at freenet dot de 2012-01-19 11:52:27 UTC --- [...] COLLECT_GCC_OPTIONS='-static' '-O2' '-v' '-Q' '-o' 'a.o' '-c' '-mtune=i386' '-march=i386' [...] GNU C (GCC) version 4.6.2 (mingw32) compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 2.4.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 options passed: -v -iprefix d:\programme\msys\mingw462\bin\../lib/gcc/mingw32/4.6.2/ a.c -mtune=i386 -march=i386 -auxbase-strip a.o -O2 options enabled: -falign-labels -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcaller-saves -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks -fdevirtualize -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types -fexpensive-optimizations -fforward-propagate -ffunction-cse -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion -fif-conversion2 -findirect-inlining -finline -finline-functions-called-once -finline-small-functions -fipa-cp -fipa-profile -fipa-pure-const -fipa-reference -fipa-sra -fira-share-save-slots -fira-share-spill-slots -fivopts -fkeep-inline-dllexport -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls -fpartial-inlining -fpeephole -fpeephole2 -fprefetch-loop-arrays -freg-struct-return -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-critical-path-heuristic -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fset-stack-executable -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing -fstrict-overflow -fstrict-volatile-bitfields -fthread-jumps -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables -fvar-tracking -fvar-tracking-assignments -fvect-cost-model -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double -maccumulate-outgoing-args -malign-double -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mno-red-zone -mno-sse4 -mpush-args -msahf -mstack-arg-probe [...]
[Bug target/51900] [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 11:57:18 UTC --- (In reply to comment #3) [...] COLLECT_GCC_OPTIONS='-static' '-O2' '-v' '-Q' '-o' 'a.o' '-c' '-mtune=i386' '-march=i386' [...] GNU C (GCC) version 4.6.2 (mingw32) compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 2.4.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 options passed: -v -iprefix d:\programme\msys\mingw462\bin\../lib/gcc/mingw32/4.6.2/ a.c -mtune=i386 -march=i386 -auxbase-strip a.o -O2 options enabled: -falign-labels -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcaller-saves -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks -fdevirtualize -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types -fexpensive-optimizations -fforward-propagate -ffunction-cse -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion -fif-conversion2 -findirect-inlining -finline -finline-functions-called-once -finline-small-functions -fipa-cp -fipa-profile -fipa-pure-const -fipa-reference -fipa-sra -fira-share-save-slots -fira-share-spill-slots -fivopts -fkeep-inline-dllexport -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls -fpartial-inlining -fpeephole -fpeephole2 -fprefetch-loop-arrays -freg-struct-return -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-critical-path-heuristic -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fset-stack-executable -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing -fstrict-overflow -fstrict-volatile-bitfields -fthread-jumps -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables -fvar-tracking -fvar-tracking-assignments -fvect-cost-model -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double -maccumulate-outgoing-args -malign-double -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mno-red-zone -mno-sse4 -mpush-args -msahf -mstack-arg-probe [...] I don't think that proves anything. Please reproduce with explicit -fcommon added. That said, works for me on x86_64-linux.
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #39 from Iain Sandoe iains at gcc dot gnu.org 2012-01-19 12:01:32 UTC --- (In reply to comment #38) If the insn pattern is #, then if no split pass splits it before final, during final it will be split anyway. So no idea why you play games with !optimize vs. optimize. hm. well, without that I was hitting the 'unreachable' here ... final.c:2715 if (new_rtx == insn PATTERN (new_rtx) == body) fatal_insn (could not split insn, insn); #ifdef HAVE_ATTR_length /* This instruction should have been split in shorten_branches, to ensure that we would have valid length info for the splitees. */ gcc_unreachable (); #endif
[Bug driver/47249] [4.4/4.5/4.6/4.7 Regression] ICE in common_handle_option, at opts.c:1695 with unknown option passed to cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47249 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:17:17 UTC --- I suppose we should avoid the ICE for releases by simply turning the gcc_assert into a gcc_checking_assert ...
[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|REOPENED|WAITING --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:21:32 UTC --- i386-pc-solaris2.10 is neither primary nor secondary target. And we are still waiting for answers.
[Bug rtl-optimization/49936] IRA handles CANNOT_CHANGE_MODE_CLASS poorly, + spills to memory on 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Target Milestone|4.7.0 |--- --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:22:25 UTC --- Whatever. Would have been nice to have a separate bugreport for this.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 12:33:55 UTC --- Created attachment 26377 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26377 gcc47-pr51895.patch Untested patch that attempts to fix BLKmode MEM_REF expansion with non-DECL_ADDRESSABLE non-BLKmode base. It creates abysmal code, so IMNSHO eipa_sra should be fixed not to do this.
[Bug libgcj/51901] [4.7 regression] java.security.Security.getProperty throws ExceptionInInitializerError
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51901 --- Comment #2 from gee jojelino at gmail dot com 2012-01-19 12:36:35 UTC --- (In reply to comment #1) Why the 4.7 regression tag? Does it work in 4.6? I think the amount of libgcj changes since 4.6 has been very small... sorry for 4.7 regression tag. it worked before i apply the patch in pr50057. this bug opened after i applied the patch. please review pr50057.
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Severity|major |normal --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:42:40 UTC --- i686-apple-darwin10 isn't a cross-only target but also a host platform.
[Bug rtl-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:46:42 UTC --- Vlad, I suppose you didn't have a chance to have a look here? Igor, after the recent RA changes, is this still an issue? This is most certainly not a P1, leaving at P3 until we get a more detailed analysis.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P3 |P4
[Bug debug/51570] [4.7 Regression] FAIL: gcc.dg/guality/pr45003-[23].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51570 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:49:40 UTC --- Any updates here? Should we simply XFAIL the tests?
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51819 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target|arm |arm-*-* Priority|P3 |P1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:51:33 UTC --- Ping?
[Bug rtl-optimization/51856] [4.7 Regression] ICE in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51856 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:54:30 UTC --- Confirmed with a cross from x86_64-linux.
[Bug middle-end/51871] [4.7 Regression] FAIL: gcc.c-torture/execute/20010122-1.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51871 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:55:26 UTC --- So, you are not sure this is a regression?
[Bug target/51876] [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 12:56:38 UTC --- I'd take that as an approval.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #32 from Rainer Orth ro at gcc dot gnu.org 2012-01-19 12:56:56 UTC --- The bootstrap without the old workaround patch has just finished successfully.
[Bug debug/51570] [4.7 Regression] FAIL: gcc.dg/guality/pr45003-[23].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51570 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 12:56:53 UTC --- Then it would XPASS with latest gdb. With the gdb 7.4.50.20120103-8.fc17 I'm only seeing lots of guality XPASSes on x86_64 and no FAILs and on i686 again lots of XPASSes and just a single FAIL: gcc.dg/guality/vla-1.c -Os line 17 sizeof (a) == 6 fail. We definitely need to do something about this, but perhaps it can wait for 4.8. Alex, do you think you could look at this? Thanks.
[Bug c++/51889] [4.7 regression] can't override a using-declaration in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51889 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1
[Bug rtl-optimization/51856] [4.7 Regression] ICE in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51856 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 12:59:44 UTC --- Why P4? This is a secondary target, failure to build mysql.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 13:03:14 UTC --- (In reply to comment #5) Created attachment 26377 [details] gcc47-pr51895.patch Untested patch that attempts to fix BLKmode MEM_REF expansion with non-DECL_ADDRESSABLE non-BLKmode base. It creates abysmal code, so IMNSHO eipa_sra should be fixed not to do this. Hm, can't we do better using extract_bit_field? I mean, it definitely should work to do any BIT_FIELD_REF on an rvalue, even if it is a register. The patch from comment #1 doesn't look completely wrong, it just seems that the caller should have catered for using the mode of the reg. The docs of operand_subword also say 'MODE is the mode of OP in case it is a CONST_INT' so MODE should be irrelevant if REG_P (op) ... Seems to be a tricky area, but using a stack temporary looks like overkill.
[Bug libfortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51899 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libfortran --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 13:04:08 UTC --- Which target exactly?
[Bug target/51876] [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 13:05:13 UTC --- I did, but I'm waiting for testing results from Ramana.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 13:11:13 UTC --- (In reply to comment #6) Untested patch that attempts to fix BLKmode MEM_REF expansion with non-DECL_ADDRESSABLE non-BLKmode base. It creates abysmal code, so IMNSHO eipa_sra should be fixed not to do this. Hm, can't we do better using extract_bit_field? I mean, it definitely should work to do any BIT_FIELD_REF on an rvalue, even if it is a register. The patch from comment #1 doesn't look completely wrong, it just seems that the caller should have catered for using the mode of the reg. The docs of operand_subword also say 'MODE is the mode of OP in case it is a CONST_INT' so MODE should be irrelevant if REG_P (op) ... Seems to be a tricky area, but using a stack temporary looks like overkill. We don't have BLKmode pseudos, the only thing that can be BLKmode is MEM. So I'm afraid we can't avoid that. E.g. VIEW_CONVERT_EXPR of a TImode value to BLKmode value would be expanded by spilling the TImode value to a stack temporary and adjust_address it to BLKmode too.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19
13:17:25 UTC ---
For example (untested, and probably completely bogus):
Index: expr.c
===
--- expr.c (revision 183296)
+++ expr.c (working copy)
@@ -1517,7 +1517,9 @@ move_block_to_reg (int regno, rtx x, int
for (i = 0; i nregs; i++)
emit_move_insn (gen_rtx_REG (word_mode, regno + i),
- operand_subword_force (x, i, mode));
+ operand_subword_force (x, i,
+ CONSTANT_P (x)
+ ? mode : GET_MODE (x)));
}
/* Copy all or part of a BLKmode value X out of registers starting at REGNO.
As written elsewhere operand_subword* should be deprecated ... so maybe
we can use sth else in move_block_to_reg?
The same effect could be achieved by changing operand_subword to adhere
to its documentation and ignore mode if op is !CONST_INT_P ... thus
Index: emit-rtl.c
===
--- emit-rtl.c (revision 183296)
+++ emit-rtl.c (working copy)
@@ -1367,7 +1367,7 @@ paradoxical_subreg_p (const_rtx x)
rtx
operand_subword (rtx op, unsigned int offset, int validate_address, enum
machine_mode mode)
{
- if (mode == VOIDmode)
+ if (!CONST_INT_P (op))
mode = GET_MODE (op);
gcc_assert (mode != VOIDmode);
Both fix the testcase.
[Bug middle-end/50200] ICE: SIGSEGV in df_insn_refs_collect (df-scan.c:3405)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50200 --- Comment #3 from Zdenek Sojka zsojka at seznam dot cz 2012-01-19 13:26:32 UTC --- Testcase from comment #2 still ICEs in r183298, the fix for PR51505 didn't help here.
[Bug libfortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51899 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-19 13:32:06 UTC --- Created attachment 26378 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26378 Draft patch, tested on x86-64-linux but not (yet) on MinGW (In reply to comment #1) Which target exactly? I don't know (it was reported to me by email). I think mingw-w64. However, I expect it to fail with both the 32bit and 64bit version of MinGW and it should work with Cygwin.
[Bug target/19520] protected function pointer doesn't work right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
CC||hubicka at gcc dot gnu.org,
||rth at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19
13:36:28 UTC ---
Final conclusion: We need to resolve to the executables PLT consistently,
even from inside the shared object where the function binds locally. This
is because of references to the function from the executables .rodata section
which we can't relocate (and thus have to point to the executables PLT entry).
Thus, this is a GCC target bug.
__attribute__((visibility(protected))) void * foo () { return foo; }
needs to return the address of foo via a load from the GOT. HJs patch
isn't correct as this is really a target ABI choice (another ABI may
choose to resolve all references to the functions start address with
the cost of having to put the constants into a .rel.rodata section).
[Bug target/51659] [4.7 regression] ICE in function output_move_double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/51344] [4.4/4.5/4.6/4.7 regression] cc1plus hangs when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51344 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P2 Target Milestone|--- |4.4.7
[Bug c/51894] Fail to warn on likely precedence error in conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51894 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-01-19 13:48:48 UTC --- This is a more general issue with not warning for parenthesized expressions. *** This bug has been marked as a duplicate of bug 25733 ***
[Bug c/25733] missed diagnostic about assignment used as truth value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||aravindvijayan224185 at ||gmail dot com --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-01-19 13:48:48 UTC --- *** Bug 51894 has been marked as a duplicate of this bug. ***
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 13:55:31 UTC --- Peter's patch does as well. The thing is that we still do wrong expand_expr on that kind of MEM_EXPR, and I don't see anything that would prevent such MEM_EXPRs in all kinds of other contexts, not just in the loading of the parameters. And each of the would need hacks to cope with a BLKmode expression surprisingly being expanded to something that doesn't have BLKmode.
[Bug lto/51280] ICE when lto1 does not have -fgnu-tm and object file uses TM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-19 13:57:12 UTC --- Author: aldyh Date: Thu Jan 19 13:57:04 2012 New Revision: 183303 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183303 Log: PR lto/51280 * lto-wrapper.c (run_gcc): Pass -fgnu_tm on. (merge_and_complain): Same. Added: trunk/gcc/testsuite/gcc.dg/lto/trans-mem-3_0.c trunk/gcc/testsuite/gcc.dg/lto/trans-mem-3_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c
[Bug lto/51280] ICE when lto1 does not have -fgnu-tm and object file uses TM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-19 13:58:41 UTC --- fixed
[Bug lto/51698] [trans-mem] TM runtime and application with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51698 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-19 14:23:15 UTC --- mine
[Bug lto/51698] [trans-mem] TM runtime and application with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51698 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Ever Confirmed|0 |1
[Bug middle-end/51871] [4.7 Regression] FAIL: gcc.c-torture/execute/20010122-1.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51871 --- Comment #4 from dave.anglin at bell dot net 2012-01-19 14:34:56 UTC --- On 1/19/2012 7:55 AM, rguenth at gcc dot gnu.org wrote: So, you are not sure this is a regression? Yes.
[Bug rtl-optimization/51856] [4.7 Regression] ICE in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51856 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-01-19 14:38:46 UTC --- Created attachment 26379 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26379 Fix I've introduced that bug with: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01527.html So it's fair to hit s390 first :( In find_reloads_subreg_address the -1 value is not properly propagated from find_reloads_address invocation so find_reloads wrongly assumes that the address has been fully reloaded into a register.
[Bug debug/51902] New: lexical_blocks inside inlined_subroutines generate duplicate debug_ranges
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902
Bug #: 51902
Summary: lexical_blocks inside inlined_subroutines generate
duplicate debug_ranges
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
CC: ja...@gcc.gnu.org, ja...@gcc.gnu.org
Created attachment 26380
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26380
debug_ranges.c - Get some statistics on .debug_ranges section.
I noticed that when you generate dwarf for an inlined function it often
comes with duplicate range lists for both the DW_TAG_inlined_subroutine
and the child DW_TAG_lexical_block DIE. For example:
static int k;
static int foo (int i)
{
int j = i + 42;
return k + (j 14 ? j : i);
}
int main (int argc, char **argv)
{
int c = argc;
k = 2 * c;
c = foo (c);
return c;
}
Generates with -O2 -gdwarf-4:
DWARF section [27] '.debug_info' at offset 0x895:
[Offset]
Compilation unit at offset 0:
Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
[...]
[a8] inlined_subroutine
abstract_origin (ref4) [31]
entry_pc (addr) 0x00400360 main
ranges (data4) range list [ 0]
call_file(data1) 1
call_line(data1) 13
[bb]formal_parameter
abstract_origin (ref4) [42]
location (block1)
[ 0] reg5
[c2]lexical_block
ranges (data4) range list [40]
[c7] variable
abstract_origin (ref4) [4b]
location (data4) location list [23]
[...]
DWARF section [32] '.debug_ranges' at offset 0xb4e:
[ 0] 0x00400360 main..0x00400363 main+0x3
0x00400366 main+0x6..0x00400369 main+0x9
0x0040036f main+0xf..0x00400374 main+0x14
[40] 0x00400360 main..0x00400363 main+0x3
0x00400366 main+0x6..0x00400369 main+0x9
0x0040036f main+0xf..0x00400374 main+0x14
[80] 0x00400360 main..0x00400375
So range list 0 for the inlined_subroutine DIE a8 is the same as range
list 40 for the lexical_block DIE c2.
I wrote a quick and dirty elfutils libdw/libdwfl based program to look for this
pattern and it seems to occur reasonably often:
$ ./debug_ranges /usr/lib/debug/bin/bash.debug
cus: 160
subprograms: 6397
inlined_subroutines: 838
lexical_blocks: 359
dup_ranges: 220
dup_addrs: 1454
$ ./debug_ranges ~/build/gcc-obj/gcc/cc1
cus: 390
subprograms: 84288
inlined_subroutines: 7860
lexical_blocks: 6256
dup_ranges: 5274
dup_addrs: 29190
$ ./debug_ranges /usr/lib/debug/lib/modules/3.1.9-1.fc16.x86_64/vmlinux
cus: 1616
subprograms: 108066
inlined_subroutines: 42784
lexical_blocks: 15276
dup_ranges: 7763
dup_addrs: 38586
Given that there will be relocations for .debug_ranges addresses pointing into
.text it could even save twice that number of addresses for ET_REL files.
See also this thread for a first try of a fix (needs some help):
http://gcc.gnu.org/ml/gcc/2012-01/msg00158.html
[Bug target/51900] [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900 --- Comment #5 from Daniel Starke daniel.f.starke at freenet dot de 2012-01-19 14:51:33 UTC --- Compiling it with gcc -static -fcommon -o main.o -c main.c gcc -static -fcommon -o a.o -c a.c gcc -static -o main.exe main.o a.o results in $ ./main myVar[0] = 5 myVar[1] = 6 myVar[2] = 7 Compiling it with gcc -static -O2 -fcommon -o main.o -c main.c gcc -static -O2 -fcommon -o a.o -c a.c gcc -static -o main.exe main.o a.o results in $ ./main myVar[0] = 0 myVar[1] = 0 myVar[2] = 0 Thus a different option causes this change.
[Bug c++/51889] [4.7 regression] can't override a using-declaration in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51889 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2012-01-19 14:58:32 UTC --- Author: jason Date: Thu Jan 19 14:58:28 2012 New Revision: 183304 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183304 Log: PR c++/51889 * class.c (finish_struct): Call add_method here for function usings. * semantics.c (finish_member_declaration): Not here. Added: trunk/gcc/testsuite/g++.dg/inherit/using7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug target/51900] [4.6 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||ktietz at gcc dot gnu.org
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19
15:01:28 UTC ---
Ugh. I think this is a bug in the way i386_pe_binds_local_p implements
the binds_local target macro:
bool
i386_pe_binds_local_p (const_tree exp)
{
/* PE does not do dynamic binding. Indeed, the only kind of
non-local reference comes from a dllimport'd symbol. */
if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
DECL_DLLIMPORT_P (exp))
return false;
/* Or a weak one, now that they are supported. */
if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
DECL_WEAK (exp))
return false;
return true;
}
It's completely bogus to return true at the end - you have to do
return default_binds_local_p (exp);
to get even slightly correct/optimal handling. Thus, confirmed as a target
issue.
[Bug tree-optimization/51903] New: [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51903
Bug #: 51903
Summary: [4.7 Regression] ICE: in
gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196
with -fnon-call-exceptions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 26381
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26381
autoreduced testcase
Compiler output:
$ g++ -O2 -fno-guess-branch-probability -fnon-call-exceptions testcase.C
testcase.C: In function 'void foo()':
testcase.C:194:6: internal compiler error: in gimple_purge_all_dead_eh_edges,
at tree-cfg.c:7196
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
(gdb) bt
#0 fancy_abort (file=0x1457590 /mnt/svn/gcc-trunk/gcc/tree-cfg.c, line=7196,
function=0x145b1d0 gimple_purge_all_dead_eh_edges)
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898
#1 0x00ba2da5 in gimple_purge_all_dead_eh_edges (blocks=optimized
out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:7196
#2 0x00ca0dca in fini_pre (do_fre=true) at
/mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:4837
#3 execute_pre (do_fre=true) at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:4931
#4 execute_pre (do_fre=true) at /mnt/svn/gcc-trunk/gcc/tree-ssa-pre.c:4859
#5 0x00a8b505 in execute_one_pass (pass=0x1b21a20) at
/mnt/svn/gcc-trunk/gcc/passes.c:2081
#6 0x00a8b8c5 in execute_pass_list (pass=0x1b21a20) at
/mnt/svn/gcc-trunk/gcc/passes.c:2136
#7 0x00a8b8d7 in execute_pass_list (pass=0x1995d40) at
/mnt/svn/gcc-trunk/gcc/passes.c:2137
#8 0x00bed99e in tree_rest_of_compilation (fndecl=0x75c2a000) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:420
#9 0x00840bba in cgraph_expand_function (node=0x75a96b40) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1818
#10 0x00842a8c in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1885
#11 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2199
#12 0x008430ea in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#13 0x00661823 in cp_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4051
#14 0x00b8049c in compile_file () at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#15 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938
#16 toplev_main (argc=16, argv=0x7fffd818) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2014
#17 0x761cc09d in __libc_start_main () from /lib64/libc.so.6
#18 0x00585bc1 in _start ()
Nonreduced testcase:
#include vector
void foo ()
{
std::vector std::vector int (2);
}
Tested revisions:
r183298 - crash
r183120 - crash
r182547 - OK
[Bug fortran/51904] New: Internal Compiler Error on size function evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51904 Bug #: 51904 Summary: Internal Compiler Error on size function evaluation Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: david.sa...@gmail.com The following program produces an internal compiler error in 4.6.3. gcc 4.5 does not show the bug: subroutine qp_draw_polyline_basic (x) implicit none real :: x(:), f f = 0 print *, size(f*x) end subroutine Result: mc66:~/Bmad/bmad_dist/bug uname -a Darwin mc66.lns.cornell.edu 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 mc66:~/Bmad/bmad_dist/bug gfortran --version GNU Fortran (GCC) 4.6.2 mc66:~/Bmad/bmad_dist/bug gfortran -c bug.f90 f951: internal compiler error: Segmentation fault Of course the workaround is easy: Just replace size(f*x) with size(x).
[Bug c++/51889] [4.7 regression] can't override a using-declaration in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51889 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P3 Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2012-01-19 15:03:58 UTC --- Fixed.
[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 Regression] const |[4.6/4.7 Regression] const |variable initialization |variable initialization |always zero |always zero --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 15:06:08 UTC --- Btw, surely latent since forever, thus since the introduction of the override.
[Bug tree-optimization/46590] [4.5/4.6/4.7 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #18 from Michael Matz matz at gcc dot gnu.org 2012-01-19 15:06:14 UTC --- Author: matz Date: Thu Jan 19 15:06:04 2012 New Revision: 183305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183305 Log: PR tree-optimization/46590 * cfgexpand.c (add_scope_conflicts_1): New old_conflicts argument, use it in remembering which conflicts we already created. (add_scope_conflicts): Adjust call to above, (de)allocate helper bitmap. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c
[Bug tree-optimization/46590] [4.5/4.6/4.7 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #19 from Michael Matz matz at gcc dot gnu.org 2012-01-19 15:10:43 UTC --- The var-expansion slowness is fixed again. The rest of course still applies.
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2012-01-19 15:16:04 UTC --- I still can't reproduce this, either on my Fedora 14 i686 laptop or on gcc20.
[Bug tree-optimization/51903] [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51903 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-19 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 15:20:04 UTC --- Confirmed.
[Bug tree-optimization/51903] [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51903 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-19 15:25:36 UTC --- I have a patch.
[Bug tree-optimization/51903] [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51903 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 15:32:28 UTC --- Created attachment 26382 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26382 pr51903.C Slightly more reduced testcase.
[Bug tree-optimization/51903] [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51903 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de 2012-01-19 15:40:08 UTC --- On Thu, 19 Jan 2012, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51903 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 15:32:28 UTC --- Created attachment 26382 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26382 pr51903.C Slightly more reduced testcase. I'm using the testcase with the #include. Richard.
[Bug target/51876] [4.7 regression] Recent extra neon related testsuite regressions on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51876 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-19 15:40:58 UTC --- (In reply to comment #5) I did, but I'm waiting for testing results from Ramana. Testresults look good. Yeah , ok. Ramana
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Attachment #26374|0 |1 is obsolete|| --- Comment #9 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-01-19 15:56:27 UTC --- Created attachment 26383 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26383 patch try 3
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 --- Comment #15 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-01-19 15:56:50 UTC --- (In reply to comment #14) I still can't reproduce this, either on my Fedora 14 i686 laptop or on gcc20. What binutils version are you running on both machines? (is PREVAILING_DEF_IRONLY_EXP already supported?) Is gcc20 a 64bit machine running a 64bit gcc?
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:08:44 UTC --- --- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:50:13 UTC --- Rainer/Andrew, please test this in your configurations. I've just successfully completed i386-pc-solaris2.1[01] gas/gld bootstraps without the previous --disable-initfini-array workaround. Thanks for fixing this. I'll check if support can unconditionally be enabled on Solaris if the tools support it. So far, ld -e 0 doesn't work: ld: fatal: entry point symbol '0' is undefined while omitting -e 0 gets a warning from gld: gld-2.22: warning: cannot find entry symbol _start; defaulting to 08048054 The latter is probably harmless, though, and we can just omit the -e 0 everwhere. While gld does merge the .init_array.N/.fini_array.N sections, Sun ld does not, so the test always fails if ld is in use. (Recent?) Sun as on Solaris 10 and 11/x86 work, too. On Solaris 11/SPARC, the test fails even with gas and gld 2.22: objdump -s -j .init_array conftest conftest: file format elf32-sparc-sol2 Contents of section .init_array: 20054 48484848 Still need to check why. Rainer
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-19 16:13:55 UTC --- I wonder why it does this, instead of just using type S, and if it really has to for some reason, why it can't at least make sure it has the same TYPE_MODE. Changing a TImode argument to a BLKmode argument doesn't look at least like a good optimization. I concur, BLKmode means spilling to memory at some point, so this looks like a clear pessimization to me.
