https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
--- Comment #6 from Francois-Xavier Coudert ---
Reported to Apple as FB17100494.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Original report there: https://github.com/GMAO-SI-Team/geosesm-spack/issues/2
/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:645:26:
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119172
Francois-Xavier Coudert changed:
What|Removed |Added
Host||*-apple-darwin*
T
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
% cat b.c
int main (void) { return 0; }
% clang b.c
% otool -l a.out | grep sdk
sdk 15.2
% codesign -dvvv a.out 2>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116980
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #6 from Francois-Xavier Coudert ---
(In reply to Jonathan Wakely from comment #5)
> > #if defined(__has_feature) && __has_feature(modules)
>
> This is a bug. If __has_feature is _not_ define, then __has_feature(modules)
> would not
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Created attachment 59187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59187&action=edit
Generated asm
FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ t]+0x14d+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #4 from Francois-Xavier Coudert ---
Simple reproducer without any libstdc++ indeed:
$ cat a.cpp
#include
$ g++ a.cpp -fmodule-header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #3 from Francois-Xavier Coudert ---
I thought the dependence on -fmodule-header was indicative of an issue with the
libstdc++ compatibility with the macOS SDK, but maybe I'm wrong. I've made it
component == target.
Looking at the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
Francois-Xavier Coudert changed:
What|Removed |Added
Build||x86_64-apple-darwin24
Last
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
I am seeing a lot of new C++ failures in the testsuite when I test on macOS 15
(Sequoia), that aren't there for macOS 14. I believe it is probably due to SDK
incompatibilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #18 from Francois-Xavier Coudert ---
I can confirm that the patch posted by Iain at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=59176 applied on top of (now
pushed)
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=43eab54939d37d4e634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #8 from Francois-Xavier Coudert ---
(In reply to Iain Sandoe from comment #2)
> Created attachment 59176 [details]
> Patch under test
Does not apply to upstream GCC. I think it needs "libgcc: limit to 11 from 11"
https://github.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
The build fails during the compilation of the libgcc_s.1.dylib library with:
:info:build Undefined symbols for architecture x86_64:
:info:build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #6 from Francois-Xavier Coudert ---
So the var_decl in question is fpstate.0:
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1035003f0 precision:8 min max
pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Francois-Xavier Coudert changed:
What|Removed |Added
CC||ilg at livius dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115006
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111853
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #3 from Francois-Xavier Coudert ---
Jakub has posted a patch in the linker PR (thanks!).
But there remains a darwin bug. The test in check_effective_target_shared
actually works with C, but not with C++, because:
Undefined symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #26 from Francois-Xavier Coudert ---
PS: I can confirm two things:
1. Your patch above is still necessary
2. In conjunction with the darwin-specific fix below, the testcase now passes:
diff --git a/gcc/testsuite/lib/target-supports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #25 from Francois-Xavier Coudert ---
Yes, that test in check_effective_target_shared actually works with C, but not
with C++, because:
Undefined symbols for architecture arm64:
"__Z3foov", referenced from:
__Z3bazv in ccCj5p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #23 from Francois-Xavier Coudert ---
It's not being passed -shared on darwin:
Executing on host: /Users/fx/ibin-20240306/gcc/testsuite/g++/../../xg++
-B/Users/fx/ibin-20240306/gcc/testsuite/g++/../../
/Users/fx/gcc-upstream/gcc/tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #21 from Francois-Xavier Coudert ---
That reduces a lot, but it's still missing main:
Excess errors:
Undefined symbols for architecture x86_64:
"_main", referenced from:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #18 from Francois-Xavier Coudert ---
First patch pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a
(forgot to add the PR number, silly me)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
Francois-Xavier Coudert changed:
What|Removed |Added
CC||jakub at redhat dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
Francois-Xavier Coudert changed:
What|Removed |Added
Target||x86_64-apple-darwin23
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
FAIL: g++.dg/other/pr113617.C -std=gnu++14 (test for excess errors)
Excess errors:
ld: Undefined symbols:
R::Y>::operator->(), referenced from:
A::fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #3 from Francois-Xavier Coudert ---
There's only one symbol we care about here, and its name is known, so I'll make
a patch with your suggestion and test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #3 from Francois-Xavier Coudert ---
Created attachment 57480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57480&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #2 from Francois-Xavier Coudert ---
This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS 14.3).
I am attaching the preprocessed source.
The code from CFData.h that is triggering this is:
typedef CF_OPTIONS(CFOpti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035
Francois-Xavier Coudert changed:
What|Removed |Added
Target||x86_64-apple-darwin23
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
FAIL: gcc.misc-tests/gcov-14.c (test for excess errors)
Excess errors:
ld: warning: -undefined suppress is deprecated
The test has specific option for darwin:
/* The following
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
on x86_64-apple-darwin23
(https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/808546.html) I
see:
FAIL: gcc.dg/pr97172-2.c (test for excess errors)
The excess error in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
We have the following failures on x86_64-apple-darwin23:
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++14 (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
Francois-Xavier Coudert changed:
What|Removed |Added
Last reconfirmed||2024-02-21
Ever confirmed
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
The test g++.dg/other/darwin-cfstring1.C fails on x86_64-apple-darwin23 for
-std=gnu++14 and later:
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++14 (test for excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
--- Comment #5 from Francois-Xavier Coudert ---
Not entirely, xtreme-header_b.C is still failing, as indicated above. See
recently:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html
FAIL: g++.dg/modules/xtreme-header-2_b.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
Francois-Xavier Coudert changed:
What|Removed |Added
Keywords||patch
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
||fxcoudert at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2023-11-22
--- Comment #1 from Francois-Xavier Coudert ---
Confirmed, and also seen on a non-linux target, x86_64-apple-darwin21:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
--- Comment #1 from Francois-Xavier Coudert ---
The stack trace for the "expecting a DefImp symbol" error is the following:
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
* frame #0: 0x00010004a240
cc1gm2`::M2E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
Francois-Xavier Coudert changed:
What|Removed |Added
Host||x86_64-apple-darwin21
: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Recent test results show ~100 test failures on Darwin (see for example
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800694.html):
=== gm2 Summary
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
FAIL: 17_intro/static.cc -std=gnu++17 (test for excess errors)
FAIL: 20_util/to_chars/4.cc -std=gnu++17 (test for excess errors
ty: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
The behaviour in GCC is pretty consistent: parts of the testsuite do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
--- Comment #2 from Francois-Xavier Coudert ---
Could have been fixed by 8c40b72036c967fbb1d1150515cf70aec382f0a2
But the set of failures on Linux and Darwin are not exactly the same, so we
will see in the next regtest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Host|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Seeing many failures on x86_64-apple-darwin21 related to
TARGET_AVX256_MOVE_BY_PIECES:
FAIL: g++.target/i386/pr80566-2.C -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
Francois-Xavier Coudert changed:
What|Removed |Added
Build||x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #5 from Francois-Xavier Coudert ---
Third try (on aarch64-darwin): I installed Homebrew's libusb. But now, the
build succeeds…
⌁ [fx:/tmp/bmpflash] f87ad30 6s ± meson compile -C build
INFO: autodetecting backend as ninja
INFO: calcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297
Francois-Xavier Coudert changed:
What|Removed |Added
Build||x86_64-apple-darwin21
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
FAIL: gcc.target/i386/pr100936.c (test for excess errors)
The error is:
pr100936.s:8:2: error: 32-bit absolute addressing is not supported in 64-bit
mode
lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Host|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
The following test failures:
FAIL: g++.dg/tls/thread_local13.C -std=gnu++14 execution test
FAIL: g++.dg/tls/thread_local13.C -std=gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112287
--- Comment #2 from Francois-Xavier Coudert ---
(In reply to Andrew Pinski from comment #1)
> My bet is that the testcase just needs a -march option since iirc Darwin
> defaults to core2.
Thanks, it works. Patch posted to the list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112287
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
The fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698 introduced
testsuite failures on x86_64-apple-darwin21:
PASS: gcc.target/i386/pr111698.c (test for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #3 from Francois-Xavier Coudert ---
Clang: 14.0.0 build 1400
CLT: 14.2.0.0.1.1668646533
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
We're seeing these failures on x86_64-apple-darwin21:
FAIL: gcc.target/i386/avx512fp16-vfcmulcph-1b.c (tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
--- Comment #1 from Francois-Xavier Coudert ---
Preprocessed source:
% cat a-tail-padding1.ii
# 0 "/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/torture/tail-padding1.C"
# 0 ""
# 0 ""
# 1 "/
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
There is an ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21. It is
linked to the -mforce-indirect-call option passed by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340
--- Comment #2 from Francois-Xavier Coudert ---
Created attachment 55857
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55857&action=edit
Output of -fdump-rtl-final
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
gcc.dg/bitint-12.c fails on x86_64-apple-darwin, with excess error:
/Users/fx/gcc-upstream/gcc/testsuite/gcc.dg/bitint-12.c:18:3: error: invalid
'asm': invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237
--- Comment #1 from Francois-Xavier Coudert ---
The failure was not seen on August 9 at
https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html on
x86_64-apple-darwin20, so either it is a regression, or the Apple assembler has
beco
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Many of these messages:
/var/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083
Francois-Xavier Coudert changed:
What|Removed |Added
Last reconfirmed||2023-08-20
Status
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
On darwin (both aarch64 and x86_64), we see the following test failure:
FAIL: g++.dg/ipa/pr67056.C scan-ipa-dump cp "Speculative outer
type:struct Composite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111081
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The test failure is seen on both x86_64-apple-darwin and aarch64-apple-darwin:
FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
--- Comment #5 from Francois-Xavier Coudert ---
Patch posted for Darwin at
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627923.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066
--- Comment #3 from Francois-Xavier Coudert ---
Makes sense, patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627922.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #2 from Francois-Xavier Coudert ---
I tried with:
diff --git a/gcc/testsuite/g++.dg/opt/icf1.C b/gcc/testsuite/g++.dg/opt/icf1.C
index fbb275e635a..d4e4bbf91b9 100644
--- a/gcc/testsuite/g++.dg/opt/icf1.C
+++ b/gcc/testsuite/g++.dg/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Francois-Xavier Coudert changed:
What|Removed |Added
Target||x86_64-apple-darwin20
Eve
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
ICE on valid C++ code, reduced from the test failure of
g++.dg/torture/tail-padding1.C observed on x86_64-apple-darwin20 (see for
example at
https://gcc.gnu.org/pipermail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110070
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
Francois-Xavier Coudert changed:
What|Removed |Added
Known to fail||14.0
Target|
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
As seen for example on
https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html
FAIL: g++.dg/opt/icf1.C -std=gnu++14 execution test
FAIL: g++.dg/opt/icf1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIR
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
A warning there triggers the failure:
FAIL: g++.dg/special/initpri3.C at line 10 (test for warnings, line 9)
FAIL: g++.dg/special/initpri3.C (test for excess errors)
Excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #8 from Francois-Xavier Coudert ---
(In reply to Richard Earnshaw from comment #6)
> Is the exception status supposed to be in a defined state when the test
> runs? Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
>
1 - 100 of 966 matches
Mail list logo
