https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102604
--- Comment #2 from Christophe Lyon ---
Right, using -Os makes these tests pass (but vsqrt.f32 and vsqrt.f64 would
fail), but I'm still wondering about the purpose of vmla?
Rather than benchmarking, the costs may come from the Architecture
docu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285
--- Comment #13 from Christophe Lyon ---
Sure, here is what I have in libstdc++.log:
In file included from
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/net:42,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
--- Comment #6 from Christophe Lyon ---
On aarch64, this also causes gcc.dg/loop-unswitch-4.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102808
Bug ID: 102808
Summary: [12 regression] sve/mask_gather_load_1.c fails since
g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815
Bug ID: 102815
Summary: gfortran.dg/bind-c-contiguous-5.f90 fails at execution
on armeb
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
--- Comment #6 from Christophe Lyon ---
I think it's better too, so this essentially means removing
gcc.target/aarch64/pr89093.c, but since Jakub's patch was specifically about
leading spaces, I was wondering whether I was missing something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
--- Comment #15 from Christophe Lyon ---
Hi, yes this is close to completion.
The patch series was approved last week by Richard Sandiford:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581778.html
but I have found a bug with more vali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Bug ID: 102857
Summary: [12 regression] r12-4526 caused regressions on
vect/bb-slp-16.c and ssa-dom-thread-7.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Bug ID: 102906
Summary: [12 regression] gcc.target/arm/ivopts-4.c fails since
r12-4526
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
--- Comment #5 from Christophe Lyon ---
Sure, I just filed PR 102906 for the ivopts-4.c issue on arm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907
Bug ID: 102907
Summary: aarch64/shrn-combine-[123].c fail with SVE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #2 from Christophe Lyon ---
Yes, I can still see failures with r12-4820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516
--- Comment #9 from Christophe Lyon ---
Indeed it works again on trunk, I bisected and it started with one of our
commits: r12-3958-g4c7731081647c22cbd249dc0faa20c3df9ed6411
Author: Richard Biener
Date: Wed Sep 29 11:18:23 2021 +0200
Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #2 from Christophe Lyon ---
Confirmed.
In test_dfp_17.c we have:
ARG(_Decimal64, 11.0dd, D0)
DOTS
ANON(struct z, a, D1)
ANON(struct z, b, STACK)
ANON(int , 5, W0)
ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #3 from Christophe Lyon ---
and patching test_dfp_17.c like so:
- ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */
+ ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */
makes it pass on aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #4 from Christophe Lyon ---
Indeed my patch aimed at catching such inconsistencies.
I guess before that the build had a 'strange' behavior? (with a missing
dirname, some parts of the shell genmultilib shell script would expand into
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #6 from Christophe Lyon ---
(In reply to James McKelvey from comment #5)
> This works:
>
> $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64
> 2c2
> < MULTILIB_DIRNAMES = 64
> ---
> > MULTILIB_DIRNAMES = 64 32
I gue
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Bug ID: 105549
Summary: aarch64: Wrong va_arg alignment handling
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Known to fail||8.5.0, 9.4.1
--- Comment #1 from Chri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105669
Bug ID: 105669
Summary: DFP to HF (_Float16) conversions use incorrect
rounding
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177
Bug ID: 106177
Summary: LTO interoperability Linux/Windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177
--- Comment #4 from Christophe Lyon ---
(In reply to Richard Weickelt from comment #3)
> @Christophe Lyon,
>
> my use-case is that vendor A provides a binary blob of a library to vendor
> B. Both A and B ensure that they use the same toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101284
Bug ID: 101284
Summary: conflicting arch/fpu result in unexpected preprocessor
defines
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
--- Comment #12 from Christophe Lyon ---
Yes, I've been working on it for a while, it's proving to be a bit tricky when
switching to HImode as suggested by Richard. I have something working, now
checking I haven't broken Neon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101299
Bug ID: 101299
Summary: bb-slp-74.c fails on arm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321
Bug ID: 101321
Summary: gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321
--- Comment #2 from Christophe Lyon ---
OK, makes sense, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
Christophe Lyon changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #5 from Christophe Lyon ---
Before the patch, combine says:
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i314: r0:SI=zero_extend(r117:H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #6 from Christophe Lyon ---
Before r12-671 before combine we have:
(insn 7 4 8 2 (set (reg:HI 117)
(unspec:HI [
(reg/v:V16QI 115 [ v ])
(reg/v:V16QI 116 [ w ])
] VCMPEQQ_S)) "arm_mv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
Bug ID: 101363
Summary: many ICEs after r12-2089 on aarch64
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #7 from Christophe Lyon ---
Before the patch:
Trying 8 -> 14:
8: r113:SI=zero_extend(r117:HI)
REG_DEAD r117:HI
14: r0:SI=r113:SI
REG_DEAD r113:SI
Successfully matched this instruction:
(set (reg/i:SI 0 r0)
(zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #8 from Christophe Lyon ---
Indeed, it's what happens in try_combine():
i2src = subst (i2src, pc_rtx, pc_rtx, 0, 0, 0);
converts i2src
(zero_extend:SI (reg:HI 117))
into:
(and:SI (subreg:SI (reg:HI 117) 0)
(const_int 1 [0x1]))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #10 from Christophe Lyon ---
This was introduced by my change at r12-671 in mve.md:
-;; [vcmpneq_])
+;; [vcmpneq_, vcmpcsq_, vcmpeqq_, vcmpgeq_, vcmpgtq_, vcmphiq_, vcmpleq_,
vcmpltq_])
;;
-(define_insn "mve_vcmpneq_"
+(define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321
--- Comment #7 from Christophe Lyon ---
> PS: I let -fno-short-enums remain in the testcase for now. If the patch
> fixes the issue while removing -fno-short-enums, the testcase can be updated
> to not have -fno-short-enums anymore.
I just che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
--- Comment #4 from Christophe Lyon ---
(In reply to Martin Sebor from comment #2)
> I don't see the ICE with my cross-compiler and the stack trace doesn't
> correspond to the latest sources (there's no call to error() at
> gcc/config/aarch64/aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
--- Comment #8 from Christophe Lyon ---
Here are the options I see in gcc.log:
-O0 -march=armv8.2-a+bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101375
Bug ID: 101375
Summary: arm: Adding -mfpu=auto makes many tests unsupported
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101375
--- Comment #1 from Christophe Lyon ---
The same is true when targeting more "natural" options for arm-eabi:
-mthumb/-mfloat-abi=hard/-march=armv7e-m+fp/-mfpu=auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
Bug ID: 101379
Summary: libatomic build failure on arm after r12-2132
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
--- Comment #5 from Christophe Lyon ---
The patch does not work, I'm now getting this error:
In file included from
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/arm/host-config.h:4,
from
/home/christop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #12 from Christophe Lyon ---
As I am going on holidays until August (back only 2 days until then), I thought
I should share my WIP here. No sure that's the right direction, anyway that's
not working yet.
a/gcc/config/arm/arm-builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
--- Comment #7 from Christophe Lyon ---
The patch in comment #6 lets the build complete, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101462
Bug ID: 101462
Summary: [12 regression] ICE on aarch64 after r12-2292
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467
Bug ID: 101467
Summary: [r12 regression] ICE on aarch64 after r12-2324
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101468
Bug ID: 101468
Summary: [r12 regression] new Wstringop-overflow tests failures
since r12-2338
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
Bug ID: 101744
Summary: [12 regression] hwasan new failures since r12-2424
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101745
Bug ID: 101745
Summary: [12 regression] hwasan new failures since r12-2424
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746
Bug ID: 101746
Summary: [12 regression] gcc.dg/tree-prof/20050826-2.c and
gcc.dg/uninit-pred-9_b.c fail since r12-2591
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746
--- Comment #1 from Christophe Lyon ---
In addition on arm:
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors)
Excess errors:
/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:148:3: warning: 'void*
__builtin_memcp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746
--- Comment #4 from Christophe Lyon ---
OK, sorry for the duplicates, I tried to find reports about 20050826-2.c, found
none, and forgot to check about the other two.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101690
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Bug ID: 101750
Summary: [12 regression] g++.dg/vect/pr99149.cc fails on
aarch64 since r12-2523
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Christophe Lyon changed:
What|Removed |Added
Target Milestone|--- |12.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755
Bug ID: 101755
Summary: [12 regression] gcc.target/arm/reg_equal_test.c fails
on arm since r12-2637
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755
Christophe Lyon changed:
What|Removed |Added
Target||arm
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101857
Bug ID: 101857
Summary: gfortran.dg/ieee/large_3.F90 fails on
arm-linux-gnueabi
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101857
--- Comment #2 from Christophe Lyon ---
Yes I still see that with r12-2842. There were link errors before r12-2839, but
now only this test fails, at execution time. There might be something about
raising exception in soft floating-point mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101890
Bug ID: 101890
Summary: [12 regression] ICEs on aarch64 after r12-2836
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101890
Christophe Lyon changed:
What|Removed |Added
Target Milestone|--- |12.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101056
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
--- Comment #13 from Christophe Lyon ---
This is also related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017
Bug ID: 102017
Summary: libgcc ieee754-df.S for arm does not support
exceptions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018
Bug ID: 102018
Summary: gcc.dg/torture/pr82692.c execution fails on arm
cortex-m7
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102020
Bug ID: 102020
Summary: [12 regression] analyzer/malloc-callbacks.c fails
since r12-3052
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90787
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018
--- Comment #2 from Christophe Lyon ---
Yes probably. I noticed it when upgrading newlib from 3.3.0 to 4.1.0, which
enabled new GCC tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285
--- Comment #8 from Christophe Lyon ---
Sorry I am still seeing errors on trunk and gcc-11:
FAIL: experimental/net/socket/socket_base.cc (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
Bug ID: 102072
Summary: New test case gcc.dg/vect/pr101145_3.c in r12-3136
fails on armeb
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
--- Comment #3 from Christophe Lyon ---
Indeed, so I don't think this is a dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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=114323
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2024-03-14
Status|UNCONFI
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
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=110378
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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=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=104167
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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=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 #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
--- 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=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=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
201 - 300 of 437 matches
Mail list logo
