https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #18 from Christophe Lyon ---
Sorry, no, this is not the cause of the problem (actually musttail7.c also
fails in gcc.log).
I looked into this, and it's a bit tricky
in arm_function_ok_for_sibcall() (from arm.cc), we have:
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #15 from Christophe Lyon ---
(In reply to andi from comment #14)
> The test relies on the
>
> gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
Are you sure?
musttail7.c has:
/* { dg-do compile { target { mustta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Bug ID: 116901
Summary: pr110625_4.c fails on aarch64 since
r15-3794-g2c04f175de4f39
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116818
Bug ID: 116818
Summary: gcc.target/aarch64/sve/strided_load_5.c fails since
gcc-15-3735-g664e0ce580a8
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116260
--- Comment #3 from Christophe Lyon ---
Thanks for the additional information, indeed in our CI we do not run
validations for several "variations", so it's not surprising this case is not
handled very well.
So you suggest having one manifest pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Bug 115635 depends on bug 115661, which changed state.
Bug 115661 Summary: [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu
since r15-1599-g63512c72df09b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #16 from Christophe Lyon ---
(In reply to Richard Biener from comment #15)
> OK, looking the fix was only half complete. Can you try
It works with this, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #14 from Christophe Lyon ---
Created attachment 58522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58522&action=edit
Wrong code after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #13 from Christophe Lyon ---
Yes it breaks at the same point, again we are returning an uninitialized value.
Adding annotate asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #11 from Christophe Lyon ---
Created attachment 58520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58520&action=edit
vect dump broken after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #5 from Christophe Lyon ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*). (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #2 from Christophe Lyon ---
Created attachment 58431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58431&action=edit
vect dump OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #3 from Christophe Lyon ---
Created attachment 58432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58432&action=edit
vect dump broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
Bug ID: 115493
Summary: gcc.c-torture/execute/pr94734.c fails on MVE after
gcc-15-1054-g202a9c8fe7d
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #1 from Christophe Lyon ---
Created attachment 58429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58429&action=edit
Wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
Bug ID: 115248
Summary: aarch64/sve/pre_cond_share_1.c fails since
gcc-15-276-gbed6ec161be
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Christophe Lyon changed:
What|Removed |Added
Target|arm |arm aarch64
--- Comment #2 from Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #32 from Christophe Lyon ---
Created attachment 58110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110&action=edit
patch v2
Here is another patch proposal along the lines of what you suggest in #c24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #30 from Christophe Lyon ---
> ./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
> pr114801.c -mthumb -O2 -da
Thanks, for some reason -O2 had disappeared from my flags, it does ICE with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #27 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #25)
>
> Indeed, it ICEs e.g. during CSE.
> Though, that also means it is just about luck, if something isn't a
> CONST_INT at expansion time but simplified into C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #26 from Christophe Lyon ---
Thanks for testing, my build is still in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #22 from Christophe Lyon ---
Sure, that's what I'm worried about.
So we can:
- leave this as-is for gcc-14 (known bug)
- commit what we discussed in #c15 #c16, (with an improved testcase as you
mentioned on the list,) thus at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #19 from Christophe Lyon ---
So basically values such as 0x are not UB and we want to accept them.
I tested:
diff --git a/gcc/rtx-vector-builder.cc b/gcc/rtx-vector-builder.cc
index 9509d9fc453..f89aa717903 100644
--- a/gcc/rtx-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #16 from Christophe Lyon ---
Thanks for the suggestion, this works.
I've posted the patch + testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #14 from Christophe Lyon ---
Created attachment 58050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050&action=edit
patch proposal
Here is the patch I propose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #12 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #11)
> So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> same size, 2 bytes, so I'd go with
> else if (VALID_MVE_PRED_MODE (mode))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #8 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #5)
> Guess the primary question is why there is the gen_lowpart call at all.
> Is it that normally the mode of x is already right due to the prototypes of
> the bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #7 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > lowpart_subreg does not work either.
> >
> > If we put the predicates in a variable in the testcase, then in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #3 from Christophe Lyon ---
lowpart_subreg does not work either.
If we put the predicates in a variable in the testcase, then in
function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
116 [ _3 ]) 0) so taking g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #7 from Christophe Lyon ---
So yes indeed at r14-5423-gfbe4e64365ec7f, autoreconf will generate the same
contents, but starting at r14-5424-gdb50aea6259545 we get this discrepancy.
We can probably commit the "fixed" version, but sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #6 from Christophe Lyon ---
(In reply to Andrew Pinski from comment #1)
> The last time aclocal.m4 had an include for override.m4 was
> r9-3776-g22e052725189a4 .
IIUC that commit actually removed the include for override.m4 ?
> Ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Bug ID: 114748
Summary: libcpp aclocal.m4 and configure incorrectly
regenerated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
--- Comment #4 from Christophe Lyon ---
I'm wondering whether you missed check_effective_target_arm_arch_FUNC_link and
friends?
Maybe check_effective_target_arm_arch_v7a_neon_link would work here, but it
does not use the exact same flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
--- Comment #2 from Christophe Lyon ---
I think the last -march option overrides the previous one(s).
I'd say the test should use an effective-target which checks that linking is
actually OK rather than just a compile OK test. Not sure if an ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Bug ID: 114522
Summary: [14 regression] gcc.target/arm/aes_xor_combine.c
scan-assembler-not veor fails after
r14-9692-g839bc42772ba7a
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #5 from Christophe Lyon ---
Exactly. I have a (one-line) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2024-03-14
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
--- Comment #3 from Christophe Lyon ---
What I meant by arm-* is that we see the same issue on several of the
configurations we test, as can be seen on
https://linaro.atlassian.net/browse/GNU-1100
We have recently improved the extraction of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
Christophe Lyon changed:
What|Removed |Added
Target|powerpc64-linux-gnu |powerpc64-linux-gnu arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
Bug ID: 113437
Summary: gcc.dg/tree-ssa/pr95906.c fails on arm since
g:6686e16fda4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
Bug ID: 113425
Summary: gcc.dg/fold-copysign-1.c fails on arm since
g:7cbe41d35e6
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278
Bug ID: 113278
Summary: analyzer tests relying on fileno() fail on arm-eabi
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113276
Bug ID: 113276
Summary: gcc.dg/torture/fp-double-convert-float-1.c fails at
execution on arm cortex-m33
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113275
Bug ID: 113275
Summary: tests pr110268-1.c pr110268-2.c csinc-1.c csinv-1.c
fail after gcc-14-5396-ged52bc2e30c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #4 from Christophe Lyon ---
@mkretz, this commit may also be of interest for some more context:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d12d2aa4fccc76a9a08c8120c5e37d9cab8683e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #1 from Christophe Lyon ---
For gcc.target/arm/bfloat16_vector_typecheck* tests, the log says:
FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors)
Excess errors:
bfloat16_vector_typecheck_1.c:122:17: error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Bug ID: 112698
Summary: gcc-14-5617-gb8592186611 introduces regressions in
bfloat16_vector_typecheck_1.c for cortex-m0 and
cortex-m3
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #3 from Christophe Lyon ---
The original problem is fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628998.html, and it seems
better not to call GLIBCXX_CHECK_LINKER_FEATURES and silently hide a potential
problem.
May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #2 from Christophe Lyon ---
Oops sorry I pushed an unwanted patch, which I reverted with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #12 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #11)
> Please file a separate bug for these failures.
Thanks for the pointers, I digged a bit more, and filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
Bug ID: 111238
Summary: libstdc++ tests should use -Wl,-gc-sections in more
configurations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Christophe Lyon from comment #8)
> > On arm-eabi targets (thus, using newlib), we've noticed new errors:
>
> New since when? These files haven
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
Bug ID: 110986
Summary: aarch64 regressions after r14-3110-g7fb65f10285
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #8 from Christophe Lyon ---
Created attachment 55707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55707&action=edit
pr110378-1.C.083i.sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #20 from Christophe Lyon ---
Sorry for the typo in the date in the commit message :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #17 from Christophe Lyon ---
Thanks Andrew, I wasn't aware of vect_float_strict.
I confirm it makes the test UNSUPPORTED.
Can you commit the fix or do you want me to do it on your behalf?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #15 from Christophe Lyon ---
(In reply to Richard Biener from comment #14)
> (In reply to Christophe Lyon from comment #12)
> > The new testcase (gcc.dg/vect/pr110381.c) fails:
> > FAIL: gcc.dg/vect/pr110381.c -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Christophe Lyon changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Christop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
--- Comment #2 from Christophe Lyon ---
This regression appeared after the patch that re-implements vdupq, but the
issue is likely more generic.
velo r
I tried to update arm_init_mve_builtins() with:
+ if (in_lto_p)
+ {
+ arm_mve::handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Bug ID: 110268
Summary: arm MVE intrinsics support broken with LTO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #3 from Christophe Lyon ---
So we have a different behavior in
libstdc++-v3/include/experimental/bits/simd_detail.h:
#if defined __ARM_NEON && (__ARM_ARCH >= 8 || defined __aarch64__)
#define _GLIBCXX_SIMD_HAVE_NEON_A32 1
#else
#defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #2 from Christophe Lyon ---
Just noticed that the test passes if GCC is configured --with-arch=armv7-a, but
fails when forcing -march=armv8-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
Bug ID: 110050
Summary: experimental/simd/pr109822_cast_functions.cc fails on
arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
Product: gcc
Version: 14.0
Status: UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #11 from Christophe Lyon ---
Thanks, trunk is now OK on both arm and aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #8 from Christophe Lyon ---
I guess gcc185 is an aarch64 machine? (as opposed to arm)
I confirm your patch fixes the problem on aarch64 (the testcase now passes),
but it still fails on arm, with:
/arm-linux-gnueabihf/libstdc++-v3/in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #6 from Christophe Lyon ---
> trunk or the backport? I tested trunk on gcc185. Will check.
That's on trunk (didn't check on the branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #5 from Christophe Lyon ---
Not sure how to update/fix the testcases though?
Since they get the declaration of fclose from stdio.h, we'd need to make
dg-error conditional to the glibc version in use, which seems unpractical.
Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Christophe Lyon from comment #0)
> > Maybe there's something wrong with the detection of HAVE_GETENTROPY in
> > configure?
>
> We only do a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
--- Comment #5 from Christophe Lyon ---
Fixed on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #10 from Christophe Lyon ---
Can you try to revert my patches:
f0d3b6e384a68f8b58bc750f240a15cad92600cd
ccb9c7b129206209cfc315ab1a0432b5f517bdd9
and remove your patch at comment #5 ?
You should still see the problem you reported in b
1 - 100 of 375 matches
Mail list logo
