https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112426
--- Comment #2 from Richard Biener ---
sched1 does not care for register pressure unless you enable -fsched-pressure,
so this isn't a bug unless you have this enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112427
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #8 from Kito Cheng ---
> Oh. I understand it now. I think it's a bug.
>
> And.. I just take a look at my internal LLVM...
> Also has same issue
>
> I think we need to adapt the Gimple IR here:
>
> _35 = .SELECT_VL (ivtmp_33,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
--- Comment #6 from Robin Dapp ---
How does the test suite look without bootstrapping? Are there still new FAILs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #9 from JuzheZhong ---
I have a draft patch to fix it:
foo:
ble a0,zero,.L5
vsetvli a5,zero,e32,m1,ta,ma
vid.v v2
.L3:
vsetvli a5,a0,e32,m1,ta,ma
sllia4,a5,2
vle32.v v3,0(a1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #10 from Kito Cheng ---
(In reply to JuzheZhong from comment #9)
> I have a draft patch to fix it:
>
> foo:
> ble a0,zero,.L5
> vsetvli a5,zero,e32,m1,ta,ma
> vid.v v2
> .L3:
> vsetvli a5,a0,e32,m1,ta,m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #11 from JuzheZhong ---
Why the splat can't be VLMAX ?
I think it must be VLMAX, otherwise, it could be wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #12 from Kito Cheng ---
oh, yeah, you are right, it already take a5 to splat, so it's right, and as you
said it must be VLMAX, unless it AVL prorogation for both splat and the
following vadd.vv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #15 from Manolis Tsamis ---
(In reply to Sam James from comment #13)
> Created attachment 56527 [details]
> compile.c.323r.fold_mem_offsets.bad.xz
>
> Output from
> ```
> hppa2.0-unknown-linux-gnu-gcc -c -DNDEBUG -g -fwrapv -O3 -Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #6 from Tamar Christina ---
First reduction:
typedef struct {
int red
} MagickPixelPacket;
GetImageChannelMoments_image, GetImageChannelMoments_image_0,
GetImageChannelMoments___trans_tmp_1, GetImageChannelMoments_M11_0,
G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
--- Comment #4 from Li Pan ---
(In reply to Richard Biener from comment #3)
> Ah, yes, for lrint we have the builtins - I just looked for lceil here. So
> yeah, where there are DEF_EXT_LIB_FLOATN_NX_BUILTINS we should have
> DEF_INTERNAL_FLT_FL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112426
--- Comment #3 from Alex Coplan ---
Seems to happen with/without -fsched-pressure FWIW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #7 from Robin Dapp ---
Ah, thanks, I can reproduce this on the cfarm/gcc185.
We don't expand:
vect__ifc__141.81_358 = .COND_ADD (vect_cst__356,
vect_GetImageChannelMoments_M00_0_lsm.74_338, { 1.0e+0, ... },
vect_GetImageChannelMomen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #13 from JuzheZhong ---
Hi, kito.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635688.html
Candidate patch to fix this.
Could you comment and give more explanation to Richards since I don't think I
can explain it bette
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #8 from Robin Dapp ---
Ah of course it's not the first argument but the mask. During vectorization we
already create
fail1.c:15:10: note: add new stmt: vect__ifc__141.81_358 = .COND_ADD
(vect_cst__356, vect_GetImageChannelMoments_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111788
--- Comment #4 from Giuliano Procida ---
Also worth noting that while Clang gives virtual table entries (for struct X)
this type in DWARF:
int(** _vptr.X)(...)
GCC gives them this type:
int(** _vptr$X)()
The different member names are an unf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #9 from Robin Dapp ---
I believe the problem is that in
if (vectype)
vector_type = vectype;
else if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
&& VECTOR_BOOLEAN_TYPE_P (stmt_vectype))
vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
--- Comment #2 from CVS Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:d56bf419453ad44e53b05a9de22e98f6a80b5efd
commit r14-5244-gd56bf419453ad44e53b05a9de22e98f6a80b5efd
Author: Mikael Morin
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #5 from CVS Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:85a9688180a5523ae1704119978f3d634493300f
commit r14-5245-g85a9688180a5523ae1704119978f3d634493300f
Author: Mikael Morin
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #6 from CVS Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:62715bf891979cfb8c6684fdcd65b06a28bbbf5c
commit r14-5246-g62715bf891979cfb8c6684fdcd65b06a28bbbf5c
Author: Mikael Morin
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439
Bug ID: 112439
Summary: Modification of a member overlapping with a
[[no_unique_address]] member in the constructor is
incorrectly rejected
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #6 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440
Bug ID: 112440
Summary: Compiler does not grok basic_string::resize and
basic_string::reserve if _CharT is char
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112437
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
--- Comment #7 from Jonathan Wakely ---
Thanks! I briefly tried but failed to reproduce it in a reduced example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-11-08
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112441
Bug ID: 112441
Summary: Comparing stages 2 and 3 Bootstrap comparison failure!
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112441
Hongtao.liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Comment #27 from Jonathan Wakely ---
(In reply to Ben Elliston from comment #26)
> This test now passes on powerpc*-linux-gnu.
I wonder how ... the "fix" got reverted, and we still use an allocator of char
to create the storage for the COW s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Comment #28 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #27)
> But the alignment problem still seems to be present in the COW std::string.
But I think that's covered by PR 8670, which is still open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #8 from Alex Coplan ---
(In reply to Vladimir Makarov from comment #7)
> (In reply to Alex Coplan from comment #6)
> > Confirmed. Here's a slightly cleaned up reproducer that doesn't warn:
> >
> > #pragma GCC arm "arm_mve_types.h"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
Bug ID: 112442
Summary: Segfault from casting a ptr when using -O2
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
--- Comment #4 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e46a07b0e8a2bb074b491e0bb54a5cc8c8051341
commit r13-8012-ge46a07b0e8a2bb074b491e0bb54a5cc8c8051341
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:66d0abdf0ade07228eba4dedcd1a9da09960ef53
commit r13-8014-g66d0abdf0ade07228eba4dedcd1a9da09960ef53
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #12 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #11)
> I don't think it's valid to use a plain char array as storage for an object
> of another type; the "provides storage" wording in
> http://eel.is/c++draft/intr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #1 from Adam Andersson ---
Disregard my comment about it working GCC 12. In gcc version 12.3.0 (GCC) it
does not work either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #2 from Jonathan Wakely ---
Looks like it doesn't always segfault, but the contents of the tmp buffer are
incorrect (which might segfault, or might fail to print "test!").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
Bug ID: 112443
Summary: Misoptimization of _mm256_blendv_epi8 intrinsic on
avx512bw+avx512vl
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Bug ID: 112444
Summary: [14 regression] ICE when buliding libqmi (internal
compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in
us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #3 from Andrew Pinski ---
I am not 100% sure but there seems like some kind of aliasing issue going on.
Basically you have a pointer to an `unsigned char` but writing it via a pointer
to `char`.
Yes writing to a type via `char` woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #4 from Adam Andersson ---
(In reply to Andrew Pinski from comment #3)
> I am not 100% sure but there seems like some kind of aliasing issue going on.
>
> Basically you have a pointer to an `unsigned char` but writing it via a
> poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #16 from Jeffrey A. Law ---
On 11/8/23 03:09, manolis.tsamis at vrull dot eu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #15 from Manolis Tsamis ---
> (In reply to Sam James from comment #13)
>> Cre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #5 from Andreas Schwab ---
warning: dereferencing type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]
15 | test((char **)&ptr, "test!");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
--- Comment #1 from Sam James ---
Created attachment 56535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56535&action=edit
reduced.i
cvise popped this out, I haven't tried to prettify it by hand at all as heading
out now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
--- Comment #5 from Tomáš Trnka ---
(In reply to Paul Thomas from comment #4)
> Created attachment 56531 [details]
> Fix for this PR
>
> The bug comes about because the vtable is being declared in one of the
> specific procedures typebound to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #7 from Xi Ruoyao ---
Note that in the "new bug" page, there is a red banner saying:
Before reporting that GCC compiles your code incorrectly, compile it with gcc
-Wall -Wextra and see whether this shows anything wrong with your cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #10 from Tamar Christina ---
Just finished second bisect and reduce. Came out to this commit as well.
---
module brute_force
integer, parameter :: r=9
integer sudoku1(1, r)
contains
subroutine brute
integer l(r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #11 from Robin Dapp ---
Thanks, this is helpful.
I have a patch that I just bootstrapped and ran the testsuite with on aarch64.
Going to post it soon, maybe Richi still has a better idea how to work around
this.
-5250-20231108213319-g8cf7b936d44-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231108 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #8 from Jonathan Wakely ---
The aliasing doesn't happen when writing to the array, it's when reading a
char* value from an object of type unsigned char*.
If you just passed the unsigned char* to memcpy instead of *(char**)&ptr it
wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Comment #22 from Jonathan Wakely ---
This bug is still present in the COW std::string, which is still supported even
though it's not the default.
There are two problems. The first is the one reported by James Kanze, that the
string contents n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
Jonathan Wakely changed:
What|Removed |Added
Assignee|giovannibajo at gmail dot com |redi at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #9 from Adam Andersson ---
I was sure I had tried -fno-strict-aliasing without any difference, but I
guessed I messed up somehow. Sorry about that.
Still, is it not strange that -Wall doesn't generate a warning about this then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112446
Bug ID: 112446
Summary: Switch -gnatyz included in -gnatyg
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #17 from dave.anglin at bell dot net ---
On 2023-11-08 9:42 a.m., jeffreyalaw at gmail dot com wrote:
> I'd probably continue with the process of narrowing down what code is
> affected using the attributes. We already know the file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Comment #24 from Jonathan Wakely ---
Oh, but this would be an ABI break. When using the explicit instantiation
definitions in libstdc++.so allocations and deallocations will match because
both will come from the library. But if anything is inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #18 from Andrew Pinski ---
I wonder if -fno-strict-aliasing works around the issue too?
I get the feeling that `fold mem offset pass` allows the aliasing code to have
a better time with the offset and that might be expose more aliasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #19 from Jeffrey A. Law ---
f-m-o runs post-allocation, so the scope of where it's behavior can change
things is narrower. So testing with -fno-schedule-insns isn't going to be
useful, but -fno-schedule-insns2 might.
I'm a bit conc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #20 from dave.anglin at bell dot net ---
On 2023-11-08 2:07 p.m., pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #18 from Andrew Pinski ---
> I wonder if -fno-strict-aliasing w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Bug ID: 112447
Summary: risc-v regression: FAIL:
gcc.c-torture/execute/memset-3.c -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #16 from Vineet Gupta ---
(In reply to Patrick O'Neill from comment #8)
> Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
>
> === gcc: Unexpected fails for rv64gcv lp64d medlow ===
> FAIL: gcc.c-torture/execu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112448
Bug ID: 112448
Summary: Constraint expression b rejected
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82524
--- Comment #22 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:dced5ae64703507a7159972316a1dde48e5f7470
commit r14-5254-gdced5ae64703507a7159972316a1dde48e5f7470
Author: Uros Bizjak
Date: Wed N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
Bug ID: 112449
Summary: Arithmetic operations can produce signaling NaNs
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #1 from Andrew Pinski ---
See
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #2 from Andrew Pinski ---
Note mips and sh and a few other targets have the quiet bit meaning the
opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #3 from Andrew Pinski ---
GCC does document some of this on
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Floating-point-implementation.html
but not the signaling nan part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #4 from Andrew Pinski ---
And documented other parts here:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/cpp/Common-Predefined-Macros.html
specifically:
It does not indicate whether optimizations respect signaling NaN semantics (the
ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112448
--- Comment #1 from Andrew Pinski ---
Note the error message on the trunk changed to:
:4:40: error: template argument 1 is invalid
4 | constexpr bool f(auto x) requires b { return true; }
|^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112448
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #1 from JuzheZhong ---
Could you share more assembly ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339
--- Comment #3 from Niall Douglas ---
Thanks for the patch. I've sent it on to the originator of the bug, if they
confirm it fixes their issue to me I'll let you know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #2 from Vineet Gupta ---
Created attachment 56539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56539&action=edit
manually reduced src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #3 from Vineet Gupta ---
Created attachment 56540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56540&action=edit
asm output ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #4 from Vineet Gupta ---
Created attachment 56541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56541&action=edit
asm output nok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #5 from JuzheZhong ---
I don't think VSETVL is wrong.
vsetivlizero,8,e8,mf2,ta,ma
sd ra,120(sp)
vmv.x.s a1,v1
...
.L36:
vse8.v
...
vsetivlizero,8,e32,m2,t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #6 from Vineet Gupta ---
I have debugged this by single stepped in qemu
when the test fails (first loop for offset 0, iteration 8)
The last VSETVLI is this one,
0x10a3e 0d107057 vsetvli zero,zero,e32,m2,ta,ma
0x10a42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #7 from JuzheZhong ---
Oh. I missed it:
vmv.v.x v2,s0
vse8.v v2,0(a5)
Leave it to me today. It should be simple fix.
Thanks for report it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #8 from JuzheZhong ---
Could you continue debug more cases ?
FAIL: gcc.c-torture/execute/pr89369.c -O2 execution test
FAIL: gcc.c-torture/execute/pr89369.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Vineet Gupta changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #10 from JuzheZhong ---
(In reply to Vineet Gupta from comment #9)
> (In reply to JuzheZhong from comment #7)
> > Oh. I missed it:
> >
> > vmv.v.x v2,s0
> > vse8.v v2,0(a5)
> >
> > Leave it to me today. It should b
1 - 100 of 156 matches
Mail list logo
