https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #33 from Wilco ---
(In reply to Richard Biener from comment #32)
> >
> > Index: gcc/expr.c
> > ===
> > --- gcc/expr.c (revision 267553)
> > +++ gcc/expr.c (working co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #34 from Wilco ---
With just the expr.c patch the gcc regression tests all pass on big-endian
AArch64. Interestingly this includes the new torture test, ie. it does not
trigger the union bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #36 from Eric Botcazou ---
> Like Wilco says, the torture test seems to pass with an unpatched compiler
> (but seems like a good thing to have anyway).
Likewise on SPARC at any optimization level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #37 from Wilco ---
(In reply to rsand...@gcc.gnu.org from comment #35)
> Yeah, the expr.c patch makes the original testcase work, but we still fail
> for:
That's the folding in ccp1 after inlining, which will require a similar fix.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #38 from rsandifo at gcc dot gnu.org
---
Created attachment 45392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45392&action=edit
patch that changes get_ref_base_and_extent for bare SSA_NAMEs
(In reply to Wilco from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #39 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #34 from Wilco ---
> With just the expr.c patch the gcc regression tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #40 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> rsandifo at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #41 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #38 from rsandifo at gcc dot gnu.org gnu.org> ---
> Created attachmen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #42 from Richard Biener ---
(In reply to rguent...@suse.de from comment #41)
> On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #38 from rsandifo at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #43 from Richard Biener ---
So to get back to this - my thinking was that for a reference REF I can do
base = get_inner_reference (ref, &bitsize, &bitpos, &offset, &mode,
&unsignedp, &reversep, &volatilep);
and get the semantically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #44 from Richard Biener ---
Created attachment 45523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45523&action=edit
workaround
So I am testing the following workaround, at least "most suitable" for
branches.
It avoids generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #45 from Eric Botcazou ---
> So to get back to this - my thinking was that for a reference REF I can do
>
> base = get_inner_reference (ref, &bitsize, &bitpos, &offset, &mode,
> &unsignedp, &reversep, &volatilep);
>
> and get the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #46 from Richard Biener ---
(In reply to Richard Biener from comment #44)
> Created attachment 45523 [details]
> workaround
>
> So I am testing the following workaround, at least "most suitable" for
> branches.
> It avoids generating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #47 from Richard Biener ---
(In reply to Eric Botcazou from comment #45)
> > So to get back to this - my thinking was that for a reference REF I can do
> >
> > base = get_inner_reference (ref, &bitsize, &bitpos, &offset, &mode,
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #48 from Eric Botcazou ---
> OK, we can certainly try to enforce this. Just to make sure - this
> refers to TREE_TYPE (TREE_OPERAND (bfr, 0)), not the base of the
> component-ref chain eventually rooted here?
Yes, formally it's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #49 from Eric Botcazou ---
> Just to remind where we're coming from - we have
>
> unData.strMemHead.b30AddrL= ulAddr >> 2;
>
> where this is a 30bit bitfield store (at bit offset % BITS_PER_UNIT == 0)
> from a unsigned :30 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
Richard Biener changed:
What|Removed |Added
Attachment #45523|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #51 from rsandifo at gcc dot gnu.org
---
FWIW, the (In reply to Richard Biener from comment #44)
> Created attachment 45523 [details]
> workaround
>
> So I am testing the following workaround, at least "most suitable" for
> branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #52 from Richard Biener ---
Author: rguenth
Date: Mon Jan 28 08:15:42 2019
New Revision: 268332
URL: https://gcc.gnu.org/viewcvs?rev=268332&root=gcc&view=rev
Log:
2019-01-28 Richard Biener
PR tree-optimization/88739
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
Richard Biener changed:
What|Removed |Added
Target|aarch64_be armb |aarch64be
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #7 from Richard Biener ---
So FRE tries to match up a store with (possibly bit-precision) type T with a
load of (possibly bit-precision) type U. The load and store are analyzed
by get_ref_base_and_extent to a common base object hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #8 from Richard Biener ---
So I think part of a fix would be the following. Not sure if
REG_WORDS_BIG_ENDIAN or FLOAT_WORDS_BIG_ENDIAN come into play.
With the fix we no longer simplify this for aarch64 since
BITS_BIG_ENDIAN is 0 eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #9 from Richard Biener ---
So somehow build up exhaustive testing via
struct S # n # AT # m { \
T pad : m; \
T val : n; \
};
T __attribute__((noinline)) load8at0 () { return u.s8at0.val; }
...
union U {
T val;
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #10 from Richard Biener ---
Created attachment 45377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45377&action=edit
exhaustive testcase
testcase, compile with -DT="unsigned long".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #11 from Richard Biener ---
Created attachment 45378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45378&action=edit
script to generate testcase
Script to generate a testcase. The attached was created by
./t.sh 64 > t.c
exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #12 from John Dong ---
Created attachment 45379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45379&action=edit
temp patch for Bug 88739
I tried to fix this bug with attached patch, but we not sure if BIT_FIELD_REF
((unsigned:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #13 from John Dong ---
(In reply to John Dong from comment #12)
> Created attachment 45379 [details]
> temp patch for Bug 88739
>
> I tried to fix this bug with attached patch, but we not sure if
> BIT_FIELD_REF ((unsigned:30)var, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #15 from Richard Biener ---
Oh, and with making U.val a same-sized float type one might be able to
test FLOAT_WORDS_BIG_ENDIAN effects (only mmix, pdp11, tilegx and visum
affected).
Not sure about REG_WORDS_BIG_ENDIAN at all (c6x is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #16 from Wilco ---
(In reply to Richard Biener from comment #8)
> So I think part of a fix would be the following. Not sure if
> REG_WORDS_BIG_ENDIAN or FLOAT_WORDS_BIG_ENDIAN come into play.
> With the fix we no longer simplify this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #17 from rguenther at suse dot de ---
On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #16 from Wilco ---
> I think we need to simplify the many BIG_ENDIAN mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #18 from Segher Boessenkool ---
Well, it is always possible to generate code with the opposite endianness to
what the hardware "wants". It just won't be very fast code.
BITS_BIG_ENDIAN is just a convenience to the target code writer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #18)
> Well, it is always possible to generate code with the opposite endianness to
> what the hardware "wants". It just won't be very fast code.
>
> BITS_BIG_ENDIAN is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #20 from Eric Botcazou ---
> BITS_BIG_ENDIAN is just a convenience to the target code writer. The other
> four do matter, and are quite obvious really (and all four are necessary).
Yes, I agree that BITS_BIG_ENDIAN shouldn't matter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #21 from Wilco ---
(In reply to Eric Botcazou from comment #20)
> > BITS_BIG_ENDIAN is just a convenience to the target code writer. The other
> > four do matter, and are quite obvious really (and all four are necessary).
>
> Yes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #22 from Eric Botcazou ---
> Is it really pure RTL, therefore not used in tree? So the above patch using
> BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?
I wouldn't say incorrect, just inappropriate and unnecessary. An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #23 from John Dong ---
diff -urp a/gcc/expr.c b/gcc/expr.c
--- a/gcc/expr.c2019-01-09 03:19:03.750205982 +0800
+++ b/gcc/expr.c2019-01-09 03:38:23.414174738 +0800
@@ -10760,6 +10760,16 @@ expand_expr_real_1 (tree exp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #24 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, dongjianqiang2 at huawei dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #23 from John Dong ---
> diff -urp a/gcc/expr.c b/gcc/expr.c
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #25 from Wilco ---
(In reply to rguent...@suse.de from comment #17)
> On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #16 from Wilco ---
> > I think w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #26 from Richard Biener ---
(In reply to Wilco from comment #25)
> (In reply to rguent...@suse.de from comment #17)
> > On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #27 from Wilco ---
(In reply to Eric Botcazou from comment #22)
> > Is it really pure RTL, therefore not used in tree? So the above patch using
> > BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?
>
> I wouldn't say incor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #28 from Richard Biener ---
(In reply to Wilco from comment #27)
> (In reply to Eric Botcazou from comment #22)
> > > Is it really pure RTL, therefore not used in tree? So the above patch
> > > using
> > > BITS_BIG_ENDIAN for tree st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #29 from Wilco ---
(In reply to Richard Biener from comment #26)
> Did anybody test the patch? Testing on x86_64 will be quite pointless...
Well that generates _18 = BIT_FIELD_REF <_2, 16, 14>; and becomes:
ubfxx1, x20, 2, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #30 from Eric Botcazou ---
> That said, the docs also refer to 'bit-field instructions' but do not
> elaborate further -- I guess zero_extract is such but I'd have guessed
> BIT_FIELD_REF (on trees) is as well. But yes, RTL expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #31 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #29 from Wilco ---
> (In reply to Richard Biener from comment #26)
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #32 from Richard Biener ---
(In reply to rguent...@suse.de from comment #31)
> On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #29 from Wilco ---
> >
47 matches
Mail list logo
