[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek 2013-01-23
08:06:57 UTC ---
struct T { int a; char b[]; };
struct T t = { .a = 1, .b = "abc", .b[0] = '2' };
is enough, fails even with 3.2, so doesn't look like a regression.
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 CC||janus at gcc dot gnu.org Known to work||4.6.4 Summary|Seg fault ICE on select |[4.7/4.8 Regression] Seg |with bad case |fault ICE on select with ||bad case Ever Confirmed|0 |1 --- Comment #3 from janus at gcc dot gnu.org 2013-01-23 08:30:34 UTC --- Further reduction: implicit none integer :: a(4) select case(a) case (0) end select end gfortran 4.6.4 gives the correct error message: select case(a) 1 Error: Argument of SELECT statement at (1) must be a scalar expression For some reason this is not being triggered any more with 4.7 and trunk.
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 --- Comment #12 from Jakub Jelinek 2013-01-23 08:37:39 UTC --- Author: jakub Date: Wed Jan 23 08:37:16 2013 New Revision: 195398 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195398 Log: PR target/49069 * config/arm/arm.md (cbranchdi4, cstoredi4): Use s_register_operand instead of cmpdi_operand for first comparison operand. Don't assert that comparison operands aren't both constants. * gcc.dg/pr49069.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49069.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/56052] [4.7/4.8 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 --- Comment #8 from Jakub Jelinek 2013-01-23 08:44:00 UTC --- Author: jakub Date: Wed Jan 23 08:43:50 2013 New Revision: 195399 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195399 Log: PR fortran/56052 * trans-decl.c (gfc_get_symbol_decl): Set DECL_ARTIFICIAL and DECL_IGNORED_P on select_type_temporary and don't set DECL_BY_REFERENCE. * gfortran.dg/gomp/pr56052.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr56052.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #21 from Iain Sandoe 2013-01-23 08:44:45
UTC ---
(In reply to comment #20)
> crttme.o comes from libgcc/config/darwin-crt-tm.c, which has:
>
> /* Provide dummy functions to satisfy linkage for versions of the Darwin
>tool-chain that that can't handle undefined weak refs at the link stage.
>??? Define these dummy functions only when !HAVE_ELF_STYLE_WEAKREF. */
>
> extern void *__cxa_allocate_exception (size_t) WEAK;
> ...
> ...
> void *__cxa_allocate_exception (size_t s UNUSED) { return NULL; }
>
> This looks like the NULL returning __cxa_allocate_exception that is causing
> all
> this grief, and came from Patrick Marlier and Iain Sandoe's patch here:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html
>
> Again, I'm a Darwin wimp. Anyone care to comment?
looks like (yet another) permutation of what works/doesn't with "ELF-style weak
linking" I don't have darwin11 or 12 (yet) - but should do soon.
[Bug target/49069] [4.6/4.7 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 Jakub Jelinek changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE in |ICE in gen_cstoredi4, at|gen_cstoredi4, at |config/arm/arm.md:7554 |config/arm/arm.md:7554 --- Comment #13 from Jakub Jelinek 2013-01-23 08:45:45 UTC --- Fixed on the trunk so far.
[Bug fortran/56052] [4.7 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Jakub Jelinek changed: What|Removed |Added Summary|[4.7/4.8 Regression] [OOP] |[4.7 Regression] [OOP] ICE |ICE in omp_add_variable, at |in omp_add_variable, at |gimplify.c:5606 |gimplify.c:5606 --- Comment #9 from Jakub Jelinek 2013-01-23 08:46:43 UTC --- Fixed on the trunk so far.
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #4 from janus at gcc dot gnu.org 2013-01-23 09:09:56 UTC ---
On the 4.6 branch, one finds the following check in resolve.c (resolve_select,
line 7426):
if (case_expr->rank != 0)
{
gfc_error ("Argument of SELECT statement at %L must be a scalar "
"expression", &case_expr->where);
/* Punt. */
return;
}
On the 4.7 branch it is simply gone. I don't directly see where it went.
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 --- Comment #5 from janus at gcc dot gnu.org 2013-01-23 09:13:19 UTC --- In ChangeLog-2011 I see the following commit: 2011-12-11 Paul Thomas Tobias Burnus PR fortran/41539 PR fortran/43214 PR fortran/43969 PR fortran/44568 PR fortran/46356 PR fortran/46990 PR fortran/49074 [...] (resolve_select): Remove scalar error for SELECT statement as a temporary measure. [...]
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #6 from janus at gcc dot gnu.org 2013-01-23 09:21:02 UTC ---
The obvious fix is certainly to re-insert that piece of code:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 195310)
+++ gcc/fortran/resolve.c(working copy)
@@ -7976,6 +7976,15 @@ resolve_select (gfc_code *code)
return;
}
+ if (case_expr->rank != 0)
+{
+ gfc_error ("Argument of SELECT statement at %L must be a scalar "
+ "expression", &case_expr->where);
+
+ /* Punt. */
+ return;
+}
+
/* Raise a warning if an INTEGER case value exceeds the range of
the case-expr. Later, all expressions will be promoted to the
largest kind of all case-labels. */
Will check for regressions now.
[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 CC||jakub at gcc dot gnu.org Target Milestone|4.8.0 |4.7.3 Summary|[4.8 Regression] ICE with |[4.7/4.8 Regression] ICE |C_PTR renaming and TRANSFER |with C_PTR renaming and ||TRANSFER Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2013-01-23 09:31:32 UTC --- The #c1 testcase started to be rejected with: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177486 and then changed from an (invalid?) error into an ICE with: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177527
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek 2013-01-23 09:43:31 UTC --- Would it help if libitm has been linked against libstdc++ on the targets which can't support weak properly?
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 --- Comment #7 from janus at gcc dot gnu.org 2013-01-23 09:52:30 UTC --- (In reply to comment #6) > Will check for regressions now. Unfortunately it seems to trigger a large number of regressions in the testsuite, e.g. on: FAIL: gfortran.dg/class_allocate_10.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_allocate_8.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_array_1.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_array_2.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_array_7.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_to_type_1.f03 -O0 (test for excess errors)
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #23 from Dominique d'Humieres 2013-01-23 09:56:13 UTC --- (In reply to comment #21) > ... I don't have darwin11 or 12 (yet) - but should do soon. The test also fails on darwin10 unless the patch in comment #7 is applied.
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 --- Comment #8 from janus at gcc dot gnu.org 2013-01-23 10:00:31 UTC --- (In reply to comment #7) > FAIL: gfortran.dg/class_allocate_10.f03 -O0 (test for excess errors) > FAIL: gfortran.dg/class_allocate_8.f03 -O0 (test for excess errors) > FAIL: gfortran.dg/class_array_1.f03 -O0 (test for excess errors) > FAIL: gfortran.dg/class_array_2.f03 -O0 (test for excess errors) > FAIL: gfortran.dg/class_array_7.f03 -O0 (test for excess errors) > FAIL: gfortran.dg/class_to_type_1.f03 -O0 (test for excess errors) In fact all of these seem to be due to SELECT TYPE statements with class arrays (which are being transformed into an ordinary SELECT at resolution time), so one should probably add an extra check, whether it actually comes from a SELECT TYPE statement.
[Bug regression/53964] regression: sparc64 FreeBSD: /usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types n declaration specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964 --- Comment #7 from Anton Shterenlikht 2013-01-23 10:14:52 UTC --- a great miracle happened here: # pkg info -xo gcc-4.6 gcc-4.6.4.20121123: lang/gcc46 # I didn't have to do anything extra to get it build. However, I'm getting this error using the new 4.6 compiler to build lapack: gfortran46 -O -Wl,-rpath=/usr/local/lib/gcc46 -fPIC -c LAPACK_version.f -o LAPACK_version.o gfortran46 -Wl,-rpath=/usr/local/lib/gcc46 -fPIC -o testlsame lsame.o lsametst.o /usr/local/lib/gcc46/gcc/sparc64-portbld-freebsd10.0/4.6.4/../../../libgfortran.so: undefined reference to `__emutls_v._ThreadRuneLocale' collect2: ld returned 1 exit status *** [testlsame] Error code 1
[Bug tree-optimization/56075] [gcc-4.7.1] 64-bit version, -Os eliminate some line of code which working fine in gcc-4.6.2 64-bit version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075 --- Comment #1 from rajendiran 2013-01-23 10:31:45 UTC --- Created attachment 29254 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29254 C Source code without preprocced
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Andrey Belevantsev changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #21 from Andrey Belevantsev 2013-01-23
11:11:22 UTC ---
Thanks again folks, it's much simpler with gdb. So the reason of the
difference that shows up in the ICE is the ira_implicitly_set_insn_hard_regs
function. Recall that we have insns 23 and 24 like this:
23: r148:SI=[unspec[`*LC..2',%2:SI] 44]
24: %3:SI=[unspec[`*LCM..2',%2:SI] 44]
and insn 17 like this:
17: {%3:SI=unspec[%3:SI,%4:SI] 25;clobber %0:SI;clobber %4:SI;clobber
%5:SI;clobber %11:SI;clobber %0:CC;clobber lr:SI;}
The dependency between insns 23 and 17 is because insn 17 clobbers reg 65 (I
guess it is lr in the dump). When analyzing insn 23,
ira_implicitly_set_insn_hard_regs is called and it notices we have a pseudo-reg
148. The function attempts to restrict the insn movement by marking the
registers that might be required by the "strict" alternatives of the insn as
implicit clobbers. For insn 23 it marks reg 65 from LINK_REGS ('l' constraint)
and reg 66 from CTR_REGS ('c' constraint AFAIR). Now we have an
anti-dependency via clobbering reg 65 with insn 17.
Insn 24 already has the hard register assigned (%3), so the above logic does
not apply and we don't get the implicit clobbers on this insn and thus a
dependency with insn 17.
In short, the implicit clobbers thing disagrees with the assumption sel-sched
mades: that renaming a hard register to a pseudo is always possible given that
the resulting insn is recognized and will never create extra dependencies.
So the choices we have are as follows:
1) make the if (! reload_completed) at sched-deps.c:2805 also conditional on
-fsched-pressure and make sel-sched incompatible with -fsched-pressure by
disallowing to specify both options at the same time. That is,
-fselective-scheduling will disable -fsched-pressure with a note to the user.
2) make the selective scheduler account for the situation when renaming a hard
register to a pseudo register before reload with sched-pressure enabled might
create extra dependencies, then insn 24 will never be considered for renaming
and the problem will be fixed.
I can do either 1 or 2, no problem with any of those given enough time until
4.8.
Thoughts?
[Bug tree-optimization/56075] [gcc-4.7.1] 64-bit version, -Os eliminate some line of code which working fine in gcc-4.6.2 64-bit version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-01-23 11:26:50 UTC --- Non-preprocessed testcase is useless (the original isn't preprocessed either). But furthermore, why do you expect that foo won't be optimized just into an empty function? If fun is inlined, it doesn't have any side-effects.
[Bug sanitizer/55989] [4.8 regresion] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2013-01-23 11:52:40 UTC --- Author: kcc Date: Wed Jan 23 11:41:33 2013 New Revision: 195404 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195404 Log: libsanitizer merge from upstream r173241 Added: trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors_scanf.inc trunk/libsanitizer/sanitizer_common/sanitizer_lfstack.h trunk/libsanitizer/sanitizer_common/sanitizer_quarantine.h Removed: trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/libsanitizer/ChangeLog trunk/libsanitizer/MERGE trunk/libsanitizer/asan/asan_allocator.cc trunk/libsanitizer/asan/asan_allocator.h trunk/libsanitizer/asan/asan_allocator2.cc trunk/libsanitizer/asan/asan_globals.cc trunk/libsanitizer/asan/asan_intercepted_functions.h trunk/libsanitizer/asan/asan_interceptors.cc trunk/libsanitizer/asan/asan_internal.h trunk/libsanitizer/asan/asan_linux.cc trunk/libsanitizer/asan/asan_lock.h trunk/libsanitizer/asan/asan_mac.cc trunk/libsanitizer/asan/asan_malloc_mac.cc trunk/libsanitizer/asan/asan_mapping.h trunk/libsanitizer/asan/asan_new_delete.cc trunk/libsanitizer/asan/asan_poisoning.cc trunk/libsanitizer/asan/asan_rtl.cc trunk/libsanitizer/asan/asan_stats.cc trunk/libsanitizer/asan/asan_thread.cc trunk/libsanitizer/asan/asan_thread_registry.cc trunk/libsanitizer/asan/asan_thread_registry.h trunk/libsanitizer/asan/asan_win.cc trunk/libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc trunk/libsanitizer/include/sanitizer/asan_interface.h trunk/libsanitizer/interception/interception.h trunk/libsanitizer/merge.sh trunk/libsanitizer/sanitizer_common/sanitizer_allocator.h trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h trunk/libsanitizer/sanitizer_common/sanitizer_atomic_msvc.h trunk/libsanitizer/sanitizer_common/sanitizer_common.cc trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_list.h trunk/libsanitizer/sanitizer_common/sanitizer_mac.cc trunk/libsanitizer/sanitizer_common/sanitizer_mutex.h trunk/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h trunk/libsanitizer/sanitizer_common/sanitizer_symbolizer.cc trunk/libsanitizer/sanitizer_common/sanitizer_symbolizer.h trunk/libsanitizer/sanitizer_common/sanitizer_win.cc trunk/libsanitizer/tsan/tsan_fd.cc trunk/libsanitizer/tsan/tsan_fd.h trunk/libsanitizer/tsan/tsan_interceptors.cc trunk/libsanitizer/tsan/tsan_mman.cc trunk/libsanitizer/tsan/tsan_report.cc trunk/libsanitizer/tsan/tsan_report.h trunk/libsanitizer/tsan/tsan_rtl_mutex.cc trunk/libsanitizer/tsan/tsan_rtl_report.cc trunk/libsanitizer/tsan/tsan_stat.cc trunk/libsanitizer/tsan/tsan_stat.h trunk/libsanitizer/tsan/tsan_symbolize.cc trunk/libsanitizer/tsan/tsan_symbolize.h
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #25 from Kostya Serebryany 2013-01-23 12:21:51 UTC --- So, what is our decision? Are we just doing - static const uptr kHighMemEnd = 0x0fffUL; + static const uptr kHighMemEnd = 0x3fffUL; , leaving SHADOW_OFFSET=(1ULL << 41) and using ADD instead of OR when applying SHADOW_OFFSET? This seems to work on my ppc box (44-bit) with LLVM (I've changed it to use ADD on PPC)
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #26 from Jakub Jelinek 2013-01-23
12:26:30 UTC ---
(In reply to comment #25)
> So, what is our decision?
>
> Are we just doing
> - static const uptr kHighMemEnd = 0x0fffUL;
> + static const uptr kHighMemEnd = 0x3fffUL;
> , leaving SHADOW_OFFSET=(1ULL << 41)
> and using ADD instead of OR when applying SHADOW_OFFSET?
>
> This seems to work on my ppc box (44-bit) with LLVM
> (I've changed it to use ADD on PPC)
If that works, it is my preference. But needs testing, also with GCC, and with
both 44-bit and 46-bit AS.
BTW, I wonder why clang generates larger and slower code with ADD instead of
OR, at least gcc seems to generate generally better code with ADD, plus on
i?86/x86_64 it even has better HW support for that (for ADD can use both
add{l,q} and leal, allowing RA to generate better code). GCC for asan
generates always ADD, on all architectures, right now.
[Bug c++/55992] constexpr static member function not recognised in templated using statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55992 Paolo Carlini changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #3 from Paolo Carlini 2013-01-23 12:30:13 UTC --- Let's add Dodji in CC.
[Bug c++/56013] ICE in lambda in a for-each in templated class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56013 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 Blocks||54367 Ever Confirmed|0 |1
[Bug c++/55828] problem with access to static method from lambda in another method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55828 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 CC|vladimir.bayda at gmail dot | |com | Blocks||54367 Ever Confirmed|0 |1
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #27 from Kostya Serebryany 2013-01-23 12:51:40 UTC --- >> BTW, I wonder why clang generates larger and slower code with ADD instead of >> OR I did not investigate. I noticed that the code size with OR is smaller than with ADD. One more thing to take care of with powerpc: the new allocator needs a change like this: --- asan/asan_allocator2.cc(revision 173248) +++ asan/asan_allocator2.cc(working copy) @@ -57,7 +57,11 @@ }; #if SANITIZER_WORDSIZE == 64 +#if defined(__powerpc64__) +const uptr kAllocatorSpace = 0xa00ULL; +#else const uptr kAllocatorSpace = 0x6000ULL; +#endif const uptr kAllocatorSize = 0x100ULL; // 1T. typedef DefaultSizeClassMap SizeClassMap; typedef SizeClassAllocator64
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #28 from Jakub Jelinek 2013-01-23 13:05:57 UTC --- Why doesn't it error for unlimited stack say on x86_64? If the stack mapping size is unlimited, it also potentially overlaps with the shadow memory. If you have a growsdown mapping, it simply needs to be capped by the end of the shadow memory area resp. start of the high memory region.
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org |
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #29 from Kostya Serebryany 2013-01-23 13:19:30 UTC --- >> Why doesn't it error for unlimited stack say on x86_64? Because on x86_64 the stack is still high enough (we are lucky). Note: I would not generally care about unlimited stack, but for some obscure reason GNU make spawns its sub-processes with unlimited stack.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #5 from Jan Hubicka 2013-01-23 13:28:35 UTC --- Path to disable early inliner iteation is posted to gcc.gnu.org/ml/gcc-patches/2013-01/msg01138.html The ICE happens in IPA inlining rather than in early inliner. I am looking into it.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #30 from Jakub Jelinek 2013-01-23 13:30:19 UTC --- What I mean, is a stack PROT_GROWSDOWN RLIM_INFINITY RLIMIT_STACK mapping is defined to be a mapping from the top of that mapping down to the first mapping of something else below it. Whether it is the shadow memory or something else doesn't matter. There is just no overlap in that case, so the error looks wrong to me.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #31 from Kostya Serebryany 2013-01-23 13:32:11 UTC --- I've committed an upstream change http://llvm.org/viewvc/llvm-project?view=rev&revision=173260 that makes kHighMemEnd dynamic. Hopefully, it will simplify further changes. I'd appreciate if someone who has access to a 46-bit AS machine propose a patch that works for both 44 and 46 AS w/ and w/o unlimited stack.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #24 from Iain Sandoe 2013-01-23 13:33:15 UTC --- (In reply to comment #23) > (In reply to comment #21) > > ... I don't have darwin11 or 12 (yet) - but should do soon. > > The test also fails on darwin10 unless the patch in comment #7 is applied. indeed it does (with xcode 3.2.6) and passes on x86-Darwin9 OK - so a recap; weak linking works just fine on Darwin - with the semantics that Darwin defines (where references are provided at link time, but may be missing at run time). Some versions of Darwin's tool chain components and dynamic linker also support ELF-style weak linking semantics. However, in this case, the references *are* present on the link line (lstdc++) but also a duplicate in crttme.o --- So, in this case (at least on x86-darwin10), I am not yet sure exactly where the problem lies. since -lstdc++ is on the link line (ahead of crttme.o) - I would expect darwin to resolve the __cxa__ symbols from the shared library. It is not doing so - and I (or someone) need(s) to re-check the priority of satisfying linkage. It might be that naming the crt as a .o forces it to be processed ahead of the shared lib. In which case, perhaps we can modify our crttme to be an arch containing that single object. [on Darwin10] If I manually remove the crttme.o from the link line, the testcase executes OK. Time is v. short at the moment - prob won't have a chance to investigate further for a couple of weeks.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #32 from Jakub Jelinek 2013-01-23 13:33:45 UTC --- I take it back, seems it is because the kernel mmaps the shared libraries in that range in this case. So indeed, you probably need a dynamic mapping, sorry for the noise. All that just to grow VA by 2 bits? Urgh. On x86_64 at least the address space was growing much more many years ago.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 --- Comment #6 from Jan Hubicka 2013-01-23 13:38:16 UTC --- The patch in Comment #4 should not have any effect (and indeed the test does not fire for me on the testcase). can_early_inline predicate already test that the callee is in SSA form and we do into-ssa just before early inlining. So the functions not processed yet in the topological order are not in SSA form.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #33 from Jakub Jelinek 2013-01-23 13:40:57 UTC --- (In reply to comment #31) > I've committed an upstream change > http://llvm.org/viewvc/llvm-project?view=rev&revision=173260 that makes > kHighMemEnd dynamic. > Hopefully, it will simplify further changes. > > I'd appreciate if someone who has access to a 46-bit AS machine > propose a patch that works for both 44 and 46 AS w/ and w/o unlimited stack. Do you really want to make kHighMemEnd dynamic always? Shouldn't it be dynamic only when needed (i.e. for configurations like ppc64 which now require it)? Otherwise it will slow down many of the inlines that use this heavily. Furthermore, in configurations where kHighMemEnd is dynamic, also IMHO all asan_mapping.h defines that are based on it should also be global variables to avoid unnecessary runtime computations everywhere. I mean kHighMemBeg, kHighShadowBeg, kHighShadowEnd, kShadowGapEnd.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek 2013-01-23 13:49:17 UTC --- For 4.9, wouldn't it be better to get all functions through the very early passes (up to and including build_ssa (or one or three passes after it, but before pass_inline_parameters)), then in another loop run the rest of early passes (i.e. inline_parameters/einline, ..., eipa_sra, ..., pass_inline_parameters) and then the normal IPA queue? The amount of issues we have with functions not in SSA form yet, whether it is in early inliner, or eipa_sra, etc. is big.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #34 from Kostya Serebryany 2013-01-23 13:50:31 UTC --- > Do you really want to make kHighMemEnd dynamic always? Shouldn't it be > dynamic > only when needed (i.e. for configurations like ppc64 which now require it)? If we make this dynamic on PPC and constant elsewhere, we risk breaking PPC frequently because we typically don't test on PPC (we don't even have a bot!). We can easily introduce a change that will assume kHighMemEnd is a constant. > Otherwise it will slow down many of the inlines that use this heavily. Hopefully, not that bad. unless an application is malloc-bound, we don't enter asan-rt too often. If it is malloc-bound, we are in trouble anyway, because the allocator is very expensive in all other parts. > Furthermore, in configurations where kHighMemEnd is dynamic, also IMHO all > asan_mapping.h defines that are based on it should also be global variables > to avoid unnecessary runtime computations everywhere. > I mean kHighMemBeg, kHighShadowBeg, kHighShadowEnd, kShadowGapEnd. Hm... I would not change that w/o some proof (benchmarks results). When e.g. we access two of these variables, we will be doing two loads instead of one load and arithmetic. Not a clear choice.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #8 from Jan Hubicka 2013-01-23
13:56:44 UTC ---
This is not really issue with early inliner confused with function not being in
SSA form. But for aid of esra, we can do that at expense of increasing of peak
memory use - the SSA form is quite bloated just after built and early passes
gets it noticeably smaller, so we may need to schedule another DCE pass or so.
The problem here is however saving body of
file_info::~file_info() (struct file_info * const this)
{
struct intrusive_ptr * _2;
struct intrusive_ptr * _5;
struct intrusive_ptr * _7;
struct section_info * _9;
:
_2 = &this_1(D)->switched_section;
_9 = _2->px;
if (_9 != 0B)
goto ;
else
goto ();
:
section_info::~section_info (_9);
:
operator delete (_9);
:
_5 = &this_1(D)->parent;
intrusive_ptr::~intrusive_ptr (_5);
return;
:
_7 = &this_1(D)->parent;
intrusive_ptr::~intrusive_ptr (_7);
resx 1
}
The basic block in unreachable, but for some reason it is not removed
prior inlining. save_function_body must run delete_unreachable_blocks in order
to update SSA after copying and that one gets rid of the call. It updates the
node itself, but not the clones. I will add code to update clones.
I suppose this is because
[Bug testsuite/56082] New: FAIL: gfortran.dg/bind_c_bool_1.f90 -O (test for errors, line 18) on powerpc-apple-darwin9 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082
Bug #: 56082
Summary: FAIL: gfortran.dg/bind_c_bool_1.f90 -O (test for
errors, line 18) on powerpc-apple-darwin9 with -m32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: bur...@net-b.de, ia...@gcc.gnu.org,
mikest...@comcast.net
Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
Build: powerpc-apple-darwin9
The test gfortran.dg/bind_c_bool_1.f90 fails on powerpc-apple-darwin9 with -m32
(but not with -m64). From
http://gcc.gnu.org/onlinedocs/gcc/Darwin-Options.html#Darwin-Options
-mone-byte-bool
Override the defaults for `bool' so that `sizeof(bool)==1'. By default
`sizeof(bool)' is `4' when compiling for Darwin/PowerPC and `1' when compiling
for Darwin/x86, so this option has no effect on x86.
As shown by the following test
[karma] f90/bug% cat c_bool.f90
use iso_c_binding; print *, C_Bool; end
[karma] f90/bug% gfc c_bool.f90
[karma] f90/bug% a.out
4
[karma] f90/bug% gfc c_bool.f90 -m64
[karma] f90/bug% a.out
1
[karma] f90/bug%
C_Bool is 4 for Darwin/PowerPC (32 bit mode) and the test
! { dg-do compile }
subroutine sub(x) bind(C) ! { dg-error "GNU Extension: LOGICAL dummy argument
'x' at .1. with non-C_Bool kind in BIND.C. procedure 'sub'" }
logical(kind=4) :: x
end subroutine sub
does not give any error even with -std=f2003.
I can think of at least 3 ways to fix the test:
(a) XFAIL the test.
--- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/bind_c_bool_1.f90
2013-01-13 07:07:14.0 +0100
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/bind_c_bool_1_a.f902013-01-23
14:44:33.0 +0100
@@ -16,7 +16,7 @@ end function sub4
subroutine sub(x) bind(C) ! { dg-error "GNU Extension: LOGICAL dummy argument
'x' at .1. with non-C_Bool kind in BIND.C. procedure 'sub'" }
- logical(kind=4) :: x
+ logical(kind=2) :: x
end subroutine sub
subroutine sub3(y) bind(C)
(b) Use logical(kind=2), hoping that there is no targer with C_Bool==2.
--- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/bind_c_bool_1.f90
2013-01-13 07:07:14.0 +0100
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/bind_c_bool_1_b.f902013-01-23
14:52:45.0 +0100
@@ -15,7 +15,7 @@ function sub4() bind(C) result(res) ! {
end function sub4
-subroutine sub(x) bind(C) ! { dg-error "GNU Extension: LOGICAL dummy argument
'x' at .1. with non-C_Bool kind in BIND.C. procedure 'sub'" }
+subroutine sub(x) bind(C) ! { dg-error "GNU Extension: LOGICAL dummy argument
'x' at .1. with non-C_Bool kind in BIND.C. procedure 'sub'" "" { xfail {
powerpc*-apple-darwin* && { ! lp64 } } } }
logical(kind=4) :: x
end subroutine sub
(c) Use the following patch
--- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/bind_c_bool_1.f90
2013-01-13 07:07:14.0 +0100
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/bind_c_bool_1.f902013-01-21
19:50:29.0 +0100
@@ -1,5 +1,6 @@
! { dg-do compile }
! { dg-options "-std=f2003" }
+! { dg-additional-options "-mone-byte-bool" { target { powerpc*-apple-darwin*
&& { ! lp64 } } } }
!
! PR fortran/55758
!
What is the best one? or is there a better one?
[Bug middle-end/56074] [4.8 regression] ICE compiling gcc.dg/vect/pr49093.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074 --- Comment #4 from Rainer Orth 2013-01-23 13:59:18 UTC --- Indeed, thanks for the superfast fix. Rainer
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 --- Comment #9 from Jan Hubicka 2013-01-23 14:00:23 UTC --- Just for record, I do not recall any issues with early inliner being run in parallel with into-SSA. As a simple inliner working in topological order, it really does not care about functions not processed yet.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #25 from Aldy Hernandez 2013-01-23 14:11:53 UTC --- > looks like (yet another) permutation of what works/doesn't with "ELF-style > weak > linking" I don't have darwin11 or 12 (yet) - but should do soon. > FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). Mac OS X 10.6.8.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #10 from Jan Hubicka 2013-01-23
14:19:51 UTC ---
I am testing the following patch. It is a side case where we save function body
but the function we save the body of becomes unnecesary as a result of dead
block removal during inlining that is caused by ipa-pure-const proving function
nothorw.
We get it almost right by removing the unnecesary clone after saving, but we
forget about the edge.
Index: cgraphclones.c
===
--- cgraphclones.c (revision 195370)
+++ cgraphclones.c (working copy)
@@ -570,7 +570,10 @@ cgraph_remove_node_and_inline_clones (st
bool found = false;
if (node == forbidden_node)
-return true;
+{
+ cgraph_remove_edge (node->callers);
+ return true;
+}
for (e = node->callees; e; e = next)
{
next = e->next_callee;
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek 2013-01-23
14:23:30 UTC ---
Note, the code is not valid ISO C99, which forbids initialization of flexible
array members, but a GNU extension, apparently not sufficiently well defined.
E.g. in struct T t2 = { .a = 1, .b[0] = 'a' }; the .b[0] initializer is ignored
with a warning, only initializing it as whole, whether as in #c3 without that
extra ", .b[0] = '2'", or e.g. as in
struct T t3 = { .a = 1, .b = { [0] = 'a', [1] = 'b', [2] = 'c' } };
So the question is how exactly we want to handle the flexible array members vs.
designated initializers, if we take the size from the first initializer and all
further ones will be either ignored (if beyond that size) or overwrite the
initializer, or if we e.g. take the highest array index ever seen anywhere.
So, say, is
struct T t4 = { .a = 1, .b[5] = '5', .b[7] = '7' };
the same as
struct T t4 = { .a = 1, .b = { 0, 0, 0, 0, 0, '5' };
with warning or:
struct T t4 = { .a = 1, .b = { 0, 0, 0, 0, 0, '5', 0, '7' };
?
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
--- Comment #5 from Jakub Jelinek 2013-01-23
14:32:31 UTC ---
--- gcc/c/c-typeck.c.jj2013-01-11 09:02:31.0 +0100
+++ gcc/c/c-typeck.c2013-01-23 15:24:50.839173887 +0100
@@ -7574,7 +7574,9 @@ set_nonincremental_init_from_string (tre
end = p + TREE_STRING_LENGTH (str);
for (purpose = bitsize_zero_node;
- p < end && !tree_int_cst_lt (constructor_max_index, purpose);
+ p < end
+ && (constructor_max_index == NULL_TREE
+ || !tree_int_cst_lt (constructor_max_index, purpose));
purpose = size_binop (PLUS_EXPR, purpose, bitsize_one_node))
{
if (wchar_bytes == 1)
makes this ICE go away, and #c3 then is handled with a warning the same as
struct T t = { .a = 1, .b = "abc" };
alone, so it is the same issue as t2 then. The rest I guess depends on how do
we want to exactly define the extension.
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #9 from Georg-Johann Lay 2013-01-23 15:13:56 UTC --- Author: gjl Date: Wed Jan 23 15:13:51 2013 New Revision: 195407 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195407 Log: PR target/54222 * config/avr/stdfix.h: New file. * t-avr (stdfix-gcc.h): New rule to build it. (EXTRA_HEADERS): Set it to install stdfix.h, stdfix-gcc.h. Added: trunk/gcc/config/avr/stdfix.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/t-avr
[Bug c/56083] New: Vectorizer uses xor/movlps/movhps rather than movups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083
Bug #: 56083
Summary: Vectorizer uses xor/movlps/movhps rather than movups
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ljkar...@cc.hut.fi
Unnecessarily complex machine code is generated on x86-64. Perhaps there is a
reason for this but to me it seems like the compiler is failing to optimize
properly. Asm code labels changed and comments added, other than that they are
are produced by the respective compilers for this C code:
void negate(float* fvec) {
fvec[0] *= -1;
fvec[1] *= -1;
fvec[2] *= -1;
fvec[3] *= -1;
}
.LC0:
.long2147483648 # float -0.00e+00
.long2147483648 # float -0.00e+00
.long2147483648 # float -0.00e+00
.long2147483648 # float -0.00e+00
.LC1:
.long 3212836864 # float -1.00e+00
.long 3212836864 # float -1.00e+00
.long 3212836864 # float -1.00e+00
.long 3212836864 # float -1.00e+00
# Hand optimized
movups(%rdi), %xmm0 # Load fvec into xmm0
xorps.LC0(%rip), %xmm0 # Invert sign bits of each float (xor -0.0f)
movups%xmm0, (%rdi) # Store xmm0 to fvec
# Clang -O3 -mllvm -vectorize
movups (%rdi), %xmm0 # Load fvec
mulps .LC1(%rip), %xmm0 # Multiply by negative ones
movups %xmm0, (%rdi) # Store fvec
# GCC 4.7.2 -O3
xorps%xmm0, %xmm0# Zero xmm0 (unnecessary)
movlps(%rdi), %xmm0 # Load two lower floats
movhps8(%rdi), %xmm0 # Load two higher floats
xorps.LC0(%rip), %xmm0 # Invert sign bits
movlps%xmm0, (%rdi) # Store two lower floats
movhps%xmm0, 8(%rdi) # Store two higher floats
[Bug c++/56084] New: poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Bug #: 56084
Summary: poor error recovery for missing ";"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
#include
#include
struct Student {
std::string surname;
std::string givenname;
}
std::ostream& operator<<(std::ostream& out, Student const& s) {
return out << "{" << s.surname << ", " << s.givenname << "}";
}
int main() {
Student me = { "Doe", "John" };
std::cout << me << "\n";
}
clang not perfect but bearable:
test.cc:9:8: error: redefinition of 'ostream' as different kind of symbol
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
/usr/lib/gcc/x86_64-linux-gnu/4.4/../../../../include/c++/4.4/iosfwd:129:33:
note: previous definition is here
typedef basic_ostream ostream;///< @isiosfwd
^
test.cc:9:15: error: expected ';' after top level declarator
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
;
2 errors generated.
G++ 4.8.0 awful:
test.cc:9:15: error: expected initializer before ‘&’ token
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
test.cc: In function ‘int main()’:
test.cc:15:13: error: no match for ‘operator<<’ (operand types are
‘std::ostream {aka std::basic_ostream}’ and ‘Student’)
std::cout << me << "\n";
^
test.cc:15:13: note: candidates are:
In file included from
/home/manuel/test1/195333M/install/include/c++/4.8.0/iostream:40:0,
from test.cc:2:
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:110:7: note:
std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]
operator<<(__ostream_type& (*__pf)(__ostream_type&))
^
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:110:7: note: no
known conversion for argument 1 from ‘Student’ to
‘std::basic_ostream::__ostream_type&
(*)(std::basic_ostream::__ostream_type&) {aka std::basic_ostream&
(*)(std::basic_ostream&)}’
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:119:7: note:
std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ios_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ios_type&)) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream; std::basic_ostream<_CharT,
_Traits>::__ios_type = std::basic_ios]
operator<<(__ios_type& (*__pf)(__ios_type&))
^
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:119:7: note: no
known conversion for argument 1 from ‘Student’ to
‘std::basic_ostream::__ios_type&
(*)(std::basic_ostream::__ios_type&) {aka std::basic_ios&
(*)(std::basic_ios&)}’
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:129:7: note:
std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]
operator<<(ios_base& (*__pf) (ios_base&))
^
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:129:7: note: no
known conversion for argument 1 from ‘Student’ to ‘std::ios_base&
(*)(std::ios_base&)’
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:168:7: note:
std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(long int) [with _CharT = char; _Traits =
std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type =
std::basic_ostream]
operator<<(long __n)
^
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:168:7: note: no
known conversion for argument 1 from ‘Student’ to ‘long int’
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:172:7: note:
std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(long unsigned int) [with _CharT = char; _Traits =
std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type =
std::basic_ostream]
operator<<(unsigned long __n)
^
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:172:7: note: no
known conversion for argument 1 from ‘Student’ to ‘long unsigned int’
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:176:7: note:
std::basic_ostream<_CharT, _Traits>::__ostream_type& std::bas
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Manuel López-Ibáñez 2013-01-23 15:44:21 UTC --- Originally from: http://stackoverflow.com/questions/8205858/clang-vs-gcc-for-linux-development-compare-and-contrast
[Bug libstdc++/56085] New: Unsafe negation in C++03 pow(complex,int)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085
Bug #: 56085
Summary: Unsafe negation in C++03 pow(complex,int)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
template
inline complex<_Tp>
pow(const complex<_Tp>& __z, int __n)
{
return __n < 0
? complex<_Tp>(1) / std::__complex_pow_unsigned(__z, -__n)
: std::__complex_pow_unsigned(__z, __n);
If I understand correctly, -__n is undefined behavior for INT_MIN, and this
should use -(unsigned)__n instead to be safe. This is not just theoretical,
other projects had to do similar changes because gcc starting with 4.7 would
produce wrong code otherwise.
[Bug c/56083] Vectorizer uses xor/movlps/movhps rather than movups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Uros Bizjak 2013-01-23 16:05:40 UTC --- (In reply to comment #0) > Unnecessarily complex machine code is generated on x86-64. Perhaps there is a > reason for this but to me it seems like the compiler is failing to optimize > properly. Asm code labels changed and comments added, other than that they are > are produced by the respective compilers for this C code: This is tuning decision, use -march= for targets that benefit from unaligned loads and stores: /* X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL */ m_COREI7 | m_AMDFAM10 | m_BDVER | m_BTVER, /* X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL */ m_COREI7 | m_BDVER, -O3 -march=corei7 produces: movups (%rdi), %xmm0 xorps .LC0(%rip), %xmm0 movups %xmm0, (%rdi) Which is the same as your hand optimized code.
[Bug c/56083] Vectorizer uses xor/movlps/movhps rather than movups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Marc Glisse 2013-01-23 16:17:02 UTC --- (In reply to comment #1) > This is tuning decision, Uros, I completely agree, but note that the PR also mentions this line: xorps%xmm0, %xmm0 which appears rather useless since the low and high parts are overwritten on the next 2 lines. Is this done on purpose to kill dependencies or something? Or is it a missed optimization? (simplify-rtx (or another place) is indeed missing a few things in that area)
[Bug c/56083] Vectorizer uses xor/movlps/movhps rather than movups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083 --- Comment #3 from Uros Bizjak 2013-01-23 16:23:47 UTC --- (In reply to comment #2) > Uros, I completely agree, but note that the PR also mentions this line: > > xorps%xmm0, %xmm0 > > which appears rather useless since the low and high parts are overwritten on > the next 2 lines. Is this done on purpose to kill dependencies or something? > Or > is it a missed optimization? (simplify-rtx (or another place) is indeed > missing > a few things in that area) IIRC, this insn is emitted to break dependency chain for %xmm0 register. Processor is not _that_ smart ;)
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.0
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-23
Ever Confirmed|0 |1
--- Comment #2 from Jonathan Wakely 2013-01-23
16:25:18 UTC ---
This reduces to:
struct ostream { };
struct A {
int i;
}
ostream& operator<<(ostream& o, const A&) { return o; }
int main()
{
A a;
ostream o;
o << a;
}
which still gives a poor error that doesn't identify the problem, but it
doesn't give pages of errors because there is only one operator<< in scope
x.cc:7:8: error: expected initializer before '&' token
ostream& operator<<(ostream& o, const A&) { return o; }
^
x.cc: In function 'int main()':
x.cc:13:7: error: no match for 'operator<<' (operand types are 'ostream' and
'A')
o << a;
^
(Separately, I'm investigating whether there's some way to reduce the output
when an invalid ostream operation is done, because the sheer number of
overloads of operator<< causes pages of output due to G++'s verbose, and
usually very useful, output describing argument deduction errors.)
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
William J. Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #35 from William J. Schmidt
2013-01-23 16:25:27 UTC ---
(In reply to comment #34)
> If we make this dynamic on PPC and constant elsewhere, we risk breaking
> PPC frequently because we typically don't test on PPC (we don't even have a
> bot!).
Well, although the ppc64 LNT bot is not quite functional yet, there are many of
us who run the LLVM unit test suite several times a day. So as long as the
changes are covered with tests in Instrumentation/{Address,Thread}Sanitizer,
we'll definitely notice PPC64 breakage and let you know. ;)
Bill
[Bug target/56056] [4.8 Regression] internal compiler error: in get_builtin_code_for_version, at config/i386/i386.c:28686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56056 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Target Milestone|--- |4.8.0 Summary|internal compiler error: in |[4.8 Regression] internal |get_builtin_code_for_versio |compiler error: in |n, at |get_builtin_code_for_versio |config/i386/i386.c:28686|n, at ||config/i386/i386.c:28686
[Bug lto/56061] [4.8 Regression] ICE in lto1 (in inline_call, at ipa-inline-transform.c:267)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/56077] volatile ignored when function inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56077 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0 --- Comment #5 from Richard Biener 2013-01-23 16:33:36 UTC --- volatile asms and volatile insns are not supposed to be interchanged by scheduling. Confirmed with 4.7.2.
[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56076 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/56075] [gcc-4.7.1] 64-bit version, -Os eliminate some line of code which working fine in gcc-4.6.2 64-bit version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-23 Ever Confirmed|0 |1
[Bug middle-end/56074] [4.8 regression] ICE compiling gcc.dg/vect/pr49093.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/56056] [4.8 Regression] internal compiler error: in get_builtin_code_for_version, at config/i386/i386.c:28686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56056
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #1 from Jakub Jelinek 2013-01-23
16:38:31 UTC ---
With the latest patch for PR55742, this doesn't ICE, but is properly rejected.
Even with added __attribute__((target ("default"))) before the first function
that is now required for the default mv version, only works if you fix up the
second target attribute.
*** This bug has been marked as a duplicate of bug 55742 ***
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jakub Jelinek changed: What|Removed |Added CC||crrodriguez at opensuse dot ||org --- Comment #43 from Jakub Jelinek 2013-01-23 16:38:31 UTC --- *** Bug 56056 has been marked as a duplicate of this bug. ***
[Bug target/56068] -march=native creates Illegal instruction on KVM guests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56068 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #16 from Richard Biener 2013-01-23 16:42:19 UTC --- mockbuild@centos6-64bit-builder ~/build/BUILD/tmp (mock-chroot) $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 13 I think that's the old qemu bug of providing a non-sensical CPUID family/model/vendor combination by default on x86_64. AMD family 6 is 32bits only. Intel family 6 has 64bit support. You'll hit funny issues with GMP as well. Thus, fix your KVM/QEMU config.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #26 from Jack Howarth 2013-01-23 16:44:51 UTC --- Iain, The initial comments from the darwin linker developer were... That test case is dying because a.out contains its own copy of __cxa_allocate_exception which just returns NULL. How was a.out built? It looks like it linked with some bogus static copy of the libc++ runtime. Are you expecting that because these bogus cxa functions are weak, they will be overridden at runtime by the real version? Weak linking does not work quite that way on darwin. For performance, the only symbols which dyld checks for weak coalescing are those which the static linker marked as needing weak binding. You can see those with "dyldinfo -weak_bind". In a.out __cxa_allocate_exception is marked for weak binding check, but in libc++abi.dylib does not mark those as weak, so dyld is not coalescing those symbols and the a.out wind up running with its own bogus implementation. Can you just not link a.out with the bogus implementation?
[Bug libstdc++/56085] Unsafe negation in C++03 pow(complex,int)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-01-23 16:46:02 UTC --- Confirmed. Or use __builtin_absu() - bah you'd need to add it first ;)
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 Richard Biener changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.7.3
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #27 from Jack Howarth 2013-01-23 16:48:19 UTC --- (In reply to comment #25) > FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). > Mac OS X 10.6.8. What Xcode do you have installed? Is it 3.2.6 or one of the 4.x series? The linker got a major rewrite in 4.0.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 Richard Biener changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #30 from Richard Biener 2013-01-23 16:49:05 UTC --- Is it still a regression from 4.7.x?
[Bug web/56063] [bugzilla] last reconfirmed : now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063 --- Comment #8 from Richard Biener 2013-01-23 16:52:13 UTC --- ISTR old bugzilla had a reconfirm-now-like style. As long as one would be able to eventually re-set the reconfirmed date back if it was changed in error the default should be to reconfirm "now".
[Bug driver/56062] Enhance -fuse-ld= option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hjl at gnu dot org Resolution||WONTFIX --- Comment #2 from Richard Biener 2013-01-23 16:53:21 UTC --- Yeah ... I even was moderately against adding -fuse-ld in the first place ...
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 --- Comment #3 from Manuel López-Ibáñez 2013-01-23 17:02:02 UTC --- > (Separately, I'm investigating whether there's some way to reduce the output > when an invalid ostream operation is done, because the sheer number of > overloads of operator<< causes pages of output due to G++'s verbose, and > usually very useful, output describing argument deduction errors.) One clear way is to avoid the repetition of: In file included from /home/manuel/test1/195333M/install/include/c++/4.8.0/iostream:40:0, from test.cc:2: Another is to add a "foverload-candidates-limit" option like ftemplate-backtrace-limit, so if there are more than the limit (let's say 5), the output is elided in a similar fashion. Another suggestion is to don't show the full function declaration like in: In file included from /home/manuel/test1/195333M/install/include/c++/4.8.0/iostream:40:0, from test.cc:2: /home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:532:5: note: template std::basic_ostream& std::operator<<(std::basic_ostream&, const char*) operator<<(basic_ostream& __out, const char* __s) ^ /home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:532:5: note: template argument deduction/substitution failed: test.cc:16:16: note: cannot convert ‘me’ (type ‘Student’) to type ‘const char*’ std::cout << me << "\n"; ^ where clang says in 1 line: /usr/lib/gcc/x86_64-linux-gnu/4.4/../../../../include/c++/4.4/bits/ostream.tcc:320:5: note: candidate function [with _CharT = char, _Traits = std::char_traits] not viable: no known conversion from 'Student' to 'const char *' for 2nd argument operator<<(basic_ostream<_CharT, _Traits>& __out, const char* __s)
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 --- Comment #4 from Manuel López-Ibáñez 2013-01-23 17:05:14 UTC --- BTW, what is the difference between deduction and substitution?
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 --- Comment #5 from Manuel López-Ibáñez 2013-01-23 17:10:58 UTC --- Of course, the color output makes much easier to spot the "note:". And the use of a common prefix "note: candidate function..." or "note: candidate template..." also makes easier to spot the start of each individual explanation.
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 --- Comment #6 from Marc Glisse 2013-01-23 17:17:53 UTC --- (In reply to comment #5) > Of course, the color output makes much easier to spot the "note:". Er, not here, bold black (the color they chose for "note:") on a black background is pretty hard to read... (otherwise I agree that colors help)
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 --- Comment #7 from Manuel López-Ibáñez 2013-01-23 17:31:21 UTC --- Strange. In the GCC farm and without any customization, clang uses gray for the note. I have seen presentations where it also uses this color scheme. I don't know if they have some brackground-color detection, and it fails in your case.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #28 from Jack Howarth 2013-01-23 17:32:34 UTC --- Iain, The ELF style weak ref issue appears to be red herring. I find that both darwin10 with Xcode 4.2 (whose build of libitm has a config.h with HAVE_ELF_STYLE_WEAKREF undefined) and darwin11/12 with Xcode 4.5.2 (which results in config.h having HAVE_ELF_STYLE_WEAKREF defined) exhibit this regression. In both cases, removing the trailing linkage on -lcrttme.o eliminates the segfaults in the test case. Is there some way to modify darwin.h's SPEC handling so that the linkage on -lcrttme.o isn't passed for the g++ compiler? As I understand this, we are only linking in crttme.o to provide stub symbols when libstdc++ linkage isn't present to provide those symbols.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #21 from Jack Howarth 2013-01-23 17:34:25 UTC --- Fixed at r195281.
[Bug c++/56084] poor error recovery for missing ";"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #8 from Jonathan Wakely 2013-01-23
17:44:24 UTC ---
(In reply to comment #4)
> BTW, what is the difference between deduction and substitution?
Some template arguments are deduced from the function arguments, and those
arguments are then substituted into the rest of the function template signature
to form a function signature.
e.g.
template
void func(T, typename T::iterator)
{ }
If you call 'func(v, v.begin())' then T will be deduced from the type of 'v', U
will be deduced as the same type, then that type will be substituted into the
type T::iterator. If 'v' has no nested 'iterator' type then substitution fails
and so deduction fails, and the template cannot be called.
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #6 from joseph at codesourcery dot com 2013-01-23 17:53:16 UTC --- I think taking the highest array index seen (determining the array bounds so that none of the initializers for a flexible array will ever be outside the bounds of the array) is the best interpretation of this extension.
[Bug tree-optimization/55927] FAIL: g++.dg/ipa/devirt-10.C -std=gnu++11 scan-ipa-dump-times inline "Discovered a virtual call to a known target" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927 Martin Jambor changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #5 from Martin Jambor 2013-01-23 17:55:49 UTC --- Uh oh, the testcase checks behavior of indirect inlining but does not turn off early inlining so the input to IPA-CP and inliner differs on platforms (and will potentially change everywhere in future) and this of course leads to different behavior. I will double check that we do not still loose an indirect inlining opportunity somehow and will try to somehow force the early inliner to do the same thing on the testcase everywhere, if possible.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #29 from Dominique d'Humieres 2013-01-23 18:30:37 UTC --- (In reply to comment #27) > > FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). > > Mac OS X 10.6.8. > > What Xcode do you have installed? Is it 3.2.6 or one of the 4.x series? The > linker got a major rewrite in 4.0. The test fails also with Xcode 3.2.6.
[Bug c/56086] New: when compiling C code with -std=gnu99 macro __STDC_UTF_16__ is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086 Bug #: 56086 Summary: when compiling C code with -std=gnu99 macro __STDC_UTF_16__ is defined Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: rjarr...@mathworks.com Created attachment 29255 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29255 sample program The macro __STDC_UTF_16__ is unexpectedly defined when compiling C code using gcc 4.7.2 (also present in gcc 4.7.1) This is a regression from gcc 4.5.3. (also gcc 4.4.6) compilation line: gcc -c -std=gnu99 gcc47_stdc_utf_16.c expected result: no output actual result: gcc47_stdc_utf_16.c:3:2: warning: #warning __STDC_UTF_16__ defined [-Wcpp] use case was in a header file used for both C and C++ compilation that contained #if defined(__STDC_UTF_16__) ... #endif workaround: use :#if (__cplusplus && defined(__STDC_UTF_16__)) in place of #if defined(__STDC_UTF_16__)
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #30 from Jack Howarth 2013-01-23 19:32:22 UTC --- Created attachment 29256 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29256 test case demonstrating need for weak symbols in crttme.o
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #31 from Jack Howarth 2013-01-23
19:41:52 UTC ---
I believe the attached testcase, weak_symbol.tar.bz2, demonstrates that the
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
Consider the following test case...
% cat fun.c
extern void foo(void) __attribute__((weak));
void fun(void)
{
if (foo) foo();
}
% cat foo.c
#include
void foo(void)
{
printf("Hello!\n");
}
% cat bar.c
#include
void foo(void) __attribute__((weak));
void foo(void)
{
printf("Goodbye!\n");
}
% cat weak_test.c
#include
void fun(void);
int main()
{
fun();
return 0;
}
compiled as...
clang -c fun.c
clang -dyanmiclib -shared -Wl,-undefined -Wl,dynamic_lookup -o libfun.dylib
fun.o
clang -c foo.c
clang -dyanmiclib -shared -Wl,-undefined -Wl,dynamic_lookup -o libfoo.dylib
foo.o
clang -c bar.c
clang -c weak_test.c
clang -o weak_test weak_test.o ./libfoo.dylib ./libfun.dylib bar.o
clang -o weak_test2 weak_test.o ./libfun.dylib bar.o
This gives...
setenv DYLD_LIBRARY_PATH .
% ./weak_test
Hello!
% ./weak_test2
Goodbye!
which argues that if we mark the weak symbols from eh_cpp.cc as weak in
crttme.o as well, those symbols can be overridden by the ones in libstdc++ as
expected. Also, this eliminates the need to place libstdc++ first...
% clang -o weak_test3 weak_test.o ./libfun.dylib bar.o ./libfoo.dylib
% ./weak_test3
Hello!
[Bug target/56087] New: [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Bug #: 56087 Summary: [m68k] gcc miscompiles pari (multiplication) Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org Created attachment 29257 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29257 preprocessed reduced testcase More context: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698380 This turned out to be a miscompilation of one function; reduced testcase (still pretty large due to header inclusion, but, oh my) attached. Using the same register twice in muls.l is not permitted. Removing -funroll-loops lets this use two distinct ones, as do control flow differences. This happens on native compilation but can be reproduced on cross compilation. tg@freewrt:~ $ m68k-linux-gnu-gcc -c -g -O3 -funroll-loops -S -o testcase.S testcase.i && fgrep muls testcase.S muls.l #954437177,%d2:%d2 tg@freewrt:~ $ m68k-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=m68k-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-15' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/m68k-linux-gnu/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=m68k-linux-gnu --program-prefix=m68k-linux-gnu- --includedir=/usr/m68k-linux-gnu/include --with-headers=/usr/m68k-linux-gnu/include --with-libs=/usr/m68k-linux-gnu/lib Thread model: posix gcc version 4.6.3 (Debian 4.6.3-15)
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #32 from Iain Sandoe 2013-01-23 19:59:40 UTC --- (In reply to comment #31) > solution on darwin is to mark the duplicate symbols in crttme.o as weak. seems reasonable - can you try that?
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Thorsten Glaser changed: What|Removed |Added Keywords||wrong-code Target||m68k-linux-gnu Known to work||4.7.2 Host||x86_64-linux-gnu or ||m68k-linux-gnu Known to fail||4.6.3 Build||x86_64-linux-gnu or ||m68k-linux-gnu --- Comment #1 from Thorsten Glaser 2013-01-23 20:03:57 UTC --- There it works: root@aranym:~ # gcc-4.7 -c -g -O3 -funroll-loops -S -o testcase.S testcase.i && fgrep muls testcase.S muls.l #954437177,%d2:%d5 root@aranym:~ # gcc-4.7 -v Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.7/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --disable-libitm --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) Would still be nice to get a patch for 4.6 which is currently the “workhorse” compiler for m68k (lots of use, patches, Ada works, fixes and ports to MiNT).
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #33 from Iain Sandoe 2013-01-23 20:14:26
UTC ---
(In reply to comment #32)
> (In reply to comment #31)
>
> > solution on darwin is to mark the duplicate symbols in crttme.o as weak.
>
> seems reasonable - can you try that?
... except that all those symbols should already be weak:
/* Provide dummy functions to satisfy linkage for versions of the Darwin
tool-chain that that can't handle undefined weak refs at the link stage.
??? Define these dummy functions only when !HAVE_ELF_STYLE_WEAKREF. */
extern void *__cxa_allocate_exception (size_t) WEAK;
extern void __cxa_throw (void *, void *, void *) WEAK;
extern void *__cxa_begin_catch (void *) WEAK;
extern void *__cxa_end_catch (void) WEAK;
extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
extern void *_ZnwX (size_t) WEAK;
extern void _ZdlPv (void *) WEAK;
extern void *_ZnaX (size_t) WEAK;
extern void _ZdaPv (void *) WEAK;
typedef const struct nothrow_t { } *c_nothrow_p;
extern void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) WEAK;
extern void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) WEAK;
extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) WEAK;
extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) WEAK;
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #15 from Jürgen Reuter 2013-01-23 20:26:48 UTC --- Am 23/1/13 5:25 PM, schrieb rguenth at gcc dot gnu.org: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 > > Richard Biener changed: > > What|Removed |Added > > Priority|P3 |P4 > Target Milestone|--- |4.8.0 > BTW, could someone arrange erasing Comment #12 (sent by myself). It should have gone to Janus only. I don't want it to be openly visible on the bugzilla page.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #34 from Iain Sandoe 2013-01-23 20:35:47 UTC --- (In reply to comment #24) > However, in this case, the references *are* present on the link line (lstdc++) > but also a duplicate in crttme.o > since -lstdc++ is on the link line (ahead of crttme.o) - I would expect darwin > to resolve the __cxa__ symbols from the shared library. It is not doing so - > and I (or someone) need(s) to re-check the priority of satisfying linkage. $ nm -mapv /usr/lib/libstdc++.6.dylib |grep __cxa_allo 000452e8 (__TEXT,__text) external ___cxa_allocate_exception $ nm -mapv /GCC/gcc-live-trunk-build/i686-apple-darwin9/libgcc/crttme.o |grep __cxa_allo 0100 (__TEXT,__textcoal_nt) weak external ___cxa_allocate_exception In fact, since the libstdc++ symbols is NOT weak, and the crttme.o is ... ... ISTR non-weak should override weak - but need to re-RTFM. if that is the case, one is tempted to speculate that this might be a ld64 bug. > It might be that naming the crt as a .o forces it to be processed ahead of the > shared lib. In which case, perhaps we can modify our crttme to be an arch > containing that single object. I have a work-around hack in test.
[Bug c++/56088] New: LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 Bug #: 56088 Summary: LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vhais...@gmail.com Created attachment 29258 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29258 bug sources I am seeing the following compilation/linking error that I am not seeing with non-LTO builds: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8< In file included from :256:0: /usr/include/x86_64-linux-gnu/bits/wchar2.h: In function ‘_ZN9__gnu_cxx12__to_xstringISbIwSt11char_traitsIwESaIwEEwEET_PFiPT0_mPKS6_P13__va_list_tagEmS9_z.constprop.0’: /usr/include/x86_64-linux-gnu/bits/wchar2.h:316:28: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining __NTH (vswprintf (wchar_t *__restrict __s, size_t __n, ^ In file included from /home/wilx/gcc48/include/c++/4.8.0/bits/stl_algobase.h:3320:0, from :1177: /usr/include/x86_64-linux-gnu/bits/wchar2.h:322:50: error: called from here return __vswprintf_alias (__s, __n, __fmt, __ap); ^ lto-wrapper: g++-4.8 returned 1 exit status /usr/bin/ld.gold: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8< I am attaching the single .o file that reproduces the problem for me. Here is a command line that causes it for me: g++-4.8 -v -fPIC -DPIC -r -nostdlib ./timehelper.o -march=native -O3 -flto -flto-partition=none -fuse-linker-plugin -o out.so
[Bug c++/56088] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 --- Comment #1 from Václav Zeman 2013-01-23 20:45:10 UTC --- Created attachment 29259 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29259 output log
[Bug c++/56088] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 --- Comment #2 from Václav Zeman 2013-01-23 20:47:01 UTC --- GCC information detail: amber2::wilx:~/log4cplus-bzr/work-trunk/objdir/lto-bug> g++-4.8 -v Using built-in specs. COLLECT_GCC=g++-4.8 COLLECT_LTO_WRAPPER=/home/wilx/gcc48/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../trunk/configure -v --with-pkgversion='wilx/amber2 custom build' --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/home/wilx/gcc48 --program-suffix=-4.8 --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=rt --enable-gnu-unique-object --enable-lto --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-gmp=/usr --with-mpc=/usr --with-mpfr=/usr --with-cloog=/usr GNAT=gnatgcc --enable-bootstrap LD=ld.gold Thread model: posix gcc version 4.8.0 20130123 (experimental) [trunk revision 195409] (wilx/amber2 custom build) This was built from svn://gcc.gnu.org/svn/gcc/trunk at revision 195409.
[Bug c/56086] when compiling C code with -std=gnu99 macro __STDC_UTF_16__ is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086 --- Comment #1 from joseph at codesourcery dot com 2013-01-23 20:47:49 UTC --- Why do you think this is a bug? GCC meets the semantics of that macro (that char16_t values are UTF-16 encoded), and gnu99 mode enables u"" strings.
[Bug lto/56088] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 --- Comment #3 from Andrew Pinski 2013-01-23 20:49:23 UTC --- Can you provide the preprocessed source that was used to generate timehelper.o?
[Bug lto/56088] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 --- Comment #4 from Václav Zeman 2013-01-23 20:53:52 UTC --- Created attachment 29260 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29260 preprocessed source of timehelper.cxx Here is the preprocessed source.
[Bug c/56089] New: Instruction Scheduling error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56089
Bug #: 56089
Summary: Instruction Scheduling error
Classification: Unclassified
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolas.va...@gmail.com
Created attachment 29261
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29261
source, object and output of objdump -S
Instruction lwz at offset 8 restores float A parameter from stack before it has
been stored at offset 14
Same for lwz at offset C restores float B parameter from stack before it has
been stored at offset 18
int almostEqual(float A, float B, int maxDiff)
{
0:94 21 ff f0 stwur1,-16(r1)
void *aAddr = &A; /* needed to avoid breaking compiler strict-aliasing
rules */
int aInt = *(int*)aAddr;
4:39 40 00 01 lir10,1
8:81 61 00 08 lwzr11,8(r1)
void *bAddr = &B;
int bInt = *(int*)bAddr;
c:81 21 00 0c lwzr9,12(r1)
// Make aInt lexicographically ordered as a twos-complement int
if (aInt < 0)
10:2f 8b 00 00 cmpwicr7,r11,0
14:d0 21 00 08 stfsf1,8(r1)
18:d0 41 00 0c stfsf2,12(r1)
