[Bug c++/57301] bit rotation is optimized in c but not c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- How old is your gcc build? (please fill in the version field when reporting bugs) This was fixed by Jakub recently, so if you could check with current trunk...
[Bug c++/57301] bit rotation is optimized in c but not c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #1) How old is your gcc build? (please fill in the version field when reporting bugs) Oups, sorry, you mention it (4.7 and 4.8) in the text. This was fixed by Jakub recently, so if you could check with current trunk... It was only fixed for 4.9.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Version|4.9.0 |4.8.1
Target Milestone|--- |4.8.1
Summary|statement in expression |[4.8/4.9 Regression]
|miscompiled at -O3 in |statement in expression
|32-bit mode |miscompiled at -O3 in
||32-bit mode
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
/* PR rtl-optimization/57300 */
/* { dg-do run } */
/* { dg-options -O3 } */
/* { dg-additional-options -msse2 { target sse2_runtime } } */
extern void abort (void);
int a, b, d[10];
long long c;
int
main ()
{
int e;
for (e = 0; e 10; e++)
d[e] = 1;
if (d[0])
c = a = (b == 0 || 1 % b);
if (a != 1)
abort ();
return 0;
}
(note, -msse needed, without it it doesn't reproduce). Started with LRA merge,
but looks very much PR57281 related.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30130 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30130action=edit gcc49-pr57300.patch Untested fix.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||krebbel at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- I'm worried if this isn't too expensive, as there are just 3 dead_or_set_p uses in define_split patterns in the compiler apparently, one in i386.md (the one hitting in this and the other PR), guarded with reload_completed, and two for movdi splitters in s390.md (not guarded by that). If the s390.md splitters could be guarded by reload_completed, we could at least avoid the df_analyze in split1 pass.
[Bug testsuite/57301] bit rotation is optimized in c but not c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-16 CC||jakub at gcc dot gnu.org Component|c++ |testsuite Ever confirmed|0 |1 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Andy Lutomirski from comment #0) It's well known [citation needed] that modern compilers are excellent at optimizing simple bit twiddling. :-) gcc -O2 (4.7 and some random 4.8 build) generates: f1: .LFB0: .cfi_startproc movl %edi, %eax rolw$8, %ax ret .cfi_endproc clang -O2 generates: f1: # @f1 .cfi_startproc # BB#0: rolw$8, %di movzwl %di, %eax ret (I suspect that these are equally good.) The gcc code is slightly better in most cases but it depends on the target. ix86 tuning is as irregular as the architecture itself. But g++ -O2 generates: _Z2f1t: .LFB0: .cfi_startproc movzwl %di, %edi movl%edi, %eax sarl$8, %edi sall$8, %eax orl %edi, %eax ret .cfi_endproc Perhaps some decent subset of the gcc testsuite should also be built with the c++ frontend to make sure it still passes... That is not so easy to do, but apparently it's necessary. gcc and g++ are not supposed to generate different code for such a trivial example. We'd have to figure out a subset of the gcc test suite that actually tests middle-end features (such as your instruction combining/folding example). For GCC 4.9 the middle-end rotation optimizations have been improved by Jakub's patches for bug 55278. For GCC 4.7 and GCC 4.8 I would expect the -fdump-tree-optimized dumps for gcc and g++ to be the same. Can you try that and have a look at those dumps?
[Bug target/19599] function pointer prevents tail-call optimization on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19599 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00449.html Fixed on trunk. Ramana
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
The alternative could be, if dead_or_set_p is going to be so rare even in the
near future, to just introduce split_dead_or_set_p wrapper around it, which
would do something like:
if (df_note == NULL)
{
df_note_add_problem ();
df_analyze ();
}
return dead_or_set_p (...);
Not sure if it is safe to run df_analyze when the cfg is gone (split5 pass), if
not, then this wrapper should detect that and just return conservatively false.
[Bug tree-optimization/57294] [4.9 Regression] ice in remove_described_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
void baz (void);
int func ();
static void
bar (int a, int foo (void))
{
baz ();
foo ();
}
void
baz (void)
{
bar (0, func);
}
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) Not sure if it is safe to run df_analyze when the cfg is gone (split5 pass) Well, it doesn't crash but it's not correct. Without basic block pointers on the insns, even the scan problem doesn't run properly anymore. One of the target machine reorgs does this, FWIW.
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #20 from Tobias Burnus burnus at gcc dot gnu.org --- Since the update, the Bugzilla favicon is shown, link rel=shortcut icon href=images/favicon.ico - http://gcc.gnu.org/bugzilla/images/favicon.ico before the GCC one was shown: link rel=shortcut icon href=http://gcc.gnu.org/favicon.ico; /
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Apparently split* passes aren't the only passes that split insns though, so the
patch I've attached is incomplete anyway.
From quick skimming, it seems split*, dbr, final, combine and pro_and_epilogue
passes split insns right now, and some backends (but not i386/s390 that are
problematic here). split* passes don't run df_analyze at all, so I think it is
safe to call df_note_add_problem (); df_analyze (); there, final/dbr don't have
cfg around, so it is unsafe, combine already has note problem computed, and
pro_and_epilogue only splits eh_return pattern.
So supposedly
bool
split_dead_or_set_p (rtx insn, const_rtx x)
{
if (BLOCK_FOR_INSN (insn) == NULL)
return false; /* If cfg is gone, be conservative. */
if (df_note == NULL)
{
df_note_add_problem ();
df_analyze ();
}
return dead_or_set_p (insn, x);
}
could work. Steven, comments?
[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #4) Yea, 254.gap is definitely overflowing signed types. I've got changes to make the warnings and -fno-strict-overflow work that I'll put through their paces tomorrow. I think we should twiddle the testcase to verify we don't muck it up when -fno-strict-overflow is active. Yes, that would be nice.
[Bug c++/10634] in-class initialization of static data members no longer allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10634 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org|paolo.carlini at oracle dot com Resolution|--- |INVALID --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com --- I think we can close this.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-16 Ever confirmed|0 |1 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I'm worried if this isn't too expensive, as there are just 3 dead_or_set_p uses in define_split patterns in the compiler apparently, one in i386.md (the one hitting in this and the other PR), guarded with reload_completed, and two for movdi splitters in s390.md (not guarded by that). If the s390.md splitters could be guarded by reload_completed, we could at least avoid the df_analyze in split1 pass. I agree that calling DF for just 3 cases sounds a bit overkill. Is the i386.md splitter really necessary or could we use a peephole2 instead?
[Bug c++/15672] local function causes weird warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15672 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Resolution|--- |DUPLICATE --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 52960 ***
[Bug c++/52960] Missing warnings on ambiguous source : function decl vs local var decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52960 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||igodard at pacbell dot net --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 15672 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30131 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30131action=edit /tmp/gcc49-pr57300.patch The split_dead_or_set_p variant patch.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #9 from Steven Bosscher steven at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
So supposedly
bool
split_dead_or_set_p (rtx insn, const_rtx x)
{
if (BLOCK_FOR_INSN (insn) == NULL)
return false; /* If cfg is gone, be conservative. */
if (df_note == NULL)
{
df_note_add_problem ();
df_analyze ();
}
return dead_or_set_p (insn, x);
}
could work. Steven, comments?
I don't think this will work. The fact that df_note != NULL does not
mean the notes are up-to-date.
It seems to me that after freeing the CFG, no pass should rely on the
REG_DEAD and REG_UNUSED notes if Eric's comment in PR57281 is correct:
That each pass is responsible for re-computing the notes if it needs
them. But I would much rather have the passes at least discard the
notes if the pass can't update them. After all, it's not just this
dead_or_set_p function that relies on these notes, but also single_set
and a bunch of other functions.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Re: Eric's question, not easily, because if we implement that define_split as define_peephole2, then it won't trigger at all, because the next define_split ;; Extend to memory case when source register does not die., will then split the insn already during split2 pass rather than waiting for peephole2 pass. So we'd need to protect that second splitter with peephole2_completed predicate which we don't have yet, or so. Is that the way to go? If so, I can try a patch. Note, s390 will still be broken, but we don't have testcases for it right now. Re: Steven, we need some solution for 4.8.1 too. While it is true that generally df_note doesn't mean the problem is up2date, doesn't df_finish_pass always kill that problem and thus at least the current pass should have called df_add_note_problem? Given the passes that split insns right now (see previous comments), having df_note non-NULL means either it is a combine pass where it is fine, or split* pass in which split_dead_or_set_p has been called already.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Re: s390, the condition includes ACCESS_REG_P test, which is for a0/a1 hard reg, so I think just adding reload_completed test to the splitters wouldn't be a problem, and if we introduce peephole2_completed, we might deal with it the same way (one splitter changed into define_peephole2, the other guarded with peephole2_completed).
[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-16
CC||jamborm at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
This
MEM[(struct __class_poly_list_Node_type_p *)node] = node_17;
MEM[(struct __class_poly_list_Node_type_p *)node + 4B] =
__vtab_poly_list_Node_type;
MEM[(struct node_type *)integer_node_4].next = VIEW_CONVERT_EXPRstruct
__class_poly_list_Node_type_p(MEM[(struct __class_poly_list_Node_type
)node]);
certainly looks suspicious - we store to node with alias type
(struct __class_poly_list_Node_type_p *) and load from the same location
with alias type (struct __class_poly_list_Node_type ).
Now, the frontend generated code doesn't have the above as it appears only
via some inlining:
append_node (struct list_type restrict list, struct
__class_poly_list_Node_type new_node)
{
...
_9 = list_4(D)-tail._data;
_9-next = VIEW_CONVERT_EXPRstruct
__class_poly_list_Node_type_p(*new_node_6(D));
and
_19 = __builtin_malloc (16);
node._data = _19;
...
_26 = node._data;
__builtin_memset (_26, 0, 16);
node._vptr = __vtab_poly_list_Node_type;
_29 = node._vptr;
_30 = _29-_size;
_31 = (unsigned long) _30;
_32 = node._vptr;
_33 = _32-_def_init;
_34 = node._data;
__builtin_memcpy (_34, _33, _31);
append_node (list, node);
It is early SRA that re-materializes in that way before the aggregate
copy:
MEM[(struct __class_poly_list_Node_type_p *)node] = node$_data_28;
MEM[(struct __class_poly_list_Node_type_p *)node + 8B] = node$_vptr_20;
list.head = VIEW_CONVERT_EXPRstruct
__class_poly_list_Node_type_p(MEM[(struct __class_poly_list_Node_type
)node]);
Access trees for node (UID: 1941):
access { base = (1941)'node', offset = 0, size = 128, expr = node, type =
struct __class_poly_list_Node_type_p, grp_read = 1, grp_write = 1,
grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 0,
grp_scalar_write = 0, grp_total_scalarization = 1, grp_hint = 1, grp_covered =
1, grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_partial_lhs =
0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0, grp_maybe_modified =
0, grp_not_necessarilly_dereferenced = 0
* access { base = (1941)'node', offset = 0, size = 64, expr = node._data, type
= struct node_type *, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 1, grp_scalar_write = 1,
grp_total_scalarization = 1, grp_hint = 1, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_partial_lhs = 0,
grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0, grp_maybe_modified = 0,
grp_not_necessarilly_dereferenced = 0
* access { base = (1941)'node', offset = 64, size = 64, expr = node._vptr, type
= struct __vtype_poly_list_Node_type * {ref-all}, grp_read = 1, grp_write = 1,
grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 1,
grp_scalar_write = 1, grp_total_scalarization = 1, grp_hint = 1, grp_covered =
1, grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_partial_lhs =
0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0, grp_maybe_modified =
0, grp_not_necessarilly_dereferenced = 0
that replacement is not 100% correct. Coming from
Therefore, I specially handle a fourth case, happening when there is a
specific type cast or it is impossible to locate a scalarized subaccess on
the other side of the expression. If that happens, I simply refresh the
RHS by storing in it is scalarized components leave the original statement
there to do the copying and then load the scalar replacements of the LHS.
This is what the first branch does. */
if (modify_this_stmt
|| gimple_has_volatile_ops (*stmt)
|| contains_vce_or_bfcref_p (rhs)
|| contains_vce_or_bfcref_p (lhs))
{
with
list.head = VIEW_CONVERT_EXPRstruct __class_poly_list_Node_type_p(MEM[(struct
__class_poly_list_Node_type )node]);
build_ref_for_offset ends up creating a MEM_REF with different alias pointer
type than the original (note that there may be multiple originals and
AFAIK we don't make any attempt to merge them conservatively).
Re-materializing the original variable will always be hard. I believe that
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c (revision 198420)
+++ gcc/tree-sra.c (working copy)
@@ -3158,7 +3158,7 @@ sra_modify_assign (gimple *stmt, gimple_
if (modify_this_stmt
|| gimple_has_volatile_ops (*stmt)
- || contains_vce_or_bfcref_p (rhs)
+ || contains_bitfld_comp_ref_p (rhs)
||
[Bug target/57293] [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||i686-w64-mingw32 Target Milestone|--- |4.8.1
[Bug middle-end/57286] [4.9 regression] infinite recursion in fold-const.c:10037
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- Should be fixed by r198964 (sorry, I changed my mind about where to break the cycle). Could you check that it works now? Thanks for the report.
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #21 from Frédéric Buclin LpSolit at netscape dot net --- (In reply to Tobias Burnus from comment #20) Since the update, the Bugzilla favicon is shown, before the GCC one was shown: Fixed.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 30132
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30132action=edit
gcc49-pr57300.patch
We can actually use epilogue_completed, while that is set already a few passes
before peephole2, the only split it runs is on eh_return immediately after
setting it, so it won't split this (and even if it would, it is not a
wrong-code matter, just missed-optimization). But, generally we then peephole2
this fine if possible (reg is dead), or split4. Tested:
long long c;
void
foo (int a)
{
c = a;
}
where the reg is indeed dead to verify. So is this approach reasonable, at
least for 4.8.1?
[Bug lto/57290] [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I'm trying to reproduce it. Can you on your side verify whether dropping -ftree-loop-linear changes anything with respect to the regression? Also what does (6) -Ofast -funroll-loops -fwhole-program numbers look like? Because if you factor in LTO then you should compare against a revision that includes 2013-04-26 Richard Biener rguent...@suse.de * Makefile.in (lto-streamer-in.o): Add $(CFGLOOP_H) dependency. (lto-streamer-out.o): Likewise. * cfgloop.c (init_loops_structure): Export, add struct function argument and adjust. (flow_loops_find): Adjust. * cfgloop.h (enum loop_estimation): Add EST_LAST. (init_loops_structure): Declare. * lto-streamer-in.c: Include cfgloop.h. (input_cfg): Input the loop tree. * lto-streamer-out.c: Include cfgloop.h. (output_cfg): Output the loop tree. (output_struct_function_base): Do not drop PROP_loops. I see (1) -Ofast -funroll-loops -fomit-frame-pointer -fwhole-program -flto (2) -Ofast -funroll-loops -fomit-frame-pointer -fwhole-program -flto -fprotect-parens revision:198332 198333 (1) 15.5+-.3 15.6+-.2 (2) 16.1+-.1 15.9+-.2 note that the PAREN_EXPR thing made me point at the extra copyprop pass. So there is a difference between -f[no-]protect-parens but between the revs I cannot see a regression. Are you testing 64bit or 32bit executables? On Intel or PPC? As you noted the non-monotonic behavior wrt inlining decisions it would be interesting if those differ for you, (5) rev. 198332 vs. 198333. Add -fdump-ipa-inline to the command-line and inspect the aermod.f90.wpa.047i.inline dumpfile, grepping for 'Inlined into'. I only see changes in estimated time/size but no real code changes. I do see code layout changes though and changes in LTRANS due to the extra copyprop pass. Note that if -flto makes things worse compared to just -fwhole-program (which it slightly does for me) then this is probably due to partitioning. So you may also want to check -flto -flto-partition=none (slightly easier to debug in the end - but without LTO it would be easiest).
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Steven Bosscher from comment #9)
(In reply to Jakub Jelinek from comment #6)
So supposedly
bool
split_dead_or_set_p (rtx insn, const_rtx x)
{
if (BLOCK_FOR_INSN (insn) == NULL)
return false; /* If cfg is gone, be conservative. */
if (df_note == NULL)
{
df_note_add_problem ();
df_analyze ();
}
return dead_or_set_p (insn, x);
}
could work. Steven, comments?
I don't think this will work. The fact that df_note != NULL does not
mean the notes are up-to-date.
It seems to me that after freeing the CFG, no pass should rely on the
REG_DEAD and REG_UNUSED notes if Eric's comment in PR57281 is correct:
That each pass is responsible for re-computing the notes if it needs
them. But I would much rather have the passes at least discard the
notes if the pass can't update them. After all, it's not just this
dead_or_set_p function that relies on these notes, but also single_set
and a bunch of other functions.
I agree that possibly bogus IL is a smoking gun that waits for this kind
of bugs to appear. If we do not want to pay the price of removing
notes can we at least have a flag that tells whether the NOTE problem
is up-to-date (and add verification that it indeed is - at least has
no bogus notes - when that flag is set)? We could introduce
a new PROP_rtl_notes for that.
As for the case in question in PR57281 - it shouldn't be hard for
postreload to remove REG_DEAD notes from all uses when it propagates
equivalencies, no?
Btw, as alternative to computing the NOTE problem at the start of split
we can also remove all notes which should be cheaper.
[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548 Ralf Baechle r...@linux-mips.org changed: What|Removed |Added CC||r...@linux-mips.org --- Comment #8 from Ralf Baechle r...@linux-mips.org --- FWIW, I'm also hitting the same compiler bug with vanilla GCC 4.7.2 and 4.8.0 compiling a heavily patched 3.4 kernel with LTO for a mips64-linux target. The error messages for gcc 4.7.2: LDFINAL .tmp_vmlinux1 In file included from include/net/sock.h:2119:0, from net/sunrpc/svcsock.c:1041, from :3662: net/sunrpc/svcsock.c: In function ‘svc_tcp_recvfrom’: net/sunrpc/svcsock.c:935:37: internal compiler error: in emit_move_insn, at expr.c:3435 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [/tmp/ccaNAG6q.ltrans1.ltrans.o] Error 1 make[1]: *** Waiting for unfinished jobs lto1: internal compiler error: in output_constructor_regular_field, at varasm.c:4821 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [/tmp/ccaNAG6q.ltrans0.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/lib64/gcc/mips64-lto-linux/4.7.2/../../../../mips64-lto-linux/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make: *** [.tmp_vmlinux1] Error 1 The error messages for gcc 4.8.0: LDFINAL .tmp_vmlinux1 net/sunrpc/svcsock.c: In function ‘svc_tcp_recvfrom’: net/sunrpc/svcsock.c:1104:0: internal compiler error: in emit_move_insn, at expr.c:3486 static int svc_tcp_recvfrom(struct svc_rqst *rqstp) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [/tmp/ccehFRUG.ltrans0.ltrans.o] Error 1 make[1]: *** Waiting for unfinished jobs net/unix/garbage.c: In function ‘scan_inflight’: net/unix/garbage.c:156:13: internal compiler error: in copy_to_mode_reg, at explow.c:641 static void scan_inflight(struct sock *x, void (*func)(struct unix_sock *), ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [/tmp/ccehFRUG.ltrans1.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/lib64/gcc/mips64-lto-linux/4.8.0/../../../../mips64-lto-linux/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make: *** [.tmp_vmlinux1] Error 1 I'm still working under the assumption that the builds are attempting to do something stupid but even if so, an ICE is not the proper way to bail out.
[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Ralf Baechle from comment #8) FWIW, I'm also hitting the same compiler bug with vanilla GCC 4.7.2 and 4.8.0 compiling a heavily patched 3.4 kernel with LTO for a mips64-linux target. Please upload a pre-processed test case. Since you're getting this with gcc-4.7.2 it's presumably not caused by r193539 as comment #1 indicated. Have you tried gcc trunk, just to see if it's been fixed there?
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
--- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com ---
I may be missing details, but I'm not sure we have a serious problem here. Note
that:
class A {
public:
A(){}
};
class B : virtual A {
};
class C : public B {};
int main () {
C c;
}
is fine. Thus, to be clear, isn't that the declared access doesn't matter.
The real issue seems that the complete rules of protected access are complex
and hard to, so to speak, summarize in the error message. Gaby?
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com --- If I understand correctly the issue, saying in enforce_access something like A::A(), declared protected, is inaccessible within this context instead of A::A() is protected within this context would be less confusing.
[Bug libstdc++/57283] missing typedefs in specialized std::mem_fn for member variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
--- Comment #5 from Lin Yi-Li record.nctu.cis91 at gmail dot com ---
(In reply to Jonathan Wakely from comment #4)
N.B. you can also do it with a nested std::bind expression and
std::logical_not
std::bind(std::logical_notint(),
std::bind(std::mem_fn(cls::value), std::placeholders::_1))
in C++14 that means you can provide a working not1 replacement:
templatetypename F
auto not1(F f)
{
return std::bind(std::logical_not(), std::bind(f,
std::placeholders::_1));
}
I understand the problem of std::mem_fn + member variable now.
Thank you for your explanation.
[Bug tree-optimization/57294] [4.9 Regression] ice in remove_described_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- We do not have a reference recorded from bar.isra.0 to func and then abort when we try to remove it. It's most probably a failure of cgraph_function_versioning during IPA-SRA because -fno-ipa-sra helps. I'll have a look at it myself but perhaps Honza will know where to look more quickly.
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #15 from Jason Merrill jason at gcc dot gnu.org ---
Yes, that would be an improvement to the diagnostic. But it seems to me that
there's a deeper issue here: I think both testcases should be ill-formed
because C::C can't form a pointer to its A base in order to try to call its
constructor. Just as in this testcase:
class A {
protected:
void g();
};
class B : virtual A { };
class C : public B {
void f() { ::A::g(); }
};
int main () {
C c;
}
Here if we could convert 'this' to an A*, we would be OK. Now, the magic
conversion for vbase construction is special, and the standard doesn't really
say how special; if it has special access (to go along with its special ability
to choose a specific subobject in a hierarchy that might have multiple bases of
the same type), the original testcase should be ok: we're calling a protected
member through a C object, which is fine by the rules for protected access. If
the constructor doesn't have special access, then it's ill-formed even if the
constructor is public.
I think a core issue is warranted. But for the mean time, making that change
to the diagnostic would be an improvement.
[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56548 --- Comment #10 from Ralf Baechle r...@linux-mips.org --- As I'm hitting this with LTO on a large test case it's non-trivial to extract a test case but I will try.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I agree that possibly bogus IL is a smoking gun that waits for this kind of bugs to appear. If we do not want to pay the price of removing notes can we at least have a flag that tells whether the NOTE problem is up-to-date (and add verification that it indeed is - at least has no bogus notes - when that flag is set)? We could introduce a new PROP_rtl_notes for that. We cannot be sure that the NOTE problem is up-to-date since DF doesn't update them on the fly; it's correct only right after calling df_analyze. As for the case in question in PR57281 - it shouldn't be hard for postreload to remove REG_DEAD notes from all uses when it propagates equivalencies, no? All the dataflow stuff is now handled by DF and I don't think that we should go backwards by asking again individual passes to fiddle with it. Btw, as alternative to computing the NOTE problem at the start of split we can also remove all notes which should be cheaper. Yes, that's another possibility.
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com --- I see, thanks Jason. Indeed, the behavior of various compilers I have here is inconsistent about the various variants of the testcase. Thus for now I'm going to test the diagnostic tweak with the plan of committing something and then immediately suspending the PR. If/when you have a DR # we can point to it in the Subject.
[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297 --- Comment #3 from gretay at gcc dot gnu.org --- Thanks a lot for the quick responses! Unfortunately, the frontend patch alone doesn't fix the problem, as Richard pointed out, but it may be needed for other reasons. The tree-sra patch fixes the test failure. If this is the right thing to do, can you please commit these changes? I applied both patches and tested for arm-none-eabi. No regression on qemu. Thank you, Greta
[Bug testsuite/57301] bit rotation is optimized in c but not c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- This regressed presumably with r131862 . Anyway, I don't think the rotate detection improvements should be backported to the release branches, therefore this will need to be FIXED in 4.9+ only.
[Bug rtl-optimization/57302] New: Should merge zeroing multiple consecutive memory locations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57302
Bug ID: 57302
Summary: Should merge zeroing multiple consecutive memory
locations
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msharov at users dot sourceforge.net
struct A { short a,b; A (void); };
A::A (void) : a(0),b(0) {}
void MoveA (const A* a, A* b) { *b = *a; }
Generates:
_ZN1AC2Ev:
movw$0, (%rdi)
movw$0, 2(%rdi)
ret
_Z5MoveAPK1APS_:
movl(%rdi), %eax
movl%eax, (%rsi)
ret
The optimizer can see that a and b are consecutive in memory and can merge the
memory movs into a single 4-byte mov, but does not do the same for the zeroing
code in the constructor. Merging the zeroing to movl, movq, and mov[au]ps (when
SSE is available), would produce smaller code and fewer memory accesses.
[Bug target/57293] [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #1 from Vladimir Makarov vmakarov at redhat dot com --- The change was done because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018 LRA misses some functionality for now for this kind of code. There will be no quick fix (I mean in a few days or even in 2 weeks) for this. But I am planning to fix it until end of June. Sorry.
[Bug target/57293] [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-16 Target Milestone|4.8.1 |4.8.2 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Thanks, postponing the fix for 4.8.2 then.
[Bug rtl-optimization/57303] New: struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
Bug ID: 57303
Summary: struct miscompiled at -O1 and above
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
With current gcc trunk, the code below is miscompiled at -O1 and higher
optimization levels on x86_64-linux-gnu, outputting '1' instead of '0' as
expected. This behavior appears in gcc 4.8.x and 4.7.x as well, but not in
4.6.x or earlier. It occurs in both 32-bit and 64-bit compiles.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130516 (experimental) [trunk revision 198967] (GCC)
$ gcc-trunk -O0 small.c
$ ./a.out
0
$ gcc-4.6 -O1 small.c
$ ./a.out
0
$ gcc-trunk -O1 small.c
$ ./a.out
1
$
-
int printf(const char *, ...);
struct S0
{
int f0;
};
struct S1
{
struct S0 f0;
};
struct S1 x = { {0} };
struct S1 y = { {1} };
static void
foo (struct S0 p)
{
struct S0 *l = y.f0;
*l = x.f0;
if (p.f0)
*l = *l;
}
int
main ()
{
foo(y.f0);
printf(%d\n, y.f0.f0);
return 0;
}
[Bug tree-optimization/57303] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-16 Component|rtl-optimization|tree-optimization Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Seems to come from the sink pass. But it is suspicious that nothing in gcc removes the following long before we get there: MEM[(struct S0 *)y] = MEM[(struct S0 *)y];
[Bug c++/17410] Specialization of nested template rejected because of unrelated declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17410 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| Known to fail|| --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- This has been fixed *long* time ago, in 4.5.x. To be safe I'm adding testcase in Comment #2 before closing the bug.
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Frédéric Buclin from comment #21) (In reply to Tobias Burnus from comment #20) Since the update, the Bugzilla favicon is shown, before the GCC one was shown: Fixed. Doesn't work here: $ curl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238 2/dev/null|grep ico still shows link rel=shortcut icon href=images/favicon.ico which is still the Bugzilla symbol instead of the GCC symbol: http://gcc.gnu.org/bugzilla/images/favicon.ico At the Sourceware site, it shows the correct favicon: http://sourceware.org/bugzilla/images/favicon.ico Did you by chance (only) fix it there?
[Bug web/52239] Upgrade GCC Bugzilla to 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239 --- Comment #23 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #22) Doesn't work here: Scratch that - the one was seemingly in the cache - despite force-reload. It *is* fixed.
[Bug c++/17410] Specialization of nested template rejected because of unrelated declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17410 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug rtl-optimization/57304] New: Revision 198896 segfaults building cpu2000 benchmark 176.gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304 Bug ID: 57304 Summary: Revision 198896 segfaults building cpu2000 benchmark 176.gcc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, mikestump at comcast dot net Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 30133 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30133action=edit Reduced testcase Started with r198896. $ ~/install/gcc/trunk/bin/gcc -c -m64 -fno-strict-aliasing -O3 -mcpu=power7 -funroll-loops c-parse.c c-parse.c: In function ‘yyparse’: c-parse.c:14:2: internal compiler error: Segmentation fault } ^ 0x105e29b7 crash_signal /home/pthaugen/src/gcc/trunk/gcc/gcc/toplev.c:333 0x108ab18c union_match_dups /home/pthaugen/src/gcc/trunk/gcc/gcc/web.c:138 0x108ab18c web_main /home/pthaugen/src/gcc/trunk/gcc/gcc/web.c:387 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 libitm/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Target||x86_64
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-16
Component|c |libitm
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
Confirmed with:
gcc version 4.9.0 20130516 (experimental) [trunk revision 198977] (GCC)
--cut here--
extern inline int __attribute__ ((__gnu_inline__, __always_inline__,
__artificial__))
_mm_popcnt_u64 (unsigned long long __X)
{
return __builtin_popcountll (__X);
}
int main (void)
{
int res = _mm_popcnt_u64 (0);
printf (Result res should be 0: %d\n, res);
return 0;
}
--cut here--
~/gcc-build/gcc/cc1 -O2 -msse4 -fgnu-tm 029.c
029.c: In function ‘main’:
029.c:2:1: error: inlining failed in call to always_inline ‘_mm_popcnt_u64’:
_mm_popcnt_u64 (unsigned long long __X)
^
029.c:9:7: error: called from here
int res = _mm_popcnt_u64 (0);
[Bug c++/17459] Spurious message when forgetting parentheses on call of member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Manuel can you help me reassessing this? I think we are doing much better.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|middle-end |tree-optimization --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- For some reason ccp1 pass doesn't fully propagate _mm_popcnt_u64 when -fgnu-tm is in effect, leaving: res_1 = _mm_popcnt_u64 (0); printf (Result res should be 0: %d\n, res_1); return 0; Without -fgnu-tm, the cpp1 tree dump reads: printf (Result res should be 0: %d\n, 0); return 0;
[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
So far I have not attempted to reproduce this myself and so do not
quite follow all the previous comments but...
(In reply to Richard Biener from comment #2)
build_ref_for_offset ends up creating a MEM_REF with different alias pointer
type than the original (note that there may be multiple originals and
AFAIK we don't make any attempt to merge them conservatively).
...it looks like the second arguments in
generate_subtree_copies (racc-first_child, racc-base, 0, 0, 0,
gsi, false, false, loc);
and
generate_subtree_copies (lacc-first_child, lacc-base, 0, 0, 0,
gsi, true, true, loc);
should be the rhs and lhs respectively, rather than [rl]acc-base.
Using rhs/lhs, the generated statements would have the same alias
pointer type as the respective sides of the original statement. Can
you try that? We should probably also change accordingly (almost all)
other calls to generate_subtree_copies (this code generally predates
generating MEM_REFs in build_ref_for_offset and this did not matter).
Re-materializing the original variable will always be hard. I believe that
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c (revision 198420)
+++ gcc/tree-sra.c (working copy)
@@ -3158,7 +3158,7 @@ sra_modify_assign (gimple *stmt, gimple_
if (modify_this_stmt
|| gimple_has_volatile_ops (*stmt)
- || contains_vce_or_bfcref_p (rhs)
+ || contains_bitfld_comp_ref_p (rhs)
|| contains_vce_or_bfcref_p (lhs))
{
if (access_has_children_p (racc))
should work.
Even though relaxing this condition might be a good idea to try to
generate better code, I'd be against fixing bugs this way, if we can
avoid it. This should be the safe path capable of handling everything
that the latter more sophisticated approaches might choke on. It
would make the already complex code more difficult to maintain and
sooner or later we'd hit the same problem again (I think it should be
possible use structures with a single field to create a testcase with
a similar problem and modify_this_stmt set to true, for example).
[Bug c++/17459] Spurious message when forgetting parentheses on call of member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459
--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #4)
Manuel can you help me reassessing this? I think we are doing much better.
I get this:
test.cc:3:19: error: invalid use of non-static member function
void bar() { foo; }
^
void S::bar3()
test.cc:5:18: error: ISO C++ forbids taking the address of an unqualified or
parenthesized non-static member function to form a pointer to member function.
Say ‘S::foo’ [-fpermissive]
void bar3() { foo; }
^
void* S::bar2()
test.cc:6:26: error: cannot convert ‘S::foo’ from type ‘void (S::)()’ to type
‘void*’
void * bar2() { return foo; }
^
The first error could be a bit nicer if it said why it is invalid. Clang does:
test.cc:3:16: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
but the thing is that this is not even a valid reference, so the error could
clarify a bit more the problem, no?
ISO C++ forbids taking the address of an unqualified non-static member
function, say ‘S::foo’ instead; or did you mean to call 'foo()'?
The last error is bogus, it should be the same as the first one. Clang gives
two errors, but at least the first is the correct one:
test.cc:6:26: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
void * bar2() { return foo; }
^~~
()
test.cc:6:26: error: cannot initialize return object of type 'void *' with an
rvalue of type 'void'
void * bar2() { return foo; }
^~~~
[Bug tree-optimization/57303] [4.7/4.8/4.9 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- It is caused by revision 170984: http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00405.html
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #6 from Ben Woodard woodard at redhat dot com --- Created attachment 30134 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30134action=edit reproducer program still working on getting access to the machine where I have ICC. My password expired.
[Bug c++/18126] sizeof compound-literal not parsed correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18126 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Looking into this.
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-16 CC||rth at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/57305] New: ICE with warnings and unlimited polymorphic (incorrect code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 Bug ID: 57305 Summary: ICE with warnings and unlimited polymorphic (incorrect code) Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com Created attachment 30135 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30135action=edit source The attached code produces ICE with recent build of 4.8: gfortran ice6.f90 -fopenmp -Wall f951: internal compiler error: NeoprĂĄvnÄĂ˝ pĹĂstup do pamÄi (SIGSEGV) 0x8ba79f crash_signal ../../gcc-4.8-20130509/gcc/toplev.c:332 0x5d6021 __gmpz_get_ui /usr/include/gmp.h:1744 0x5d6021 gfc_target_expr_size(gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/target-memory.c:143 0x5445cd gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned long*, unsigned long*, unsigned long*) ../../gcc-4.8-20130509/gcc/fortran/check.c:4028 0x544788 gfc_check_transfer(gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/check.c:4093 0x56dffa check_specific ../../gcc-4.8-20130509/gcc/fortran/intrinsic.c:3928 0x57ad1e gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc-4.8-20130509/gcc/fortran/intrinsic.c:4144 0x5b690f resolve_unknown_f ../../gcc-4.8-20130509/gcc/fortran/resolve.c:2602 0x5b690f resolve_function ../../gcc-4.8-20130509/gcc/fortran/resolve.c:3204 0x5b690f gfc_resolve_expr(gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/resolve.c:6544 0x5bc0a9 resolve_code ../../gcc-4.8-20130509/gcc/fortran/resolve.c:10135 0x5bbe8b gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-4.8-20130509/gcc/fortran/resolve.c:9449 0x5bc0ea resolve_code ../../gcc-4.8-20130509/gcc/fortran/resolve.c:10121 0x5bec4e resolve_codes ../../gcc-4.8-20130509/gcc/fortran/resolve.c:14975 0x5afb22 gfc_resolve ../../gcc-4.8-20130509/gcc/fortran/resolve.c:15003 0x5a4662 resolve_all_program_units ../../gcc-4.8-20130509/gcc/fortran/parse.c:4406 0x5a4662 gfc_parse_file() ../../gcc-4.8-20130509/gcc/fortran/parse.c:4673 0x5dfd15 gfc_be_parse_file ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189 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 tree-optimization/57303] [4.7/4.8/4.9 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- statement_sink_location in /* A killing definition is not a use. */ if (gimple_assign_single_p (use_stmt) gimple_vdef (use_stmt) operand_equal_p (gimple_assign_lhs (stmt), gimple_assign_lhs (use_stmt), 0)) continue; doesn't check: (gdb) call debug_gimple_stmt (use_stmt) # .MEM_11 = VDEF .MEM_10 y.f0 = y.f0;
[Bug fortran/57306] New: ICE on valid with class pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 Bug ID: 57306 Summary: ICE on valid with class pointer assignment Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com The following causes an ICE with gfortran 4.9.0 r198983: module t type :: c end type c type(c), target :: cd class(c), public, pointer :: cc = cd end module t $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.9.0 20130516 (experimental) (GCC) $ gfortran -c bug.F90 -o bug.o bug.F90:7:0: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:6027 class(c), public, pointer :: cc = cd ^ 0x5be449 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-trunk/gcc/fortran/trans-expr.c:6027 0x5be610 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:5606 0x5a8cd6 gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.c:1500 0x5aeb02 gfc_create_module_variable ../../gcc-trunk/gcc/fortran/trans-decl.c:4144 0x572ed3 do_traverse_symtree ../../gcc-trunk/gcc/fortran/symbol.c:3571 0x5aef52 gfc_generate_module_vars(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:4543 0x588ec1 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:1738 0x547687 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4456 0x547687 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4666 0x583a25 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 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 fortran/57305] ICE with warnings and unlimited polymorphic (incorrect code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #1 from Vladimir Fuka vladimir.fuka at gmail dot com --- Created attachment 30136 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30136action=edit ice7.f90 (second source)
[Bug fortran/57305] ICE with warnings and unlimited polymorphic (incorrect code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #2 from Vladimir Fuka vladimir.fuka at gmail dot com --- Connected error: gfortran -Wall -c ice7.f90 ice7.f90: In function âadd_element_polyâ: ice7.f90:25:0: internal compiler error: in lhd_incomplete_type_error, at langhooks.c:203 dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e)) ^ 0x7d3bbc lhd_incomplete_type_error(tree_node const*, tree_node const*) ../../gcc-4.8-20130509/gcc/langhooks.c:203 0xa200db size_in_bytes(tree_node const*) ../../gcc-4.8-20130509/gcc/tree.c:2379 0x61748f gfc_conv_intrinsic_sizeof ../../gcc-4.8-20130509/gcc/fortran/trans-intrinsic.c:5209 0x61df6d gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-intrinsic.c:6824 0x6098e2 gfc_conv_function_expr ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:5547 0x609dca gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6258 0x6058da gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:4230 0x60992a gfc_conv_function_expr ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:5566 0x609dca gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6258 0x60f3a6 gfc_trans_assignment_1 ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:7739 0x5e3975 trans_code ../../gcc-4.8-20130509/gcc/fortran/trans.c:1422 0x6274c8 gfc_trans_if_1 ../../gcc-4.8-20130509/gcc/fortran/trans-stmt.c:965 0x627454 gfc_trans_if_1 ../../gcc-4.8-20130509/gcc/fortran/trans-stmt.c:988 0x62cb7a gfc_trans_if(gfc_code*) ../../gcc-4.8-20130509/gcc/fortran/trans-stmt.c:1015 0x5e37d7 trans_code ../../gcc-4.8-20130509/gcc/fortran/trans.c:1519 0x600c92 gfc_generate_function_code(gfc_namespace*) ../../gcc-4.8-20130509/gcc/fortran/trans-decl.c:5397 0x5a49d0 translate_all_program_units ../../gcc-4.8-20130509/gcc/fortran/parse.c:4474 0x5a49d0 gfc_parse_file() ../../gcc-4.8-20130509/gcc/fortran/parse.c:4688 0x5dfd15 gfc_be_parse_file ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189 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 fortran/57305] ICE with warnings and unlimited polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #3 from Vladimir Fuka vladimir.fuka at gmail dot com --- The first one is incorrect code, the other one compiles with ifort 13.1.
[Bug fortran/57306] [OOP] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-16 CC||janus at gcc dot gnu.org Summary|ICE on valid with class |[OOP] ICE on valid with |pointer assignment |class pointer ||initialization Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed with 4.7, 4.8 and trunk.
[Bug middle-end/56552] conditional move can generate unnecessary conversion code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- I've probably missed the bigger picture here, but FWIW, I don't see any problem with extending *movGPR:mode_on_MOVECC:mode to QI and HI. I suppose it would just be a case of replacing GPR in that pattern with a new iterator.
[Bug middle-end/56552] conditional move can generate unnecessary conversion code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552 --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #4) I've probably missed the bigger picture here, but FWIW, I don't see any problem with extending *movGPR:mode_on_MOVECC:mode to QI and HI. I suppose it would just be a case of replacing GPR in that pattern with a new iterator. Er, to be clear: I mean doing that on top of anything else that might be needed. Andrew's patch still looks good too.
[Bug fortran/57307] New: ICE with sourced allocation with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57307 Bug ID: 57307 Summary: ICE with sourced allocation with array constructor Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com integer,allocatable :: a(:) integer :: e allocate(a,source=[e]) end produces: gfortran -c ice8.f90 f951: internal compiler error: NeoprĂĄvnÄĂ˝ pĹĂstup do pamÄi (SIGSEGV) 0x8ba79f crash_signal ../../gcc-4.8-20130509/gcc/toplev.c:332 0x5bab06 conformable_arrays ../../gcc-4.8-20130509/gcc/fortran/resolve.c:7077 0x5bab06 resolve_allocate_expr ../../gcc-4.8-20130509/gcc/fortran/resolve.c:7247 0x5bab06 resolve_allocate_deallocate ../../gcc-4.8-20130509/gcc/fortran/resolve.c:7670 0x5bcf56 resolve_code ../../gcc-4.8-20130509/gcc/fortran/resolve.c:10335 0x5bec4e resolve_codes ../../gcc-4.8-20130509/gcc/fortran/resolve.c:14975 0x5afb22 gfc_resolve ../../gcc-4.8-20130509/gcc/fortran/resolve.c:15003 0x5a4662 resolve_all_program_units ../../gcc-4.8-20130509/gcc/fortran/parse.c:4406 0x5a4662 gfc_parse_file() ../../gcc-4.8-20130509/gcc/fortran/parse.c:4673 0x5dfd15 gfc_be_parse_file ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189 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. lada@meop37:~/f/testy/errors lada@meop37:~/f/testy/errors lada@meop37:~/f/testy/errors gfortran -c ice8.f90 f951: internal compiler error: NeoprĂĄvnÄĂ˝ pĹĂstup do pamÄi (SIGSEGV) 0x8ba79f crash_signal ../../gcc-4.8-20130509/gcc/toplev.c:332 0x5bab06 conformable_arrays ../../gcc-4.8-20130509/gcc/fortran/resolve.c:7077 0x5bab06 resolve_allocate_expr ../../gcc-4.8-20130509/gcc/fortran/resolve.c:7247 0x5bab06 resolve_allocate_deallocate ../../gcc-4.8-20130509/gcc/fortran/resolve.c:7670 0x5bcf56 resolve_code ../../gcc-4.8-20130509/gcc/fortran/resolve.c:10335 0x5bec4e resolve_codes ../../gcc-4.8-20130509/gcc/fortran/resolve.c:14975 0x5afb22 gfc_resolve ../../gcc-4.8-20130509/gcc/fortran/resolve.c:15003 0x5a4662 resolve_all_program_units ../../gcc-4.8-20130509/gcc/fortran/parse.c:4406 0x5a4662 gfc_parse_file() ../../gcc-4.8-20130509/gcc/fortran/parse.c:4673 0x5dfd15 gfc_be_parse_file ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189 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 c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314 --- Comment #17 from Jason Merrill jason at gcc dot gnu.org --- Actually, this seems to be issue 7: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7 So we should reject the variant with a public constructor as well. It would be good to get the same diagnostic as in comment #4.
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314 --- Comment #18 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jason Merrill from comment #17) It would be good to get the same diagnostic as in comment #4. And also give a warning about the private virtual base.
[Bug c++/57279] [C++11] alias declaration fails to declare function types with cv-qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-16 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.8.1 Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/56547] [SH] missed opportunity for fmac with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-16 Component|target |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- This looks like a tree optimization issue. In tree-ssa-math-ops.c, the function 'convert_mult_to_fma' bails out in the first for-each at: if (!is_gimple_assign (use_stmt)) return false; Apart from that, it still might be a good idea to put the SH fmac combine patterns back, which I removed when adding support for the FMA patterns. The following should do. Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md(revision 198802) +++ gcc/config/sh/sh.md(working copy) @@ -12285,6 +12285,29 @@ fmac.s %1, %2, %0 [(set_attr type fparith_media)]) +;; For some cases such as 'a * b + a' the FMA pattern is not generated by +;; previous transformations. If FMA is generally allowed, let the combine +;; pass utilize it. +(define_insn *fmasf4 + [(set (match_operand:SF 0 fp_arith_reg_operand =f) +(plus:SF (mult:SF (match_operand:SF 1 fp_arith_reg_operand %w) + (match_operand:SF 2 fp_arith_reg_operand f)) + (match_operand:SF 3 arith_reg_operand 0))) +(use (match_operand:PSI 4 fpscr_operand c))] + TARGET_SH2E flag_fp_contract_mode != FP_CONTRACT_OFF + fmac%1,%2,%0 + [(set_attr type fp) + (set_attr fp_mode single)]) + +(define_insn *fmasf4_media + [(set (match_operand:SF 0 fp_arith_reg_operand =f) +(plus:SF (mult:SF (match_operand:SF 1 fp_arith_reg_operand %f) + (match_operand:SF 2 fp_arith_reg_operand f)) + (match_operand:SF 3 fp_arith_reg_operand 0)))] + TARGET_SHMEDIA_FPU flag_fp_contract_mode != FP_CONTRACT_OFF + fmac.s %1, %2, %0 + [(set_attr type fparith_media)]) + (define_expand divsf3 [(set (match_operand:SF 0 arith_reg_operand ) (div:SF (match_operand:SF 1 arith_reg_operand )
[Bug bootstrap/57266] [4.9 regression] comparison between signed and unsigned integer expressions in fold_binary_loc breaks m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57266 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- r198880 | glisse | 2013-05-14 14:06:27 +0200 (Tue, 14 May 2013) | 8 lines 2013-05-14 Marc Glisse marc.gli...@inria.fr PR bootstrap/57266 * fold-const.c (fold_binary_loc) shift: Use an unsigned variable for the shift amount. Check that we shift by non-negative amounts.
[Bug rtl-optimization/57304] Revision 198896 segfaults building cpu2000 benchmark 176.gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304
mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #1 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org ---
DF_REF_LOC has:
DF_REF_CLASS(REF) == DF_REF_REGULAR ?
in it, but
DF_REF_REAL_LOC
does not. :-( So, does:
Index: web.c
===
--- web.c(revision 198909)
+++ web.c(working copy)
@@ -133,9 +133,10 @@ union_match_dups (rtx insn, struct web_e
entry = type == OP_IN ? use_entry : def_entry;
for (; *ref; ref++)
{
- if (DF_REF_LOC (*ref) == recog_data.operand_loc[op])
+ rtx *l = DF_REF_LOC (*ref);
+ if (l == recog_data.operand_loc[op])
break;
- if (DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op])
+ if (l DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op])
break;
}
@@ -143,9 +144,10 @@ union_match_dups (rtx insn, struct web_e
{
for (ref = use_link, entry = use_entry; *ref; ref++)
{
- if (DF_REF_LOC (*ref) == recog_data.operand_loc[op])
+ rtx *l = DF_REF_LOC (*ref);
+ if (l == recog_data.operand_loc[op])
break;
- if (DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op])
+ if (l DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op])
break;
}
}
fix the problem? This copies the style of the other uses of this macro, so, it
should be correct.
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #7 from Ben Woodard woodard at redhat dot com --- Created attachment 30137 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30137action=edit t_repro.c compiled -g -O2
[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 30138 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30138action=edit frontend patch, second try This variant reduces the amount of VIEW_CONVERT_EXPR, which should make the code less confusing downstream.
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314 --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com --- I see, thanks.
[Bug rtl-optimization/57308] New: DF_REF_REAL_LOC segfault in web.c:union_match_dups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308 Bug ID: 57308 Summary: DF_REF_REAL_LOC segfault in web.c:union_match_dups Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Program received signal SIGSEGV, Segmentation fault. 0x10af1214 in _ZL8web_mainv () at /nasfarm/dje/src/src/gcc/web.c:138 138 if (DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op]) This recent change causes segfaults on 32 bit POWER AIX. This fails for libgomp vla1.f90, vla2.f90, vla4.f90, vla5.f90, vla6.f90, vla8.f90 -O3 -funroll-all-loops -fopenmp and gcc.dg/torture/stackalign/setjmp-1.c and gcc.c-torture/execute/built-in-setjmp.c -O3 -funroll-all-loops
[Bug rtl-optimization/57308] [4.9 Regression] DF_REF_REAL_LOC segfault in web.c:union_match_dups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-17 CC||mikestump at comcast dot net Summary|DF_REF_REAL_LOC segfault in |[4.9 Regression] |web.c:union_match_dups |DF_REF_REAL_LOC segfault in ||web.c:union_match_dups Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/57308] [4.9 Regression] DF_REF_REAL_LOC segfault in web.c:union_match_dups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I think this is a dup of bug 57304.
[Bug rtl-optimization/57304] Revision 198896 segfaults building cpu2000 benchmark 176.gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57304 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #2 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- *** Bug 57308 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/57308] [4.9 Regression] DF_REF_REAL_LOC segfault in web.c:union_match_dups
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57308 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mrs at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- The fix for PR57304 needs to resolve this issue as well/ *** This bug has been marked as a duplicate of bug 57304 ***
[Bug target/57309] New: Spill code degrades vectorized loop for 437.leslie3d on PPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57309 Bug ID: 57309 Summary: Spill code degrades vectorized loop for 437.leslie3d on PPC64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org CC: bergner at vnet dot ibm.com Host: powerpc*-*-* Target: powerpc*-*-* Build: powerpc*-*-* Note: This bug does NOT occur on current trunk. To reproduce, it's necessary to patch config/rs6000/rs6000.h so that MALLOC_ABI_ALIGNMENT is defined as: #define MALLOC_ABI_ALIGNMENT (TARGET_64BIT ? 128 : 64) This allows more vectorization opportunities for loops that access malloc'd arrays that can be vectorized with 128-bit vectors. I observed that making this change introduces a degradation of SPEC CPU2006 437.leslie3d, built for 64-bit PowerPC Linux. There are a number of degraded loops in the code, which seem to all be pretty similar. In all cases the loops are vectorized with and without the patch, but with the patch there is no need for prolog code to align the data. Unfortunately, with the patch, the loops also contain a great deal of spill code (ld, addi, lxvd2x, stxvd2x) which reloads not only vector registers, but also GPRs used for address computation of vector loads and stores. Without the spill code, the main loop body would be vectorized identically with and without the patch. One of the worst degraded loops is in function fluxk. I have oprofile data available to identify the loop as well as some dumps showing how the loop is transformed in various phases, available by request.
[Bug libstdc++/50160] vectorbool comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 jandyu rata amandalionard at gmail dot com changed: What|Removed |Added CC||amandalionard at gmail dot com --- Comment #37 from jandyu rata amandalionard at gmail dot com --- “It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward.” http://rajasthanispecial.com/index.php/womens-collection/sarees.html
