https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111263
avieira at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc64-linux-gnu,|powerpc64-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111263
--- Comment #4 from avieira at gcc dot gnu.org ---
I've added arm-none-linux-gnueabihf to the target list there, but I'm wondering
whether we should have a separate bugzilla given it's likely this is a target
issue as Andrew pointed out and will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111263
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 116997, which changed state.
Bug 116997 Summary: Wrong bitfield accesses since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #38 from avieira at gcc dot gnu.org ---
> At least if the behavior is either perform the operation on all elements and
> then based on the 16 bits in the predicate choose result between the newly
> computed result and something else o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #7 from avieira at gcc dot gnu.org ---
My aarch64_be-none-elf regression testing also came back with no new failures.
@Pinski: given it was your suggestion do you want the commit? ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #5 from avieira at gcc dot gnu.org ---
I checked it locally and Pinski's recommended change does seem to fix the
codegen for this case. I end up with:
MEM [(void *)Ptr.0_1] = { 7, 6291456 };
I am regression testing the change now on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #1 from avieira at gcc dot gnu.org ---
Had a look at this and I see similar codegen for aarch64 when compiling for
big-endian.
If I disable tree-ifcvt (-fdisable-tree-ifvt) I end up with:
MEM [(void *)Ptr.0_1] = 30071062528;
Which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
--- Comment #5 from avieira at gcc dot gnu.org ---
Posted a fix, I believe it's related to the fact that for the cases where we
were using noce before, it was using the default hook to do a cost check, my
patch blankly approved those, this fix ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
--- Comment #4 from avieira at gcc dot gnu.org ---
No hadn't seen that yet. Will look at it thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115611
Bug ID: 115611
Summary: mve: vsetq_lane for 64-bits has wrong codegen when
setting lane 1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96342
--- Comment #11 from avieira at gcc dot gnu.org ---
I realized this ticket hadn't been updated in a while. Late in development for
gcc-14 I realized sve simdclone usage was leading to a regression on a
benchmark, I couldn't get to the bottom of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360
Bug ID: 115360
Summary: cmse_nonsecure_call wrapper missing STT_FUNCTION
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115278
--- Comment #8 from avieira at gcc dot gnu.org ---
Thanks! Missed that Andrew.
> It's a low-level worker, it relies on the caller to have performed sanity
> checking on the stmt itself. I'm testing a patch doing that.
OK, no strong opinion her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115278
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
avieira at gcc dot gnu.org changed:
What|Removed |Added
Summary|[13/14/15 Regression] : |[13 Regression] : internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #18 from avieira at gcc dot gnu.org ---
Sorry to be clear, the 'here' in the last sentence refers to supporting masks
as 0x to control the writing of the output register as the ISA allows,
rather than interpret 0x and 0x a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #13 from avieira at gcc dot gnu.org ---
They have both been backported, @Eric the tests should be passing again now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #12 from avieira at gcc dot gnu.org ---
Sorry, missed that comment, thanks! I'll test backporting both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #10 from avieira at gcc dot gnu.org ---
First of all, apologies for this! I don't know why I didn't test this on x86_64
too, I usually do for such backports.
Anyway I checked locally and backporting:
r14-2821-gd1c072a1c3411a6fe29900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
--- Comment #6 from avieira at gcc dot gnu.org ---
Oh forgot to mention, this is triggering because of the div optimization in:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c69db3ef7f7d82a50f46038aa5457b7c8cc2d643
But I suspect that too is jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
--- Comment #5 from avieira at gcc dot gnu.org ---
Oh forgot to mention, this is triggering because of the div optimization in:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c69db3ef7f7d82a50f46038aa5457b7c8cc2d643
But I suspect that too is jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-01-05
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
--- Comment #4 from avieira at gcc dot gnu.org ---
Drive by comments as it's been a while since I looked at this. I'm also
surprised we didn't adjust the bounds. But why do we only subtract VF? Like you
say, if there's no loop around edge, can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
avieira at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
Bug ID: 112787
Summary: Codegen regression of large GCC vector extensions when
enabling SVE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282
--- Comment #11 from avieira at gcc dot gnu.org ---
So I had a look at that u_lsm.72_510 variable and it's only undefined if we
don't loop, but if we don't loop then u_lsm_flag is set to 0 and we don't use
u_lsm. So it's OK. I also checked and th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282
--- Comment #10 from avieira at gcc dot gnu.org ---
So I had a look at that u_lsm.72_510 variable and it's only undefined if we
don't loop, but if we don't loop then u_lsm_flag is set to 0 and we don't use
u_lsm. So it's OK. I also checked and th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-07-10
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
--- Comment #8 from avieira at gcc dot gnu.org ---
I'll try adding to one of the header file lists in gcc's makefile. Probably the
INTERNAL_FN_H one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
--- Comment #7 from avieira at gcc dot gnu.org ---
> I guess you mean insn-opinit.h, not internal-fn.h. internal-fn.h is in the
> GCC Git repo.
Yeah sorry! I did mean insn-opinit.h
> We are already installing insn-{addr,attr-common,attr,codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
--- Comment #5 from avieira at gcc dot gnu.org ---
intenral-fn.h is generated at gcc build-time. I'm not sure we want to 'install'
it with a gcc install. Might make more sense to trigger a the generation of it
when building this gcc-plugin. But I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557
--- Comment #5 from avieira at gcc dot gnu.org ---
Hi Xi,
Feel free to test your patch and submit it to the list for review. I had a look
over and it looks correct to me.
I feel like it also addresses the cases where the bitfield is 'sandwiched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
--- Comment #4 from avieira at gcc dot gnu.org ---
Meant to say I'll look at it ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
--- Comment #4 from avieira at gcc dot gnu.org ---
> OK, so I take away from this that you don't think this is done the way
it is on purpose.
I don't think so, I think I just found a place where it was safe to do so, i.e.
where we knew the vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
--- Comment #2 from avieira at gcc dot gnu.org ---
I can't remember the exact reason either, though I do vaguely remember niter
updating being something that we felt 'needed more future work' at the time.
Just a side question, AVX512 has predica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
--- Comment #1 from avieira at gcc dot gnu.org ---
Found the issue to be with passing a subtype to vect_recog_widen_op_pattern in
vect_recog_widen_{plus,minus}_pattern where we didn't before. Removing those
and letting it default to a NULL pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #3 from avieira at gcc dot gnu.org ---
Err that should be 'double d[4];' so:
typedef struct
{
float __attribute__ ((vector_size(16))) v[2];
} STRUCT;
#ifdef GOOD
typedef STRUCT TYPE;
#else
typedef union
{
STRUCT s;
doubl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #2 from avieira at gcc dot gnu.org ---
Sorry for the delay. Here's the typedefs with GNU vectors.
typedef struct
{
float __attribute__ ((vector_size(16))) v[2];
} STRUCT;
#ifdef GOOD
typedef STRUCT TYPE;
#else
typedef union
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
Bug ID: 109543
Summary: Avoid using BLKmode for unions with a non-BLKmode
member when possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98850
--- Comment #2 from avieira at gcc dot gnu.org ---
I failed to reproduce it with a trunk build of arm-none-linux-gnueabihf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #5 from avieira at gcc dot gnu.org ---
Im slightly confused here, on entry to BB 5 we know the opposite of _1 < 0.0
no? if we branch to BB 5 we know !(_1 < 0.0) so we can't fold _1 <= 1.0, we
just know that the range of _1 is >= 0.0 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #9 from avieira at gcc dot gnu.org ---
Hmm I was seeing the change in opus_ifft but that does look like different
codegen :/ I might not be looking at the right thing.
That transformation looks definitely wrong though as the selectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #6 from avieira at gcc dot gnu.org ---
Thanks!
My initial investigation has lead me to think the change is being caused at
vrp2, which is the only time the pattern gets triggered with -O2, the tree
before the pass (at the place where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #21 from avieira at gcc dot gnu.org ---
Something else that might be obvious, how do I create a minimal ifcvt_demo.adb
file that uses the .ads, so that I can add it as a testcase to gcc, as the
testsuite seems to pick up .adb files on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #20 from avieira at gcc dot gnu.org ---
It's probably obvious to people that know Ada, so I just have to apologize for
my ignorance in that area :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #15 from avieira at gcc dot gnu.org ---
@richi: Yeah and as I mentioned on IRC I can confirm it fixes the issue, I also
bootstrapped and regression tested the change on aarch64-unknown-linux-gnu.
Simon, I can't compile your minimal r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #8 from avieira at gcc dot gnu.org ---
Oh nvm... you did.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #7 from avieira at gcc dot gnu.org ---
I'm still trying to build ADA to reproduce this.
Could you try 'p debug_tree (var)'
if var is a SSA_NAME debug won't print anything. If it comes back as not 0
could you also do p debug_tree (TR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96342
--- Comment #10 from avieira at gcc dot gnu.org ---
yang I assume you are no longer working on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107987
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108443
Bug ID: 108443
Summary: arm: MVE wrongly re-interprets predicate constants
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
--- Comment #1 from avieira at gcc dot gnu.org ---
This fails equally for any vld1* vstr1* intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
Bug ID: 108442
Summary: arm: MVE's vld1* and vst1* do not work when
__ARM_MVE_PRESERVE_USER_NAMESPACE is defined
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #3 from avieira at gcc dot gnu.org ---
The architecture describes it as only writing the true-predicated bytes and
leaving the others untouched. I guess reading and writting to the same memory
is the best we can do to 'mimic' that in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #1 from avieira at gcc dot gnu.org ---
I noticed that for SVE stores seem to be marked as volatile memory accesses, I
suspect it's because they are represented using masked stores which probably
are by definition volatile (for this re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
Bug ID: 108177
Summary: MVE predicated stores to same address get optimized
away
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107987
Bug ID: 107987
Summary: [12/13 Regression] MVE vcmpq vector-scalar can trigger
ICE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107808
--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Rainer,
I suspect this means SPARC should be added to the list of targets that fail
check_effective_target_vect_long_long. From the dump it looks like the target
doesn't support a long long v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Bug ID: 107678
Summary: [13 Regression] Segfault in
aarch64_fallback_frame_state
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
--- Comment #5 from avieira at gcc dot gnu.org ---
It looks that way on my end, but I'll let Arseny confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #9 from avieira at gcc dot gnu.org ---
Hi Eric,
I realised the same, got a patch pending here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604139.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #6 from avieira at gcc dot gnu.org ---
> There are no differences between gnat1 and cc1/cc1plus as far as dumps are
> concerned, e.g. -fdump-tree-optimized creates the .optimized dump.
This was my bad, I'm not used to using cc1 dire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #4 from avieira at gcc dot gnu.org ---
Funnily enough, if I transform the Int24 into a 32-bit integer in the testcase
and disable all bitfield lowering just to make sure, I get the same failure. I
tried using __attribute__((packed)) i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #3 from avieira at gcc dot gnu.org ---
I am wondering whether I should try to support this, or bail out of
vect_check_gather_scatter if pbitpos is not a multiple of BITS_PER_UNIT. The
latter obviously feels safer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107338
--- Comment #3 from avieira at gcc dot gnu.org ---
Hi Kewen,
I believe you are right. I was waiting for a powerpc machine in the board farm,
but I suspect I can reproduce this with an aarch64 BE target and I should be
able to confirm.
But your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
Bug ID: 107346
Summary: gnat.dg/loop_optimization23_pkg.ad failure afer
r13-3413-ge10ca9544632db
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Arseny,
Apologies for this, I thought I had caught this with testing, but seems I had
not. I am testing a fix right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
--- Comment #3 from avieira at gcc dot gnu.org ---
The prodding helped! The problem is that dce was indeed removing the ASM as it
wasn't recognizing it as a stmt that was live. This is because ifcvt would have
normally bailed out when encounterin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
avieira at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #4 from avieira at gcc dot gnu.org ---
Might be worth posting the output of -fdump-tree-vect-all might be failing to
vectorize due to some specific lack of feature that we can test for.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Seurer, Peter,
Adding something like: { xfail { powerpc*-*-* && { ! powerpc_vsx_ok } } } }
should xfail all powerpc architectures that don't support this no?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107226
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-10-12
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107229
--- Comment #2 from avieira at gcc dot gnu.org ---
So it seems I should have taken DECL_FIELD_OFFSET into account when computing
the bitpos in get_bitfield_rep (tree-if-conv.cc).
I am testing a patch for this whilst I also look at the failures i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #18 from avieira at gcc dot gnu.org ---
(In reply to Richard Biener from comment #16)
> (In reply to rsand...@gcc.gnu.org from comment #15)
> > (In reply to Richard Biener from comment #14)
> > > diff --git a/gcc/tree-vect-loop.cc b/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
--- Comment #9 from avieira at gcc dot gnu.org ---
Found the issue, it's due to the way we encode TARGET_CPU_DEFAULT in aarch64,
it is only able to support 64 cores and we have 65 now.
Testing a work around for now and we have plans to fix this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #7 from avieira at gcc dot gnu.org ---
And I was thinking it didn't know how to handle anchor + offset...
Anyway if I just record the swap and use it to invert the distance calculation
that seems to 'work' for the testcase. I'm happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #5 from avieira at gcc dot gnu.org ---
You mean this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
it only works for direct symbols I think it never enters
the block under: if (GET_CODE (x) == SYMBOL_REF && GET_CODE (y) == SYMBO
1 - 100 of 136 matches
Mail list logo
