[Bug bootstrap/50229] [4.7/4.8 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #16 from Ray Donnelly mingw.android at gmail dot com 2013-01-16 07:59:48 UTC --- Of course, when I wrote '--enable-plugins' I really mean't *not* passing --disable-plugin (without the 's').
[Bug target/55940] [4.7 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Summary|[4.7/4.8 Regression]|[4.7 Regression] Incorrect |Incorrect code for |code for accessing |accessing parameters with |parameters with 32-bit |32-bit Intel hosts |Intel hosts --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 07:59:51 UTC --- Fixed on the trunk so far.
[Bug c++/55998] [4.8 Regression] [C++11] 'integral expression .. is not constant' when instantiating template alias in a template using a parameter of an encapsulating template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55998 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 08:02:44 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=191412
[Bug middle-end/56000] [4.8 Regression] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 08:08:33 UTC --- Does this help? http://sourceware.org/ml/libffi-discuss/2012/msg00279.html
[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 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 08:11:42 UTC --- Merging of target attribute is what gcc/g++ did though, the function would get then both target attributes (seems later decl's target wins), and the first target attribute in DECL_ATTRIBUTES would be the one to be used. Perhaps we can add a -Wattributes warning for that case if mv attribute isn't present and are merging target attributes with different strings.
[Bug target/55301] [SH] broken sp_switch function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #1 from chrbr at gcc dot gnu.org 2013-01-16 08:24:49 UTC --- missing: 2013-01-12 DJ Delorie d...@redhat.com * config/sh/sh.md (UNSPECV_SP_SWITCH_B): New. (UNSPECV_SP_SWITCH_E): New. (sp_switch_1): Change to an unspec. (sp_switch_2): Change to an unspec. Don't use post-inc when we replace $r15. but when applied : /tmp/cc9Bqh88.s: Assembler messages: /tmp/cc9Bqh88.s:11: Error: pcrel too far
[Bug fortran/55984] [4.8 Regression] ICE: gfc_trans_code(): Bad statement code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984 --- Comment #5 from janus at gcc dot gnu.org 2013-01-16 08:31:21 UTC --- The patch in comment 4 fails on: FAIL: gfortran.dg/select_type_24.f90 -O (test for errors, line 48)
[Bug target/55301] [SH] broken sp_switch function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301 --- Comment #2 from chrbr at gcc dot gnu.org 2013-01-16 08:30:05 UTC --- Author: chrbr Date: Wed Jan 16 08:29:54 2013 New Revision: 195230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195230 Log: PR target/55301 * config/sh/sh.c (sh_expand_prologue): Postpone new_stack mem symbol. (broken_move): Handle UNSPECV_SP_SWITCH_B. * config/sh/sh.md (sp_switch_1): Use set (reg:SI SP_REG). * config/sh/sh.md (UNSPECV_SP_SWITCH_B): New. (UNSPECV_SP_SWITCH_E): New. (sp_switch_1): Change to an unspec. (sp_switch_2): Change to an unspec. Don't use post-inc when we replace $r15. * gcc.target/sh/sh-switch.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/sh/sp-switch.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug target/55301] [SH] broken sp_switch function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from chrbr at gcc dot gnu.org 2013-01-16 08:31:38 UTC --- Fixed in trunk @ 195230.
[Bug target/55940] [4.7 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 --- Comment #15 from Frank Mehnert fm3 at os dot inf.tu-dresden.de 2013-01-16 09:01:02 UTC --- Great, thank you Jakub! As it will take some time until the Linux distributions will update their gcc binaries to include this fix, do you have any suggestion how to work around this bug by changing the code? Omitting compiler switches on the command line will not work in our scenario as the Linux kernel Makefiles define the gcc command line parameters. And can you confirm that this bug only affects 32-bit x86 targets or does it affect 64-bit x86 targets as well?
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #7 from Daniel Krügler daniel.kruegler at googlemail dot com
2013-01-16 09:03:56 UTC ---
I stumbled across a similar problem recently within a member function of a
class template:
//
templateclass T
struct A {
static bool test() {
static bool value = false;
if (value)
return false;
struct S {
S() { value = true; }
};
static S s;
return true;
}
};
int main()
{
Aint::test();
}
//
obj\Debug\main.o||In function `Aint::test()::S::S()':|
main.cpp|8|undefined reference to `value'
It doesn't occur if A is not a template.
I can confirm the error with gcc 4.7.2 and gcc 4.8.0 20130113 (experimental)
compiled with the flags
-Wall -pedantic-errors
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 09:08:51 UTC --- I'd say it is too late for autoconf update for 4.8 now, if this is about LN_S uses in a single Makefile (are we talking about libada/Makefile.in ? ), you could temporarily use something like ifeq (cp -p,$(LN_S)) LN_S_RECURSIVE = cp -pR else LN_S_RECURSIVE = $(LN_S) endif (or even limit it to targets known to support cp -pR well that don't have ln -s) and use $(LN_S_RECURSIVE) in $(LN_S) $(ADA_RTS_DIR) adainclude $(LN_S) $(ADA_RTS_DIR) adalib (2x) instead $(LN_S). Then for 4.9 we can upgrade autoconf requirements and revert this.
[Bug target/55940] [4.7 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 09:16:15 UTC --- As a workaround, you can use something like #if __GNUC__ == 4 __GNUC_MINOR__ == 7 __attribute__((__optimize__ (no-shrink-wrap))) #endif on the VBoxHost_RTR0MemObjGetPagePhysAddr function or don't use long long for the return type here (pass it by reference etc., that is the reason why gcc even thought about potentially needing the stack realignment), don't use -mpreferred-stack-boundary=2, or -Os, or use optimize (2) attribute, there are lots of options.
[Bug libstdc++/55043] [4.7/4.8 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16 09:20:43 UTC --- Author: redi Date: Wed Jan 16 09:20:34 2013 New Revision: 195231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195231 Log: PR libstdc++/55043 * include/std/unordered_map: Include alloc_traits.h * include/std/unordered_set: Likewise. * include/bits/alloc_traits.h: Define __is_copy_insertable. * include/bits/unordered_map.h: Use it. * include/bits/unordered_set.h: Likewise. * include/debug/unordered_map.h: Likewise. * include/debug/unordered_set.h: Likewise. * include/profile/unordered_map.h: Likewise. * include/profile/unordered_set.h: Likewise. * include/bits/hashtable.h: Fix comment typos. * testsuite/23_containers/unordered_map/55043.cc: New. * testsuite/23_containers/unordered_multimap/55043.cc: New. * testsuite/23_containers/unordered_multiset/55043.cc: New. * testsuite/23_containers/unordered_set/55043.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/55043.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/55043.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/55043.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/55043.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/alloc_traits.h trunk/libstdc++-v3/include/bits/hashtable.h trunk/libstdc++-v3/include/bits/unordered_map.h trunk/libstdc++-v3/include/bits/unordered_set.h trunk/libstdc++-v3/include/debug/unordered_map trunk/libstdc++-v3/include/debug/unordered_set trunk/libstdc++-v3/include/profile/unordered_map trunk/libstdc++-v3/include/profile/unordered_set trunk/libstdc++-v3/include/std/unordered_map trunk/libstdc++-v3/include/std/unordered_set
[Bug middle-end/55882] [4.7 Regression] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 09:26:11 UTC --- Author: rguenth Date: Wed Jan 16 09:26:05 2013 New Revision: 195232 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195232 Log: 2013-01-16 Richard Biener rguent...@suse.de PR middle-end/55882 * emit-rtl.c (set_mem_attributes_minus_bitpos): Correctly account for bitpos when computing alignment. * gcc.dg/torture/pr55882.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55882.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/emit-rtl.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/55043] [4.7 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression] issue |[4.7 Regression] issue with |with nesting unordered_map |nesting unordered_map |containing unique_ptr into |containing unique_ptr into |vector |vector --- Comment #23 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16 09:26:39 UTC --- Fixed on trunk so far.
[Bug libstdc++/55043] [4.7 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #24 from Marc Glisse glisse at gcc dot gnu.org 2013-01-16 09:39:00 UTC --- That really feels like a hack. Anyone using boost::is_copy_constructible or whatever personal trick to detect copyable types will still be impacted. Did your idea in comment #15 not work?
[Bug libstdc++/55043] [4.7 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 --- Comment #25 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-16 09:43:07 UTC --- (In reply to comment #24) That really feels like a hack. It is also broken, I think. The P/R has the effect that is_copy_constructible is now out-of-sync with is_constructible, so the difference is easily observable.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-16 09:51:45 UTC --- Created attachment 29176 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29176 Patch for using recursive copy for directories. AFAIU we are talking about libada only here. I agree that it is too late for an libtool update for 4.8 gcc. As suggested the changeLog for libada/ * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. As soon as libtool got updated this patch can be removed.
[Bug tree-optimization/55999] gcc 4.7.2 -O2 -floop-parallelize-all generates incorrect code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55999 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 Known to work||4.8.0 Ever Confirmed|0 |1 Known to fail||4.6.3, 4.7.2 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 09:53:52 UTC --- Confirmed on the 4.7/4.6 branches.
[Bug tree-optimization/55999] gcc 4.7.2 -O2 -floop-parallelize-all generates incorrect code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55999 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 09:56:22 UTC --- Fixed by using ISL which properly handles overflow.
[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added CC||bergner at vnet dot ibm.com --- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16 10:01:24 UTC --- +berg...@vnet.ibm.com, who changed kHighMemEnd to 0x0fffUL From the proc mappings in the prev comment it looks like kHighMemEnd should be 0x4000-1 [Please forgive my complete ignorance in PowerPC, I will try to educate myself]
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-16
Ever Confirmed|0 |1
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
10:04:27 UTC ---
In another bug I stated that
while (1)
{
...
if (countm1.0 == 0) goto L.2;
countm1.0 = countm1.0 + 4294967295;
}
L.2:;
is bad for the vectorizer (the non-empty latch block). You instead
want GFortran to emit
while (1)
{
...
tem = countm1.0
countm1.0 = countm1.0 + 4294967295;
if (tem == 0) goto L.2;
}
L.2:;
where hopefully the addition does not overflow ...
That said, somewhat lessening the restriction on empty latch blocks is
certainly possible (IV increments should be fine), but it might be not
as trivial as it looks.
[Bug middle-end/56000] [4.8 Regression] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 10:05:03 UTC --- Confirmed - I also see spurious libffi testing messages.
[Bug libstdc++/55997] build of libstd3++ segfaults armv5tel.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55997 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 10:07:07 UTC --- While generating a PCH ... ugh.
[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55995 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-16 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 10:09:25 UTC --- Index: gcc/testsuite/gcc.dg/vect/vect.exp === --- gcc/testsuite/gcc.dg/vect/vect.exp (revision 195232) +++ gcc/testsuite/gcc.dg/vect/vect.exp (working copy) @@ -156,7 +156,7 @@ dg-runtest [lsort [glob -nocomplain $src # alignment-sensitive -fsection-anchors tests set DEFAULT_VECTCFLAGS $SAVED_DEFAULT_VECTCFLAGS -lappend DEFAULT_VECTCFLAGS -fsection-anchors -fdump-ipa-increase_alignment +lappend DEFAULT_VECTCFLAGS -fsection-anchors -fdump-ipa-increase_alignment-details dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/aligned-section-anchors-*.\[cS\]]] \ $DEFAULT_VECTCFLAGS should work, can you verify that?
[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16 10:14:03 UTC --- Btw, the mapping I see on my PPC linux box ends with 0x1000 (with ASLR off) ffd-1000 rw-p 00:00 0 [stack] (with ASLR on) fffe4c9-fffe4cc rw-p 00:00 0 [stack] Are you using some special kernel settings to get stack at 0x4000?
[Bug middle-end/55882] [4.7 Regression] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 10:21:09 UTC --- Fixed.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 10:25:48 UTC --- countm1.0 type is unsigned, thus + 0x is effectively - 1.
[Bug libstdc++/55043] [4.7 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 --- Comment #26 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16 10:25:57 UTC --- (In reply to comment #24) That really feels like a hack. It is a hack, to work around a throwing move ctor that I don't have time to fix. Anyone using boost::is_copy_constructible or whatever personal trick to detect copyable types will still be impacted. Impacted in what way? They'll get the same result as they did previously. This changes std::is_copy_constructible to be more accurate and makes __move_if_noexcept work for the unordered containers. How does that affect boost::is_copy_constructible? It gives the wrong result for unordered_containers of non-copyable types, but already did, and it's not my responsibility to fix everyone else's traits :-) Did your idea in comment #15 not work? I don't think that would be conforming and would be a huge amount of work to replace every constructor in vector and forward_list (and every other container as they are updated to be allocator-aware) with a template constructor. I'm not going to work on that solution, and I won't approve patches to do that without a lot of persuasion. I still do want to use SFINAE to remove allocator_traitsA::construct(args) from participating in overload resolution when A().construct(args) is not valid and is_constructibleA::value_type, args is false, which I hope is conforming, and would allow a better solution similar to comment 17, by deleting the unordered_xxx copy ctor. I'll revisit the patch tonight.
[Bug bootstrap/56001] New: [4.7.3 regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001 Bug #: 56001 Summary: [4.7.3 regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.7-20130112 on powepc64-linux fails for me with: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/mikpe/pkgs/linux-ppc64/gmp-5.0.5/lib -L/home/mikpe/pkgs/linux-ppc64/mpfr-3.1.1/lib -L/home/mikpe/pkgs/linux-ppc64/mpc-1.0.1/lib -lmpc -lmpfr -lgmp -L../zlib -lz libbackend.a(except.o): In function `VEC_uchar_base_splice': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x9238): relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o libbackend.a(except.o): In function `VEC_uchar_base_quick_insert': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x92f0): relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o libbackend.a(except.o): In function `VEC_uchar_base_ordered_remove': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x934c): relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o libbackend.a(except.o): In function `VEC_uchar_base_block_remove': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x93c0): relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o collect2: ld returned 1 exit status make[3]: *** [cc1] Error 1 make[3]: Leaving directory `/mnt/archive/objdir47/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/mnt/archive/objdir47' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/mnt/archive/objdir47' make: *** [bootstrap] Error 2 On the same machine with the same system toolchain (gcc-4.6.3, binutils-2.22), both the previous 4.7 snapshot (4.7-20130105) and the current 4.8 snapshot (4.8-20130113) bootstrapped fine.
[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 10:38:01 UTC --- Sounds like a recent change: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=048ee0993ec8360abb0b51bdf8f8721e9ed62ec4 The question is what to do about that on the libasan side. Can we keep + (1ULL 41) asan_shadow_offset for both 44-bit and 46-bit user address spaces? If we just increase kHighMemEnd to 0x3fffUL, it will mean that on older kernels half of the user address space will be the shadow memory (from 0x200 to 0x9ff). Perhaps that is still acceptable, but if ever the address space grows again, we'd need to make size of shadow memory region and kHighMemEnd dynamic.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 10:47:18 UTC --- BTW, does Fortran have well defined number of iterations if say a do loop goes from (unknown to compiler): integer :: i, m, n m = huge(0) - 7 n = huge(0) - 2 do i = m, n, 4 ... end do ? If it must iterate exactly twice (for i = huge(0) - 7 and i = huge(0) - 3), then it can't be expressed as a corresponding C loop (which would end up with undefined behavior). But using a temporary, increment and then test of the temporary should be doable in the FE, the question is if it does cure this.
[Bug libstdc++/55043] [4.7 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 --- Comment #27 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16 10:52:57 UTC --- Actually, now that the unordered containers do not inherit from Hashtable it should be much easier to implement something like comment 17. When Daniel first suggested it I thought it would be tricky given the current design of the containers, but François changed them three days later. I'll revert today's patch and fix it properly by making __is_copy_insertable more accurate and removing the unordered container constructors when appropriate.
[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:22:23 UTC --- Created attachment 29177 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29177 gcc48-pr50176.patch Are you sure about it? For me on the http://gcc.gnu.org/bugzilla/attachment.cgi?id=25088 testcase with -m32 -O2 with the attached patch I get just minor RA changes: - movl(%esp), %edi + movl(%esp), %esi addl$3, %ecx - movl4(%esp), %esi - movzbl(%edi,%eax), %ebx + movl4(%esp), %edi + movzbl(%esi,%eax), %ebx + movzbl(%edi,%eax), %esi movzbl0(%ebp,%eax), %edi - movzbl(%esi,%eax), %esi The fwprop extension is performed as can be seen in the dump, but the overall effect isn't there.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:31:51 UTC --- Author: vmakarov Date: Tue Jan 15 16:47:36 2013 New Revision: 195211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195211 Log: 2013-01-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55153 * sched-deps.c (sched_analyze_2): Add pending reads for prefetch. 2013-01-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55153 * gcc.dg/pr55153.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr55153.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-16 11:32:15 UTC --- (In reply to comment #8) In another bug I stated that See PR 53957
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Summary|FAIL: |asan does not work with 46 |c-c++-common/asan/global-ov |bit address space on |erflow-1.c -O0 output |PowerPC64 |pattern test| --- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16 11:47:38 UTC --- we'd need to make size of shadow memory region and kHighMemEnd dynamic. Probably so. We already have a macro ASAN_FLEXIBLE_MAPPING_AND_OFFSET that makes the SHADOW_SCALE and SHADOW_OFFSET dynamic. We'll soon make this the default since we want to use the zero base for asan on linux more widely (under a flag). What is the best way to compute kHighMemEnd at startup (anything better than reading proc maps?)
[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 #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:50:47 UTC --- I think for 44-46 bits we can still make it constant. But generally, the constructors of libasan are usually run from the stack of the initial thread, so it should be enough to look at address of any local variable and check if it is around (1 44) - epsilon or (1 46) - epsilon.
[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 #8 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16 11:54:36 UTC --- Sounds good for both. Andreas, could you please try replacing kHighMemEnd = 0x0fffUL with kHighMemEnd = 0x3fffUL and see if it helps?
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:59:29 UTC --- Created attachment 29178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29178 gcc48-pr52865.patch This untested patch makes the loop vectorizable. Not sure if it is better this way, or with doing assignment of the condition result into a bool and using it later (as done in the patch for the other PR).
[Bug libstdc++/56002] New: [mutex] allow generic classes to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 Bug #: 56002 Summary: [mutex] allow generic classes to be used without requiring plattform support for threads Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at Created attachment 29179 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29179 patch for mutex. diffed against 4.7.2 I am using gcc libstdc++ on a plattform that isnt natively supported and thus thread-functionality is not available from libstdc++. However I would like to be able to still use std::lock_guard, std::unique_lock, std::lock with my own mutex-classes. There ist no technical reason to prevent use of those generic classes and functions which are deliberately designed to work with custom implementations. ---mutex like it is now (all-or-nothing): #if HAS_GCC_THREADS mutexes definiton generic stuff like defer_lock_t,lock_guard, unique_lock, lock once_flag #endif ---mutex like it should be: #if HAS_GCC_THREADS mutexes definiton #endif generic stuff like defer_lock_t,lock_guard, unique_lock, lock #if HAS_GCC_THREADS once_flag #endif
[Bug libstdc++/56002] [mutex] allow generic classes to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 Ever Confirmed|0 |1
[Bug tree-optimization/42108] [4.6/4.7/4.8 Regression] 50% performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #54 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
12:36:52 UTC ---
Re-confirmed on trunk. The initial GFortran IL is still ... awkward. Apart
from the issue of using a canonicalized IV at all we have
D.1910 = i;
D.1911 = *nnd;
D.1912 = *n;
k = D.1910;
if (D.1912 0)
{
if (D.1911 D.1910) goto L.6;
}
else
{
if (D.1911 D.1910) goto L.6;
}
countm1.6 = (unsigned int) ((D.1911 - D.1910) *
(D.1912 0 ? -1 : 1)) / (unsigned int) ((D.1912 0 ? -1 : 1) * D.1912);
while (1)
{
...
do_exit.7 = countm1.6 == 0;
countm1.6 = countm1.6 + 4294967295;
if (do_exit.7) goto L.6;
}
}
L.6:;
in the computation of countm1.6 we have a redundant (D.1912 0 ? -1 : 1)
test which ends up complicating the CFG. It's also redundant again
with a test that was done just above. In fact it completely cancels out
in the countm1 compute. (the exit test via a do_exit temporary is
because of a local change in my tree ... eh)
Also note that
/* Calculate the loop count. to-from can overflow, so
we cast to unsigned. */
but we do
(unsigned)(to * step_sign - from * step_sign) / (unsigned) (step * step_sign)
that does not avoid overflow of step * step_sign (step == INT_MIN, step_sign ==
-1) nor overflow of to * step_sign - from * step_sign which we fold to
(to - from) * step_sign anyway (signed overflow is undefined, heh).
I believe we need to do
((unsigned)to - (unsigned)from) * (unsigned)step_sign / ((unsigned) step *
(unsigned) step_sign)
to avoid these issues.
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713 --- Comment #29 from Michael van der Kolff mvanderkolff at gmail dot com 2013-01-16 12:38:41 UTC --- Created attachment 29180 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29180 testcase for member function pointer that isn't inlined
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
Michael van der Kolff mvanderkolff at gmail dot com changed:
What|Removed |Added
CC||mvanderkolff at gmail dot
||com
--- Comment #30 from Michael van der Kolff mvanderkolff at gmail dot com
2013-01-16 12:39:24 UTC ---
The following is currently (g++ 4.7.2) inlined:
#include iostream
using namespace std;
class Foo
{
public:
void Bar() const
{
cout Howdy! endl;
}
};
int main()
{
Foo x;
auto y = [] (const Foo z) { z.Bar(); };
y(x);
return 0;
}
objdump -D:
--snip --
400700: 48 83 ec 08 sub$0x8,%rsp
400704: be 0c 09 40 00 mov$0x40090c,%esi
400709: bf a0 0c 60 00 mov$0x600ca0,%edi
40070e: e8 cd ff ff ff callq 4006e0
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt
400713: 48 89 c7mov%rax,%rdi
400716: e8 d5 ff ff ff callq 4006f0
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@plt
40071b: 31 c0 xor%eax,%eax
40071d: 48 83 c4 08 add$0x8,%rsp
400721: c3 retq
400722: 66 66 66 66 66 2e 0fdata32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
--snip --
whereas any version with ptr-to-mem fn is not:
...
int main()
{
Foo x;
auto y = Foo::Bar;
(x.*y)();
return 0;
}
objdump -D:
--snip --
00400830 main:
400830: 48 83 ec 18 sub$0x18,%rsp
400834: 48 8d 7c 24 0f lea0xf(%rsp),%rdi
400839: e8 42 01 00 00 callq 400980 _ZNK3Foo3BarEv
40083e: 31 c0 xor%eax,%eax
400840: 48 83 c4 18 add$0x18,%rsp
400844: c3 retq
400845: 66 66 2e 0f 1f 84 00data32 nopw %cs:0x0(%rax,%rax,1)
--snip --
[Bug rtl-optimization/55273] [4.8 Regression] ICE in iv_number_of_iterations, at loop-iv.c:2819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273
--- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16
13:17:30 UTC ---
OK, the problem is that the induction variable here is not normal induction
variable but handed by xor.
PPC target seems to be only that translates (flags 0x8000)
into
(insn 47 45 54 11 (set (reg/v:SI 125 [ flags ])
(plus:SI (reg/v:SI 125 [ flags ])
(const_int -2147483648 [0x8000]))) t.c:15 64
{*addsi3_internal1}
(nil))
so turning it into normal IV var.
This makes loop-iv to get what tree level IV doesn't. We could make tree level
IV to also handle this XOR as plus, but that is more an enhancement.
I am testing the following patch.
Index: loop-iv.c
===
--- loop-iv.c (revision 195144)
+++ loop-iv.c (working copy)
@@ -2819,7 +2819,8 @@ iv_number_of_iterations (struct loop *lo
else
{
max = determine_max_iter (loop, desc, old_niter);
- gcc_assert (max);
+ if (!max)
+ goto zero_iter_simplify;
if (!desc-infinite
!desc-assumptions)
record_niter_bound (loop, double_int::from_uhwi (max),
[Bug lto/54095] Unnecessary static variable renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095 --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16 13:18:51 UTC --- Well, we slipped the 4.8 window :( But I will make the patch soon so it goes into early 4.9 at least.
[Bug fortran/55983] [4.7/4.8 Regression] ICE in find_typebound_proc_uop, at fortran/class.c:2711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983 --- Comment #7 from janus at gcc dot gnu.org 2013-01-16 13:30:42 UTC --- Further reduced test case: type :: mpdata_t class(bcd_t), pointer :: bcx, bcy end type type(mpdata_t) :: this call this%bcx%fill_halos() end
[Bug tree-optimization/56003] New: SCEV should thread flags ^= 0x80000000 as an addition to discover an IV var.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56003
Bug #: 56003
Summary: SCEV should thread flags ^= 0x8000 as an addition
to discover an IV var.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org
In the following testcase we fail to work out that the loop is not really
iterating after unswitching otherwise.
void my_waitpid (int flags, int wnohang)
{
while (1)
{
if (flags 0x8000)
{
if (wnohang)
break;
if (debug_threads)
__builtin_puts (blocking\n);
sigsuspend ();
}
flags ^= 0x8000;
}
}
[Bug tree-optimization/54767] [4.7/4.8 Regression] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 13:57:53 UTC --- Author: rguenth Date: Wed Jan 16 13:57:48 2013 New Revision: 195238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195238 Log: 2013-01-16 Richard Biener rguent...@suse.de PR tree-optimization/54767 PR tree-optimization/53465 * tree-vrp.c (vrp_meet_1): Revert original fix for PR53465. (vrp_visit_phi_node): For PHI arguments coming via backedges drop all symbolical range information. (execute_vrp): Compute backedges. * gfortran.fortran-torture/execute/pr54767.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr54767.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/53465] [4.7/4.8 Regression] wrong code with -O1 -ftree-vrp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 13:57:54 UTC --- Author: rguenth Date: Wed Jan 16 13:57:48 2013 New Revision: 195238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195238 Log: 2013-01-16 Richard Biener rguent...@suse.de PR tree-optimization/54767 PR tree-optimization/53465 * tree-vrp.c (vrp_meet_1): Revert original fix for PR53465. (vrp_visit_phi_node): For PHI arguments coming via backedges drop all symbolical range information. (execute_vrp): Compute backedges. * gfortran.fortran-torture/execute/pr54767.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr54767.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/55964] [4.7/4.8 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 14:07:03 UTC --- Author: rguenth Date: Wed Jan 16 14:06:58 2013 New Revision: 195239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195239 Log: 2013-01-16 Richard Biener rguent...@suse.de PR tree-optimization/55964 * tree-flow.h (rename_variables_in_loop): Remove. (rename_variables_in_bb): Likewise. * tree-loop-distribution.c (update_phis_for_loop_copy): Remove. (copy_loop_before): Adjust and delete update-ssa status. * tree-vect-loop-manip.c (rename_variables_in_bb): Make static. (rename_variables_in_bb): Likewise. Properly walk over predecessors. (rename_variables_in_loop): Remove. (slpeel_update_phis_for_duplicate_loop): Likewise. (slpeel_tree_duplicate_loop_to_edge_cfg): Handle nested loops, use available cfg machinery instead of duplicating it. Update PHI nodes and perform poor-mans SSA update here. (slpeel_tree_peel_loop_to_edge): Adjust. * gcc.dg/torture/pr55964.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55964.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-loop-distribution.c trunk/gcc/tree-vect-loop-manip.c
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Comment #31 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16
14:20:46 UTC ---
Well, after early optimizations we get:
int main() ()
{
struct Foo x;
void Foo::T392 (const struct Foo *) * iftmp.0;
long int _3;
long int _4;
int (*__vtbl_ptr_type) () * _5;
long int _6;
sizetype _7;
int (*__vtbl_ptr_type) () * _8;
bb 2:
_3 = (long int) Bar;
_4 = _3 1;
if (_4 == 0)
goto bb 4;
else
goto bb 3;
bb 3:
_5 = MEM[(int (*__vtbl_ptr_type) () * *)x];
that is only later, at ccp2 times turned int
int main() ()
{
struct Foo x;
long int _3;
bb 2:
_3 = (long int) Bar;
Foo::Bar (x);
x ={v} {CLOBBER};
return 0;
}
ccp1 s not able to do this because it still sees:
int main() ()
{
struct
{
void Foo::T392 (const struct Foo *) * __pfn;
long int __delta;
} y;
struct Foo x;
void Foo::T392 (const struct Foo *) * iftmp.0;
void Foo::T392 (const struct Foo *) * _5;
long int _6;
long int _7;
long int _9;
sizetype _10;
struct Foo * _11;
int (*__vtbl_ptr_type) () * _12;
void Foo::T392 (const struct Foo *) * _13;
long int _14;
long int _15;
sizetype _16;
int (*__vtbl_ptr_type) () * _17;
long int _19;
sizetype _20;
const struct Foo * _21;
bb 2:
y.__pfn = Bar;
y.__delta = 0;
_5 = y.__pfn;
_6 = (long int) _5;
_7 = _6 1;
if (_7 == 0)
goto bb 3;
else
goto bb 4;
This is fixed by SRA to:
bb 2:
y$__pfn_4 = Bar;
y$__delta_3 = 0;
_5 = y$__pfn_4;
_6 = (long int) _5;
_7 = _6 1;
if (_7 == 0)
goto bb 3;
else
goto bb 4;
bb 3:
iftmp.0_8 = y$__pfn_4;
Richi, is there chance for subsequent FRE to catch this?
[Bug tree-optimization/55964] [4.7 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression]|[4.7 Regression] |Segmentation fault with -O |Segmentation fault with -O |-ftree-loop-distribution|-ftree-loop-distribution |-funswitch-loops|-funswitch-loops --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 14:22:49 UTC --- Fixed for 4.8+ so far.
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|jamborm at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #32 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 14:49:31 UTC --- Created attachment 29181 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29181 patch
[Bug c++/56004] New: Possible bug with decltype and access modifer order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004
Bug #: 56004
Summary: Possible bug with decltype and access modifer order
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.irv...@maidsafe.net
Please see this stackoverflow question for an overview.
http://stackoverflow.com/questions/14188535/clang-access-modifier-order-and-decltype
The issue seems to be that the private members are not visible at compilation
to the decltype call. This is a minimum example (from the question). (I am the
questioner in this case). This also seems to appear as a 'bug' in gcc but not
msvc (12). I am not 100% convinced but cannot find in the standard why this
will not work. I hope this helps.
#include future
#include iostream
#include thread
#include vector
template class T T self(T t) { return t; }
templatetypename T struct Dependent { };
templatetypename T
class Synchronised : DependentT{
public:
explicit Synchronised(T t = T()) : t_(t) {}
templatetypename Functor
auto operator()(Functor functor) const -decltype(functor(self(*this).t_)) {
//auto operator()(Functor functor) const -decltype(functor(this-t_)) {
std::lock_guardstd::mutex lock(mutex_);
return functor(t_);
}
private:
mutable T t_;
mutable std::mutex mutex_;
};
int main() {
Synchronisedstd::string sync_string(Start\n);
std::vectorstd::futurevoid futures;
}
[Bug rtl-optimization/55547] [4.8 Regression] Alias analysis does not handle AND addresses correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 15:19:47 UTC --- Unfortunately the fix caused some guality regressions, on x86_64 -m32 +FAIL: gcc.dg/guality/drap.c -O1 line 21 a == 5 +FAIL: gcc.dg/guality/drap.c -O1 line 22 b == 6 up to -Os, and +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg7 == 30 (up to -Os), +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg7 == 30 (up to -Os), +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg7 == 30 (up to -Os) and finally +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg7 == 30 (up to -Os), and similarly for x86_64 -m64 (fewer 36728-*.c regressions, but still some and all drap.c regressions).
[Bug tree-optimization/54767] [4.7 Regression] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] Incorrect |Incorrect code generated|code generated with -O2 |with -O2 -fcheck=bounds |-fcheck=bounds Known to fail|4.8.0 | --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16 15:23:06 UTC --- Fixed on trunk sofar.
[Bug bootstrap/56001] [4.7 Regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.7.3 Summary|[4.7.3 regression] |[4.7 Regression] relocation |relocation truncated to |truncated to fit: |fit: R_PPC_REL24 breaks |R_PPC_REL24 breaks |bootstrap on|bootstrap on |powerpc64-linux |powerpc64-linux
[Bug target/56005] New: [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 Bug #: 56005 Summary: [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: hjl.to...@gmail.com, vmaka...@gcc.gnu.org Target: x86_64-*-* i686-*-* The test gcc.target/i386/pr45352.c has started to fail (see http://gcc.gnu.org/ml/gcc-regression/2013-01/msg00148.html) between revisions 195208 (OK) and 195212 (ICE /opt/gcc/work/gcc/testsuite/gcc.target/i386/pr45352.c: In function 'foo': /opt/gcc/work/gcc/testsuite/gcc.target/i386/pr45352.c:25:1: internal compiler error: in add_insn_mem_dependence, at sched-deps.c:1717 } The options -O3 -march=amdfam10 -fselective-scheduling2 are enough to trigger the ICE. It is likely due to revision 195211 Author:vmakarov Date:Tue Jan 15 16:47:36 2013 UTC (22 hours, 42 minutes ago) Changed paths:4 Log Message: 2013-01-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55153 * sched-deps.c (sched_analyze_2): Add pending reads for prefetch. 2013-01-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55153 * gcc.dg/pr55153.c: New.
[Bug target/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 15:40:46 UTC --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153#c4 Let's close PR55153 as fixed and keep this PR to track the regression the fix caused.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 15:41:46 UTC --- Fixed, the regression caused by the fix is tracked now as PR56005.
[Bug rtl-optimization/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target|x86_64-*-* i686-*-* |x86_64-*-* i686-*-* ||ia64-*-* Component|target |rtl-optimization --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 15:53:34 UTC --- Likely target independent, also breaks gcc.dg/pr45352-1.c on ia64 with the same ICE.
[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 --- Comment #24 from Jason Merrill jason at gcc dot gnu.org 2013-01-16 15:53:28 UTC --- (In reply to comment #23) Merging of target attribute is what gcc/g++ did though, the function would get then both target attributes (seems later decl's target wins), and the first target attribute in DECL_ATTRIBUTES would be the one to be used. This seems like broken behavior that we don't need to preserve, in which case my suggestion in comment #8 could work.
[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
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
16:02:35 UTC ---
The actual merging of target attribute isn't that important, what would be more
important is that other attributes are merged together in that case and the
decls treated as the same thing.
Anyway, with target(any) attribute, what would happen for
void foo () __attribute__((target (avx)));
void foo () __attribute__((target (any)));
void foo () {}
Is the definition any, something else?
[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 --- Comment #26 from richard.guenther at gmail dot com richard.guenther at gmail dot com 2013-01-16 16:05:01 UTC --- On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:02:35 UTC --- The actual merging of target attribute isn't that important, what would be more important is that other attributes are merged together in that case and the decls treated as the same thing. Anyway, with target(any) attribute, what would happen for void foo () __attribute__((target (avx))); void foo () __attribute__((target (any))); IMHO the re-declaration with a different target attribute should be an error. A proper forward declaration for a function with MV applied shouldn't have any target attribute.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:05:42 UTC --- Author: jakub Date: Wed Jan 16 16:05:27 2013 New Revision: 195241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195241 Log: PR fortran/52865 * trans-stmt.c (gfc_trans_do): Put countm1-- before conditional and use value of countm1 before the decrement in the condition. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c
[Bug c++/56004] Possible bug with decltype and access modifer order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16 16:19:33 UTC --- As was explained on stackoverflow, this has nothing t odo with access modifiers, as you can easily demonstrate by making everything public. _t has not been declared at the point where you try to use it, so the name is not in scope. What are you claiming is a bug?
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-16 16:19:42 UTC --- Author: burnus Date: Wed Jan 16 16:19:32 2013 New Revision: 195242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195242 Log: gcc/fortran/ 2013-01-16 Jakub Jelinek ja...@redhat.com Tobias Burnus bur...@net-b.de PR driver/55884 * lang.opt (fintrinsic-modules-path): Don't accept Joined. (fintrinsic-modules-path=): New. * options.c (gfc_handle_option, gfc_get_option_string, gfc_get_option_string): Handle the latter. libgomp/ 2013-01-16 Jakub Jelinek ja...@redhat.com Tobias Burnus bur...@net-b.de PR driver/55884 * testsuite/libgomp.fortran/fortran.exp: Use -fintrinsic-modules-path= instead of -fintrinsic-modules-path. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.fortran/fortran.exp
[Bug middle-end/56000] [4.8 Regression] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 --- Comment #4 from dave.anglin at bell dot net 2013-01-16 16:24:47 UTC --- On 1/16/2013 3:08 AM, sch...@linux-m68k.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 08:08:33 UTC --- Does this help? http://sourceware.org/ml/libffi-discuss/2012/msg00279.html Yes, the two patches fix the libffi fails.
[Bug debug/56006] New: [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 Bug #: 56006 Summary: [4.8 Regression] Many guality testsuite failures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 195227 gave FAIL: gcc.dg/guality/drap.c -O1 line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O1 line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O2 line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O2 line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O3 -fomit-frame-pointer line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O3 -fomit-frame-pointer line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O3 -g line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O3 -g line 22 b == 6 FAIL: gcc.dg/guality/drap.c -Os line 21 a == 5 FAIL: gcc.dg/guality/drap.c -Os line 22 b == 6 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg7
[Bug rtl-optimization/55547] [4.8 Regression] Alias analysis does not handle AND addresses correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:31:10 UTC --- Ah, hjl opened PR56006 to track #c11.
[Bug debug/56006] [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:33:47 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=195227 See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547#c11
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:35:30 UTC --- Assuming fixed.
[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55995 --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2013-01-16 16:38:24 UTC --- Interesting, it causes the compiler to segfault on both arm-none-eabi and powerpc-none-eabi: /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/aligned-section-anchors-nest-1.c:31:1: internal compiler error: Segmentation fault^M 0x8605072 crash_signal^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/toplev.c:332^M 0x82f5523 contains_struct_check^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/tree.h:3782^M 0x82f5523 dump_loc^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/dumpfile.c:266^M 0x82f56a2 dump_printf_loc(int, unsigned int, char const*, ...)^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/dumpfile.c:370^M 0x882ffc7 increase_alignment^M /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/gcc/tree-vectorizer.c:238^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See http://gcc.gnu.org/bugs.html for instructions.^M FAIL: gcc.dg/vect/aligned-section-anchors-nest-1.c (internal compiler error) FAIL: gcc.dg/vect/aligned-section-anchors-nest-1.c (test for excess errors)
[Bug rtl-optimization/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org 2013-01-16 16:39:21 UTC --- (In reply to comment #1) See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153#c4 Let's close PR55153 as fixed and keep this PR to track the regression the fix caused. Sorry, I forgot about selective scheduler which uses deps-readonly mechanism for its own purposes. The fix is really easy. It is just adding an if-cond when prefetch is added. if (!deps-readonly) add_insn_mem_dependence (deps, true, insn, gen_rtx_MEM (Pmode, XEXP (PATTERN (insn), 0))); I'll submit the patch today.
[Bug target/27855] [4.5/4.7/4.8 regression] reassociation causes the RA to be confused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|i686-pc-linux-gnu |i686-pc-linux-gnu, ||x86_64-pc-linux-gnu Status|WAITING |NEW --- Comment #44 from Uros Bizjak ubizjak at gmail dot com 2013-01-16 16:40:36 UTC --- Still the same old story... Target: x86_64-unknown-linux-gnu gcc version 4.8.0 20130116 (experimental) [trunk revision 195240] (GCC) corei7 SNB: -DREPS=1 -msse3 -O2 -ffast-math ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1 1.636 2640.99 -DREPS=1 -msse3 -O2 -ffast-math -fno-tree-reassoc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1 1.218 3547.34 -DREPS=1 -msse3 -O2 -ffast-math -ftree-vectorize ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1 1.654 2612.25 -DREPS=1 -msse3 -O2 -ffast-math -ftree-vectorize -fno-tree-reassoc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1 1.555 2778.56 The testcase is at http://www.cs.utsa.edu/~whaley/mmbench4.tar.gz Reconfirmed with 4.8.0.
[Bug c++/56004] Possible bug with decltype and access modifer order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004 --- Comment #2 from David Irvine david.irvine at maidsafe dot net 2013-01-16 16:40:43 UTC --- (In reply to comment #1) As was explained on stackoverflow, this has nothing t odo with access modifiers, as you can easily demonstrate by making everything public. _t has not been declared at the point where you try to use it, so the name is not in scope. What are you claiming is a bug? It might be my confusion but is that not altering modifiers ? I am not sure why the initialisation list does not make the private member available (at least declared). On the clang mailing list this was hinted at as well, but I am not sure that this is a case where private: before public: does work and not vice versa although as I said it is very likely a c++ issue that I have just not come across yet (although I will remember as usual). Can you confirm why the _t is not available or declared when it is in the initialisation list ? does the decltype require earlier visibility than the ctr ? Sorry if this is indeed not a bug but a misunderstanding.
[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55995 Sharad Singhai singhai at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED AssignedTo|unassigned at gcc dot |singhai at gcc dot gnu.org |gnu.org | --- Comment #3 from Sharad Singhai singhai at gcc dot gnu.org 2013-01-16 17:03:26 UTC --- Hmm, it looks like it is trying to output a source location where none exists. This is clearly a bug. I would look at it. Thanks, Sharad
[Bug fortran/56007] New: Remarkably bad error message with DO array=1,2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007
Bug #: 56007
Summary: Remarkably bad error message with DO array=1,2
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@gcc.gnu.org
$ cat t3.f90
real iw1(90)
do iw1=1,2
end do
END
$ gfortran t3.f90
t3.f90:2.6:
do iw1=1,2
1
Error: Loop variable at (1) cannot be a sub-component
t3.f90:3.3:
end do
1
Error: Expecting END PROGRAM statement at (1)
$
match.c has the following check in gfc_match_iterator:
if (var-ref != NULL)
{
gfc_error (Loop variable at %C cannot be a sub-component);
goto cleanup;
}
This assumes that all ref's are component ref's. I verified that the bug
happens with 4.7.2, but looking at the code I would assume that this also
happens with the trunk.
This error message was mildly confusing, as I ran into this in a Fortran 77
codebase where there are no components.
[Bug fortran/56007] Remarkably bad error message with DO array=1,2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-16 17:11:48 UTC --- I get the same error with gcc version 4.4.6 and trunk.
[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
--- Comment #27 from Sriraman Tallam tmsriram at google dot com 2013-01-16
17:20:28 UTC ---
(In reply to comment #26)
On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
16:02:35 UTC ---
The actual merging of target attribute isn't that important, what would be
more
important is that other attributes are merged together in that case and the
decls treated as the same thing.
Anyway, with target(any) attribute, what would happen for
void foo () __attribute__((target (avx)));
void foo () __attribute__((target (any)));
IMHO the re-declaration with a different target attribute should be an error.
A proper forward declaration for a function with MV applied shouldn't have
any target attribute.
Richard, I am not sure I fully understand what you mean. In this example, with
your approach:
test.cc
--
int foo (); // forward declaration
int
main ()
{
foo ();
}
int foo ()
{
...
}
int foo () __attribute__ (sse2)
{
}
How can you tell if the call to foo is multi-versioned or not?
[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
--- Comment #28 from Sriraman Tallam tmsriram at google dot com 2013-01-16
17:25:21 UTC ---
(In reply to comment #25)
The actual merging of target attribute isn't that important, what would be
more
important is that other attributes are merged together in that case and the
decls treated as the same thing.
Anyway, with target(any) attribute, what would happen for
void foo () __attribute__((target (avx)));
void foo () __attribute__((target (any)));
void foo () {}
Is the definition any, something else?
Further, if we have these three declarations in this order:
void foo () __attribute__((target (avx)));
void foo () __attribute__((target (sse4.2)));
void foo () __attribute__((target (any)));
This seems to mean that we want foo to be multi-versioned. However, when the
front-end is processing the second declaration, how would it decide between
merging or not without seeing the third? IMHO, I think each declaration should
be self-contained like Jakub proposed, and by just looking at the declaration
we should be able to tell if the target attribute affects the signature or not.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #171 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16 17:25:04 UTC --- Created attachment 29182 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29182 Patch to compress line info This patch removes column information from LTO (so we lose carret diagnostics in warnings/errors output at LTO time that seems resonable thing to do) and avoid entering duplicate locators into the linemap. The patch reduces linemap usage from 23% to 5% of GGC memory saving 1-2GB on Mozilla. (also reducing LTO file size).
[Bug c++/56004] Possible bug with decltype and access modifer order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
17:30:55 UTC ---
(In reply to comment #2)
(In reply to comment #1)
As was explained on stackoverflow, this has nothing t odo with access
modifiers, as you can easily demonstrate by making everything public.
_t has not been declared at the point where you try to use it, so the name
is
not in scope. What are you claiming is a bug?
It might be my confusion but is that not altering modifiers ?
I don't know what you mean. Change private to public, the code fails in
exactly the same way, therefore the problem is nothing to do with
accessibility.
I am not sure why
the initialisation list does not make the private member available (at least
declared).
The init list is a *use* of the member, not a declaration. Ctor init lists are
part of the function body, so only parsed once the class is complete. You
could also use t_ in the constructor body, that doesn't mean it's in scope
outside that function body.
On the clang mailing list this was hinted at as well, but I am not sure that
this is a case where private: before public: does work and not vice versa
although as I said it is very likely a c++ issue that I have just not come
across yet (although I will remember as usual).
It has nothing to do with private vs public!
Can you confirm why the _t is not available or declared when it is in the
initialisation list ? does the decltype require earlier visibility than the
ctr
?
See above. The init list is part of a function body. Function bodies are
processed when the class is complete, as though they were defined after the
class. Look:
struct A {
A() : i(0) { ++i; } // i is in scope
decltype(i) get(); // error, i not in scope
int i; // i declared here
decltype(i) get2(); // OK, i has been declared
};
This is equivalent to:
struct A {
A();
decltype(i) get(); // error, i not in scope
int i; // i declared here
decltype(i) get2(); // OK, i has been declared
};
A::A() : i(0) { ++i; } // OK, class is complete, i in scope.
In the first example the constructor can use 'i' in the init list and the ctor
body, that's OK. You can *not* use 'i' in a function signature before it's
declared. get() is an error, get2() is OK.
[Bug fortran/56007] Remarkably bad error message with DO array=1,2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf anlauf at gmx dot de 2013-01-16 17:40:00 UTC --- (In reply to comment #1) I get the same error with gcc version 4.4.6 and trunk. It dates back to g95, so no regression.
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 --- Comment #6 from Fanael fanael4 at gmail dot com 2013-01-16 18:15:25 UTC --- Oh right. Works for me too. I should've tested it more thoroughly first. Sorry for bothering you guys.
[Bug c++/56004] Possible bug with decltype and access modifer order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004
--- Comment #4 from David Irvine david.irvine at maidsafe dot net 2013-01-16
18:16:58 UTC ---
I see
In my case in a simpler version than posted
this compiles fine
template class T
class Synchronised {
public:
Synchronised(T t = T{}) : t_{t} {}
template typename F
auto operator()(F f) const - decltype(f(t_)) {
std::lock_guardstd::mutex lock{mutex_};
return f(t_);
}
private: // place this before public: and this object compiles
mutable T t_;
mutable std::mutex mutex_;
};
Fails and swapping private to be declared before public works ! as below
This will not compile
template class T
class Synchronised {
private: // place this before public: and this object compiles
mutable T t_;
mutable std::mutex mutex_;
public:
Synchronised(T t = T{}) : t_{t} {}
template typename F
auto operator()(F f) const - decltype(f(t_)) {
std::lock_guardstd::mutex lock{mutex_};
return f(t_);
}
};
I think you are saying the same thing but this is what I mean by private coming
before public (changing accessors or their order). I think it is the only
situation I have encountered this.
[Bug c++/56004] Possible bug with decltype and access modifer order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
18:25:52 UTC ---
(In reply to comment #4)
I think you are saying the same thing but this is what I mean by private
coming
before public (changing accessors or their order). I think it is the only
situation I have encountered this.
You still seem to have some weird mental model about public and private.
This has nothing to do with public or private
In your example t_ happens to be private, but that is completely irrelevant.
It only matters if it is declared before it is used. It can be declared public,
or declared private, or protected, it's irrelevant.
This doesn't work either, even though everything is public:
template class T
class Synchronised {
public:
Synchronised(T t = T{}) : t_{t} {}
template typename F
auto operator()(F f) const - decltype(f(t_)) {
return f(t_);
}
public:
mutable T t_;
};
Closing as not a bug.
[Bug rtl-optimization/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org 2013-01-16 18:28:04 UTC --- Author: vmakarov Date: Wed Jan 16 18:27:58 2013 New Revision: 195247 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195247 Log: 2013-01-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/56005 * sched-deps.c (sched_analyze_2): Check deps-readonly for adding pending reads for prefetch. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41557 Andris Pavenis andris.pavenis at iki dot fi changed: What|Removed |Added CC||andris.pavenis at iki dot ||fi --- Comment #2 from Andris Pavenis andris.pavenis at iki dot fi 2013-01-16 18:33:01 UTC --- I do not remeber that I ever have seen this problem. It looks that in the first case (message from 2009-10-03) my build for DJGPP v2.03 has been used. For that case I would suggest to remove command line option -fpch-preprocess. I initially had problem using PCH for DJGPP and after that I always used --disable-pch. About second message: Are You using unmodified gcc sources on Ubuntu? All builds of GCC for DJGPP has additional changes to the original sources (I know it would be nice to have changes submitted). For ubunto one could try to use alien to convert my RPM packages available from ftp://ftp.delorie.com/pub/djgpp/rpms (or my latest test build at http://ap1.pp.fi/djgpp/gcc/test/4.8.0-20130111/) to .deb (I'm specially performing RPM builds to reduce possible dependence on system as much as possible so it is rather likely that packages should work on Ubuntu after converted to .deb)
[Bug rtl-optimization/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 18:36:47 UTC --- Fixed.
[Bug target/55433] [4.8 Regression][LRA] ICE on excessive reloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org 2013-01-16 18:44:14 UTC --- (In reply to comment #3) This bug is still present and biting me as of r195176. Is there anything I can do to help make some progress on this? I managed to reproduce it on Linux and started to work on it. I hope it will be fixed at the end of this week.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2013-01-16 18:50:06 UTC --- Author: janis Date: Wed Jan 16 18:49:57 2013 New Revision: 195249 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195249 Log: PR testsuite/54622 * lib/target-supports.exp (check_effective_target_vect_perm_byte, check_effective_target_vect_perm_short, check_effective_target_vect_widen_mult_qi_to_hi_pattern, check_effective_target_vect64): Return 0 for big-endian ARM. (check_effective_target_vect_widen_sum_qi_to_hi): Return 1 for ARM. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 --- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2013-01-16 18:52:56 UTC --- Author: janis Date: Wed Jan 16 18:52:51 2013 New Revision: 195250 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195250 Log: PR testsuite/55994 * gcc.c-torture/execute/builtins/builtins.exp: Add -Wl,--allow-multiple-definition for eabi and elf targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41557 --- Comment #3 from Andris Pavenis andris.pavenis at iki dot fi 2013-01-16 18:57:42 UTC --- I also verified that I have already mostly applied a patch sent to gcc-bugs recently (http://gcc.gnu.org/ml/gcc-bugs/2013-01/msg01142.html) already for my builds, except of course one typo in the patch: +#define INT_FAST16_TYPE int I do not remeber any more why it was done. It would also have been be faster to report problem also to DJGPP mailing list.
[Bug bootstrap/56001] [4.7 Regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 19:04:34 UTC --- Is your toolchain using BSS PLT?
[Bug debug/56006] [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 19:06:09 UTC --- The second patch in http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00822.html (which is waiting for Uros' bootstrap/regtest on alpha AFAIK) seems to fix these regressions.
[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 #9 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 19:12:01 UTC --- -FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==9876== AddressSanitizer CHECK failed: ../../../../../gcc/libsanitizer/asan/asan_thread.cc:74 ((AddrIsInMem(stack_bottom_))) != (0) (0x0, 0x0) +FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ASAN:SIGSEGV = -==9876== ERROR: AddressSanitizer: unknown-crash on address 0x3fffc266bcc0 at pc 0x3fff8c011b1c bp 0x3fffc266a7f0 sp 0x3fffc266a860 -WRITE of size 1 at 0x3fffc266bcc0 thread T0 -==9876== AddressSanitizer: while reporting a bug found another one.Ignoring. +==15643== ERROR: AddressSanitizer: SEGV on unknown address 0x020002002471 (pc 0x1a4c sp 0x3fffe508dba0 bp 0x3fffe508dba0 T0) +AddressSanitizer can not provide additional info. +#0 0x1a48 in main /home/andreas/src/gcc/gcc/gcc/testsuite/c-c++-common/asan/global-overflow-1.c:15 +Stats: 0M malloced (0M for red zones) by 0 calls +Stats: 0M realloced by 0 calls +Stats: 0M freed by 0 calls +Stats: 0M really freed by 0 calls +Stats: 0M (0M-0M) mmaped; 0 maps, 0 unmaps + mmaps by size class: + mallocs by size class: + frees by size class: + rfrees by size class: +Stats: malloc large: 0 small slow: 0 +Stats: StackDepot: 0 ids; 0M mapped +==15643== ABORTING === gcc Summary for unix/-m64 === -# of expected passes210 -# of unexpected failures91 +# of expected passes214 +# of unexpected failures87 # of unsupported tests17
