https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61301
--- Comment #4 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #3)
> _3 = MEM[(const float *)this_1(D) + 4B];
> _4 = MEM[(const float *)this_1(D)];
> _5 = MEM[(const float *)this_1(D) + 12B];
> _6 = MEM[(const float *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #34 from Thomas Preud'homme ---
Ok, committed then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #32 from Thomas Preud'homme ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #31)
> > --- Comment #30 from Thomas Preud'homme
> > ---
> > Can you run the test manually under gdb and tell me what is the value for
> > the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #30 from Thomas Preud'homme ---
Can you run the test manually under gdb and tell me what is the value for the
"out" variable in hex format?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #28 from Thomas Preud'homme ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #22)
> > --- Comment #21 from Thomas Preud'homme
> > ---
> >
> > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to
> > c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #26 from Thomas Preud'homme ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #25)
>
> Ah, I see: write-after-approval maintainers do get bugzilla write
> access, but your not according to the MAINTAINERS file.
Oups, my mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #24 from Thomas Preud'homme ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #22)
>
> I'm giving both patches combined a try right now, though SPARC bootstrap
> will take 7+ hours to complete.
Great, thanks.
>
> Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #23 from Thomas Preud'homme ---
(In reply to Eric Botcazou from comment #20)
>
> > Maybe a better solution for sparc would be to add a switch for this pass and
> > disable it by default on sparc. What do you think about that?
>
> Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #21 from Thomas Preud'homme ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #19)
>
> I've now regtested that patch on sparc-sun-solaris2.11 (compared to a
> bootstrap without java before) and i386-pc-solaris2.11. No regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #18 from Thomas Preud'homme ---
(In reply to Eric Botcazou from comment #16)
> > unsigned int foo (unsigned short *x)
> > {
> > return x[0] << 16 | x[1];
> > }
> >
> > [...]
> > gets you
> >
> > foo:
> > lduh[%o0], %g1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #17 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #12)
>
> I'd say
>
> Index: tree-ssa-math-opts.c
> ===
> --- tree-ssa-math-opts.c(revis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #10 from Thomas Preud'homme ---
So I am testing the patch right now and should be able to send it tomorrow.
However, the code already shall already mark the load with the actual alignment
the access is being done with. Therefore it se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #9 from Thomas Preud'homme ---
Sorry, I didn't realize it was preventing bootstrap. I have a small patch that
disable the optimization for STRICT_ALIGNMENT target but was reluctant to use
it as is because this effectively disable this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #5 from Thomas Preud'homme ---
I have a working patch that also pass bootstrap. I'll do a bit more testing and
post it for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328
--- Comment #4 from Thomas Preud'homme ---
Oh I think I see. When I wrote find_bswap_or_nop_load () I assumed that it
would only return in find_bswap_or_nop_1 as called in the GIMPLE_UNARY_RHS
case. It seems I was wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #4 from Thomas Preud'homme ---
I finally managed to find the root cause for the bootstrap failure with my
current fix. I shall be able to improve my fix and should hopefully be ready
tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328
--- Comment #1 from Thomas Preud'homme ---
*facepalm*
Yes indeed. Does this qualify for an obvious fix as per commiting rules?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #6 from Thomas Preud'homme ---
Sure, I'll push a patch for this as soon as I finish fixing the regressions
that poped up due to the change I made to the bswap pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306
--- Comment #3 from Thomas Preud'homme ---
Indeed. I also noticed that the original bswap code would happily accept signed
ssa value and signed cast which can lead to disaster. I worked out a patch for
this issue that check the sign of the lhs of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #20 from Thomas Preud'homme ---
(In reply to rguent...@suse.de from comment #19)
> On Thu, 15 May 2014, thomas.preudhomme at arm dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
> >
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #18 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #17)
>
> Citing myself:
>
> On the GIMPLE level before expansion we have
>
> +40 = Arr_2_Par_Ref_22(D) + (_41 + pretmp_20);
>
> _51 = Arr_2_Par_Ref_22(D) +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #16 from Thomas Preud'homme ---
Hi Richard,
could you expand on what you said in comment #13? I don't see how reassoc could
help cse here. From what I understood, reassoc tries to group per rank. In our
case, we have (view of the sou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
Thomas Preud'homme changed:
What|Removed |Added
CC||thomas.preudhomme at arm dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
--- Comment #4 from Thomas Preud'homme ---
Sorry for the late reply, I wasn't aware of this bug report until today.
(In reply to Richard Earnshaw from comment #1)
> This is an unresolvable problem.
>
> If we made __builtin_frame_address(N > 0) a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
Thomas Preud'homme changed:
What|Removed |Added
CC||thomas.preudhomme at arm dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54733
Thomas Preud'homme changed:
What|Removed |Added
CC||thomas.preudhomme at arm dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454
Thomas Preud'homme changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454
--- Comment #5 from Thomas Preud'homme ---
I have posted the patch on gcc-patches mailing list. The discussion can be
followed from http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00313.html.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454
Thomas Preud'homme changed:
What|Removed |Added
Attachment #32299|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454
--- Comment #3 from Thomas Preud'homme ---
Created attachment 32299
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32299&action=edit
Fix_bswap_detection
See in attachment for the patch I wrote to fix the issue. I'm welcoming any
comment on i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454
--- Comment #1 from Thomas Preud'homme ---
Created attachment 32297
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32297&action=edit
Unpreprocessed testcase for incorrect bswap detection
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.preudhomme at arm dot com
Created attachment 32296
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32296&action=edit
Testcase for bswap incorrect detection
Optimization pass optimize_bswap in tree-s
32 matches
Mail list logo
