[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
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
pointer_to_this >
BLK
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4b28
domain
DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4a80 precision:64 min max >
pointer_to_this >
addressable used ignored BLK s.f90:10:17 size
unit-size
align:8 warn_if_not_align:0 context >
And if I look at the tree dump, it seems the variable is indeed not created
correctly:
__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
try
{
_gfortran_ieee_procedure_entry ((void *) );
see the missing declaration for fpstate.0. But it is created by
gfc_create_var(), like so many other local variables in the front-end, so I
have no idea why it's disappearing.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment #5 from Francois-Xavier Coudert ---
The only thing IEEE_ARITHMETIC does here is call _gfortran_ieee_procedure_entry
/ _gfortran_ieee_procedure_exit to save and restore the floating-point state.
The middle-end code that errors out is this:
/* ??? If this is a local variable, and it has not been seen in any
outer BIND_EXPR, then it's probably the result of a duplicate
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
in g++.old-deja/g++.jason/binding.C.
Another possible culpit are size expressions for variably modified
types which are lost in the FE or not gimplified correctly. */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
&& decl_function_context (decl) == current_function_decl)
{
gcc_assert (seen_error ());
return GS_ERROR;
}
I don't have a debug build available right now, so I don't know which variable
is causing the issue or why. But it seems like a very weird interplay between
IEEE and DT (which are normally completely orthogonal), so maybe we're just
catching it "by chance" and the bug is preexisting (but silent).
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 Francois-Xavier Coudert changed: What|Removed |Added CC||ilg at livius dot net --- Comment #27 from Francois-Xavier Coudert --- *** Bug 115006 has been marked as a duplicate of this bug. ***
[Bug bootstrap/115006] Bootstrap with clang 17 on macOS & CLT 15.3 fails to compile gcov.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115006 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Francois-Xavier Coudert --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 *** This bug has been marked as a duplicate of bug 111632 ***
[Bug fortran/111853] f951: Segmentation fault at gfc_expression_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111853 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert --- This seems safe to backport, what do you think?
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #7 from Francois-Xavier Coudert --- I'd say that a SDK bug? It definitely shows with clang, so I filed it as FB13678545 with Apple.
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
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 for architecture arm64:
"__Z3foov", referenced from:
__Z3bazv in ccCj5plO.o
Why have we not seen it before? Because most of the use of that check is in {
dg-require-effective-target shared } so we're effectively skipping tests, and
that is silent. As far as I can tell, this addition is the first time { target
shared } is used as a conditional in something like { dg-additional-options }
in the C++ testsuite.
The fix is simple:
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index ae33c4f1e3a..467b539b20d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1390,7 +1390,7 @@ proc check_effective_target_shared { } {
# here to be undefined.
set extra_flags ""
if { [istarget *-*-darwin\[912\]*] } {
- set extra_flags "-Wl,-U,_foo,-U,_bar"
+ set extra_flags "-Wl,-U,_foo,-U,_bar,-U,__Z3foov"
}
# Note that M68K has a multilib that supports -fpic but not
# -fPIC, so we need to check both. We test with a program that
The question is: will this reveal new issues in other tests that weren't
running before. I'm starting a new regtest and will post the results here.
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
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.exp
b/gcc/testsuite/lib/target-supports.exp
index ae33c4f1e3a..467b539b20d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1390,7 +1390,7 @@ proc check_effective_target_shared { } {
# here to be undefined.
set extra_flags ""
if { [istarget *-*-darwin\[912\]*] } {
- set extra_flags "-Wl,-U,_foo,-U,_bar"
+ set extra_flags "-Wl,-U,_foo,-U,_bar,-U,__Z3foov"
}
# Note that M68K has a multilib that supports -fpic but not
# -fPIC, so we need to check both. We test with a program that
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
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 ccCj5plO.o
Why have we not seen it before? Because most of the use of that check is in {
dg-require-effective-target shared } so we're effectively skipping tests, and
that is silent.
As far as I can tell, your addition is the first time { target shared } is used
as a conditional in something like { dg-additional-options } in the C++
testsuite.
Thanks for helping me figuring it out, that's definitely at least a darwin
issue, which I'll take care of.
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
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/testsuite/g++.dg/other/pr113617.C -fdiagnostics-plain-output -nostdinc++ -I/Users/fx/ibin-20240306/x86_64-apple-darwin23/libstdc++-v3/include/x86_64-apple-darwin23 -I/Users/fx/ibin-20240306/x86_64-apple-darwin23/l ibstdc++-v3/include -I/Users/fx/gcc-upstream/libstdc++-v3/libsupc++ -I/Users/fx/gcc-upstream/libstdc++-v3/include/backward -I/Users/fx/gcc-upstream/libstdc++-v3/testsuite/util -fmessag e-length=0 -std=gnu++20 -O2 -fPIC /Users/fx/gcc-upstream/gcc/testsuite/g++.dg/other/pr113617-aux.cc -dumpbase "" -L/Users/fx/ibin-20240306/x86_64-apple-darwin23/./libstdc++-v3/src /.libs -B/Users/fx/ibin-20240306/x86_64-apple-darwin23/./libstdc++-v3/src/.libs -L/Users/fx/ibin-20240306/x86_64-apple-darwin23/./libstdc++-v3/src/.libs -L/Users/fx/ibin-20240306/x8 6_64-apple-darwin23/./libstdc++-v3/src/experimental/.libs -B/Users/fx/ibin-20240306/x86_64-apple-darwin23/./libitm/ -L/Users/fx/ibin-20240306/x86_64-apple-darwin23/./libitm/.libs -lm -o pr113617.exe(timeout = 300)
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
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:
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
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)
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #19 from Francois-Xavier Coudert --- The testcase introduced fails on darwin, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 Francois-Xavier Coudert changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #2 from Francois-Xavier Coudert --- Jakub, could you advise on what should happen for this test case? It's failing on darwin due to undefined symbols.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #11 from Francois-Xavier Coudert --- Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking bootstrap on x86_64-apple-darwin23
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 Francois-Xavier Coudert changed: What|Removed |Added Target||x86_64-apple-darwin23 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-05 CC||iains at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/114233] New: Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 Bug ID: 114233 Summary: Newly-introduced pr113617.C test fails on Darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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::foo(long long, long long) in cci8MVgO.o R::Y>::operator->(), referenced from: A::foo(long long, long long) in cci8MVgO.o N1::N2::N3::AB::bleh(), referenced from: A::foo(long long, long long) in cci8MVgO.o N1::N2::N3::AC::m1(R::S), referenced from: void N1::N2::N3::X<1>::boo, false>>(long long, long long, long long, N1::N2::N3::C<(anonymous namespace)::D, false>&) in cci8MVgO.o void N1::N2::N3::X<1>::boo, false>>(long long, long long, long long, N1::N2::N3::C<(anonymous namespace)::D, false>&) in ccjwgqSE.o N1::N2::N3::AC::AC(int), referenced from: void N1::N2::N3::X<1>::boo, false>>(long long, long long, long long, N1::N2::N3::C<(anonymous namespace)::D, false>&) in cci8MVgO.o void N1::N2::N3::X<1>::boo, false>>(long long, long long, long long, N1::N2::N3::C<(anonymous namespace)::D, false>&) in ccjwgqSE.o _main, referenced from:
[Bug target/114036] Test failure of gcov-14.c on darwin
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.
[Bug target/114033] Failure of test darwin-cfstring1.C
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=edit Preprocessed source
[Bug target/114033] Failure of test darwin-cfstring1.C
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(CFOptionFlags, CFDataSearchFlags) {
kCFDataSearchBackwards = 1UL << 0,
kCFDataSearchAnchored = 1UL << 1
} API_AVAILABLE(macos(10.6), ios(4.0), watchos(2.0), tvos(9.0));
which preprocesses to:
typedef __attribute__((availability(swift,unavailable))) CFOptionFlags
CFDataSearchFlags; enum : CFDataSearchFlags {
kCFDataSearchBackwards = 1UL << 0,
kCFDataSearchAnchored = 1UL << 1
} ;
There is similar code linked to the error in CFString.h:
typedef CF_OPTIONS(CFOptionFlags, CFStringCompareFlags) {
kCFCompareCaseInsensitive = 1,
kCFCompareBackwards = 4,/* Starting from the end of the string
*/
kCFCompareAnchored = 8, /* Only at the specified starting point
*/
kCFCompareNonliteral = 16, /* If specified, loose equivalence is
performed (o-umlaut == o, umlaut) */
kCFCompareLocalized = 32, /* User's default locale is used for
the comparisons */
kCFCompareNumerically = 64, /* Numeric comparison is used; that is,
Foo2.txt < Foo7.txt < Foo25.txt */
kCFCompareDiacriticInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
watchos(2.0), tvos(9.0)) = 128, /* If specified, ignores diacritics (o-umlaut
== o) */
kCFCompareWidthInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
watchos(2.0), tvos(9.0)) = 256, /* If specified, ignores width differences ('a'
== UFF41) */
kCFCompareForcedOrdering API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0),
tvos(9.0)) = 512 /* If specified, comparisons are forced to return either
kCFCompareLessThan or kCFCompareGreaterThan if the strings are equivalent but
not strictly equal, for stability when sorting (e.g. "aaa" > "AAA" with
kCFCompareCaseInsensitive specified) */
};
[Bug target/114035] Failure of pr97172-2.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035 Francois-Xavier Coudert changed: What|Removed |Added Target||x86_64-apple-darwin23 Last reconfirmed||2024-02-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Target||x86_64-apple-darwin23 Ever confirmed|0 |1 Last reconfirmed||2024-02-21
[Bug target/114036] New: Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Bug ID: 114036
Summary: Test failure of gcov-14.c on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 line arranges that Darwin has behavior like elf weak import.
*/
/* { dg-additional-options "-flat_namespace -undefined suppress" { target
*-*-darwin* } } */
Maybe on modern systems we should simply remove that? The test appears to be
passing anyway :)
[Bug target/114035] New: Failure of pr97172-2.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035 Bug ID: 114035 Summary: Failure of pr97172-2.c on darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target 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 question is really weird: Excess errors: ld: Undefined symbols: _f2_n, referenced from: _g2_n in ccFWgwRZ.o _f2_np1, referenced from: _g2_np1 in ccFWgwRZ.o _g2_nd2p1 in ccFWgwRZ.o _fn, referenced from: _gn in ccFWgwRZ.o _fn_3, referenced from: _gn_3 in ccFWgwRZ.o _fn_n, referenced from: _gn_n in ccFWgwRZ.o _fn_n_n, referenced from: _gn_n_n in ccFWgwRZ.o _fn_n_np1, referenced from: _gn_n_np1 in ccFWgwRZ.o _fn_np1, referenced from: _gn_np1 in ccFWgwRZ.o _fn_np1_np1, referenced from: _gn_np1_np1 in ccFWgwRZ.o _fna3_1, referenced from: _gna3_1 in ccFWgwRZ.o _fna3_2_3_4, referenced from: _gna3_2_3_4 in ccFWgwRZ.o _fnp1, referenced from: _gnp1 in ccFWgwRZ.o _gnd2p1 in ccFWgwRZ.o _fnp1_3, referenced from: _gnp1_3 in ccFWgwRZ.o _gnd2p1_3 in ccFWgwRZ.o _fnp1_np1, referenced from: _gnp1_np1 in ccFWgwRZ.o _gnd2p1_nd2p1 in ccFWgwRZ.o _fnp1_np1_np1, referenced from: _gnp1_np1_np1 in ccFWgwRZ.o _gnd2p1_nd2p1_nd2p1 in ccFWgwRZ.o _fx_n, referenced from: _gx_n in ccFWgwRZ.o _fx_np1, referenced from: _gx_np1 in ccFWgwRZ.o _gx_nd2p1 in ccFWgwRZ.o
[Bug target/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Target||x86_64-apple-darwin23 Last reconfirmed||2024-02-21 CC||iains at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/114034] New: Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Bug ID: 114034
Summary: Failure of tests gcov-dump-{1,2}.C
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 for excess errors)
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++20 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++20 (test for excess errors)
Excess errors:
ld: warning: ignoring duplicate libraries: '-lgcov'
The compilation line only includes one -lgcov:
/Users/fx/ibin-20240219/gcc/testsuite/g++1/../../xg++
-B/Users/fx/ibin-20240219/gcc/testsuite/g++1/../../
/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/gcov/gcov-dump-1.C
-fdiagnostics-plain-output -nostdinc++
-I/Users/fx/ibin-20240219/x86_64-apple-darwin23/libstdc++-v3/include/x86_64-apple-darwin23
-I/Users/fx/ibin-20240219/x86_64-apple-darwin23/libstdc++-v3/include
-I/Users/fx/gcc-upstream/libstdc++-v3/libsupc++
-I/Users/fx/gcc-upstream/libstdc++-v3/include/backward
-I/Users/fx/gcc-upstream/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -fprofile-generate -ftest-coverage -lgcov
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-B/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/experimental/.libs
-B/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm/
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm/.libs -lm -o
./gcov-dump-1.exe
but the driver somehow includes another one when calling collect2:
/Users/fx/ibin-20240219/gcc/testsuite/g++1/../../collect2 -demangle -syslibroot
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64
-platform_version macos 14.0.0 0.0 -o ./gcov-dump-1.exe
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/experimental/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm/.libs
-L/Users/fx/ibin-20240219/gcc/testsuite/g++1/../..
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm -lemutls_w -lheapt_w
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccyOpfRM.o -lgcov -lstdc++
-lgcov -lgcc_s.1.1 -lgcc -lSystem -no_compact_unwind -rpath @loader_path -rpath
/Users/fx/ibin-20240219/gcc -rpath
/Users/fx/ibin-20240219/x86_64-apple-darwin23/libstdc++-v3/src/.libs -rpath
/Users/fx/ibin-20240219/x86_64-apple-darwin23/libitm
I'm wondering if it's a good idea to simply ignore the warning in the two test
cases. It's not such a frequent use case, and darwin linker to being a pain
here.
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2024-02-21 Ever confirmed|0 |1 Target||x86_64-apple-darwin23 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org
[Bug target/114033] New: Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 Bug ID: 114033 Summary: Failure of test darwin-cfstring1.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target 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) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++20 (test for excess errors) But the same test passes with -std=gnu++98: PASS: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for excess errors) The excess errors that result in failure are: Excess errors: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFData.h:67:9: error: 'unavailable' was not declared in this scope /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:420:9: error: 'unavailable' was not declared in this scope
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Francois-Xavier Coudert --- Didn't have any fallout reported, so let's go. Backported to 13 as https://gcc.gnu.org/git?p=gcc.git;a=commit;h=0ea5efea8f24e182b17c7f4f2e3923a2938a2de3 Backported to 12 as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=56071adae867e63248816f5879339eec27785383 Backported to 11 as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=407100bffa8c66e92fd4f6bfd2a083995b9dab93
[Bug target/105980] [11 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #13 from Francois-Xavier Coudert --- The new test fails on darwin, with an ICE. Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342
[Bug target/111342] ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-10 Ever confirmed|0 |1
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
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 -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Also, there are more failures with -m32 on the same x86_64-linux: FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-4_c.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-6_c.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 Francois-Xavier Coudert changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-19 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Decembe ||r/640943.html Ever confirmed|0 |1 --- Comment #4 from Francois-Xavier Coudert --- I introduced the original behaviour and I'm not sure I remember why. I've propose to remove the duplication, because I cannot see a single case where it could be useful. Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640943.html
[Bug fortran/112828] Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #1 from Francois-Xavier Coudert --- I cannot reproduce this on macOS with gfortran 13.2.0 Could you give more details on what compiler version, what target, etc?
[Bug fortran/100651] [11/12/13/14 Regression] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
Last reconfirmed|2021-07-29 00:00:00 |2023-11-25
Target|x86_64-linux-gnu, |
|x86_64-apple-darwin |
--- Comment #10 from Francois-Xavier Coudert ---
Further reduced to this:
meau /tmp $ cat a.f90
program main
character(:), allocatable :: err_msg
call to_int(err_msg)
print *, 'allocated :', allocated(err_msg)
print *, err_msg(1:7)
print *, 'len : ', len(err_msg)
print *, 'err_msg : ', err_msg
contains
subroutine assert_code(err_msg)
character(:), optional, allocatable :: err_msg
err_msg = 'foo bar'
end
subroutine to_int(err_msg)
character(:), optional, allocatable :: err_msg
call assert_code(err_msg)
end
end
meau /tmp $ gfortran a.f90 -O0 -g && ./a.out
allocated : T
foo bar
len : 39026212
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc
The problem is in the code generated for the to_int subroutine, handling the
optional aspect. We can see above that the string is allocated and set
correctly. However, the length is not correctly set. You can see from the dump:
__attribute__((fn spec (". w ")))
void to_int (character(kind=1)[1:*_err_msg] * * err_msg, integer(kind=8) *
_err_msg)
{
{
character(kind=1)[1:*_err_msg] * * D.3001;
integer(kind=8) D.3002;
D.3001 = err_msg != 0B ? err_msg : 0B;
D.3002 = err_msg != 0B ? *_err_msg : 0;
assert_code (D.3001, );
}
}
The string length passed as second argument to assert_code is a pointer to a
local variable, and its value will not be propagated back into _err_msg (the
string length passed to to_int).
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||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://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801216.html
[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21
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`::M2Emit_InternalError(message_="expecting a DefImp symbol",
_message_high=25) at M2Emit.c:97:8
frame #1: 0x00010004be0c
cc1gm2`::M2Error_InternalError(message_=, _message_high=25) at
M2Error.c:2605:24
frame #2: 0x0001000a9543 cc1gm2`::SymbolTable_IsDefinitionForC(Sym=165)
at SymbolTable.c:16397:31
frame #3: 0x000100047676 cc1gm2`::M2Comp_compile(void *) at
M2Comp.c:1114:43
frame #4: 0x0001000475db cc1gm2`::M2Comp_compile(void *) at
M2Comp.c:1189:28
frame #5: 0x000100047246 cc1gm2`::M2Comp_compile(void *) [inlined]
Compile(s=0x637079c0) at M2Comp.c:427:11
frame #6: 0x000100047246
cc1gm2`::M2Comp_compile(filename=) at M2Comp.c:1540:11
frame #7: 0x000163e1 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:803:26
frame #8: 0x00016393 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:810:25
frame #9: 0x000101476d04 cc1gm2`::compile_file() at toplev.cc:446:25
frame #10: 0x000101db1d06 cc1gm2`toplev::main(int, char**) at
toplev.cc:2129:24
frame #11: 0x000101dc13c0 cc1gm2
The trace for the other one is:
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0001000692b0 cc1gm2`::M2MetaError_MetaErrorT1(tok=3628,
m_="module {%1Ea} has a corresponding DEFINITION MODULE but no IMPLEMENTATION
keyword in the main module", _m_high=100, s=155) at M2MetaError.c:3471:1
frame #1: 0x00010009823d
cc1gm2`::P1SymBuild_P1StartBuildProgramModule() at P1SymBuild.c:633:31
frame #2: 0x0001000e5b43 cc1gm2`::P1Build_CompilationUnit() [inlined]
ProgramModule(stopset0=1, stopset1=0, stopset2=0) at P1Build.c:3038:40
frame #3: 0x0001000e5b10 cc1gm2`::P1Build_CompilationUnit() [inlined]
ImplementationOrProgramModule(stopset0=1, stopset1=0, stopset2=0) at
P1Build.c:3143:21
frame #4: 0x0001000e5b10 cc1gm2`::P1Build_CompilationUnit() [inlined]
FileUnit(stopset0=1, stopset1=0, stopset2=0) at P1Build.c:2993:37
frame #5: 0x0001000e51e0 cc1gm2`::P1Build_CompilationUnit() at
P1Build.c:6664:12
frame #6: 0x000100047c59 cc1gm2`::M2Comp_compile(void *) at
M2Comp.c:1258:46
frame #7: 0x000100047bd8 cc1gm2`::M2Comp_compile(void *) [inlined]
Compile(s=0x6370a1c0) at M2Comp.c:433:11
frame #8: 0x000100047246
cc1gm2`::M2Comp_compile(filename=) at M2Comp.c:1540:11
frame #9: 0x000163e1 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:803:26
frame #10: 0x00016393 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:810:25
frame #11: 0x000101476d04 cc1gm2`::compile_file() at toplev.cc:446:25
frame #12: 0x000101db1d06 cc1gm2`toplev::main(int, char**) at
toplev.cc:2129:24
frame #13: 0x000101dc13c0 cc1gm2
[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 Francois-Xavier Coudert changed: What|Removed |Added Host||x86_64-apple-darwin21 Target||x86_64-apple-darwin21 Last reconfirmed||2023-11-13 Status|UNCONFIRMED |NEW Known to fail||14.0 Keywords||testsuite-fail Build||x86_64-apple-darwin21 Ever confirmed|0 |1
[Bug modula2/112506] New: gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
Bug ID: 112506
Summary: gm2 test failures on x86_64-apple-darwin21
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 ===
# of expected passes12740
# of unexpected failures60
# of unresolved testcases 48
They seem to belong to two different series:
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-g } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -g } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O -g } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O -g } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-Os } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -Os } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O3 -fomit-frame-pointer } timeout=10 (internal compiler error: expecting a
DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O3 -fomit-frame-pointer } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O3 -fomit-frame-pointer -finline-functions } timeout=10 (internal compiler
error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O3 -fomit-frame-pointer -finline-functions } timeout=10
fails with: "cc1gm2: internal compiler error: expecting a DefImp symbol"
and
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -g }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O -g }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -Os }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -Os }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -g }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O -g }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -Os }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -Os }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
FAIL: gm2/pim/run/pass/longint1.mod compilation, {additional_flags= -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/longint1.mod execution, {additional_flags= -g }
timeout=10
FAIL: gm2/pim/run/pass/longint1.mod
[Bug libstdc++/112397] New: Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Bug ID: 112397 Summary: Two persistent libstdc++ test failures on x86_64-apple-darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal 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) The both have the same linker warning: ld: warning: direct access in function 'operator new[](unsigned long, std::nothrow_t const&) (.cold)' from file '/Users/fx/ibin-2023 1105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator new[](unsigned long, s td::nothrow_t const&)' from file '/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' m eans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with diff erent visibility settings. ld: warning: direct access in function 'operator new[](unsigned long, std::nothrow_t const&) (.cold)' from file '/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator new[](unsigned long, std::nothrow_t const&)' from file '/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. I am not sure what the "different visibility settings" are, or if it's just a red herring, but the testcase is compiled with: Executing on host: /Users/fx/ibin-20231105/./gcc/xg++ -shared-libgcc -B/Users/fx/ibin-20231105/./gcc -nostdinc++ -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src/.libs -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/libsupc++/.libs -B/Users/fx/irun-20231105/x86_64-apple-darwin21/bin/ -B/Users/fx/irun-20231105/x86_64-apple-darwin21/lib/ -isystem /Users/fx/irun-20231105/x86_64-apple-darwin21/include -isystem /Users/fx/irun-20231105/x86_64-apple-darwin21/sys-include -fchecking=1 -B/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/include/x86_64-apple-darwin21 -I/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/include -I/Users/fx/gcc-upstream/libstdc++-v3/libsupc++ -I/Users/fx/gcc-upstream/libstdc++-v3/include/backward -I/Users/fx/gcc-upstream/libstdc++-v3/testsuite/util /Users/fx/gcc-upstream/libstdc++-v3/testsuite/17_intro/static.cc -std=gnu++17 -static-libstdc++ -fdiagnostics-plain-output ./libtestc++.a -liconv -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src/filesystem/.libs -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src/experimental/.libs -lm -o ./static.exe(timeout = 360)
[Bug libbacktrace/112396] New: "make check" should not error out, even when some checks failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396 Bug ID: 112396 Summary: "make check" should not error out, even when some checks failed Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: 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 error out in make, even when individual tests fail. The one exception is libbacktrace, which does error out when one or more test failed: make[4]: *** [test-suite.log] Error 1 make[3]: *** [check-TESTS] Error 2 make[2]: *** [check-am] Error 2 make[2]: Target `check' not remade because of errors. make[1]: *** [check-target-libbacktrace] Error 2 This means that if, like me, you forgot to run "make check" with -k, you get stopped in the middle of testing. To be nice to users, and for consistency, it would be nice if this behaviour was changed.
[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Francois-Xavier Coudert --- OK, it's gone.
[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces
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.
[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Host||x86_64-apple-darwin21 Last reconfirmed||2023-11-03 CC||hjl.tools at gmail dot com, ||iains at gcc dot gnu.org Target||x86_64-apple-darwin21 Status|UNCONFIRMED |NEW Keywords||testsuite-fail Build||x86_64-apple-darwin21
[Bug target/112368] New: Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368 Bug ID: 112368 Summary: Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal 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=gnu++98 scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 4 FAIL: g++.target/i386/pr80566-2.C -std=gnu++14 scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 4 FAIL: g++.target/i386/pr80566-2.C -std=gnu++17 scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 4 FAIL: g++.target/i386/pr80566-2.C -std=gnu++20 scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 4 FAIL: gcc.target/i386/eh_return-1.c scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 4 FAIL: gcc.target/i386/pieces-memcpy-12.c scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 4 FAIL: gcc.target/i386/pieces-memcpy-13.c scan-assembler-times vmovdqu64[ t]+[^\\n]*%zmm 2 FAIL: gcc.target/i386/pieces-memcpy-15.c scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 2 FAIL: gcc.target/i386/pieces-memcpy-16.c scan-assembler-times vmovdqu[ t]+[^\\n]*%ymm 2 FAIL: gcc.target/i386/pieces-memcpy-17.c scan-assembler-times vmovdqu64[ t]+[^\\n]*%zmm 2 FAIL: gcc.target/i386/pieces-memcpy-18.c scan-assembler-times vmovdqu64[ t]+[^\\n]*%zmm 2 FAIL: gcc.target/i386/pieces-memcpy-20.c scan-assembler-times vmovdqu(?:64|)[ t]+[^\\n]*%ymm 4 FAIL: gcc.target/i386/pieces-memcpy-21.c scan-assembler-times vmovdqu(?:64|)[ t]+[^\\n]*%ymm 4 FAIL: gcc.target/i386/pr90773-26.c scan-assembler-times vmovdqu[t ]%ymm[0-9]+, (%[^,]+) 1 FAIL: gcc.target/i386/pr90773-26.c scan-assembler-times vmovdqu[t ]%ymm[0-9]+, 32(%[^,]+) 1 They were not present on 20230909 (https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795615.html) and first appeared on test results in 20231023 (https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/799220.html). Taking the example of gcc.target/i386/pieces-memcpy-12.c, the asm generated is: .build_version macos, 12, 0 .text .p2align 4 .globl _foo _foo: LFB0: movq_src@GOTPCREL(%rip), %rdx movq_dst@GOTPCREL(%rip), %rax movq(%rdx), %rdx movq(%rax), %rax vmovdqu (%rdx), %xmm0 vmovdqu %xmm0, (%rax) vmovdqu 16(%rdx), %xmm1 vmovdqu %xmm1, 16(%rax) vmovdqu 32(%rdx), %xmm2 vmovdqu %xmm2, 32(%rax) vmovdqu 48(%rdx), %xmm3 vmovdqu %xmm3, 48(%rax) ret LFE0: .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0 .byte 0x3 .ascii "zR\0" .uleb128 0x1 .sleb128 -8 .uleb128 0x10 .uleb128 0x1 .byte 0x10 .byte 0xc .uleb128 0x7 .uleb128 0x8 .byte 0x90 .uleb128 0x1 .align 3 LECIE1: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .long LASFDE1-EH_frame1 .quad LFB0-. .set L$set$2,LFE0-LFB0 .quad L$set$2 .uleb128 0 .align 3 LEFDE1: .subsections_via_symbols
[Bug testsuite/111066] g++.dg/special/initpri3.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Francois-Xavier Coudert --- Fixed on mainline (14).
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 Francois-Xavier Coudert changed: What|Removed |Added Build||x86_64-apple-darwin21 Resolution|--- |FIXED Status|NEW |RESOLVED Target||x86_64-apple-darwin21 Host||x86_64-apple-darwin21 --- Comment #6 from Francois-Xavier Coudert --- Fixed on mainline.
[Bug target/111635] Objects built with -flto cannot be linked with Xcode
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: calculating backend command to run: /opt/homebrew/bin/ninja -C /private/tmp/bmpflash/build ninja: Entering directory `/private/tmp/bmpflash/build' [27/27] Linking target src/bmpflash
[Bug target/111635] Objects built with -flto cannot be linked with Xcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert --- (In reply to Amyspark from comment #0) > It is still easily > reproducible by building https://github.com/blackmagic-debug/bmpflash with > `meson setup build -Db_lto=true --buildtype=debug` followed by `meson > compile -C build`. I tried but could not reproduce on aarch64-apple-darwin23. The first try failed because the code was updated and refuses to build with LTO. I checked out commit f87ad307ddc1822e3a770e234ae2adcbe5ea855b The second try failed because: libusb| Run-time dependency iokit found: NO (tried framework) deps/libusb/meson.build:112:2: ERROR: Dependency "IOKit" not found, tried framework
[Bug target/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 Francois-Xavier Coudert changed: What|Removed |Added Build||x86_64-apple-darwin21 Status|UNCONFIRMED |NEW Host||x86_64-apple-darwin21 Keywords||testsuite-fail CC||iains at gcc dot gnu.org Target||x86_64-apple-darwin21 Ever confirmed|0 |1 Last reconfirmed||2023-10-30 --- Comment #1 from Francois-Xavier Coudert --- I don't know enough to see if the asm in the code is incompatible with darwin syntax, or if the middle-end should emit different asm.
[Bug target/112297] New: Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 Bug ID: 112297 Summary: Failure of pr100936.c on x86_64-apple-darwin21 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 _var, %rax ^ The testcase is compiled to: .build_version macos, 12, 0 .text .p2align 4 .globl _baz _baz: LFB2: # 12 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/pr100936.c" 1 lea _var, %rax # 0 "" 2 # 22 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/pr100936.c" 1 mov %gs:(%rax), %eax # 0 "" 2 ret LFE2: .globl _var .zerofill __DATA,__common,_var,4,2 .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0 .byte 0x3 .ascii "zR\0" .uleb128 0x1 .sleb128 -8 .uleb128 0x10 .uleb128 0x1 .byte 0x10 .byte 0xc .uleb128 0x7 .uleb128 0x8 .byte 0x90 .uleb128 0x1 .align 3 LECIE1: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .long LASFDE1-EH_frame1 .quad LFB2-. .set L$set$2,LFE2-LFB2 .quad L$set$2 .uleb128 0 .align 3 LEFDE1: .ident "GCC: (GNU) 14.0.0 20231029 (experimental) [master c6929b08558]" .subsections_via_symbols
[Bug target/112294] thread_local13.C and thread_local14.C fail on x86_64-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Host||x86_64-apple-darwin21 Last reconfirmed||2023-10-30 Known to fail||13.1.0, 14.0 Status|UNCONFIRMED |NEW Target||x86_64-apple-darwin21 Keywords||testsuite-fail Build||x86_64-apple-darwin21 CC||iains at gcc dot gnu.org
[Bug target/112294] New: thread_local13.C and thread_local14.C fail on x86_64-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294
Bug ID: 112294
Summary: thread_local13.C and thread_local14.C fail on
x86_64-darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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++17 execution test
FAIL: g++.dg/tls/thread_local13.C -std=gnu++20 execution test
FAIL: g++.dg/tls/thread_local14.C -std=gnu++14 execution test
FAIL: g++.dg/tls/thread_local14.C -std=gnu++17 execution test
FAIL: g++.dg/tls/thread_local14.C -std=gnu++20 execution test
have been present in (at least) GCC 14 and 13 for some months:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-May/783122.html
The runtime failure is a segfault, and the backtrace (obtained by adding -g to
the compilation flags) is:
Process 72865 launched: '/Users/fx/ibin-20231029/gcc/thread_local13.exe'
(x86_64)
Process 72865 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x00013df3 thread_local13.exe`baz() at
thread_local13.C:17:13
14 {
15 while (1)
16 {
-> 17 t.foo ();
18 if (!bar ())
19 return false;
20 }
Target 0: (thread_local13.exe) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
* frame #0: 0x00013df3 thread_local13.exe`baz() at
thread_local13.C:17:13
frame #1: 0x00013e79 thread_local13.exe`main + 9
frame #2: 0x00010001552e dyld`start + 462
[Bug target/112287] gcc.target/i386/pr111698.c fails on x86_64-darwin
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.
[Bug target/112287] gcc.target/i386/pr111698.c fails on x86_64-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112287 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-30 Target||x86_64-apple-darwin21 Status|UNCONFIRMED |NEW CC||ubizjak at gmail dot com Host||x86_64-apple-darwin21 Build||x86_64-apple-darwin21
[Bug target/112287] New: gcc.target/i386/pr111698.c fails on x86_64-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112287 Bug ID: 112287 Summary: gcc.target/i386/pr111698.c fails on x86_64-darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 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 excess errors) FAIL: gcc.target/i386/pr111698.c scan-assembler-not testl gcc.target/i386/pr111698.c: testb found 0 times FAIL: gcc.target/i386/pr111698.c scan-assembler-times testb 1 gcc.target/i386/pr111698.c: testw found 0 times FAIL: gcc.target/i386/pr111698.c scan-assembler-times testw 1 The assembly produced is the following: .build_version macos, 12, 0 .text .p2align 4 .globl _foo _foo: LFB0: testl $655360, _m(%rip) setne %al ret LFE0: .p2align 4 .globl _bar _bar: LFB1: testl $10526720, _m(%rip) setne %al ret LFE1: .globl _m .zerofill __DATA,__common,_m,4,2 .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0 .byte 0x3 .ascii "zR\0" .uleb128 0x1 .sleb128 -8 .uleb128 0x10 .uleb128 0x1 .byte 0x10 .byte 0xc .uleb128 0x7 .uleb128 0x8 .byte 0x90 .uleb128 0x1 .align 3 LECIE1: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .long LASFDE1-EH_frame1 .quad LFB0-. .set L$set$2,LFE0-LFB0 .quad L$set$2 .uleb128 0 .align 3 LEFDE1: LSFDE3: .set L$set$3,LEFDE3-LASFDE3 .long L$set$3 LASFDE3: .long LASFDE3-EH_frame1 .quad LFB1-. .set L$set$4,LFE1-LFB1 .quad L$set$4 .uleb128 0 .align 3 LEFDE3: .subsections_via_symbols
[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
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
[Bug target/111350] New: gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
Bug ID: 111350
Summary: gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends
fail on x86_64-apple-darwin21
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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 (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfcmulcsh-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfmulcsh-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16vl-vfcmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16vl-vfmulcph-1b.c (test for excess errors)
The errors are all similar-looking:
FAIL: gcc.target/i386/avx512fp16-vfmulcsh-1b.c (test for excess errors)
Excess errors:
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cclz0cVD.s:379:2: warning:
Destination register should be distinct from source registers
vfmulcsh{rn-sae}, %xmm1, %xmm3, %xmm0{%k1}
^
FAIL: gcc.target/i386/avx512fp16-vfcmulcph-1b.c (test for excess errors)
Excess errors:
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccB0dfAf.s:475:2: warning:
Destination register should be distinct from source registers
vfcmulcph _src2(%rip), %zmm2, %zmm0{%k1}
^
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccB0dfAf.s:540:2: warning:
Destination register should be distinct from source registers
vfcmulcph {rn-sae}, %zmm7, %zmm6, %zmm0{%k1}
^
I tried to reduce one, and got:
$ cat avx512fp16vl-vfcmulcph-1b.i
typedef _Float16 __m256h __attribute__ ((__vector_size__ (32), __may_alias__));
typedef _Float16 __v16hf __attribute__ ((__vector_size__ (32)));
typedef union {
__m256h ymmh[2];
unsigned short u16[32];
} V512;
V512 src1, src2;
int n_errs = 0;
extern __inline __m256h __attribute__ ((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_mask_fcmul_pch (__m256h __A, unsigned char __B, __m256h __C, __m256h
__D)
{ return (__m256h) __builtin_ia32_vfcmulcph256_mask ((__v16hf) __C, (__v16hf)
__D, (__v16hf) __A, __B); }
void check_results(void *got, void *exp, int n_elems, char *banner) {
int i;
V512 *v1 = (V512*)got;
V512 *v2 = (V512*)exp;
for (i = 0; i < n_elems; i++) {
if (v1->u16[i] != v2->u16[i] &&
((v1->u16[i] > (v2->u16[i] + 1)) ||
(v1->u16[i] < (v2->u16[i] - 1 {
n_errs++;
break;
}
}
}
int main () {
V512 res;
V512 exp;
res.ymmh[0] = _mm256_mask_fcmul_pch (res.ymmh[0], 0xcc, src1.ymmh[0],
src2.ymmh[0]);
check_results ((void*), (void*), (256 / 16),
"_mm256_mask_fcmul_pch");
}
which yields the warning:
$ /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ avx512fp16vl-vfcmulcph-1b.i -O2
-mavx512fp16 -mavx512vl -mavx512dq -c
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccruiM7F.s:57:2: warning:
Destination register should be distinct from source registers
vfcmulcph _src2(%rip), %ymm1, %ymm0{%k1}
^
[Bug c++/111075] ICE on g++.dg/torture/tail-padding1.C on darwin
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 "/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/torture/tail-padding1.C"
struct X { ~X() {} int n; char d; };
struct Y { Y(); char c[3]; };
struct Z : X, virtual Y { Z(); };
X f() { X nrvo; __builtin_memset(, 0, sizeof(X)); return nrvo; }
Z::Z() : Y(), X(f()) {}
Y::Y() { c[0] = 1; }
int main() {
Z z;
if (z.c[0] != 1)
__builtin_abort ();
}
Backtrace of the ICE:
* frame #0: 0x000101b76378 cc1plus`internal_error(char const*, ...)
[inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at
diagnostic.cc:2320:14
frame #1: 0x000101b76378 cc1plus`internal_error(gmsgid="in %s, at
%s:%d")
frame #2: 0x000101f92296
cc1plus`fancy_abort(file="/Users/fx/gcc-upstream/gcc/cp/constexpr.cc",
line=2918, function="cxx_eval_call_expression") at diagnostic.cc:2311:18
frame #3: 0x000101c8254e
cc1plus`::__second_sect_of_cxx_eval_call_expression() at constexpr.cc:2918:3
frame #4: 0x000100054f3b
cc1plus`::cxx_eval_constant_expression(ctx=0x7ff7bfefe500, t=,
lval=vc_prvalue, non_constant_p=0x7ff7bfefe4ee,
overflow_p=0x7ff7bfefe4ef, jump_target=0x) at
constexpr.cc:7257:36
frame #5: 0x000100060156
cc1plus`::cxx_eval_outermost_constant_expr(t=0x0001045b9880,
allow_non_constant=true, strict=, manifestly_const_eval=mce_false,
constexpr_dtor=false, object=0x) at constexpr.cc:8500:36
frame #6: 0x00010006601c cc1plus`maybe_constant_value(t=,
decl=0x, manifestly_const_eval=mce_false) at
constexpr.cc:8788:45
frame #7: 0x000100091cf1 cc1plus`::cp_fold(x=,
flags=) at cp-gimplify.cc:3052:31
frame #8: 0x000100091f46 cc1plus`::cp_fold_r(stmt_p=0x0001045a3ca0,
walk_subtrees=0x7ff7bfefe8dc, data_=0x7ff7bfefe9a0) at
cp-gimplify.cc:1077:28
frame #9: 0x000101952268 cc1plus`walk_tree_1(tp=,
func=, data=0x7ff7bfefe9a0, pset=,
lh=(cc1plus`cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*) at tree.cc:5453:1))(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)) at
tree.cc:11398:25
frame #10: 0x000101952f0a cc1plus`walk_tree_1(tp=,
func=, data=0x7ff7bfefe9a0, pset=,
lh=(cc1plus`cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*) at tree.cc:5453:1))(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)) at
tree.cc:11514:4
frame #11: 0x000100087c18
cc1plus`cp_fold_function(fndecl=0x0001045be000) at cp-gimplify.cc:1199:3
frame #12: 0x0001000dc0b9
cc1plus`finish_function(inline_p=) at decl.cc:18345:22
frame #13: 0x0001001938bf
cc1plus`::maybe_thunk_body(fn=0x0001045b4e00, force=) at
optimize.cc:445:26
frame #14: 0x00010019443a
cc1plus`maybe_clone_body(fn=0x0001045b4e00) at optimize.cc:557:38
frame #15: 0x000100278978
cc1plus`expand_or_defer_fn_1(fn=0x0001045b4e00) at semantics.cc:4901:24
frame #16: 0x000100278c5e
cc1plus`expand_or_defer_fn(fn=0x0001045b4e00) at semantics.cc:4932:28
frame #17: 0x00010013c6d8
cc1plus`synthesize_method(fndecl=) at method.cc:1842:24
frame #18: 0x0001000ee7c2 cc1plus`mark_used(decl=0x0001045be000,
complain=) at decl2.cc:5855:25
frame #19: 0x00010002016b cc1plus`::build_over_call(cand=,
flags=, complain=3) at call.cc:10403:21
frame #20: 0x00010001d900
cc1plus`build_new_method_call(instance=0x0001044305d0,
fns=0x000104591f20, args=, conversion_path=,
flags=1, fn_p=0x, complain=3) at call.cc:11710:31
frame #21: 0x00010001eac0
cc1plus`build_special_member_call(instance=,
name=0x000104422100, args=0x7ff7bfeff110, binfo=, flags=1,
complain=3) at call.cc:11190:31
frame #22: 0x00010010fc1d cc1plus`::expand_aggr_init_1(tree, tree,
tree, tree, int, tsubst_flags_t) at init.cc:2203:40
frame #23: 0x00010010fb34
cc1plus`::expand_aggr_init_1(binfo=0x0001045b02a0,
true_exp=0x, exp=0x0001044305d0, init=,
flags=1, complain=3)
frame #24: 0x000100117964
cc1plus`emit_mem_initializers(mem_inits=) at init.cc:1562:23
frame #25: 0x0001001ebec0
cc1plus`::cp_parser_ctor_initializer_opt_and_function_body(parser=0x0001045ac150,
in_function_try_block=false) at parser.cc:17188:29
frame #26: 0x0001001ed6e0
cc1plus`::cp_parser_function_definition_after_declarator(parser=0x0001045ac150,
inline_p=false) at parser.cc:32243:7
frame #27: 0x0001001eecbe
[Bug target/111342] New: ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342
Bug ID: 111342
Summary: ICE for g++.target/i386/pr105980.C on
x86_64-apple-darwin21
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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 testcase: without that
option, the test can compile fine.
$ cat pr105980.ii
# 0 "/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C"
# 0 ""
# 0 ""
# 1 "/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C"
struct A {
virtual ~A();
};
struct B : virtual A {};
void bar() { B(); }
$ /Users/fx/ibin/gcc/testsuite/g++/../../cc1plus -fpreprocessed pr105980.ii
-fPIC -quiet -mforce-indirect-call -std=gnu++20
/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C: In member
function ‘virtual void B::_ZTv0_n24_N1BD1Ev()’:
/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C:8:19: error:
unrecognizable insn:
8 | void bar() { B(); }
| ^
(call_insn/j 4 3 5 (call (mem:QI (symbol_ref/i:DI ("_ZN1BD1Ev") [flags 0x8001]
) [0 S1 A8])
(const_int 0 [0]))
"/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C":7:8 -1
(nil)
(nil))
The backtrace, obtained under lldb, is:
* frame #0: 0x000101b76378 cc1plus`internal_error(char const*, ...)
[inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at
diagnostic.cc:2320:14
frame #1: 0x000101b76378 cc1plus`internal_error(gmsgid="in %s, at
%s:%d")
frame #2: 0x000101f92296
cc1plus`fancy_abort(file="/Users/fx/gcc-upstream/gcc/config/i386/i386.md",
line=22310, function="insn_default_length") at diagnostic.cc:2311:18
frame #3: 0x000101ebe875 cc1plus`_fatal_insn(msgid=,
insn=0x0001046cfd80, file="/Users/fx/gcc-upstream/gcc/config/i386/i386.md",
line=22310, function="insn_default_length") at rtl-error.cc:108:15
frame #4: 0x000101ebe893
cc1plus`_fatal_insn_not_found(insn=, file=,
line=, function=) at rtl-error.cc:116:17
frame #5: 0x000101dd06fb cc1plus`insn_default_length(rtx_insn*) at
i386.md:22310:9
frame #6: 0x00010101883d cc1plus`shorten_branches(first=)
at final.cc:1088:35
frame #7: 0x0001019f32bc
cc1plus`::x86_output_mi_thunk(file=0x7ff84841be00,
thunk_fndecl=0x0001046b5300, delta=,
vcall_offset=, function=) at i386.cc:22087:20
frame #8: 0x000100ead83a cc1plus`expand_thunk(node=0x0001046cb000,
output_asm_thunks=, force_gimple_thunk=) at
symtab-thunks.cc:388:39
frame #9: 0x000100ebf673
cc1plus`cgraph_node::assemble_thunks_and_aliases(this=0x00010451bdd0) at
cgraphunit.cc:1763:15
frame #10: 0x000100ebf9a4 cc1plus`cgraph_node::expand() at
cgraphunit.cc:1914:31
frame #11: 0x000100ebf7b0
cc1plus`cgraph_node::expand(this=0x00010451bdd0)
frame #12: 0x000100ec10c0
cc1plus`symbol_table::compile(this=0x000104506000) at cgraphunit.cc:2191:19
frame #13: 0x000100ec4656
cc1plus`symbol_table::finalize_compilation_unit() [inlined]
symbol_table::compile(this=0x000104506000) at cgraphunit.cc:2311:3
frame #14: 0x000100ec4645
cc1plus`symbol_table::finalize_compilation_unit(this=0x000104506000)
frame #15: 0x0001015b5efe cc1plus`::compile_file() at toplev.cc:471:41
frame #16: 0x000101f96942 cc1plus`toplev::main(this=0x7ff7bfeff8fe,
argc=, argv=) at toplev.cc:2126:24
frame #17: 0x000101f9712e cc1plus`main(argc=8, argv=0x7ff7bfeffa48)
at main.cc:39:23
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin
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=edit Output of -fdump-rtl-final
[Bug c/111340] New: gcc.dg/bitint-12.c fails on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 Bug ID: 111340 Summary: gcc.dg/bitint-12.c fails on x86_64-apple-darwin Product: gcc 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: --- 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 expression as operand I am not sure what the cause is, I don't know x86_64 assembler :(
[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #4 from Francois-Xavier Coudert --- Hum, I think I understand what happens then. This is a cross-compiler from aarch64-apple-darwin22 to x86_64-apple-darwin22, configured with: configure --prefix=/tmp/irun --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --target=x86_64-apple-darwin22 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk AS_FOR_TARGET=/usr/bin/as LD_FOR_TARGET=/usr/bin/ld NM_FOR_TARGET=/usr/bin/nm RANLIB_FOR_TARGET=/usr/bin/ranlib AR_FOR_TARGET=/usr/bin/ar LIPO_FOR_TARGET=/usr/bin/lipo DSYMUTIL_FOR_TARGET=/usr/bin/dsymutil The tests are using AS_FOR_TARGET but not passing the arch, which is necessary because it's a multi-arch linker. The actual GCC cross-compiler knows that, and systematically passes an arch argument, but gcc_GAS_CHECK_FEATURE does not know that. INVALID, then. I need a better way to create this cross-compiler.
[Bug c/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
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 become more strict between darwin20 and darwin22.
[Bug c/111237] New: fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237
Bug ID: 111237
Summary: fp-int-convert-float64x.c fails on x86_64-apple-darwin
with "ambiguous instructions require an explicit
suffix"
Product: gcc
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/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccO1vBzR.s:16:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
fild-8(%rbp)
^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccO1vBzR.s:19:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
fisttp -8(%rbp)
^
This is on a cross-compiler from aarch64-apple-darwin22 to
x86_64-apple-darwin22, but I think it would be the same on a native compiler.
Short reproducer:
$ cat toto.c
int main(void)
{
unsigned char ivin;
unsigned char ivout;
_Float64x fv1;
_Float64x fv2;
ivin = 0;
fv1 = 0;
fv2 = (_Float64x) ivin;
ivout = (unsigned char) fv1;
}
$ ./bin/x86_64-apple-darwin22-gcc toto.c -c
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccn0Y3rC.s:14:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
fild-66(%rbp)
^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccn0Y3rC.s:17:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
fisttp -66(%rbp)
^
$ ./bin/x86_64-apple-darwin22-gcc toto.c -S
$ cat toto.s
.text
.globl _main
_main:
LFB0:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
movb$0, -1(%rbp)
fldz
fstpt -32(%rbp)
movzbl -1(%rbp), %eax
movw%ax, -66(%rbp)
fild-66(%rbp)
fstpt -48(%rbp)
fldt-32(%rbp)
fisttp -66(%rbp)
movzwl -66(%rbp), %eax
movb%al, -49(%rbp)
movl$0, %eax
popq%rbp
LCFI2:
ret
LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long 0
.byte 0x1
.ascii "zR\0"
.byte 0x1
.byte 0x78
.byte 0x10
.byte 0x1
.byte 0x10
.byte 0xc
.byte 0x7
.byte 0x8
.byte 0x90
.byte 0x1
.align 3
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long LASFDE1-EH_frame1
.quad LFB0-.
.set L$set$2,LFE0-LFB0
.quad L$set$2
.byte 0
.byte 0x4
.set L$set$3,LCFI0-LFB0
.long L$set$3
.byte 0xe
.byte 0x10
.byte 0x86
.byte 0x2
.byte 0x4
.set L$set$4,LCFI1-LCFI0
.long L$set$4
.byte 0xd
.byte 0x6
.byte 0x4
.set L$set$5,LCFI2-LCFI1
.long L$set$5
.byte 0xc
.byte 0x7
.byte 0x8
.align 3
LEFDE1:
.ident "GCC: (GNU) 14.0.0 20230830 (experimental)"
.subsections_via_symbols
For the record, the assembler is called as:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx13.0.0 -filetype obj -main-file-name
ccImMDJg.s -target-cpu penryn -fdebug-compilation-dir=/tmp/irun
-dwarf-debug-producer "Apple clang version 14.0.3 (clang-1403.0.22.14.1)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-x86-pad-for-align=false -mllvm -disable-aligned-alloc-awareness=1 -o toto.o
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccImMDJg.s
[Bug c++/111083] Test failure of g++.dg/ipa/pr67056.C on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2023-08-20 Status|UNCONFIRMED |NEW Host||*-*-darwin* Target||*-*-darwin* Build||*-*-darwin* Known to fail||14.0 Ever confirmed|0 |1
[Bug c++/111083] New: Test failure of g++.dg/ipa/pr67056.C on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083 Bug ID: 111083 Summary: Test failure of g++.dg/ipa/pr67056.C on darwin Product: gcc 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: --- 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 CompositeClass" This is the content generated for pr67056.C.082i.cp: -- IPA constant propagation start: Determining dynamic type for call: CompositeClass::~CompositeClass (_3); Starting walk at: CompositeClass::~CompositeClass (_3); instance pointer: _3 Outer instance pointer: _3 offset: 0 (bits) vtbl reference: Checking vtbl store: MEM[(struct CompositeClass *)_3]._vptr.CompositeClass = [(void *)&_ZTV14CompositeClass + 16B]; Recording type: struct CompositeClass at offset 0 Determined dynamic type. Determining dynamic type for call: operator delete (this_2(D)); Starting walk at: operator delete (this_2(D)); instance pointer: this_2(D) Outer instance pointer: this_2(D) offset: 0 (bits) vtbl reference: No dynamic type change found. IPA structures before propagation: Jump functions: Jump functions of caller void operator delete(void*)/461: Jump functions of caller void* operator new(std::size_t)/460: Jump functions of caller int main(int, char**)/332: callsite int main(int, char**)/332 -> virtual CompositeClass::~CompositeClass()/320 : param 0: UNKNOWN Aggregate passed by reference: offset: 0, type: int (*) () *, CONST: [(void *)&_ZTV14CompositeClass + 16B] Context: Outer type (dynamic):struct CompositeClass offset 0 value: 0x0, mask: 0x [irange] void * [1, +INF] callsite int main(int, char**)/332 -> void* operator new(std::size_t)/460 : param 0: CONST: 16 value: 0x10, mask: 0x0 [irange] size_t [16, 16] Jump functions of caller bool boolFunc()/321: Jump functions of caller virtual CompositeClass::~CompositeClass()/320: callsite virtual CompositeClass::~CompositeClass()/320 -> void operator delete(void*)/461 : param 0: PASS THROUGH: 0, op nop_expr Context: Outer type (dynamic):struct CompositeClass offset 0 value: 0x0, mask: 0x [irange] void * [1, +INF] Jump functions of caller virtual CompositeClass::~CompositeClass()/319: Jump functions of caller EmptyClass::EmptyClass()/313: Jump functions of caller EmptyClass::EmptyClass()/312: callsite EmptyClass::EmptyClass()/312 -> EmptyClass::EmptyClass()/313 : param 0: PASS THROUGH: 0, op nop_expr value: 0x0, mask: 0x [irange] void * [1, +INF] Propagating constants: Not considering int main(int, char**)/332 for cloning; no hot calls. Not considering virtual CompositeClass::~CompositeClass()/320 for cloning; no hot calls. Not considering virtual CompositeClass::~CompositeClass()/319 for cloning; no hot calls. Considering EmptyClass::EmptyClass()/313 for cloning. Not considering EmptyClass::EmptyClass()/312 for cloning; no hot calls. overall_size: 28 - context independent values, size: 9, time_benefit: 2.00 - context independent values, size: 2, time_benefit: 1.00 Decided to specialize for all known contexts, growth (to 30) deemed beneficial. IPA lattices after all propagation: Lattices: Node: int main(int, char**)/332: param [0]: BOTTOM ctxs: BOTTOM Bits unusable (BOTTOM) [unsupported_range] VARYING AGGS BOTTOM param [1]: BOTTOM ctxs: BOTTOM Bits unusable (BOTTOM) [unsupported_range] VARYING AGGS BOTTOM Node: bool boolFunc()/321: Node: virtual CompositeClass::~CompositeClass()/320: param [0]: BOTTOM ctxs: BOTTOM Bits unusable (BOTTOM) [unsupported_range] VARYING AGGS BOTTOM Node: virtual CompositeClass::~CompositeClass()/319: param [0]: BOTTOM ctxs: BOTTOM Bits unusable (BOTTOM) [unsupported_range] VARYING AGGS BOTTOM Node: EmptyClass::EmptyClass()/313: param [0]: VARIABLE ctxs: VARIABLE Bits unusable (BOTTOM) [unsupported_range] VARYING AGGS VARIABLE Node: EmptyClass::EmptyClass()/312: param [0]: BOTTOM ctxs: BOTTOM Bits unusable (BOTTOM) [unsupported_range] VARYING AGGS BOTTOM IPA decision stage: - Creating a specialized node of EmptyClass::EmptyClass()/313 for all known contexts. IPA constant propagation end Reclaiming functions: Reclaiming variables: Clearing address taken flags: Symbol table: _ZN10EmptyClassC1Ev.constprop.0/468 (EmptyClass::EmptyClass()) Type: function definition analyzed
[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment #13 from Francois-Xavier Coudert ---
That test case also fails on darwin. Adding:
diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
index 452e1b88514..57c5262dd4a 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
@@ -1,4 +1,5 @@
/* { dg-do link } */
+/* { dg-require-alias "" } */
/* { dg-options "-O2 -fdump-ipa-icf-optimized -flto -fdump-tree-optimized" }
*/
/* { dg-require-effective-target lto } */
/* { dg-additional-sources "ipa-icf-38a.c" }*/
[Bug lto/111081] LTO link failure on darwin: g++.dg/lto/pr65276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111081 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||14.0 Last reconfirmed||2023-08-20 Status|UNCONFIRMED |NEW Target||*-apple-darwin Build||*-apple-darwin Host||*-apple-darwin
[Bug lto/111081] New: LTO link failure on darwin: g++.dg/lto/pr65276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111081 Bug ID: 111081 Summary: LTO link failure on darwin: g++.dg/lto/pr65276 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11 The error occurs at linking, and it says: duplicate symbol 'typeinfo name for std2::exception' in: cp_lto_pr65276_0.o cp_lto_pr65276_1.o duplicate symbol 'typeinfo for std2::exception' in: cp_lto_pr65276_0.o cp_lto_pr65276_1.o ld: 2 duplicate symbols for architecture arm64
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
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
[Bug testsuite/111066] g++.dg/special/initpri3.C fails on darwin
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
[Bug testsuite/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
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/opt/icf1.C
@@ -1,6 +1,7 @@
// Test that -fipa-icf combines i and j.
// { dg-do run { target c++11 } }
// { dg-options -fipa-icf }
+// { dg-add-options bind_pic_locally }
[[no_unique_address]] extern const int i[] = { 1,2,3 };
[[no_unique_address]] extern const int j[] = { 1,2,3 };
and similarly on the other files, but it does not make the tests pass.
[Bug c++/111075] ICE on g++.dg/torture/tail-padding1.C on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075 Francois-Xavier Coudert changed: What|Removed |Added Target||x86_64-apple-darwin20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-19 Build||x86_64-apple-darwin20 Keywords||ice-on-valid-code Known to fail||14.0 Host||x86_64-apple-darwin20
[Bug c++/111075] New: ICE on g++.dg/torture/tail-padding1.C on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Bug ID: 111075
Summary: ICE on g++.dg/torture/tail-padding1.C on darwin
Product: gcc
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: ---
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/gcc-testresults/2023-August/793205.html):
$ cat z.C
struct X { ~X() {} int n; char d; };
struct Y { Y(); char c[3]; };
struct Z : X, virtual Y { Z(); };
X f() { X nrvo; __builtin_memset(, 0, sizeof(X)); return nrvo; }
Z::Z() : Y(), X(f()) {}
$ /tmp/irun/bin/g++ -Os z.C
z.C: In copy constructor ‘constexpr X::X(const X&)’:
z.C:1:8: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.cc:2918
1 | struct X { ~X() {} int n; char d; };
|^
[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #7 from Francois-Xavier Coudert --- The test case (g++.dg/tree-ssa/pr107876.C) fails on aarch64-darwin. FAIL: g++.dg/tree-ssa/pr107876.C -std=gnu++14 scan-tree-dump unswitch "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2" FAIL: g++.dg/tree-ssa/pr107876.C -std=gnu++17 scan-tree-dump unswitch "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2" FAIL: g++.dg/tree-ssa/pr107876.C -std=gnu++20 scan-tree-dump unswitch "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2" The output says: ;; Function test17 (_Z6test17i, funcdef_no=0, decl_uid=4194, cgraph_uid=1, symbol_order=0) Estimating # of iterations of loop 1 g++.dg/tree-ssa/pr107876.C:21:7: optimized: unswitching loop 1 on 'if' with condition: i_7(D) == 0 g++.dg/tree-ssa/pr107876.C:21:7: note: optimized sizes estimated to 0 (true) and 0 (false) from original size 16
[Bug c++/105838] [11/12 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment #25 from Francois-Xavier Coudert ---
The new test (g++.dg/tree-ssa/initlist-opt5.C) fails on darwin. The gimple dump
is like this:
void f (const char * p)
{
const struct basic_string * retval.0;
const struct basic_string * D.24981;
const struct basic_string * D.24982;
long int D.24983;
struct allocator D.24824;
struct initializer_list lst;
const struct basic_string D.24980[72];
try
{
lst = {};
lst._M_len = 72;
D.24981 =
D.24982 = D.24981;
D.24983 = 71;
try
{
_4 = D.24982;
try
{
std::allocator::allocator ();
try
{
std::__cxx11::basic_string::basic_string (_4, "aahing",
);
D.24982 = D.24982 + 32;
D.24983 = D.24983 + -1;
_5 = D.24982;
std::__cxx11::basic_string::basic_string (_5, "aaliis",
);
D.24982 = D.24982 + 32;
D.24983 = D.24983 + -1;
_6 = D.24982;
std::__cxx11::basic_string::basic_string (_6, "aarrgh",
);
D.24982 = D.24982 + 32;
D.24983 = D.24983 + -1;
_7 = D.24982;
[...]
std::__cxx11::basic_string::basic_string (_75,
"absent", );
D.24982 = D.24982 + 32;
D.24983 = D.24983 + -1;
retval.0 = D.24981;
D.24983 = 71;
lst._M_array =
}
finally
{
std::allocator::~allocator ();
}
}
finally
{
D.24824 = {CLOBBER(eol)};
}
}
catch
{
{
const struct basic_string * D.24984;
if (D.24981 != 0B) goto ; else goto ;
:
_1 = 71 - D.24983;
_2 = (sizetype) _1;
_3 = _2 * 32;
D.24984 = D.24981 + _3;
:
if (D.24984 == D.24981) goto ; else goto ;
:
D.24984 = D.24984 + 18446744073709551584;
std::__cxx11::basic_string::~basic_string (D.24984);
goto ;
:
goto ;
:
:
}
}
try
{
g ();
}
finally
{
{
const struct basic_string * D.24985;
D.24985 = + 2304;
:
if ( == D.24985) goto ; else goto ;
:
D.24985 = D.24985 + 18446744073709551584;
std::__cxx11::basic_string::~basic_string (D.24985);
goto ;
:
}
}
}
finally
{
lst = {CLOBBER(eol)};
D.24980 = {CLOBBER(eol)};
}
}
__attribute__((always_inline))
void std::allocator::allocator (struct allocator * const this)
{
try
{
{
std::__new_allocator::__new_allocator (this);
try
{
}
catch
{
std::__new_allocator::~__new_allocator (this);
}
}
}
catch
{
<<>>
}
}
__attribute__((always_inline))
void std::__new_allocator::__new_allocator (struct __new_allocator *
const this)
{
try
{
{
}
}
catch
{
<<>>
}
}
__attribute__((always_inline))
void std::allocator::~allocator (struct allocator * const this)
{
try
{
{
try
{
}
finally
{
std::__new_allocator::~__new_allocator (this);
}
}
}
catch
{
<<>>
}
}
void std::__new_allocator::~__new_allocator (struct __new_allocator *
const this)
{
try
{
{
}
}
catch
{
<<>>
}
}
[Bug c++/110070] Code quality regression with for (int i: {1,2,4,6})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110070 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert --- The tests introduced by the commit above all fail on Darwin, both on Intel and ARM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 Francois-Xavier Coudert changed: What|Removed |Added Known to fail||14.0 Target||x86_64-apple-darwin20 CC||jason at gcc dot gnu.org Host||x86_64-apple-darwin20 Build||x86_64-apple-darwin20 Last reconfirmed||2023-08-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/111067] New: g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
Bug ID: 111067
Summary: g++.dg/opt/icf{1,2,3}.C tests fail on darwin
Product: gcc
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: ---
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 -std=gnu++17 execution test
FAIL: g++.dg/opt/icf1.C -std=gnu++20 execution test
FAIL: g++.dg/opt/icf2.C -std=gnu++14 execution test
FAIL: g++.dg/opt/icf2.C -std=gnu++17 execution test
FAIL: g++.dg/opt/icf2.C -std=gnu++20 execution test
FAIL: g++.dg/opt/icf3.C -std=gnu++14 execution test
FAIL: g++.dg/opt/icf3.C -std=gnu++17 execution test
FAIL: g++.dg/opt/icf3.C -std=gnu++20 execution test
The tests fail on Darwin. I'm willing to help but do not know where to begin
debugging this.
[Bug c++/111066] g++.dg/special/initpri3.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target||x86_64-apple-darwin20 Build||x86_64-apple-darwin20 CC||ppalka at gcc dot gnu.org Host||x86_64-apple-darwin20 Last reconfirmed||2023-08-18 --- Comment #1 from Francois-Xavier Coudert --- Seen in multiple test runs, like this one: https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html
[Bug c++/111066] New: g++.dg/special/initpri3.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066 Bug ID: 111066 Summary: g++.dg/special/initpri3.C fails on darwin Product: gcc 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: --- 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 errors: /tmp/gcc-darwin-arm64/gcc/testsuite/g++.dg/special/initpri3.C:9:55: warning: 'init_priority' attribute ignored [-Wattributes]
[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf
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 > start of the test? Isn't the exception status guaranteed to be defined (and not signaling) when the program starts? But adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() could not hurt, for sure.
[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #5 from Francois-Xavier Coudert ---
OK, so it signals FE_INVALID on the first test. Can you run this with the same
options, and see what happens?
---
#include
#include
void
ftrue (float x, float y)
{
if (!__builtin_iseqsig (x, y))
__builtin_abort ();
}
int
main ()
{
volatile float f1, f2;
f1 = 0.f; f2 = 0.f;
if (fetestexcept (FE_INVALID)) printf("Invalid 1\n");
ftrue (f1, f2);
if (fetestexcept (FE_INVALID)) printf("Invalid 2\n");
return 0;
}
---
One surprising thing is that the directive "dg-add-options ieee" in the test
did not apparently add any other option for IEEE conformance…
[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796 --- Comment #3 from Francois-Xavier Coudert --- Do the failure only occur at -Os? Does it pass at -O0, -O1, -O2? And could you possibly run builtin-iseqsig-1.c under gdb and obtain a backtrace?
[Bug libfortran/110759] [14 Regression] IEEE Fortran change broke RISC-V linux build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110759 --- Comment #11 from Francois-Xavier Coudert --- Thanks Andrew for fixing it, my mistake. Apologies to everyone.
[Bug target/104871] macosx-version-min wrong for macOS >= Big Sur (darwin20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104871 Francois-Xavier Coudert changed: What|Removed |Added Target Milestone|--- |10.5 CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Francois-Xavier Coudert --- Fixed on all open branches.
[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #9 from Francois-Xavier Coudert --- I've not seen these issues for a long time, and according to testresults from July 2022 they are not seen on any of the darwin targets tested by Iain (and that's a long list!): https://gcc.gnu.org/pipermail/gcc-testresults/2022-July/thread.html I'd suggest closing.
[Bug libfortran/105935] libgfortran build fails if HAVE_VSNPRINTF test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105935 --- Comment #3 from Francois-Xavier Coudert --- > These two functions are available from libiberty. Are we linking runtime libraries like libgfortran against libiberty? I thought that was only for the compiler itself.
[Bug libfortran/105935] libgfortran build fails if HAVE_VSNPRINTF test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105935 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #1 from Francois-Xavier Coudert --- Created attachment 55363 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55363=edit Proposed patch The issue is real, but I would suggest that snprintf() and vsnprintf() should always be available, being C99 functions, on our targets. The real trigger for your issue in a mingw-w64 bug, if I read that right. I would simply recommend we stop providing our own, unsafe workarounds for these functions, per the patch attached (needs regenerating in maintainer mode, on top of the patch file).
[Bug libfortran/74755] libgfortran: build breaks if localtime_r prototype is present, but definition is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74755 Francois-Xavier Coudert changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |INVALID CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert --- > I suppose that needs to be fixed in nvptx-newlib, unless this (localtime_r > prototype present, but definition not) is a configuration that needs to be > supported in libgfortran? I totally agree that the target libc/system headers providing a localtime_r prototype without implementation is the real issue. That's how we detect a lot of functions, breaking that assumption will lead to a lot more trouble.
[Bug libfortran/37643] fortran doesn't build on 4.4.0 for vax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37643 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Francois-Xavier Coudert --- I don't think anyone on the gfortran team has access to a VAX machine to build, and so much has changed in the compiler and library since 2008 that I am going to close this. If someone can reproduce on modern versions, reopen and I will have a look. The middle-end seems to be guilty for emitting QNaN in the first place.
[Bug libfortran/109207] Uninitialised static variables in unit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109207 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Francois-Xavier Coudert --- Agree with Andrew, this is a valgrind false-positive, initialisation is done to zero because the variable is static.
[Bug libfortran/81985] several sanitizer undefined runtime errors in sanitized libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81985 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert --- Agree, was fixed for the 11 branch and later. Closing.
[Bug libfortran/109373] remove --enable-intermodule from libgfortran configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED CC||fxcoudert at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Francois-Xavier Coudert --- Fixed in https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934
[Bug fortran/105105] [Meta] Fortran IEEE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105105 Bug 105105 depends on bug 95644, which changed state. Bug 95644 Summary: [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 Francois-Xavier Coudert changed: What|Removed |Added Known to work||13.0 Target Milestone|12.4|13.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #19 from Francois-Xavier Coudert --- Not sure why this was not cross-posted here automatically, but it was fixed a year ago, and part of GCC 13 release: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c4c65d11469d29403d5a88316445ec95cd3c3f8 commit 7c4c65d11469d29403d5a88316445ec95cd3c3f8 Author: Francois-Xavier Coudert Date: Wed Aug 31 15:22:50 2022 +0200 fortran: Add IEEE_SIGNBIT and IEEE_FMA functions The functions are added to the IEEE_ARITHMETIC module, but are entirely expanded in the front-end, using GCC built-ins. 2022-08-31 Francois-Xavier Coudert PR fortran/95644 gcc/fortran/ * f95-lang.cc (gfc_init_builtin_functions): Declare FMA built-ins. * mathbuiltins.def: Declare FMA built-ins. * trans-intrinsic.cc (conv_intrinsic_ieee_fma): New function. (conv_intrinsic_ieee_signbit): New function. (gfc_build_intrinsic_lib_fndecls): Add cases for FMA and SIGNBIT. gcc/testsuite/ * gfortran.dg/ieee/fma_1.f90: New test. * gfortran.dg/ieee/signbit_1.f90: New test. libgfortran/ * ieee/ieee_arithmetic.F90: Add IEEE_SIGNBIT and IEEE_FMA.
[Bug bootstrap/105664] Install with suffix creates extra file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105664 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2023-04-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #9 from Francois-Xavier Coudert --- Present in gcc-13.1.0-RC-20230421
[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Francois-Xavier Coudert --- Closing.
[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062 --- Comment #5 from Francois-Xavier Coudert --- Fixed on trunk: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=31d7c8bc2630e1b5a35ccce97ac862c4920ba582
