https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122028
Bug ID: 122028
Summary: vect: Known vs variable stride
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121959
Bug ID: 121959
Summary: riscv: vector sign extend instead of zero extend
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121910
--- Comment #1 from Robin Dapp ---
Yes, dynamic LMUL is not in great shape right now. I can have a look after
stage 1 closes and things slow down a bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121908
Robin Dapp changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121908
Bug ID: 121908
Summary: Hot loop in xz not vectorized
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121510
Robin Dapp changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121510
--- Comment #5 from Robin Dapp ---
Reduced example:
long *print_bfloat_block;
void ftoastr(float);
void print_bfloat() {
for (;;) {
long j;
union {
_Float16 x;
char b[]
} u;
j = 0;
for (; j < sizeof 0; j++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121510
Robin Dapp changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121787
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121523
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121780
--- Comment #4 from Robin Dapp ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121660
Bug 121660 depends on bug 121523, which changed state.
Bug 121523 Summary: [16 Regression] RISC-V: ICE in apply_scale, at
profile-count.h:1187 since r16-3065-geee51f9a4b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121523
What|R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121781
Robin Dapp changed:
What|Removed |Added
Last reconfirmed||2025-9-4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121780
--- Comment #2 from Robin Dapp ---
*** Bug 121781 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121780
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121742
--- Comment #5 from Robin Dapp ---
(In reply to Peter Bergner from comment #4)
> (In reply to Robin Dapp from comment #3)
> > Fixed on trunk, do we want to backport this?
>
> Is this a trick question? :-) It's a wrong-code bug and doesn't look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121742
--- Comment #3 from Robin Dapp ---
Fixed on trunk, do we want to backport this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121742
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121523
--- Comment #4 from Robin Dapp ---
(In reply to Pengfei Li from comment #3)
> Sorry for my late response. I just added myself to the CC list.
>
> I tried the cases by Edwin Lu and Anton but haven't reproduced the ICE on
> AArch64. Since I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121659
Robin Dapp changed:
What|Removed |Added
Last reconfirmed||2025-8-25
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121485
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120674
--- Comment #3 from Robin Dapp ---
I believe the issue is that we can actually return 0 for factor in
riscv_dwarf_poly_indeterminate_value. Using the second coefficient is
reasonable but we cannot reasonably set a vector size when there is no v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121334
--- Comment #3 from Robin Dapp ---
(In reply to Richard Biener from comment #2)
> Possibly some place in the vectorizer doesn't properly check a constant it
> expands? But this is a VLS mode vector, so it should be loadable from
> memory?
> OTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121334
--- Comment #1 from Robin Dapp ---
We actually don't consider the constant legitimate via
riscv_legitimate_constant_p but expr.cc says
if (!targetm.legitimate_constant_p (mode, y))
{
y = force_const_mem (mode, y);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121334
Bug ID: 121334
Summary: riscv: ICE compiling 523.xalancbmk_r with
-fno-vect-cost-model
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-valid-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120687
--- Comment #7 from Robin Dapp ---
(In reply to Richard Biener from comment #6)
> (In reply to Richard Biener from comment #5)
> > The issue is that we somehow fail to SLP discover the reduction chain. I
> > will have a look to check why.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
--- Comment #6 from Robin Dapp ---
> If we have to force the IV live due to early break it means the IV wasn't
> used inside the loop, so we're free to make a choice.
>
> So, mine unless you already did work here Robin?
I have only done some v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121073
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121126
--- Comment #5 from Robin Dapp ---
I'll have a look. I'm currently tied down with other things, so maybe next
week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121065
--- Comment #3 from Robin Dapp ---
Should be fixed. My armhf qemu tests weren't really successful due to a qemu
configuration issue. I did verify that the test here (and others) don't ICE,
of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121073
--- Comment #2 from Robin Dapp ---
Yes, the issue is that Wdm was a memory constraint before, giving reload more
freedom. In the case here we have a real mask operand that only the strided
alternatives support. Need to think of another solutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121073
--- Comment #1 from Robin Dapp ---
That's very likely due to my recent broadcast changes. Will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120930
--- Comment #2 from Robin Dapp ---
I'm seeing a difference between -O2 and -O3 where the -O2 version gets the
proper result (3). In the -O3 version we completely unroll the loop but don't
seem to populate the "b" array entirely but just the fir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Robin Dapp changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #8 from Robin Dapp -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #7 from Robin Dapp ---
Picking a random commit in May (r16-649-g5c012971969db9) also shows the issue.
It looks as if we pick the wrong LMUL for a store and this rule is to blame:
DEF_SEW_LMUL_RULE (
ratio_and_ge_sew, sew_only, se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #6 from Robin Dapp ---
I was able to reproduce it on our internal tree. Disabling scheduling as well
as using the simple vsetvl strategy make the problem disappear so everything
points to a vsetvl issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #5 from Robin Dapp ---
Tried to reproduce again with the latest trunk and didn't succeed. I'm always
getting 234635118 no matter the VLEN and options. I'll try to bisect a failing
commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734
Robin Dapp changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120930
Robin Dapp changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rdapp at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113829
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120461
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #6 from Robin Dapp ---
(In reply to Tamar Christina from comment #5)
> Question, can I count on
>
> -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8
>
> always being available as a codegen option for RVV? or do I nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120461
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #8 from Robin Dapp ---
The vlse comes from a vec_duplicate:V2DI that has a reg pointing to a
"real(kind=4)", so a float.
What's interesting, though, is that the MEM is supposedly 64-bit aligned (see
below, A64).
(insn 285 282 287 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #7 from Robin Dapp ---
Ok, I was able to reproduce it with r15-9904-g2498cbbcdb23da.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #5 from Robin Dapp ---
I tried reproducing this with a recent trunk (r16-1965-gc512c9090f52e7) but
didn't see the exact code sequence. wrf also ran to completion on the Banana
Pi.
Did you use a stock GCC 15.1 or a specific commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #3 from Robin Dapp ---
(In reply to Jeffrey A. Law from comment #2)
> Yea, this bug may have been filed while we were discussing it in a team
> meeting.
>
> I think the question is whether or not to include the new guards in the
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
Robin Dapp changed:
What|Removed |Added
Last reconfirmed||2025-6-23
--- Comment #1 from Robin Dapp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #5 from Robin Dapp ---
> Well, consider the desired index vector being a real induction (just
> store it somewhere). If we can handle that, we should be able to
> handle the scatter. If not, we can't handle the scatter.
Hmm, I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #3 from Robin Dapp ---
> We could use scatter stores, building the index vector somehow cleverly with
> i_width contiguous indexes interspaced by i_dst_stride. In fact this vector
> could be built as inductions when building the i_h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120687
--- Comment #3 from Robin Dapp ---
Yeah, for 8 elements we still have a mode but beyond 8 we at least cannot do a
segment access anymore. Then we try with even/odd or interleaved permutations.
I kind of wonder why the cost model doesn't reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #1 from Robin Dapp ---
I'm just realizing that without knowing the stride statically, we'd generate a
lot of code as we don't have a way of setting an element size for loads
dynamically. Although riscv offers a dynamic element size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Robin Dapp changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Bug ID: 120639
Summary: vect: Strided memory access type, stores with gaps?
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #14 from Robin Dapp ---
I managed to have a look now but the whole builtin and LTO machinery is kind of
new to me.
As Andreas mentioned already the issue is that we do not register vector
builtins when the current target is !TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120459
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120436
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #11 from Robin Dapp ---
Tried building highway to reproduce and hit another error in fre...
Do we have a minimal example for this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #3 from Robin Dapp ---
vnclipu is basically a scaling (narrowing), rounding shift with subsequent
"clip" i.e. saturation. Its input and output is unsigned, though, so for the
function above we first need to "clip" the negative value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #4 from Robin Dapp ---
Does it make sense to have the vmax/vmin/truncate pattern as a fallback for
other targets? On riscv it would save one predicated instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #4 from Robin Dapp ---
I can reproduce this, but only with a qemu VLEN=128, VLEN >= 256 result in the
correct value of 234635118.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
Bug ID: 120378
Summary: Support narrowing clip idiom
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #11 from Robin Dapp ---
> Yes. I am sure. And SPIKE and QEMU have no problem.
So vlre/vsre should execute despite a VILL in VTYPE? At first sight I don't
find any specifics in the vector spec.
qemu is not very pedantic in that res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #9 from Robin Dapp ---
> No. vlre should not depend on vtype. It should be hardware bug.
Are you sure about that? vmv1r also doesn't depend on a specific vtype, each
one is OK, but the vtype must at least be valid. So we get a SIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #6 from Robin Dapp ---
(In reply to Kito Cheng from comment #5)
> Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg
> load store
On the Banana Pi I get a SIGILL for
int
main() {
asm volatile ("lui a5, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #4 from Robin Dapp ---
> I see, but when I changed to
>
> addia5,a5,912
>
> aka load from 0xdd390, the board still has the illegal insn. 0xdd390 is
> aligned for -O2 -march=rv64gcv -mrvv-vector-bits=zvl build, right?
Hmm, righ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #1 from Robin Dapp ---
That's a misaligned vector load I suppose?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #13 from Robin Dapp ---
Going to push this to the 14 branch later today if the x86 testsuite shows no
regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120067
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
--- Comment #3 from Robin Dapp ---
I manage to have a quick look at the code now. It looks like we force live
every induction and build slp instances for the IV increments.
I don't think adjusting the actual IV creation in vectorizable_inducti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #16 from Robin Dapp ---
> Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually
> in cvt_64f). After the commit 34ae3a99, the default value of
> LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672
--- Comment #8 from Robin Dapp ---
(In reply to Jakub Jelinek from comment #7)
> Thanks, I've posted it to gcc-patches in case some CI picks it up too:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680408.html
Testing looked good on rv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #15 from Robin Dapp ---
> Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually
> in cvt_64f). After the commit 34ae3a99, the default value of
> LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #13 from Robin Dapp ---
Hmm, now I compiled with -O3 on top of --param logical-op-non-short-circuit=0
(which shouldn't actually be necessary or change anything as it's the default)
but there is a segmentation fault in
_ZN2cv12cpu_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #12 from Robin Dapp ---
> I recompile the opencv application with current gcc(commit b6aafe9a5b), and
> it still reproduce this bug. Do you have apply the patch of step 3 which
> enable vector implement of cvt_64f function?
Yes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #10 from Robin Dapp ---
> 4. run
> ```
> export LD_LIBRARY_PATH=//lib
> ./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"
> ```
[==] Running 1 test from 1 test case.
[--] Global test e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #7 from Robin Dapp ---
Ah, not a regression but just a checking assert, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Robin Dapp changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #9 from Robin Dapp ---
> cmake --build cross-build/$BUILD_DIR-gcc --target opencv_test_core -j10
> ```
> 4. run
> ```
> export LD_LIBRARY_PATH=//lib
> ./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119373
--- Comment #5 from Robin Dapp ---
> The analysis of SPEC2017's 510.parest_r shows that the topmost basic block
> is a tight loop (see attached reducer). Once vectorised, by unrolling and
> mutualising 4 instructions, AArch64 achieves a 22% redu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119572
Robin Dapp changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #3 from Robin Dapp ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
Bug ID: 119577
Summary: RISC-V: Redundant vector IV roundtrip.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #5 from Robin Dapp ---
Do you happen to have an excution test ready so I can have a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #4 from Robin Dapp ---
(In reply to Edwin Lu from comment #3)
> I'm not familiar enough with how the two modes interact with each other but
> I guess my question is, why do we have so many conversions between the two
> modes? What's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #2 from Robin Dapp ---
I looked into this some more and it points to a general deficiency in how we
handle the split between VLA and VLS modes.
With ...bits=zvl the RVVM1SI etc modes. become VLS modes. In turn, this means
that whene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #1 from Robin Dapp ---
The issue is due to:
_279 = BIT_FIELD_REF <_480, 64, 0>;
_330 = BIT_FIELD_REF <_480, 64, 64>;
_340 = BIT_FIELD_REF <_481, 64, 0>;
_350 = BIT_FIELD_REF <_481, 64, 64>;
Ideally they expand to simple sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #17 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
Robin Dapp changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
1 - 100 of 471 matches
Mail list logo
