https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116479
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215
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=118976
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=118955
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=116445
--- Comment #4 from avieira at gcc dot gnu.org ---
Good point Kyrill! I was just merely comparing m3 to m55 but yes you are right,
with low overhead loops you don't need the r3 count...
But -O2 also removes the r3, seems it does it at u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
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=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 point
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 somet
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 chang
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
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, thi
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
$ cat t.s
#include
int64x2_t fn (int64x2_t v, int64_t a)
{
return vsetq_lane_s64(a, v, 1);
}
compiled with
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
The Arm ABI requires a linker to handle calls to 'distant' functions by
inserting a wrapper veneer, or trampoline. Such functions need to be given
permission
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, n
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
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:
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
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
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
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 loo
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
typedef int __attribute__((__vector_size__ (64))) vec;
vec fn (vec a, vec b)
{
return a + b;
}
with
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'
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'
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
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
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-co
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
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
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
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.
wher
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 quest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
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
{
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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
So with the following C-code:
$ cat t.c
#include
#ifdef GOOD
typedef float64x2x2_t TYPE;
#else
typedef union
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 o
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
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
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
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 mi
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
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
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
compiling:
$ cat t.c
#include
uint32x4_t foo (uint32_t *a)
{
mve_pred16_t p = 0x00cc;
return vldrwq_z_u32 (a, p);
}
with:
$ arm-none-eabi-gcc -march=armv8.1
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.
IRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
$ cat t.c
#include
uint32x4_t foo (uint32_t *p)
{
return __arm_vld1q_u32 (p);
}
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
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
GCC currently generates wrong code for predicated MVE stores to the same
address. Like:
#include
uint8x16_t foo (uint8x16_t a, uint8_t *pa
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Using the following testcase
$ cat t.c
#include
uint32x4_t foo (uint32x4_t a, uint32x4_t b)
{
mve_pred16_t p = vcmpneq_n_u32 (vandq_u32
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
We ran into a segfault when running SPEC 2017 Parest for aarch64-none-linux-gnu
on a Neoverse V1 target after g:146e45914032
These are
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 t
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
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
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
As reported by Eric in
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603356.html
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
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
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
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
1 - 100 of 220 matches
Mail list logo
