[Bug target/55718] [4.8 Regression] ICE in gen_reg_rtx, at emit-rtl.c:866
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55718 --- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-01-10 08:15:23 UTC --- Author: krebbel Date: Thu Jan 10 08:15:07 2013 New Revision: 195078 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195078 Log: 2013-01-10 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/55718 * config/s390/s390.c (s390_symref_operand_p) (s390_loadrelative_operand_p): Merge the two functions. (s390_check_qrst_address, print_operand_address): Add parameters to s390_loadrelative_operand_p invokation. (s390_check_symref_alignment): Use s390_loadrelative_operand_p. (s390_reload_larl_operand, s390_secondary_reload): Use s390_loadrelative_operand_p instead of s390_symref_operand_p. (legitimize_pic_address): Handle @GOTENT and @PLT + addend. Added: trunk/gcc/testsuite/gcc.target/s390/pr55718.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
[Bug target/55718] [4.8 Regression] ICE in gen_reg_rtx, at emit-rtl.c:866
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55718 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-01-10 08:21:30 UTC --- Fixed per commit above.
[Bug fortran/55905] [OOP] [F008] ICE for polymorphic dummy argument with an allocatable coarray component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55905 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-10 CC||janus at gcc dot gnu.org Summary|ICE for polymorphic dummy |[OOP] [F008] ICE for |argument with an|polymorphic dummy argument |allocatable coarray |with an allocatable coarray |component |component Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2013-01-10 08:30:35 UTC --- I can confirm it with: gcc version 4.8.0 20130105 (experimental) [trunk revision 194927] (GCC) I get the following backtrace: 0xb0d96d crash_signal /home/jweil/gcc48/trunk/gcc/toplev.c:334 0x616b10 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) /home/jweil/gcc48/trunk/gcc/tree.h:3793 0x64366a duplicate_allocatable /home/jweil/gcc48/trunk/gcc/fortran/trans-array.c:7334 0x6439cf gfc_duplicate_allocatable(tree_node*, tree_node*, tree_node*, int) /home/jweil/gcc48/trunk/gcc/fortran/trans-array.c:7396 0x644d00 structure_alloc_comps /home/jweil/gcc48/trunk/gcc/fortran/trans-array.c:7738 0x644ee2 gfc_copy_alloc_comp(gfc_symbol*, tree_node*, tree_node*, int) /home/jweil/gcc48/trunk/gcc/fortran/trans-array.c:7790 0x6741e9 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool, bool) /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6841 0x676cf7 gfc_trans_assignment_1 /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:7757 0x677342 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool) /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:7915 0x677372 gfc_trans_init_assign(gfc_code*) /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:7921 4.7 gives: c0.f90:7.19: class(foo) this 1 Error: Component '_def_init' at (1) with coarray component shall be a nonpointer, nonallocatable scalar c0.f90:7.19: class(foo) this 1 Error: Variable 'dst' at (1) is INTENT(OUT) and can thus not be an allocatable coarray or have coarray components c0.f90:7.19: class(foo) this 1 Error: Component '_def_init' at (1) with coarray component shall be a nonpointer, nonallocatable scalar
[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45076 --- Comment #3 from janus at gcc dot gnu.org 2013-01-10 08:43:09 UTC --- (In reply to comment #2) With 4.7 I get instead of an ICE just the warning: Same with curent 4.8 trunk: dynamic_dispatch_6.f03:66:0: note: Skipping target new_periodic_5th_order with mismatching types for icall u = field_creator%create()
[Bug fortran/46952] [OOP] Spurious recursive call error with type bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952 --- Comment #3 from janus at gcc dot gnu.org 2013-01-10 08:50:51 UTC --- Further reducing the test case: module m type, abstract :: t contains procedure(inter), pass, deferred :: foo end type contains subroutine inter(this) class(t) :: this call this%foo() end subroutine inter end module m
[Bug middle-end/55921] [4.6/4.7/4.8 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 09:25:27 UTC --- Author: jakub Date: Thu Jan 10 09:25:12 2013 New Revision: 195080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195080 Log: PR tree-optimization/55921 * tree-complex.c (expand_complex_asm): New function. (expand_complex_operations_1): Call it for GIMPLE_ASM. * gcc.c-torture/compile/pr55921.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55921.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-complex.c
[Bug middle-end/55921] [4.6/4.7 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Crash |Crash in verify_ssa for asm |in verify_ssa for asm to |to side-steps complex |side-steps complex |pessimization |pessimization --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 09:31:53 UTC --- Fixed for 4.8+ so far.
[Bug web/55933] New: Missing attachment download link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55933 Bug #: 55933 Summary: Missing attachment download link Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org There should be a download link for every attachment directly in the comment. The best option would be to disable the useless patch viewer.
[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 --- Comment #13 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10 09:48:41 UTC --- I have bootstrapped and tested the patch from comment #11 on sparc64-linux (gcc63 on compile farm) and there were no issues (actually g++.old-deja/g++.law/operators23.C failed because ld returned 2 but that is almost certainly noise).
[Bug inline-asm/55934] New: [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
Bug #: 55934
Summary: [4.8 Regression] LRA inline asm error recovery
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
_Complex float
foo (void)
{
_Complex float x;
__asm ( : =x (x)); /* { dg-error impossible register constraint } */
return x;
}
on x86_64 used to ICE since the introduction of LRA (before that it has been
just issuing error on the asm). Starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=193871
this got fixed, but already (guess) starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=193901
it issues both the expected error and also ICE after it.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ra Priority|P3 |P2 CC||vmakarov at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug fortran/55932] DDT's default structure constructor does not work with having allocatable member variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-10 CC||bur...@net-b.de Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10 10:38:05 UTC --- This is a bug with allocatable scalars (the code is rejected with -std=f95). The code work as expected if I replace 'REAL, ALLOCATABLE :: a' with 'REAL, ALLOCATABLE :: a(:)' and 'a=1.0' with 'a=[1.0]'. AFAIK all the allocatable scalar bugs have not yet been fixed and this PR may be a duplicate of an existing one. Workaround: don't use allocatable scalars if you can.
[Bug web/55933] Missing attachment download link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55933 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-10 10:47:46 UTC --- (In reply to comment #0) The best option would be to disable the useless patch viewer. This gets my vote.
[Bug tree-optimization/55923] tree passes pessimize complex load/store operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55923 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-10 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 11:05:34 UTC --- Confirmed.
[Bug middle-end/55929] lra-constraints-ICE while xg++ compile libitm with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-10 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2013-01-10 11:10:39 UTC --- (In reply to comment #1) /sandbox/gcc-git/libitm/beginend.cc:346:1: error: unable to generate reloads Reload would not be able handle this either as it is jump_insn. How annoying. In this case, we have to expand with a hard-reg temporary (%eax). I will prepare a patch for this.
[Bug tree-optimization/32306] [4.6/4.7/4.8 Regression] redundant || not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 11:26:09 UTC --- It generally depends on the branch cost, e.g. out of #c19 testcase on x86_64 we generate: D.1729 = b1 != 0; D.1730 = b2 != 0; D.1731 = D.1729 D.1730; if (D.1731 != 0) goto D.1732; else goto D.1727; D.1732: D.1733 = b3 != 0; D.1734 = b4 != 0; D.1735 = D.1733 D.1734; if (D.1735 != 0) goto D.1736; else goto D.1727; D.1736: etc., but on other targets it could have just one comparison per conditional jump, or on the other side 4. While the tests don't have side-effects, turning too many s into s wouldn't result in very good code, though of course would make it easier to perform some optimizations. Anyway, you can write it in the source as a series of ifs: array[0] = 1; if (!b1) array[0] = 0; else if (!b2) array[0] = 0; else if (!b3) array[0] = 0; ... and we wouldn't be able to optimize it anyway.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #34 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-01-10 11:26:23 UTC --- (In reply to comment #33) Can you sent it to review? You can also mention that it fixes issue 40362. I had a closer look at PR40362. Actually, I don't think this patch fixes PR40362, as it only addresses the config/linux/ variant and not the config/posix/ (which is what the --disable-linux-futex choice in PR40362 follows). I would be happy if you could sent the patch, I wouldn't be able to explain the rationale for the changes, I just followed your instructions in comment #26. You'll notice that the changelog I prepared also puts your name, I think this is appropriate.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #24 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 11:29:16 UTC --- Created attachment 29139 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29139 patch to verify locations as LTO expects them This verifies that all stmts locations (missing expr locations) have a BLOCK that is in the functions BLOCK tree (_not_ counting abstract origins, as LTO does not stream the abstract part of the BLOCK tree!). It fires on trivial inlining testcases which means that LTO will end up with the issue you are seeing. Ugh. Investigating.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #35 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 11:37:08 UTC --- For config/posix it is not that easy, because you can't assume that atomics are available. You'd need to guard it with #ifdef HAVE_SYNC_BUILTINS and do something else (nothing?) otherwise. Those targets don't support tsan anyway...
[Bug fortran/46952] [OOP] Spurious recursive call error with type bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
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 |
--- Comment #4 from janus at gcc dot gnu.org 2013-01-10 11:48:54 UTC ---
I think the following patch makes sense:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 194927)
+++ gcc/fortran/resolve.c(working copy)
@@ -3803,7 +3803,7 @@ resolve_call (gfc_code *c)
/* Subroutines without the RECURSIVE attribution are not allowed to
* call themselves. */
- if (csym is_illegal_recursion (csym, gfc_current_ns))
+ if (!c-expr1 csym is_illegal_recursion (csym, gfc_current_ns))
{
if (csym-attr.entry csym-ns-entries)
gfc_error (ENTRY '%s' at %L cannot be called recursively, as
This is the same workaround that we use in resolve_call for deferred TBPs with
abstract interfaces.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #29139|0 |1 is obsolete|| --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 12:15:41 UTC --- Created attachment 29140 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29140 updated patch with fixes Fix for virtual operands (shouldn't be relevant for LTO). My guess would still be IPA opts, so can you check if it triggers? I'm doing regular bootstrap / testing and will commit the virtuals fix independently.
[Bug web/32927] Online installation instructions only for mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2013-01-10 13:08:43 UTC --- This has caused quite a bit of confusion lately with people installing ISL instead of PPL for gcc-4.7.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #26 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 13:42:33 UTC --- Author: rguenth Date: Thu Jan 10 13:42:27 2013 New Revision: 195084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195084 Log: 2013-01-10 Richard Biener rguent...@suse.de PR bootstrap/55792 * tree-into-ssa.c (rewrite_add_phi_arguments): Do not set locations for virtual PHI arguments. (rewrite_update_phi_arguments): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-into-ssa.c
[Bug c/52381] asm goto output operands diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381 Timo Kreuzer timo.kreuzer at reactos dot org changed: What|Removed |Added CC||timo.kreuzer at reactos dot ||org --- Comment #3 from Timo Kreuzer timo.kreuzer at reactos dot org 2013-01-10 13:49:11 UTC --- I support this feature request. As an exmple I'd like to mention the x86 instruction cmpxchg. While GCC has 2 CAS builtins (__sync_bool_compare_and_swap and __sync_val_compare_and_swap) neither of these supports what the x86 cmpxchg instruction does, namely returning both a boolean value indicating success AND the previous value of the memory operand in case of failure. So here's the code that would handle this, if output operand was usable. try_again: // do something asm goto ( lock cmpxchg %%ecx, %[Destination] \t\n jnz %l[try_again] \t\n : =c(Exchange) // = does not work : [Destination]m(Destination), [Comparand]a(Comparand), [Exchange]c(Exchange) : memory : try_again ); Note that in this case the output is needed on the jump path.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #29140|0 |1 is obsolete|| --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 14:07:55 UTC --- Created attachment 29141 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29141 updated checker Also verify expressions. Bootstrapped ok, target libs building now, testing pending. I'll give it a LTO profiledbootstrap try as well ... if that's not it then the issue must be elsewhere :(
[Bug fortran/46952] [OOP] Spurious recursive call error with type bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
--- Comment #5 from janus at gcc dot gnu.org 2013-01-10 14:09:54 UTC ---
The following patch is equivalent in functionality to the one in comment 4, but
includes some minor cleanup (and regtests cleanly):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 194927)
+++ gcc/fortran/resolve.c(working copy)
@@ -3792,28 +3792,30 @@ resolve_call (gfc_code *c)
}
}
- /* If this ia a deferred TBP with an abstract interface
- (which may of course be referenced), c-expr1 will be set. */
- if (csym csym-attr.abstract !c-expr1)
+ /* If this ia a deferred TBP, c-expr1 will be set. */
+ if (!c-expr1 csym)
{
- gfc_error (ABSTRACT INTERFACE '%s' must not be referenced at %L,
- csym-name, c-loc);
- return FAILURE;
-}
+ if (csym-attr.abstract)
+{
+ gfc_error (ABSTRACT INTERFACE '%s' must not be referenced at %L,
+csym-name, c-loc);
+ return FAILURE;
+}
- /* Subroutines without the RECURSIVE attribution are not allowed to
- * call themselves. */
- if (csym is_illegal_recursion (csym, gfc_current_ns))
-{
- if (csym-attr.entry csym-ns-entries)
-gfc_error (ENTRY '%s' at %L cannot be called recursively, as
-subroutine '%s' is not RECURSIVE,
- csym-name, c-loc, csym-ns-entries-sym-name);
- else
-gfc_error (SUBROUTINE '%s' at %L cannot be called recursively, as it
-is not RECURSIVE, csym-name, c-loc);
+ /* Subroutines without the RECURSIVE attribution are not allowed to
+ call themselves. */
+ if (is_illegal_recursion (csym, gfc_current_ns))
+{
+ if (csym-attr.entry csym-ns-entries)
+gfc_error (ENTRY '%s' at %L cannot be called recursively,
+ as subroutine '%s' is not RECURSIVE,
+ csym-name, c-loc, csym-ns-entries-sym-name);
+ else
+gfc_error (SUBROUTINE '%s' at %L cannot be called recursively,
+ as it is not RECURSIVE, csym-name, c-loc);
- t = FAILURE;
+ t = FAILURE;
+}
}
/* Switch off assumed size checking and do this again for certain kinds
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 14:11:43 UTC --- Another possibility lies in DEBUG stmts which we do not consider at all ... (in the checker, that is).
[Bug c/52381] asm goto output operands diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2013-01-10 14:12:54 UTC --- Like __atomic_compare_exchange_n?
Re: [Bug tree-optimization/55927] New: FAIL: g++.dg/ipa/devirt-10.C -std=gnu++11 scan-ipa-dump-times inline Discovered a virtual call to a known target 1
This will be usual difference of virtual call representation in ia64. The .cp test is going fine? Honza
[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 --- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2013-01-10 14:33:48 UTC --- This will be usual difference of virtual call representation in ia64. The .cp test is going fine? Honza
[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 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-10 14:44:20 UTC --- Yes, it does.
[Bug fortran/47203] USE of module with same name as SUBROUTINE not reject, but also not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47203 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2013-01-10 14:58:43 UTC --- Fixed for 4.8.0
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
15:02:37 UTC ---
By unswitching on an exit test that exits to the enclosing loop we create
an unswitched loop that is now reached by what looks like an exit test
of the outer loop which is part of an irreducible region.
I'm not sure we can reliably detect all cases we need to manually mark
the entry edge for. So ... re-mark_irreducible_loops () after each
transform?
And cheaper checking by
Index: loop-unswitch.c
===
--- loop-unswitch.c (revision 195085)
+++ loop-unswitch.c (working copy)
@@ -145,12 +145,7 @@ unswitch_loops (void)
/* Go through inner loops (only original ones). */
FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
-{
- unswitch_single_loop (loop, NULL_RTX, 0);
-#ifdef ENABLE_CHECKING
- verify_loop_structure ();
-#endif
-}
+unswitch_single_loop (loop, NULL_RTX, 0);
iv_analysis_done ();
}
@@ -370,6 +365,10 @@ unswitch_single_loop (struct loop *loop,
nloop = unswitch_loop (loop, bbs[i], copy_rtx_if_shared (cond), cinsn);
gcc_assert (nloop);
+#ifdef ENABLE_CHECKING
+ verify_loop_structure ();
+#endif
+
/* Invoke itself on modified loops. */
unswitch_single_loop (nloop, rconds, num + 1);
unswitch_single_loop (loop, conds, num + 1);
[Bug fortran/47136] local identifier shall not be the same as a global identifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org 2013-01-10 15:03:04 UTC --- (In reply to comment #10) (In reply to comment #7) By this reasoning the PR is actually of the type accepts-invalid and not rejects-valid. It seems to me that all the cases presented here (comment #0, comment #2, the two cases in comment #3, comment #6) are invalid. Thus it's a rejects-invalid, in other words not a bug. Closing as per the reason above.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #170 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-10 15:04:10 UTC --- OK, here is updated memory use: cgraph.c:863 (cgraph_allocate_init_indirect_info5905200: 0.1% 0: 0.0%6020160: 0.1% 0: 0.0% 298134 tree.c:1237 (build_int_cst_wide) 15554272: 0.4% 0: 0.0% 782528: 0.0% 0: 0.0% 510525 tree.c:1559 (build_string) 10685931: 0.2% 0: 0.0% 16715642: 0.4%2193469: 1.7% 563828 stringpool.c:75 (alloc_node) 0: 0.0% 0: 0.0% 30574880: 0.7% 0: 0.0% 764372 lto/lto.c:2286 (create_subid_section_table) 1522184: 0.0% 0: 0.0% 39117064: 0.8%8051472: 6.4% 3978 stringpool.c:58 (stringpool_ggc_alloc)0: 0.0% 0: 0.0% 41092405: 0.9%2954893: 2.4% 764372 gimple.c:3167 (iterative_hash_canonical_type) 45040752: 1.0% 0: 0.0% 0: 0.0% 0: 0.0%2815047 lto/lto.c:1222 (iterative_hash_gimple_type)68276864: 1.6% 0: 0.0% 0: 0.0% 0: 0.0%4267304 ggc-common.c:249 (ggc_cleared_alloc_ptr_array_tw 91784: 0.0% 487289424:48.8% 71432600: 1.5% 248976: 0.2% 10974 lto/lto.c:1266 (iterative_hash_gimple_type)75288576: 1.8% 0: 0.0% 0: 0.0% 0: 0.0%4705536 lto-section-in.c:362 (lto_new_in_decl_state) 694320: 0.0% 0: 0.0% 94861800: 2.0% 0: 0.0% 796301 tree.c:1263 (build_int_cst_wide) 76232736: 1.8% 0: 0.0% 19358880: 0.4% 0: 0.0%2987238 cgraph.c:794 (cgraph_create_edge_1) 0: 0.0% 0: 0.0% 125510632: 2.7% 0: 0.0%1206833 vec.h:565 ((null)) 66034564: 1.5% 98716: 0.0% 68500548: 1.5%3484420: 2.8% 597783 vec.h:695 ((null))124654648: 2.9% 122044288:12.2% 63749232: 1.4%2614800: 2.1%1590429 tree-streamer-in.c:562 (streamer_alloc_tree) 125829312: 2.9% 0: 0.0% 74222904: 1.6% 7072: 0.0%2005091 lto/lto.c:267 (lto_read_in_decl_state) 1478720: 0.0% 0: 0.0% 216390688: 4.7% 38247784:30.5%5574107 vec.h:747 ((null))173791988: 4.0% 19565412: 2.0% 68225644: 1.5%2680332: 2.1%1396070 vec.h:707 ((null))133872480: 3.1% 0: 0.0% 285212728: 6.1% 800360: 0.6%1059913 cgraph.c:500 (cgraph_allocate_node) 0: 0.0% 0: 0.0% 472831880:10.2% 0: 0.0%1597405 tree.c:1223 (build_int_cst_wide) 607138944:14.1% 0: 0.0% 10427664: 0.2%4719336: 3.8% 315034 toplev.c:959 (realloc_for_line_map) 0: 0.0% 358037664:35.8% 1073872920:23.1%184: 0.0% 16 tree-streamer-in.c:573 (streamer_alloc_tree) 2762184192:64.2% 0: 0.0% 1861017624:40.0% 59027616:47.1% 34649937 Total4302007795999178184 4651003487125411458 68828967 source location GarbageFreed Leak OverheadTimes --- Actually it is a bit of improvement over my past report. Some obvious things 1) we still soak in too many trees (40%) of memory. The per-tree stats are: decls17310018 -1609736744 types8983387 1509209016 exprs2427302 80045744 constants4079292 135393547 binfos 2005091 200038072 random kinds 5691481 227659664 and counts: tree_list5691475 pointer_type 2337585 record_type 3702066 function_decl1856282 field_decl 2812564 const_decl 2739702 parm_decl3549707 type_decl4780459 result_decl 1144482 tree_binfo 2005091 2) new linemaps are still a disaster 3) VEC rewrite did break stats. Honza
[Bug fortran/55345] ICE with abstract interface type with use-renamed local names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55345 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org 2013-01-10 15:06:07 UTC --- Closing then.
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-10 15:11:34 UTC --- (In reply to comment #6) By unswitching on an exit test that exits to the enclosing loop we create an unswitched loop that is now reached by what looks like an exit test of the outer loop which is part of an irreducible region. I'm not sure we can reliably detect all cases we need to manually mark the entry edge for. So ... re-mark_irreducible_loops () after each transform? Yeah, I'm looking into this for quite some time now and this occurred me too. I'm going to prepare some patch (together with your version of cheaper checking).
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org |gnu.org | --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-10 15:18:33 UTC --- BTW, here is the CFG right before the verify_loops_structure (), which fails: http://people.redhat.com/mpolacek/src/pr55833.png
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rakdver at gcc dot gnu.org --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 15:22:46 UTC --- Zdenek may also have an idea here.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #29 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 15:28:38 UTC --- (In reply to comment #27) Created attachment 29141 [details] updated checker Also verify expressions. Bootstrapped ok, target libs building now, testing pending. I'll give it a LTO profiledbootstrap try as well ... if that's not it then the issue must be elsewhere :( Besides a few fortran ICEs in the testsuite a regular bootstrap and regtest went ok with this version. The Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs which have a location with bogus BLOCK. FAIL: gfortran.dg/class_array_15.f03 -O0 (internal compiler error) FAIL: gfortran.dg/class_array_15.f03 -O0 (test for excess errors) WARNING: gfortran.dg/class_array_15.f03 -O0 compilation failed to produce exec utable FAIL: gfortran.dg/typebound_operator_13.f03 -O0 (internal compiler error) FAIL: gfortran.dg/typebound_operator_13.f03 -O0 (test for excess errors) WARNING: gfortran.dg/typebound_operator_13.f03 -O0 compilation failed to produ ce executable FAIL: gfortran.dg/typebound_operator_7.f03 -O0 (internal compiler error) FAIL: gfortran.dg/typebound_operator_7.f03 -O0 (test for excess errors) WARNING: gfortran.dg/typebound_operator_7.f03 -O0 compilation failed to produc e executable FAIL: gfortran.dg/typebound_operator_8.f03 -O0 (internal compiler error) FAIL: gfortran.dg/typebound_operator_8.f03 -O0 (test for excess errors) WARNING: gfortran.dg/typebound_operator_8.f03 -O0 compilation failed to produc e executable
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #30 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 15:34:39 UTC --- LTO profiled-bootstrap revals: /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan': /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references block not in block tree reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED) ^ ee fmt_351 = ee; /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error: verify_gimple failed this is a STRING_CST node. Needs to be tracked down ... more IPA stuff needs to use copy_tree_without_location.
[Bug tree-optimization/44061] [4.6/4.7/4.8 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 15:35:40 UTC --- I'm updating and testing the patch.
[Bug fortran/55935] New: [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 Bug #: 55935 Summary: [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org, pa...@gcc.gnu.org I assume that that relates to the __copy function. From PR 55792 comment 29: - The Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs which have a location with bogus BLOCK. Also verify expressions. Bootstrapped ok, target libs building now, testing pending. FAIL: gfortran.dg/class_array_15.f03 -O0 (internal compiler error) FAIL: gfortran.dg/typebound_operator_13.f03 -O0 (internal compiler error) FAIL: gfortran.dg/typebound_operator_7.f03 -O0 (internal compiler error) FAIL: gfortran.dg/typebound_operator_8.f03 -O0 (internal compiler error)
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #8 from janus at gcc dot gnu.org 2013-01-10 15:46:12 UTC ---
(In reply to comment #7)
I want to emphasize again that the error I wanted to report was that gfortran
is rejecting valid structure constructor expressions (see comment 3).
Here is a slightly reduced version of comment 3:
type :: S
integer :: n
end type
type(S) :: Sobj
type :: T
class(S), allocatable :: x
end type
Sobj = S(1)
call pass_it (T(Sobj))
contains
subroutine pass_it (foo)
type(T) :: foo
end subroutine
end
One can get past the error message with the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 194927)
+++ gcc/fortran/resolve.c(working copy)
@@ -1103,7 +1103,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
/* If we don't have the right type, try to convert it. */
if (!comp-attr.proc_pointer
- !gfc_compare_types (cons-expr-ts, comp-ts))
+ !gfc_compare_types (comp-ts, cons-expr-ts))
{
t = FAILURE;
if (strcmp (comp-name, _extends) == 0)
but the one runs into an ICE:
internal compiler error: in fold_convert_loc, at fold-const.c:1986
call pass_it (T(Sobj))
^
0x845634 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/jweil/gcc48/trunk/gcc/fold-const.c:1986
0x671aa9 gfc_trans_subcomponent_assign
/home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6001
0x671e10 gfc_trans_structure_assign
/home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6068
0x671f46 gfc_conv_structure(gfc_se*, gfc_expr*, int)
/home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6095
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-10 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10 16:00:46 UTC --- I assume that that relates to the __copy function. It looks likely: with the patch at http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00547.html, I get [macbook] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/class_array_15.f03 /opt/gcc/work/gcc/testsuite/gfortran.dg/class_array_15.f03: In function 'pr54992': /opt/gcc/work/gcc/testsuite/gfortran.dg/class_array_15.f03:97:0: error: location references block not in block tree subroutine pr54992 ! This test remains as the original. ^ __copy_g_nodes_Ncbhstd _22 = __copy_g_nodes_Ncbhstd; /opt/gcc/work/gcc/testsuite/gfortran.dg/class_array_15.f03:97:0: internal compiler error: verify_gimple failed and so on for the other failing tests.
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #9 from janus at gcc dot gnu.org 2013-01-10 16:06:51 UTC --- In fact one also gets an ICE when replacing class(S) with type(S) in comment 8 (already with an unpatched gfortran): type :: S integer :: n end type type(S) :: Sobj type :: T type(S), allocatable :: x end type Sobj = S(1) call pass_it (T(Sobj)) contains subroutine pass_it (foo) type(T) :: foo end subroutine end internal compiler error: in fold_convert_loc, at fold-const.c:1864 call pass_it (T(Sobj)) ^ 0x844efe fold_convert_loc(unsigned int, tree_node*, tree_node*) /home/jweil/gcc48/trunk/gcc/fold-const.c:1863 0x671aa9 gfc_trans_subcomponent_assign /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6001 0x671e10 gfc_trans_structure_assign /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6068 0x671f46 gfc_conv_structure(gfc_se*, gfc_expr*, int) /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:6095 This is similar, but not identical, to the ICE in comment 8.
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10 16:25:05 UTC --- For the test gfortran.dg/class_array_15.f03, the ICE is triggered by the statement: allocate(b%cBh(1),source=defaultBhC) (note that the test compiles with -fno-whole-file;-).
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 16:29:17 UTC --- Supposedly ADDR_EXPR is shared between several functions or something similar.
[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 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-10 16:42:46 UTC --- Martin, I guess it is yours then. Why we fail to analyze one call but suceed with the another?
[Bug tree-optimization/52448] [4.6/4.7/4.8 Regression] cselim broken with calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 16:49:26 UTC --- Any progress with this?
[Bug tree-optimization/55936] New: Missed VRP optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936
Bug #: 55936
Summary: Missed VRP optimization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@redhat.com
gcc.dg/tree-ssa/vrp06.c looks like:
foo (int i, int j, int a)
{
if (i = 10)
if (i = 30)
if (i == j)
{
a--;
/* This should fold to 'if (0)'. */
if (i 0)
i = baz ();
/* This should fold to 'if (1)'. */
if (j 0)
a--;
/* This should fold to 'if (0)'. */
if (i != j)
return 0;
}
return i + a + j;
}
VRP is supposed to optimize away the 3 innermost conditions in a single pass;
the key being to realize that the test i 0 is always false and thus i does
not vary (nor does j vary). Once i j are determined to have non-varying
values, we should be able to optimize away the i != j test because we're in the
true clause if the i == j test.
Unfortunately, VRP drops i to varying and it's unable to optimize away the last
test during the first VRP pass. It does get optimized later.
[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683 --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10 16:58:35 UTC --- (In reply to comment #13) The acutal ICE should be fixed. Martinj, I will leave the PR open just to make you to double check that ipa-cp is doing properly the translation from constants to binfos, too. At -O2, IPA-CP does not even consider cloning C::c1 because it is not allowed to grow code by creating clones. At -O3 (or with -fipa-cp-clone), IPA-CP discovers that cloning for c would lead to devirtualization but because the target of the devirtualized call is not analyzed, it gets only minimal bonus for that. Eventually the cloning opportunity gets score 437 (cloning threshold is 500) and thus it is dropped. This is as it should be. I would expect this testcase to be caught by ipa-cp prior inlining. Also I think that when merging values, we should go from constant to binfo when constants differs but their binfos match (so when method is called with multiple static instances of the same object we will get devirtualization). I don't see ipa-cp doing that. Well, the problem with that of course is that we do not merge stuff now, we accumulate all possible constants. So what we perhaps should do instead is (if ipcp_param_lattices-virt_call is true) to try to see if a number of ADDR_EXPR constants yield the same binfo and if so, consider that new value first, before any real constants.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #31 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 17:03:13 UTC --- (In reply to comment #30) LTO profiled-bootstrap revals: /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan': /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references block not in block tree reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED) ^ ee fmt_351 = ee; This is the same problem in comment #13: In file included from :4457:0: /export/gnu/import/git/gcc/gcc/reginfo.c: In function ‘reg_scan’: /export/gnu/import/git/gcc/gcc/reginfo.c:1015:0: error: location references block not in block tree reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED) ^ ee fmt_388 = ee; /export/gnu/import/git/gcc/gcc/reginfo.c:1015:0: internal compiler error: verify_gimple failed 0x9c7dc8 verify_gimple_in_cfg(function*) /export/gnu/import/git/gcc/gcc/tree-cfg.c:4726 0x8ad9e0 execute_function_todo /export/gnu/import/git/gcc/gcc/passes.c:1968 0x8acd04 do_per_function /export/gnu/import/git/gcc/gcc/passes.c:1703 0x8adb04 execute_todo /export/gnu/import/git/gcc/gcc/passes.c:2001 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug other/55899] GCC should provide built-ins in stdint.h data types flavor/version/variation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-10 CC||hp at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2013-01-10 17:29:48 UTC --- Sounds fair. Note the inconsistency between clz/ctz builtins and bswap builtins.
[Bug middle-end/55929] lra-constraints-ICE while xg++ compile libitm with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929
--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2013-01-10 17:30:36
UTC ---
Patch in testing:
Index: i386.md
===
--- i386.md (revision 195063)
+++ i386.md (working copy)
@@ -18018,7 +18018,10 @@
{
rtx label = gen_label_rtx ();
- operands[1] = force_reg (SImode, constm1_rtx);
+ /* xbegin is emitted as jump_insn, so reload won't be able
+ to reload its operand. Force the value into AX hard register. */
+ operands[1] = gen_rtx_REG (SImode, AX_REG);
+ emit_move_insn (operands[1], constm1_rtx);
emit_jump_insn (gen_xbegin_1 (operands[1], label));
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10
17:35:13 UTC ---
(note that the test compiles with -fno-whole-file;-).
To be honest, this is not true for the other failing tests. Reduced
typebound_operator_8.f03
! { dg-do compile }
! PR48946 - complex expressions involving typebound operators of derived types.
!
module field_module
implicit none
type ,abstract :: field
contains
procedure(field_op_real) ,deferred :: multiply_real
procedure(field_plus_field) ,deferred :: plus
generic :: operator(*) = multiply_real
generic :: operator(+) = plus
end type
abstract interface
function field_plus_field(lhs,rhs)
import :: field
class(field) ,intent(in) :: lhs
class(field) ,intent(in) :: rhs
class(field) ,allocatable :: field_plus_field
end function
end interface
abstract interface
function field_op_real(lhs,rhs)
import :: field
class(field) ,intent(in) :: lhs
real ,intent(in) :: rhs
class(field) ,allocatable :: field_op_real
end function
end interface
end module
module i_field_module
use field_module
implicit none
type, extends (field) :: i_field
integer :: i
contains
procedure :: multiply_real = i_multiply_real
procedure :: plus = i_plus_i
end type
contains
function i_plus_i(lhs,rhs)
class(i_field) ,intent(in) :: lhs
class(field) ,intent(in) :: rhs
class(field) ,allocatable :: i_plus_i
integer :: m = 0
select type (lhs)
type is (i_field); m = lhs%i
end select
select type (rhs)
type is (i_field); m = rhs%i + m
end select
allocate (i_plus_i, source = i_field (m))
end function
function i_multiply_real(lhs,rhs)
class(i_field) ,intent(in) :: lhs
real ,intent(in) :: rhs
class(field) ,allocatable :: i_multiply_real
integer :: m = 0
select type (lhs)
type is (i_field); m = lhs%i * int (rhs)
end select
allocate (i_multiply_real, source = i_field (m))
end function
end module
This test compiles if I comment one of the ALLOCATE.
[Bug target/55565] [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565
--- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-10
17:46:39 UTC ---
I compared the code generated by trunk with the generated code in rev 190339
which broke the test. The trunk code is more optimal than when the test
passed, so I suggest either removing the dg-final in the test, or modifying
the regex in the dg-final.
In the testcase we have something functionally equivalent to (where x is the
original function argument passed in f1):
if (huge + x 0.0) {
if ((int)x 0)
return 0.0;
...
} else
return x;
When the test passed, we used to generate:
.L17:
ld %r8,.LC0@toc(%r2)
ld %r10,.LC2@toc(%r2)
lfd %f13,0(%r8)
lfd %f0,0(%r10)
fadd %f1,%f1,%f13
fcmpu %cr7,%f1,%f0
bng %cr7,.L4 /* if (!(huge + x 0.0)) return x; */
...
...
.L4: /* return x; */
std %r9,-8(%r1)
ori 2,2,0
lfd %f1,-8(%r1)
blr
Notice that since we perform the fadd onto %f1, we need to reload %f1 from
memory.
On trunk though, we keep x/%f1 and 0.0/%f0 around so we can return them
directly. We can return x/%f1 directly in one case, or copy 0.0/%f0 to the
return register (%f1) in the another case.
.L18:
ld %r8,.LC6@toc(%r2)
ld %r9,.LC1@toc(%r2)
lfd %f13,0(%r8)
lfd %f0,0(%r9)
fadd %f13,%f1,%f13
fcmpu %cr7,%f13,%f0
bnglr %cr7/* if (!(huge + x 0.0)) return x; */
cmpdi %cr7,%r10,0
fmr %f1,%f0
bgelr %cr7/* if (huge+x0.0 (int)x 0) return 0.0 */
Bottom line, on trunk we avoid a branch and memory load/stores.
Testing a patch.
[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 jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10 17:49:32 UTC --- (In reply to comment #3) Martin, I guess it is yours then. Why we fail to analyze one call but suceed with the another? I have not looked at this ia64 bug specifically yet, but does my comment #1 in PR 55913 answer your question?
[Bug target/55565] [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-10 17:53:24 UTC --- (In reply to comment #4) Bottom line, on trunk we avoid a branch and memory load/stores. I agree the code is much better now. Only moving between the fpr and gpr where needed instead of keeping x into the GPRs.
[Bug sanitizer/55488] Implement cold calls in tsan run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488 --- Comment #1 from wmi at gcc dot gnu.org 2013-01-10 17:57:40 UTC --- Author: wmi Date: Thu Jan 10 17:57:34 2013 New Revision: 195092 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195092 Log: 2013-01-10 Wei Mi w...@google.com libsanitizer/ PR sanitizer/55488 * tsan/Makefile.am: Add tsan_rtl_amd64.S. * tsan/Makefile.in: Regenerated. * tsan/tsan_rtl.h: Enable HACKY_CALL. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/tsan/Makefile.am trunk/libsanitizer/tsan/Makefile.in trunk/libsanitizer/tsan/tsan_rtl.h
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10 18:02:35 UTC --- (In reply to comment #8) Let me look into those... Try the patch I attached to PR45375 I have updated to revision 195082 which I understand already has it and tried again but it did not help.
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10 18:14:44 UTC --- And no wonder it did not because those failures are ICEs in ipcp_verify_propagated_values. So that's mine.
[Bug target/27338] Violation of mips o64 ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27338 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #2 from Steve Ellcey sje at gcc dot gnu.org 2013-01-10 18:34:11 UTC --- Richard, has the need for any documentation change been removed by the age of this defect? Perhaps it should just be closed now.
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-10 19:31:42 UTC --- I'll take a look.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 19:36:08 UTC --- (In reply to comment #30) LTO profiled-bootstrap revals: /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan': /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references block not in block tree reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED) ^ ee fmt_351 = ee; /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error: verify_gimple failed this is a STRING_CST node. Needs to be tracked down ... more IPA stuff needs to use copy_tree_without_location. I think this BLOCK comes from LTO streamer.
[Bug middle-end/55929] lra-constraints-ICE while xg++ compile libitm with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929 --- Comment #4 from uros at gcc dot gnu.org 2013-01-10 19:49:34 UTC --- Author: uros Date: Thu Jan 10 19:49:17 2013 New Revision: 195094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195094 Log: PR target/55929 * config/i386/i386.md (xbegin): Use %eax as a temporary register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/55929] lra-constraints-ICE while xg++ compile libitm with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-01/msg00568.htm ||l Component|middle-end |target Resolution||FIXED Severity|major |normal --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2013-01-10 19:51:50 UTC --- Fixed.
[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2013-01-10 20:23:49 UTC --- Author: vmakarov Date: Thu Jan 10 20:07:55 2013 New Revision: 195095 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195095 Log: 2013-01-10 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2013-01-10 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55672 * gcc.target/i386/pr55672.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr55672.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-eliminations.c trunk/gcc/testsuite/ChangeLog
[Bug target/55565] [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-10 20:28:33 UTC --- Author: aldyh Date: Thu Jan 10 20:28:26 2013 New Revision: 195097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195097 Log: PR target/55565 * gcc.target/powerpc/ppc-mov-1.c: Update scan-assembler-not regex. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/ppc-mov-1.c
[Bug target/55565] [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-10 20:29:41 UTC --- Fixed in trunk.
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #10 from janus at gcc dot gnu.org 2013-01-10 20:39:58 UTC ---
The following patch makes comment 8 and 9 compile, but I'm not sure if the
generated code is correct:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 194927)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -5990,23 +5990,11 @@ gfc_trans_subcomponent_assign (tree dest, gfc_comp
gfc_add_expr_to_block (block, tmp);
}
}
- else if (expr-ts.type == BT_DERIVED)
+ else if (expr-ts.type == BT_DERIVED expr-expr_type == EXPR_STRUCTURE)
{
- if (expr-expr_type != EXPR_STRUCTURE)
-{
- gfc_init_se (se, NULL);
- gfc_conv_expr (se, expr);
- gfc_add_block_to_block (block, se.pre);
- gfc_add_modify (block, dest,
- fold_convert (TREE_TYPE (dest), se.expr));
- gfc_add_block_to_block (block, se.post);
-}
- else
-{
- /* Nested constructors. */
- tmp = gfc_trans_structure_assign (dest, expr);
- gfc_add_expr_to_block (block, tmp);
-}
+ /* Nested constructors. */
+ tmp = gfc_trans_structure_assign (dest, expr);
+ gfc_add_expr_to_block (block, tmp);
}
else
{
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-10 CC||pinskia at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-10 21:17:05 UTC --- Confirmed.
[Bug target/55721] -mabi=64 compilation results in unknown UNSPEC note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55721
--- Comment #14 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
2013-01-10 21:32:24 UTC ---
(In reply to comment #12)
Here is another testcase that looks different then the others, it is cutdown
from newlib/libm/math/k_rem_pio2.c.
% cat bug3.c
static const int init_jk[] = {2,3,4,6};
double twon24 = 5.9604644775390625e-08;
int __kernel_rem_pio2(double *x, double *y, int e0, int nx, int prec)
{
int jz,jx,jv,jp,jk,carry,n,iq[20],i,j,k,m,q0,ih;
double z,fw,f[20],fq[20],q[20];
jk = init_jk[prec];
jz = jk;
for(i=0,j=jz,z=q[jz];j0;i++,j--) {
fw = (double)((int)(twon24* z));
}
switch(prec) {
case 0:
y[0] = fq[0]; y[1] = fq[1]; y[2] = fw;
}
}
% gcc -mips64r2 -mabi=64 -c -O2 -g bug3.c
bug3.c: In function '__kernel_rem_pio2':
bug3.c:3:5: note: non-delegitimized UNSPEC unknown (230) found in variable
location
int __kernel_rem_pio2(double *x, double *y, int e0, int nx, int prec)
^
bug3.c:3:5: note: non-delegitimized UNSPEC unknown (230) found in variable
location
I've extended the patch to cope with the case in comment 10/comment 11
by adding an optional negation to each piece of the address.
But I'm not sure what to do about the case in comment 12. The problem
there is that vartracking is creating notes for the temporary (incomplete)
results in an lea64 expansion, I wondered at first whether that was
because we were reusing the register rtx that holds the final (full)
address to store intermediate results, but changing that didn't seem
to make any difference.
I suppose we could get rid of the unspecs by turning things like
SYMBOL_64_HIGH into ((x + 0x800080008000) 48) 0x. But although
that's possible, is it actually _useful_? I think in practice only
the complete address will be of interest for debugging, and any attempt
to output partial addresses will bloat the output for no benefit.
And it doesn't really seem worth adding a target hook to test for
these cases because AIUI the lack of delegitimisation already causes
us to drop the values (albeit noisily for --enable-checking).
[Bug lto/55937] New: lto hides possible link issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55937
Bug #: 55937
Summary: lto hides possible link issues
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bo...@fau.re
When compiling the following on linux where gethrtime is not defined, it links
with -O1 but not with -O0:
char gethrtime ();
char (*f) () = gethrtime;
int main () {
return f != gethrtime;
}
'gcc-4.7.2 -O1 -flto -o conftest conftest.c' works, while 'gcc-4.7.2 -O0 -flto
-o conftest conftest.c' outputs:
/tmp/ccT5O10r.ltrans0.ltrans.o: In function `main':
ccT5O10r.ltrans0.o:(.text+0xd): undefined reference to `gethrtime'
/tmp/ccT5O10r.ltrans0.ltrans.o:(.data+0x0): undefined reference to `gethrtime'
collect2: error: ld returned 1 exit status
Compiling with -fwhole-program, it would fail as expected:
'gcc-4.7.2 -O1 -fwhole-program -o conftest conftest.c' outputs:
/tmp/ccaHfhb0.o:(.rodata+0x0): undefined reference to `gethrtime'
collect2: error: ld returned 1 exit status
That code is actually produced by the following autoconf macro while
configuring erlang-R15B02:
AC_CHECK_FUNC(gethrtime)
The macro would include limits.h but since it's not defined, the same
behaviour is shown without that include.
[Bug lto/55937] lto hides possible link issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55937 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-10 21:47:29 UTC --- I think this is really invalid and the check (autoconf) should be changed instead. What is happening is f is known to be used outside of the program. If f is marked as externally_visible then it would not remove the variable f.
[Bug c++/55742] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Sriraman Tallam tmsriram at google dot com changed: What|Removed |Added CC||richard.guenther at gmail ||dot com --- Comment #7 from Sriraman Tallam tmsriram at google dot com 2013-01-10 22:10:14 UTC --- Jason/Richard, Would like to hear your thoughts on this.
[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] Erroneous |Erroneous optimization |optimization causes wrong |causes wrong Neon data |Neon data management |management | Known to fail|4.8.0 | --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-10 22:19:25 UTC --- I could not reproduce this in a modified 4.7.0 which has patches from the trunk. I think it was fixed by http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01732.html .
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10 22:35:06 UTC --- Shorter test case for gfortran.dg/typebound_operator_*: module i_field_module implicit none type :: i_field integer :: i end type contains function i_plus_i(lhs) class(i_field) ,intent(in) :: lhs class(i_field) ,allocatable :: i_plus_i allocate (i_plus_i, source = i_field (0)) end function function i_multiply_real(lhs) class(i_field) ,intent(in) :: lhs class(i_field) ,allocatable :: i_multiply_real allocate (i_multiply_real, source = i_field (0)) end function end module Note that if the 'class's are replaced with 'type's, the program compiles.
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10 23:10:39 UTC --- Note that if the 'class's are replaced with 'type's, the program compiles. The assert also triggers if class(i_field) ,intent(in) :: lhs is replaced with type(i_field) ,intent(in) :: lhs
[Bug sanitizer/55938] New: g++.dg/asan/deep-stack-uaf-1.C fails at r195092 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938 Bug #: 55938 Summary: g++.dg/asan/deep-stack-uaf-1.C fails at r195092 on darwin Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org After the commit of r195092, x86_64-apple-darwin12 exhibits new failures. These are of the form... FAIL: g++.dg/asan/deep-stack-uaf-1.C -O0 output pattern test, is = ==47472== ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs free) on 0x00010bb0ae00 #0 0x108cb6cc5 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libsanitizer/asan/.libs/libasan.0.dylib+0x8cc5) #1 0x108cb6e4a (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libsanitizer/asan/.libs/libasan.0.dylib+0x8e4a) #2 0x108c9da27 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x10a27) #3 0x108c9ee77 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11e77) #4 0x108c9ee5d (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11e5d) #5 0x108c9ee43 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11e43) #6 0x108c9ee29 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11e29) #7 0x108c9ee0f (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11e0f) #8 0x108c9edf5 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11df5) #9 0x108c9eddb (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11ddb) #10 0x108c9edc1 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11dc1) #11 0x108c9eda7 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11da7) #12 0x108c9ed8d (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11d8d) #13 0x108c9ed73 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11d73) #14 0x108c9ed59 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11d59) #15 0x108c9ed3f (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11d3f) #16 0x108c9ed25 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11d25) #17 0x108c9ed0b (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11d0b) #18 0x108c9ecf1 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11cf1) #19 0x108c9ecd7 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11cd7) #20 0x108c9ecbd (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11cbd) #21 0x108c9eca3 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11ca3) #22 0x108c9ec89 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11c89) #23 0x108c9ec6f (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11c6f) #24 0x108c9ec55 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11c55) #25 0x108c9ec3b (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11c3b) #26 0x108c9ec21 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11c21) #27 0x108c9ec07 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11c07) #28 0x108c9ebed (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11bed) #29 0x108c9ebd3 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11bd3) #30 0x108c9ebb9 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/./deep-stack-uaf-1.exe+0x11bb9) #31 0x108c9eb9f
[Bug sanitizer/55938] g++.dg/asan/deep-stack-uaf-1.C fails at r195092 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-11 Ever Confirmed|0 |1 --- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-11 06:36:44 UTC --- The tests have bugs: gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C char *x = new char[10]; ... ::free(x); The new asan run-time detects the new/free mismatch and crashes before it detects the expected use-after-free bug. These tests in gcc/testsuite were forked from the upstream variant, which is already fixed. What is surprising is why I don't see these failures on Linux.
