https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #59 from Martin Jambor ---
(In reply to Jan Hubicka from comment #36)
> We end up with algnment unkonwn instead of a. (did not managed to reproduce
> the wrong alignment here). What about the following:
It is certainly better than w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #58 from Markus Trippelsdorf ---
The Firefox issue from comment #49 is fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #57 from Jan Hubicka ---
> Another issue is propagate_constants_accross_call has
>
> for (; (i < args_count) && (i < parms_count); i++)
> {
> struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
> stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #56 from Jan Hubicka ---
Author: hubicka
Date: Thu Feb 19 23:31:40 2015
New Revision: 220826
URL: https://gcc.gnu.org/viewcvs?rev=220826&root=gcc&view=rev
Log:
PR ipa/65028
* ipa-cp.c (propagate_alignment_accross_jump_functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #55 from H.J. Lu ---
Another issue is propagate_constants_accross_call has
for (; (i < args_count) && (i < parms_count); i++)
{
struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
struct ipcp_param_la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #54 from Jan Hubicka ---
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 440ced4..3bf068a 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -1451,7 +1451,7 @@ propagate_alignment_accross_jump_function (struct
> cgraph_edge *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #53 from H.J. Lu ---
(In reply to Martin Jambor from comment #52)
> So, as you might have guessed from the previous comment, this is the
> fix. I should have left the office half an hour ago so I will
> properly bootstrap and test an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #52 from Martin Jambor ---
So, as you might have guessed from the previous comment, this is the
fix. I should have left the office half an hour ago so I will
properly bootstrap and test and submit it tomorrow, but feel free to
do all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #51 from Martin Jambor ---
So unless I made some mistake, we are looking a the following chain of
calls and aliases
main/48071 -> _ZN18eonImageCalculatorC1Ev/50391 ->alias->
_ZN18eonImageCalculatorC2Ev/50390 ->
->_ZN12ggPhotometerC1E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #50 from Martin Jam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #49 from Markus Trippelsdorf ---
The same issue also happen when I build Firefox on my amdfam10 testbox.
With "-flto -march=native" Firefox crashes:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff9a5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
H.J. Lu changed:
What|Removed |Added
Attachment #34793|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #48 from H.J. Lu ---
(In reply to Martin Jambor from comment #46)
> release_ssa is an early optimization pass, wpa dump is not helpful.
> We need release-ssa dump from the compilation stage (as opposed to the
> linking stage) of the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #46 from Martin Jambor ---
(In reply to H.J. Lu from comment #45)
>
> Can you see anything wrong with the new dump?
release_ssa is an early optimization pass, wpa dump is not helpful.
We need release-ssa dump from the compilation st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #45 from H.J. Lu ---
(In reply to Martin Jambor from comment #43)
>
> I really find it very suspicious that even the jump-function printing
> code, which is a an iteration over edges as simple as they get, does
> not see the wrong cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #44 from H.J. Lu ---
Created attachment 34804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34804&action=edit
Dumps from -fdump-ipa-cp-details -fdump-tree-release_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #43 from Martin Jambor ---
(In reply to H.J. Lu from comment #42)
> Does it skip a jump func when its argument alignment is unknown?
No, I don't think it does. Cur is initialized to unknown alignment
and then only overwrites the who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #42 from H.J. Lu ---
(In reply to Martin Jambor from comment #41)
> (In reply to H.J. Lu from comment #24)
> >
> > IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
> > _ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.
>
> If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #41 from Martin Jambor ---
(In reply to H.J. Lu from comment #24)
>
> IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
> _ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.
If I am not mistaken and this call is in between nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #40 from Jan Hubicka ---
Do you know why propagate_constants_accross_call skippes the call? Is it
because it is never called on it or is it because it quits on one of the early
exits?
It may be a case that we produce wrong strongly c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #39 from H.J. Lu ---
(In reply to Jan Hubicka from comment #38)
> Created attachment 34803 [details]
> ipp
>
> OK. Though I do not directly see how it can solve this wrong code issue.
It doesn't work. propagate_constants_accross_ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #38 from Jan Hubicka ---
OK. Though I do not directly see how it can solve this wrong code issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #36 from Jan Hubicka ---
Hi,
I do not really see the reason for wrong code, but the merging logic seems
weird for me. There is no merging done when we get two different alignments
and also we seem to immediately drop lattice to botto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #37 from H.J. Lu ---
(In reply to Jan Hubicka from comment #36)
> Hi,
> I do not really see the reason for wrong code, but the merging logic seems
> weird for me. There is no merging done when we get two different alignments
> and al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #35 from Jan Hubicka ---
> propagate_alignment_accross_jump_function seems wrong:
>
> if (cur.known)
> {
> if (!dest_lat->alignment.known)
> {
> dest_lat->alignment = cur;
> return true;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #34 from H.J. Lu ---
propagate_alignment_accross_jump_function seems wrong:
if (cur.known)
{
if (!dest_lat->alignment.known)
{
dest_lat->alignment = cur;
return true;
}
We can't ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #33 from H.J. Lu ---
There are many calls to _ZmlRK10ggSpectrumS1_ in LTO IR. Some calls have
parameters with unknown alignment. But they are ignored by IPA-CP, which
applies parameter alignment from calls with known parameter alignm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #32 from H.J. Lu ---
_ZN18eonImageCalculatorC2Ev has an alias, _ZN18eonImageCalculatorC1Ev.
It is only called once in main. _ZN18eonImageCalculatorC1Ev calls
_ZmlRK10ggSpectrumS1_. But _ZN18eonImageCalculatorC1Ev is ignored
by ipa_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #31 from H.J. Lu ---
If I dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #30 from Jan Hubicka ---
>
> I uploaded a patch to check all aliases for parameter alignments. It
> fixes eon on x32.
Thanks for looking into this. The bug is however a bit earlier. The
propagation
stage should never put anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #29 from H.J. Lu ---
Created attachment 34797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34797&action=edit
A reorg patch
This patch should be a no-op. But it changes parameter
alignments for _ZmlRK10ggSpectrumS1_. It look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #28 from H.J. Lu ---
(In reply to H.J. Lu from comment #26)
> (In reply to H.J. Lu from comment #24)
> > (In reply to H.J. Lu from comment #18)
> > > There are
> > >
> > > ;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #27 from H.J. Lu ---
Created attachment 34794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34794&action=edit
A patch
We should check all aliases for parameter alignments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #26 from H.J. Lu ---
(In reply to H.J. Lu from comment #24)
> (In reply to H.J. Lu from comment #18)
> > There are
> >
> > ;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, decl_uid=4292,
> > cgraph_uid=5, symbol_order=465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #25 from H.J. Lu ---
IPA dump uses node->name () instead of node->asm_name ().
node->name () is kind of useless here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #24 from H.J. Lu ---
(In reply to H.J. Lu from comment #18)
> There are
>
> ;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, decl_uid=4292,
> cgraph_uid=5, symbol_order=46520)
>
> Modification phase of node operator*/465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #23 from H.J. Lu ---
(In reply to Jan Hubicka from comment #20)
> The -fipa-cp-alignment patch looks like a resonable idea. These days you
> want to check opt_for_fn (decl, flag_ipa_cp_alignment). Ok with that change
> and documentat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #22 from H.J. Lu ---
Created attachment 34793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34793&action=edit
Dumps from -fdump-ipa-cp-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #21 from H.J. Lu ---
(In reply to Martin Jambor from comment #19)
> HJ, how do I configure build an x32 gcc? I have working x32 debian
> chroot environment but building gcc fails with:
I suggest you use Ubuntu 14.04 or newer.
> che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #20 from Jan Hubicka ---
H.J. Can you, please attach the full .cp dump file and release_ssa dump of the
corresponding functions?
The -fipa-cp-alignment patch looks like a resonable idea. These days you want
to check opt_for_fn (decl,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #19 from Martin Jambor ---
HJ, how do I configure build an x32 gcc? I have working x32 debian
chroot environment but building gcc fails with:
checking for int64_t underlying type... long long
configure: error: error verifying int64_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #18 from H.J. Lu ---
There are
;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, decl_uid=4292,
cgraph_uid=5, symbol_order=46520)
Modification phase of node operator*/46520
Adjusting alignment of param 1 to 16, misalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
H.J. Lu changed:
What|Removed |Added
Attachment #34791|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #16 from H.J. Lu ---
Created attachment 34791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34791&action=edit
A patch to add -fipa-cp-alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #15 from H.J. Lu ---
(In reply to Jan Hubicka from comment #14)
> Thanks for looking into that!
> >
> > Why do we think rPrimary is 16-byte aligned when it is only 8-byte aligned?
>
> ipa-cp newly does alignment propagation. You ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #14 from Jan Hubicka ---
Thanks for looking into that!
>
> Why do we think rPrimary is 16-byte aligned when it is only 8-byte aligned?
ipa-cp newly does alignment propagation. You may try to just disable it
by short cirucuiting ipc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #13 from H.J. Lu ---
(In reply to Jan Hubicka from comment #12)
> I agree it is probably differnt issue, but lets see. It would help if you
> can look at the backtract and see if there is a problem between
> local/non-local calling co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #12 from Jan Hubicka ---
I agree it is probably differnt issue, but lets see. It would help if you can
look at the backtract and see if there is a problem between local/non-local
calling conventions. I.e. function called with paramet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #11 from H.J. Lu ---
(In reply to Martin Jambor from comment #10)
> (In reply to H.J. Lu from comment #9)
> > The same bug affects 252.eon in SPEC CPU 2000 on x32:
>
> ...
>
> >
> > The fix isn't sufficient since adding -fno-ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #10 from Martin Jambor ---
(In reply to H.J. Lu from comment #9)
> The same bug affects 252.eon in SPEC CPU 2000 on x32:
...
>
> The fix isn't sufficient since adding -fno-ipa-cp fixes eon on x32.
I really doubt that it is "the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 13 20:04:32 2015
New Revision: 220693
URL: https://gcc.gnu.org/viewcvs?rev=220693&root=gcc&view=rev
Log:
PR ipa/65028
* ipa-inline-transform.c (mark_all_inlined_calls_cdt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #7 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 13 20:05:39 2015
New Revision: 220694
URL: https://gcc.gnu.org/viewcvs?rev=220694&root=gcc&view=rev
Log:
PR ipa/65028
* ipa-prop.c (update_indirect_edges_after_inlining):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #5 from Jan Hubicka ---
>
> 2015-02-13 Martin Jambor
>
> PR ipa/65028
> * ipa-inline-transform.c (mark_all_inlined_calls_cdtor): New function.
> (inline_call): Use it.
Oops, that is quite an oversight at my side. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #4 from Martin Jambor ---
OK, so here are my findings. Switching off IPA-CP helps because the
pass then does not propagate polymorphic context from
_ZN8MySoPlexC2EN6soplex6SoPlex4TypeENS1_14RepresentationE/5887 to
_ZN6soplex9SPxSolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Martin Jambor changed:
What|Removed |Added
CC|mjambor at suse dot cz |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
61 matches
Mail list logo
