https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
avieira at gcc dot gnu.org changed:
What|Removed |Added
Known to work|10.2.1 |
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
--- Comment #8 from avieira at gcc dot gnu.org ---
Aye my bad there, Thanks for the change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
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=97327
--- Comment #4 from avieira at gcc dot gnu.org ---
With -mcpu=cortex-m55+nomve should be equivalent to -march=armv8.1-m.main+dsp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
--- Comment #5 from avieira at gcc dot gnu.org ---
Your other one:
-mcpu=cortex-m55+nomve -march=armv8.1-m.main+mve -mfloat-abi=softfp
This has cpu without mve and arch with mve.
Another fun caveat to look at is in:
-mcpu=cortex-m55 -mfloat-abi=s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
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=93053
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=95646
avieira at gcc dot gnu.org changed:
What|Removed |Added
Summary|arm-none-eabi function |[GCC 9/10] arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
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=97528
--- Comment #12 from avieira at gcc dot gnu.org ---
@jakub: backported to gcc-8 and gcc-9. OK to close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
Bug ID: 98974
Summary: ICE in vectorizable_condition after
STMT_VINFO_VEC_STMTS
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
--- Comment #1 from avieira at gcc dot gnu.org ---
The testcase above issues a warning, around do j=jts,enddo
To use it as a testcase in my patch I'd like to get rid of it so if someone
proficient in Fortran knows a way to get rid of it that'd be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 98974, which changed state.
Bug 98974 Summary: [11 Regression] ICE in vectorizable_condition after
STMT_VINFO_VEC_STMTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98657
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #7 from avieira at gcc dot gnu.org ---
I'm looking at this and I have a feeling there is a disconnect on how some
passes define VECTOR_CST and how the expand pass handles it.
So the problem here seems to lie with the V4SImode VECTOR_C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #8 from avieira at gcc dot gnu.org ---
Also at some point we should figure out why the vectorizer is generating this
much code for this example, where I think it should be able to optimized it to:
a = 22;
b &= c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981
--- Comment #5 from avieira at gcc dot gnu.org ---
Yeah that works. Ran it as is, no abort, ran it with s/ne/eq/ and it aborts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981
--- Comment #6 from avieira at gcc dot gnu.org ---
FYI Tamar asked me to make sure the instructions were being generated. I
checked and they were, but not being used as it decides to inline MAIN__ and
inlining seems to break (as in not apply/miss
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=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=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=107987
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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=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=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 #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 #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 #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=104498
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=105157
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=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=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=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=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=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=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
--- 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=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=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=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=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
--- 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=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 #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=103977
--- Comment #5 from avieira at gcc dot gnu.org ---
Posted a fix on ML:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588237.html
Sorry for the breakage, wrong assumption by my part :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103971
--- Comment #1 from avieira at gcc dot gnu.org ---
seurer could you check whether
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588237.html fixes this?
I don't have easy access to a powerpc target for bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
--- Comment #7 from avieira at gcc dot gnu.org ---
Thanks for confirming that Jeff :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103971
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
--- Comment #8 from avieira at gcc dot gnu.org ---
The patch Jeff mentioned is this:
[vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only
gcc/ChangeLog:
* tree-vect-loop.c (vect-analyze-loop): Handle scenario where target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
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=103997
--- Comment #7 from avieira at gcc dot gnu.org ---
Hmm thinking out loud here. As vector sizes (or ISAs) change vectorization
strategies could indeed change. Best that I can think of is things like
rounding, where you might need to do operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #3 from avieira at gcc dot gnu.org ---
Hi Kewen,
Thanks for the analysis. The param_vect_partial_vector_usage suggestion seems
valid, but that shouldn't be the root cause.
I would expect an unpredicated V8HI epilogue to fail for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #5 from avieira at gcc dot gnu.org ---
Thanks Kewen, that seems worrying, I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #7 from avieira at gcc dot gnu.org ---
Yeah I'm with Richard on this one, I just checked and the generated assembly is
the same for before and after my patch, so this looks like a testism.
And yeah I agree, if we were to decide to u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #10 from avieira at gcc dot gnu.org ---
Hi Levy,
I did a quick experiment, compiled exchange2_r with trunk and with trunk + all
my epilogue and unroll vector patches reverted, with '-march=alderlake -Ofast
-flto -funroll_loops' and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #12 from avieira at gcc dot gnu.org ---
Right and did you happen to see a perf increase on these benchmarks with any of
the patches I mentioned the hash of in the previous comment?
Just to explain a bit further what I think is going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
Bug ID: 104498
Summary: Alias attribute being ignored by scheduler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #1 from avieira at gcc dot gnu.org ---
Forgot to mention, this happens during the sched1 pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #3 from avieira at gcc dot gnu.org ---
Sorry some confusion there, I thought it was base_alias_check bailing out
early, but that seems to return true, it is the memrefs_conflict_p that returns
0.
I suspect rtx_equal_for_memref_p shou
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
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=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=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=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
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
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=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=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=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
--- 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=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=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=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=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 #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=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=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
--- 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=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=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=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=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=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
--- 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=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=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=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=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=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=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=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=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=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
--- 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=112787
Bug ID: 112787
Summary: Codegen regression of large GCC vector extensions when
enabling SVE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 142 matches
Mail list logo
