Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Can you post an updated version of the patch, following the first round of review? FX
Re: Nonbootstrap build with Apple clang broken in gm2
> Ah yes indeed it is systematic. Many thanks for spotting this - git > pushed GNU flex required > https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html Couldn’t the generated files be committed to the tree, so that flex is not needed (unless one modifies the source). This is what is done for the other use of flex. FX
Re: Nonbootstrap build with Apple clang broken in gm2
Another quick m2-related question: I am seeing, in a build of GCC 14.1.0 on Linux, that flex is called when building with the modula-2 front-end. It was not the case in previous builds, and the only difference is that I added m2 to the languages. Is that systematic? If so, the prerequisites page should be amended: https://gcc.gnu.org/install/prerequisites.html Best, FX
Re: [PATCH] fixincludes: skip stdio_stdarg_h on darwin
Hi Iain, > This does fix the bootstrap problem on those, thanks > In this case, I’d like to test it across the OS versions I still test > regularly - but the machines are all going to be tied up testing the 11.5 RC > - so it might be a week or so. I do want to get this in as soon as poss - > reducing the dependency on SDK version is a good mission. Yes, the fact that it fixes the bootstrap shows (I believe) that I have now correctly understood the issue. But for sure it needs wider testing, and there is no emergency, although as you stated it is a desirable goal. I dream of a day where we no longer have to use fixincludes. FX
Nonbootstrap build with Apple clang broken in gm2
Hi, I am unable to perform a nonbootstrap build when gm2 is included, with Apple clang 15 as compiler. The error is due to incorrect inclusion of headers ( and ) which are included after GCC’s system.h has been included, and macros like abort() are redefined or poisoned. I think the correct idiom in GCC is to #define INCLUDE_STRING (for example) before “system.h” is included, rather than #include directly. The attached patch fixes the issue. Best, FX gm2.diff Description: Binary data
Re: [PATCH] fixincludes: skip stdio_stdarg_h on darwin
Hi Iain, Sorry about that, thanks for reverting. It appears to be a SDK version issue, so my analysis of the old SDK versions was incorrect. Could you try (when you get some time) the attached patch on one of the versions that was broken by my earlier patch? (darwin19 or darwin21). FX test.diff Description: Binary data
[PATCH] fixincludes: skip stdio_stdarg_h on darwin
I found another useless fixincludes on darwin, but this one was a bit harder to diagnose. GCC trunk applies a fix to on modern Darwin: it is stdio_stdarg_h. That fix is actually part of a pair, along with stdio_va_list, and they appear to work around issues with some old Unix (or BSD?) headers and the definition of va_list. It is not entirely clear to me what they fix, but they have been here forever. They use various bypass mechanisms, but those are fragile. I have no idea if the fix is actually needed on any still-supported system, and maybe some global reviewer might want to remove it. But for now, I only want to bypass the fix on Darwin: it is useless there, and applying it makes our builds more fragile (and sensitive to the SDK version). Solaris has already opted out years ago, and now we do the same. To show the madness of this fix, the macOS headers actually contain a comment that is supposed to trigger the bypass: /* DO NOT REMOVE THIS COMMENT: fixincludes needs to see: * __gnuc_va_list and include */ This kludge was added to the Apple headers in Libc-391 released around 2004. But it recently became ineffective, due to the majority of the content of being moved into <_stdio.h> (which is not covered by fixincludes). Anyway, the only sane thing to do is to disarm this fix on darwin, as the attached patch does. Tested on aarch64-apple-darwin24, OK to push? FX PS: With that patch, only two fixincludes remain active for latest darwin: - handling of __FLT_EVAL_METHOD__ == 16 in math.h (I have reported this as a bug) - handling of Apple’s “deprecated” functions: gets, sprintf, tmpnam, vsprintf, tempnam 0001-fixincludes-skip-stdio_stdarg_h-on-darwin.patch Description: Binary data
Re: [PATCH] fixincludes: add bypass to darwin_objc_runtime_1
Thanks, pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8326956159053b215b5cfe6cd41bfceff413491e FX
[PATCH] fixincludes: add bypass to darwin_objc_runtime_1
The header that this fix applies to has been fixed in macOS 15 beta SDK. Therefore, we can include a bypass. Tested on aarch64-apple-darwin24. OK to push? FX 0001-fixincludes-add-bypass-to-darwin_objc_runtime_1.patch Description: Binary data
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
> This part of the patch is quite old, but from the remaining log it looks I > got an error here: > Now on a second thought, this did not require a fix perhaps. We can drop it. I have addressed this: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656484.html The test should now be run on all targets, regardless of the issignaling() macro availability. > By the way, do we have some point of comparison from other ppc32 platforms, > Linux or BSD (for the recent gcc master)? You can have a look at testresults here: https://gcc.gnu.org/pipermail/gcc-testresults/ FX
[PATCH, pushed] Fortran: switch test to use issignaling() built-in
Pushed after testing on x86_64-unknown-linux-gnu. The macro may not be present in all libc's, but the built-in is always available. See https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656409.html for context. gcc/testsuite/ChangeLog: * gfortran.dg/ieee/signaling_2.f90: Adjust test. * gfortran.dg/ieee/signaling_2_c.c: Adjust test. 0001-Fortran-switch-test-to-use-issignaling-built-in.patch Description: Binary data
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Hi,
The core of the powerpc-FPU manipulation is okay for me. Some comments below.
> --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> @@ -1,3 +1,11 @@
> +#ifdef __POWERPC__ // No support for issignaling in math.h on Darwin PPC
Two things:
1. I don’t understand why that needs to be added. The companion test in
signaling_2.f90 has:
! { dg-require-effective-target issignaling } */
! The companion C source needs access to the issignaling macro.
Therefore, if the issignaling macro is not available, the test should not even
be run.
2. Maybe this is actually moot. Is the __builtin_issignaling() macro available
on all targets? The test was written before it was added to the middle-end. If
the answer to the previous question is yes, we should simply use it in instead
of the macro.
> +/* There is no consistency re what is to be included in all_invalid.
> + Apple libm has 0x01f80300, Openlibm/FreeBSD/NetBSD has 0x21f80700
> + and OpenBSD has 0x01f80700. In particular, FE_INVALID_SOFT and
> + FE_INVALID are contested. */
> +#define FE_ALL_INVALID 0x01F80700
> +#define FE_NO_INVALID 0xFE07F8FF
> +
> +/* Apple libm has 0xFFF80300 and 0x0007FCFF here. */
> +#define FE_ALL_FLAGS0xFFF80700
> +#define FE_NO_FLAGS 0x0007F8FF
Since it’s a darwin-only file, why not follow Apple libm conventions?
> There is one test which changes from PASS to FAIL (round_4), however I think
> this is not a real regression, and the test in its present form is expected
> to fail.
> See comments in the test code in the source and my post:
> https://gcc.gnu.org/pipermail/fortran/2024-July/060612.html
I agree that round_4.f90 should be added to the dg-skip-if.
But I’d like to understand better what are the other new failures, and why
there arise?
FX
Re: [PATCH] jit: Ensure ssize_t is defined.
> But isn't the bigger issue that sys/types.h isn't guaranteed to contain > a declaration of ssize_t? And that when sys/types.h isn't available > we don't get ssize_t from it either? Some targets seem to get it indirectly from stdio.h As far as I know, darwin is the only platform broken currently, and the patch is definitely an improvement there. > That said, maybe we're fine with this but then I walk back and say > just unconditionally include sys/types.h ... It is included unconditionally in other headers, yes. > Should be Davids say as he added this API. Agreed, but a version of the patch was original proposed in January by Iain Sandoe, and I have proposed and pinged another version since May 2nd, and got no response from him. It is breaking build on a FX
Re: [PATCH] fixincludes: adjust stdio fix for macOS 15 headers
> OK. thanks for the fix > I guess we have also to backport if we want earlier branches to bootstrap > there too? Thanks. I’ll backport after some time. FX
Re: [PATCH] jit: Ensure ssize_t is defined.
Among the review comments from the last round, Jakub suggested: > Perhaps libgccjit.h could use > #ifdef __has_include > #if __has_include () > #include > #endif > #endif > instead of just #include . I’m not sure it’s necessary since other headers treat as always available, but I suppose it can’t hurt. So here is a revised patch as suggested. Bootstrapped on x86_64-apple-darwin23. OK to push? FX 0001-jit-Ensure-ssize_t-is-defined.patch Description: Binary data
[PATCH] fixincludes: adjust stdio fix for macOS 15 headers
macOS 15 headers move the bulk of the content of to an included header <_stdio.h> so we apply the “apple_local_stdio_fn_deprecation” fixinclude to this file also. Restores bootstrap on darwin24. OK to push? FX fixincludes/ChangeLog: * fixincl.x: Regenerate. * inclhack.def (apple_local_stdio_fn_deprecation): Also apply to _stdio.h. 0001-fixincludes-adjust-stdio-fix-for-macOS-15-headers.patch Description: Binary data
Re: [PATCH] jit: Ensure ssize_t is defined.
> While stdio.h can be relied on to exist I do not think you can assume > the same for sys/types.h without "configury", but libgccjit.h is an > installed API. sys/types.h is already included unconditionally in gcc/system.h and gcc/tsystem.h. The later says: /* All systems have this header. */ #include FX
Re: [PATCH] jit: Ensure ssize_t is defined.
Hi I can’t seem to get a review of this one-line patch. Could a global reviewer help? Thanks, FX ping**3 > Le 11 mai 2024 à 17:16, FX Coudert a écrit : > > Hi, > > On some targets it seems that ssize_t is not defined by any of the headers > transitively included by . This leads to a bootstrap fail when jit > is enabled. The attached patch fixes it by include . Other > headers in GCC treat as available on all targets, so we include > it unconditionally. > > Tested on x86_64-darwin and x86_64-linux. OK to push? > > FX > 0001-jit-Ensure-ssize_t-is-defined.patch Description: Binary data
Re: What is the purpose of these two fixincludes?
> Laugh or cry. Wow. But how does any other compiler deal with them? I’ve pushed the change as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66d6b1861ec57ba29540a5fa7854df3978ba5409 Please let me know if you see any issue in the next tests. FX
Re: [PATCH] fixincludes: bypass the math_exception fix on __cplusplus
> However, please note that the comment states > * This should be bypassed on __cplusplus, but some supposedly C++ > * aware headers, such as Solaris 8 and 9, don't wrap their struct > It's "such as Solaris 8 and 9", so there may well be others. I know, but that was 24 years ago, and I could find zero documentation anywhere (mailing-list or bugzilla) of what those other targets could be. I don’t think it’s unreasonable, for the benefit of all the other working targets, to reverse now. It is early in stage 1, and the fix be restored if needed on specific targets. Best, FX
Re: [PATCH] fixincludes: bypass the math_exception fix on __cplusplus
> :-D Looks good to me. EXCEPT I think the test sample file would need a > change, too. I didn't see that. Running “make check” produces the additional diff, which I’ll add to the patch before I push. Does it look okay? FX diff --git a/fixincludes/tests/base/math.h b/fixincludes/tests/base/math.h index 7b92f29a409..3c378c5df95 100644 --- a/fixincludes/tests/base/math.h +++ b/fixincludes/tests/base/math.h @@ -7,12 +7,6 @@ This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ -#ifndef FIXINC_WRAP_MATH_H_MATH_EXCEPTION -#define FIXINC_WRAP_MATH_H_MATH_EXCEPTION 1 - -#ifdef __cplusplus -#define exception __math_exception -#endif #if defined( BROKEN_CABS_CHECK ) @@ -146,8 +140,3 @@ int foo; #endif /* _C99 */ #endif /* VXWORKS_MATH_H_FP_C99_CHECK */ -#ifdef __cplusplus -#undef exception -#endif - -#endif /* FIXINC_WRAP_MATH_H_MATH_EXCEPTION */
[PATCH] fixincludes: bypass the math_exception fix on __cplusplus
The fixincludes fix “math_exception” is being applied overly broadly, including many targets which don’t need it, like darwin (and probably all non-glibc targets). I’m not sure if it is still needed on any target, but because I can’t be absolutely positive about that, I don’t want to remove it. But it dates from before 1998. In subsequent times (2000) it was bypassed on glibc headers, as well as Solaris 10. It was still needed on Solaris 8 and 9, which are (AFAICT) unsupported nowadays. The fix was originally bypassed on __cplusplus, which is the correct thing to do, but that bypass was neutralized to cater to a bug on Solaris 8 and 9 headers. Now that those are gone… let’s revert to the previous bypass. Bootstrapped and regtested on x86_64-apple-darwin23, where it no longer “fixes” the header unnecessarily. OK to push? FX 0001-fixincludes-bypass-the-math_exception-fix-on-__cplus.patch Description: Binary data
[PATCH] fixincludes: bypass some fixes for recent darwin headers
Hi, macOS SDKs sometimes contain non-standard constructs, and require fixes through fixincludes. However, they are typically fixed in later SDK versions, although the process can be slow. Fixes have accumulated, which may be needed only for some older versions of the SDKs. They should be bypassed on modern macOS, and this patch does that for 4 cases. This makes the compiler less fragile when switching between SDKs. Before the patch, 8 headers are fixincluded on x86_64-apple-darwin23: AvailabilityInternal.h math.h os/base.h stdint.h dispatch/object.h objc/runtime.h os/trace.h stdio.h After the patch, only 4: AvailabilityInternal.h math.h objc/runtime.h stdio.h Bootstrapped and regtested on x86_64-apple-darwin23. OK to push? FX 0001-fixincludes-bypass-some-fixes-for-recent-darwin-head.patch Description: Binary data
Results for 15.0.0 20240604 (experimental) [master 4f96425b9b7] (GCC) testsuite on x86_64-apple-darwin23
LAST_UPDATED: Tue Jun 4 12:39:13 UTC 2024 (revision 4f96425b9b7) Native configuration is x86_64-apple-darwin23 === g++ tests === Running target unix FAIL: g++.dg/cpp2a/consteval-prop6.C -std=c++20 at line 58 (test for warnings, line 57) FAIL: g++.dg/ipa/pr67056.C scan-ipa-dump cp "Speculative outer type:struct CompositeClass" 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 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) FAIL: g++.dg/tree-ssa/initlist-opt5.C -std=c++14 scan-tree-dump-times gimple ">::basic_string" 2 FAIL: g++.dg/lto/pr108772 cp_lto_pr108772_0.o-cp_lto_pr108772_0.o link, -flto -fPIC -shared -O1 -fimplicit-constexpr -g1 FAIL: g++.dg/lto/pr85405 cp_lto_pr85405_0.o-cp_lto_pr85405_1.o link, -fPIC -shared -flto FAIL: g++.dg/lto/pr85405b cp_lto_pr85405b_0.o-cp_lto_pr85405b_1.o link, -fPIC -shared -flto FAIL: g++.dg/lto/pr85655 cp_lto_pr85655_0.o-cp_lto_pr85655_0.o link, -O2 -fPIC -shared -flto FAIL: g++.dg/lto/pr86523-3 cp_lto_pr86523-3_0.o-cp_lto_pr86523-3_0.o link, -fPIC -flto -g -shared FAIL: g++.dg/lto/pr86585 cp_lto_pr86585_0.o-cp_lto_pr86585_1.o link, -flto -g -nostdlib -shared -fPIC FAIL: g++.dg/lto/pr87295 cp_lto_pr87295_0.o assemble, -flto -ffat-lto-objects -fdebug-types-section -g -std=gnu++17 FAIL: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o link, -O -fPIC -flto FAIL: g++.dg/lto/pr88046 cp_lto_pr88046_0.o-cp_lto_pr88046_0.o link, -O2 -fPIC -flto FAIL: g++.dg/lto/pr88758 cp_lto_pr88758_0.o-cp_lto_pr88758_1.o link, -O3 -fPIC -flto -shared FAIL: g++.dg/lto/pr89330 cp_lto_pr89330_0.o-cp_lto_pr89330_1.o link, -O3 -g -flto -shared -fPIC -Wno-odr FAIL: g++.dg/lto/pr91574 cp_lto_pr91574_0.o-cp_lto_pr91574_0.o link, -fPIC -flto -O2 FAIL: g++.dg/lto/pr92609 (test for LTO warnings, pr92609_0.C line 75) FAIL: g++.dg/lto/pr92609 cp_lto_pr92609_0.o-cp_lto_pr92609_1.o link, -fPIC -flto FAIL: g++.dg/lto/pr93166 cp_lto_pr93166_0.o-cp_lto_pr93166_0.o link, -fPIC -O2 -flto -fvisibility=hidden FAIL: g++.dg/modules/pr99425-2_b.X -std=c++2a (test for excess errors) FAIL: g++.dg/modules/pr99425-2_b.X -std=c++2b (test for excess errors) 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 FAIL: g++.dg/torture/tail-padding1.C -Os (internal compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:3036) FAIL: g++.dg/torture/tail-padding1.C -Os (test for excess errors) UNRESOLVED: g++.dg/torture/tail-padding1.C -Os compilation failed to produce executable FAIL: g++.target/i386/pr105980.C -std=gnu++14 (internal compiler error: in insn_default_length, at config/i386/i386.md:24280) FAIL: g++.target/i386/pr105980.C -std=gnu++14 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (internal compiler error: in insn_default_length, at config/i386/i386.md:24280) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (internal compiler error: in insn_default_length, at config/i386/i386.md:24280) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (internal compiler error: in insn_default_length, at config/i386/i386.md:24280) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (test for excess errors) FAIL: g++.target/i386/pr107563-a.C scan-assembler-times por 1 FAIL: g++.target/i386/pr107563-b.C scan-assembler-times por 1 === g++ Summary === # of expected passes255309 # of unexpected failures50 # of expected failures 2770 # of unresolved testcases 1 # of unsupported tests 11518 /Users/fx/ibin-20240604/gcc/xg++ version 15.0.0 20240604 (experimental) [master 4f96425b9b7] (GCC) === gcc tests === Running target unix FAIL: gcc.dg/debug/dwarf2/dwarf2-macro.c scan-assembler Start new file FAIL: gcc.dg/debug/dwarf2/dwarf2-macro2.c scan-assembler At line number 0 FAIL: gcc.dg/pr86058.c actual at line 15 (test for warnings, line 14) FAIL: gcc.dg/pr97172-2.c
Re: What is the purpose of these two fixincludes?
Hi, > I usually just install with install-no-fixedincludes, but really this > should probably be a configure option and default to on. It would be great if we could measure what fixincludes are still needed, on which targets. Could we possibly modify contrib/test_summary to list the fixincluded headers? How would people feel about that? Out of 273 fixes, ~170 are explicitly target-specific. When we look at machines involved: 34 *-*-aix* 22 *-*-darwin* 15 *-*-solaris2* 12 *-*-vxworks* 10 *-*-*vms* 5 *-hp-hpux11* 3 i[34567]86-*-linux* 3 *-hp-hpux11.[0-3]* 3 *-*-solaris* 3 *-*-netbsd* The question is: out of the remaining ~100, how many trigger on common targets, when they are actually useless. Having the information in the test summary would be great, I think. Best, FX
What is the purpose of these two fixincludes?
Hi, I am trying to reduce the number of unneeded fixincludes that are used on darwin (because fixincluded headers make it impossible to change SDK once the compiler is built, which is common practice in the macOS world, and quite useful). There are currently two generic (not darwin-specific) fixincludes that are triggered: - math_exception. Right not it is very broad, and only skipped on glibc and Solaris. I think the comment "This should be bypassed on __cplusplus, but that does not work on solaris 8 and 9” indicates that this fix is really outdated, probably not necessary. Most if not all headers nowadays are C++-compatible, no? I would like to suggest replacing this with a proper bypass on __cplusplus, with the attached patch. - stdio_stdarg_h and stdio_va_list. These, I simply don’t understand what is the intent. It appears to me that they are not necessary on darwin, and I could potentially add it to “skip”. But… is it really necessary anywhere? It is from before 1998. I would welcome guidance on how to handle these, or advice on what the second is supposed to achieve. Thanks, FX math_exception.diff Description: Binary data
Re: [PATCH] jit: Ensure ssize_t is defined.
ping**2 for this one-liner > Le 11 mai 2024 à 17:16, FX Coudert a écrit : > > Hi, > > On some targets it seems that ssize_t is not defined by any of the headers > transitively included by . This leads to a bootstrap fail when jit > is enabled. The attached patch fixes it by include . Other > headers in GCC treat as available on all targets, so we include > it unconditionally. > > Tested on x86_64-darwin and x86_64-linux. OK to push? > > FX > > <0001-jit-Ensure-ssize_t-is-defined.patch>
Re: [wwwdocs][patch] gcc-15/changes.html: Fortran - mention F2023 logical-kind additions
Seems good, thanks Tobias! FX
Re: [PATCH] jit: Ensure ssize_t is defined.
ping > Le 11 mai 2024 à 17:16, FX Coudert a écrit : > > Hi, > > On some targets it seems that ssize_t is not defined by any of the headers > transitively included by . This leads to a bootstrap fail when jit > is enabled. The attached patch fixes it by include . Other > headers in GCC treat as available on all targets, so we include > it unconditionally. > > Tested on x86_64-darwin and x86_64-linux. OK to push? > > FX > > <0001-jit-Ensure-ssize_t-is-defined.patch>
Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single
Hi Tobias, > OK for mainline? Seems reasonable, OK to push in 48 hours unless someone has suggestions related to wording. FX
Re: [Patch] Fortran: Fix SHAPE for zero-size arrays
Hi Tobias, > That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, > caused when switching from a libgomp call to inline code and missing the > corner case of zero-size arrays … OK to push, thanks. FX
Results for 15.0.0 20240516 (experimental) [remotes/origin/trunk e656656e711] (GCC) testsuite on x86_64-apple-darwin23
r105980.C -std=gnu++14 (internal compiler error: in
insn_default_length, at config/i386/i386.md:23893)
FAIL: g++.target/i386/pr105980.C -std=gnu++14 (test for excess errors)
FAIL: g++.target/i386/pr105980.C -std=gnu++17 (internal compiler error: in
insn_default_length, at config/i386/i386.md:23893)
FAIL: g++.target/i386/pr105980.C -std=gnu++17 (test for excess errors)
FAIL: g++.target/i386/pr105980.C -std=gnu++20 (internal compiler error: in
insn_default_length, at config/i386/i386.md:23893)
FAIL: g++.target/i386/pr105980.C -std=gnu++20 (test for excess errors)
FAIL: g++.target/i386/pr105980.C -std=gnu++98 (internal compiler error: in
insn_default_length, at config/i386/i386.md:23893)
FAIL: g++.target/i386/pr105980.C -std=gnu++98 (test for excess errors)
FAIL: g++.target/i386/pr107563-a.C scan-assembler-times por 1
FAIL: g++.target/i386/pr107563-b.C scan-assembler-times por 1
=== g++ Summary ===
# of expected passes255073
# of unexpected failures62
# of expected failures 2775
# of unresolved testcases 1
# of unsupported tests 11514
/Users/fx/ibin-20240516/gcc/xg++ version 15.0.0 20240516 (experimental)
[remotes/origin/trunk e656656e711] (GCC)
=== gcc tests ===
Running target unix
FAIL: gcc.dg/debug/dwarf2/dwarf2-macro.c scan-assembler Start new file
FAIL: gcc.dg/debug/dwarf2/dwarf2-macro2.c scan-assembler At line number 0
FAIL: gcc.dg/pr97172-2.c (test for excess errors)
FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ t]+0x14d+[ t]+[#;]+[
t]+Pub Info Length
FAIL: gcc.dg/pubtypes-3.c scan-assembler long+[ t]+0x14d+[ t]+[#;]+[
t]+Pub Info Length
FAIL: gcc.dg/pubtypes-4.c scan-assembler long+[ t]+0x184+[ t]+[#;]+[
t]+Pub Info Length
FAIL: gcc.dg/scantest-lto.c scan-assembler-not ascii
FAIL: gcc.dg/scantest-lto.c scan-assembler-times ascii 0
FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "_not_eliminated_" 0
FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "strlen" 0
FAIL: gcc.dg/strlenopt-80.c scan-tree-dump-times optimized "failure_on_line
(" 0
FAIL: gcc.dg/strlenopt-82.c scan-tree-dump-times optimized
"call_in_true_branch_not_eliminated_" 0
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs:
0" 1
FAIL: gcc.dg/lto/pr61526 c_lto_pr61526_0.o-c_lto_pr61526_1.o link, -fPIC -flto
-flto-partition=1to1
FAIL: gcc.dg/lto/pr99849 c_lto_pr99849_0.o-c_lto_pr99849_0.o link, -flto
-flto-partition=1to1 -O2 -Wno-incompatible-pointer-types
-Wno-discarded-qualifiers -fPIC
XPASS: gcc.dg/tree-ssa/pr91091-2.c scan-tree-dump-times fre1 "x = " 1
XPASS: gcc.dg/tree-ssa/ssa-fre-100.c scan-tree-dump-not fre1 "baz"
XPASS: gcc.dg/tree-ssa/ssa-fre-77.c scan-tree-dump fre1 "return 1;"
FAIL: gcc.dg/tree-ssa/ssa-lim-15.c scan-tree-dump lim2 "Executing store motion"
FAIL: outputs-25 exe savetmp named2-4: outputs.args.3
FAIL: outputs-25 exe savetmp named2-4: std out
FAIL: gcc.target/i386/amxtile-4.c scan-assembler-times pxor[^\\n]*%xmm 1
FAIL: gcc.target/i386/apx-ndd-no-seg-global-1.c scan-assembler-not mov
FAIL: gcc.target/i386/apx-push2pop2-2.c scan-assembler-not pop2(|p)[t ]*%r
FAIL: gcc.target/i386/apx-push2pop2-2.c scan-assembler-not push2(|p)[t ]*%r
FAIL: gcc.target/i386/avx512bw-pr103750-2.c scan-assembler-not kmov
FAIL: gcc.target/i386/avx512bw-pr88465.c scan-assembler-times kxnor[dq][ \\t] 2
FAIL: gcc.target/i386/avx512dq-pr88465.c scan-assembler-times kxnorb[ \\t] 1
FAIL: gcc.target/i386/avx512f-pr103750-2.c scan-assembler-not kmov
FAIL: gcc.target/i386/avx512f-pr88465.c scan-assembler-times kxnorw[ \\t] 1
FAIL: gcc.target/i386/avx512fp16-pr103750-2.c scan-assembler-not kmov
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kmovb[\\t ] 4
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times korb[\\t ] 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kxorb[\\t ] 1
FAIL: gcc.target/i386/harden-sls-4.c scan-assembler jmp[ \\t]+*_?fptr
FAIL: gcc.target/i386/pr100704-3.c scan-assembler push[lq]\\tf+
FAIL: gcc.target/i386/pr101908-1.c scan-assembler-not (?n)movhpd[ t]
FAIL: gcc.target/i386/pr101908-3.c scan-assembler-not (?n)movhpd[ t]+
FAIL: gcc.target/i386/pr107548-1.c scan-assembler-not addl
FAIL: gcc.target/i386/pr107548-1.c scan-assembler-times \\tv?movd\\t 3
FAIL: gcc.target/i386/pr107548-1.c scan-assembler-times v?paddd 6
FAIL: gcc.target/i386/pr107548-2.c scan-assembler v?psrldq
FAIL: gcc.target/i386/pr107548-2.c scan-assembler-not \\taddq\\t
FAIL: gcc.target/i386/pr107548-2.c scan-assembler-times v?paddq 2
FAIL: gcc.target/i386/pr11877-2.c scan-assembler-not \$0,
FAIL: gcc.target/i386/pr11877.c scan-assembler-not \$0,
FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 5
FAIL: gcc.target/i386/pr78035.c scan-assembler-times cmp 2
FAIL: gcc.target/i386/pr89618-2
[PATCH] jit: Ensure ssize_t is defined.
Hi, On some targets it seems that ssize_t is not defined by any of the headers transitively included by . This leads to a bootstrap fail when jit is enabled. The attached patch fixes it by include . Other headers in GCC treat as available on all targets, so we include it unconditionally. Tested on x86_64-darwin and x86_64-linux. OK to push? FX 0001-jit-Ensure-ssize_t-is-defined.patch Description: Binary data
Re: [PATCH, libgfortran] aix: Fix building fat library for AIX
> libgfortran/ChangeLog: > * config/t-aix (all-local, libcaf_single): Explicitly reference > caf/.libs/single.o OK, and sorry for the breakage. FX
Re: [PATCH] libgfortran: Fix libgfortran.so versioning on Solaris with subdirs
Hi Rainer, > This patch fixes this by allowing for the new structure. > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. > > Ok for trunk? OK to push, given it’s localised inside LIBGFOR_USE_SYMVER_SUN. I find it weird though that .libs is harcoded there. If we look at all the lib*/Makefile.am in gcc, the only thing that ever needs to specify .libs is for Solaris versioning. It feels like it should be more generic, as you say (but that’s for longer term). FX
Re: [PATCH] libgfortran: Fix up the autoreconf warnings.
> libgfortran/ChangeLog: > * Makefile.am: Use sub-dirs, amend recipies accordingly. > * Makefile.in: Regenerate. Thanks Iain, I’ve tested it both with and without maintainer mode, and regenerated files with no issue. I can also confirm that the many autoreconf warnings that plagued libgfortran are now gone. Push as affd24bfc62203db9f9937c0d6cf8f1f75b80d72 FX
Re: [PATCH] jit: Ensure ssize_t is defined.
I’d like to ping the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644134.html
The original proposal by Iain was:
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 235cab053e0..db4f27a48bf 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -21,6 +21,9 @@ along with GCC; see the file COPYING3. If not see
#define LIBGCCJIT_H
#include
+#if __has_include()
+# include /* For ssize_t. */
+#endif
#ifdef __cplusplus
extern "C" {
but it seems we can’t use __has_include. However, other code in GCC treats
as available on all targets. See unconditional inclusion in
gcc/system.h and gcc/tsystem.h. The latter even says:
/* All systems have this header. */
#include
So: would an unconditional inclusion be suitable? I’ve tested on linux and
darwin with no issues:
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 74e847b2dec..cbe0f70abee 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3. If not see
#define LIBGCCJIT_H
#include
+#include
#ifdef __cplusplus
extern "C” {
Thanks,
FX
Re: Updated Sourceware infrastructure plans
> I regenerate auto* files from time to time for libgfortran. Regenerating > them has always been very fragile (using --enable-maintainer-mode), > and difficult to get right. I have never found them difficult to regenerate, but if you have only a non maintainer build, it is a pain to have to make a new maintainer build for a minor change. Moreover, our m4 code is particularly painful to use and unreadable. I have been wondering for some time: should we switch to simpler Python scripts? It would also mean that we would have fewer files in the generated/ folder: right now, every time we add new combinations of types, we have a combinatorial explosion of files. $ ls generated/sum_* generated/sum_c10.c generated/sum_c17.c generated/sum_c8.c generated/sum_i16.c generated/sum_i4.c generated/sum_r10.c generated/sum_r17.c generated/sum_r8.c generated/sum_c16.c generated/sum_c4.c generated/sum_i1.c generated/sum_i2.c generated/sum_i8.c generated/sum_r16.c generated/sum_r4.c We could imagine having a single file for all sum intrinsics. How do Fortran maintainers feel about that? FX
Re: [PATCH] Fortran: ALLOCATE of fixed-length CHARACTER with SOURCE/MOLD [PR113793]
Hi Harald, > Regtested on x86_64-pc-linux-gnu. OK for mainline? Looks good to me. FX
Re: [PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf
> Gentle ping. If this looks good, can someone commit to main (I don't have > commit privileges). This is also something that could be considered for > stable, since it's been around for many years. Thanks for the patch. Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3bd3ca05b519b99b5ea570c10fd80737cd4c6c49 FX
Re: [PATCH] Fortran: fix argument checking of intrinsics C_SIZEOF, C_F_POINTER [PR106500]
Hi Harald,
Thanks for the patch.
> + if (attr.function)
> +{
> + gfc_error ("FPTR at %L to C_F_POINTER is a function returning a
> pointer",
> + >where);
> + return false;
> +}
> +
>if (fptr->rank > 0 && !is_c_interoperable (fptr, , false, true))
> return gfc_notify_std (GFC_STD_F2018, "Noninteroperable array FPTR "
> "at %L to C_F_POINTER: %s", >where, msg);
In both of these gfc_error(), could we change our error message to say "FPTR
argument” instead of “FPTR”? “FPTR to C_F_POINTER” does not really make sense
to me.
This would be more in line with what the generally do:
> Error: 'x' argument of 'sqrt' intrinsic at (1) must be REAL or COMPLEX
So maybe “FPTR argument to C_F_POINTER at %L” ? That’s much more readable to me.
Otherwise, OK.
FX
Results for 14.0.1 20240319 (experimental) [remotes/origin/HEAD 9eeca775367] (GCC) testsuite on x86_64-apple-darwin23
O -fPIC -flto FAIL: g++.dg/lto/pr88046 cp_lto_pr88046_0.o-cp_lto_pr88046_0.o link, -O2 -fPIC -flto FAIL: g++.dg/lto/pr88758 cp_lto_pr88758_0.o-cp_lto_pr88758_1.o link, -O3 -fPIC -flto -shared FAIL: g++.dg/lto/pr89330 cp_lto_pr89330_0.o-cp_lto_pr89330_1.o link, -O3 -g -flto -shared -fPIC -Wno-odr FAIL: g++.dg/lto/pr91574 cp_lto_pr91574_0.o-cp_lto_pr91574_0.o link, -fPIC -flto -O2 FAIL: g++.dg/lto/pr92609 (test for LTO warnings, pr92609_0.C line 75) FAIL: g++.dg/lto/pr92609 cp_lto_pr92609_0.o-cp_lto_pr92609_1.o link, -fPIC -flto FAIL: g++.dg/lto/pr93166 cp_lto_pr93166_0.o-cp_lto_pr93166_0.o link, -fPIC -O2 -flto -fvisibility=hidden FAIL: g++.dg/modules/pr99425-2_b.X -std=c++2b (test for excess errors) 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 FAIL: g++.dg/torture/tail-padding1.C -Os (internal compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:3027) FAIL: g++.dg/torture/tail-padding1.C -Os (test for excess errors) UNRESOLVED: g++.dg/torture/tail-padding1.C -Os compilation failed to produce executable FAIL: g++.target/i386/pr105980.C -std=gnu++14 (internal compiler error: in insn_default_length, at config/i386/i386.md:23888) FAIL: g++.target/i386/pr105980.C -std=gnu++14 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (internal compiler error: in insn_default_length, at config/i386/i386.md:23888) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (internal compiler error: in insn_default_length, at config/i386/i386.md:23888) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (internal compiler error: in insn_default_length, at config/i386/i386.md:23888) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (test for excess errors) === g++ Summary === # of expected passes253514 # of unexpected failures84 # of expected failures 2778 # of unresolved testcases 1 # of unsupported tests 11387 /Users/fx/ibin-20240319/gcc/xg++ version 14.0.1 20240319 (experimental) [remotes/origin/HEAD 9eeca775367] (GCC) === gcc tests === Running target unix FAIL: gcc.dg/cpp/ucnid-1-utf8.c (test for excess errors) FAIL: gcc.dg/cpp/ucnid-1.c (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gdwarf-2 -g3 -O (test for excess err
[PATCH] Fortran: add two small F2023 features
Hi, These two (independent) patches add two tiny Fortran 2023 features: new ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic. Bootstrapped and regtested on x86_64-pc-linux-gnu. Please review, and let me know if it’s okay to push once we’re back in stage 1. (I know it’s not particularly soon, but I don’t want to forget these so I’m posting them for review) FX 0001-Fortran-add-F2023-ISO_FORTRAN_ENV-named-constants.patch Description: Binary data 0002-Fortran-add-SELECTED_LOGICAL_KIND.patch Description: Binary data
Re: [PATCH] Fix libcc1plugin and libc1plugin to avoid poisoned identifiers
Given its fixes build, is obvious, and tested appropriately: patch pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5213047b1d50af63dfabb5e5649821a6cb157e33 FX
Results for 14.0.1 20240312 (experimental) [master 73dac51b325] (GCC) testsuite on x86_64-apple-darwin23
O -fPIC -flto FAIL: g++.dg/lto/pr88046 cp_lto_pr88046_0.o-cp_lto_pr88046_0.o link, -O2 -fPIC -flto FAIL: g++.dg/lto/pr88758 cp_lto_pr88758_0.o-cp_lto_pr88758_1.o link, -O3 -fPIC -flto -shared FAIL: g++.dg/lto/pr89330 cp_lto_pr89330_0.o-cp_lto_pr89330_1.o link, -O3 -g -flto -shared -fPIC -Wno-odr FAIL: g++.dg/lto/pr91574 cp_lto_pr91574_0.o-cp_lto_pr91574_0.o link, -fPIC -flto -O2 FAIL: g++.dg/lto/pr92609 (test for LTO warnings, pr92609_0.C line 75) FAIL: g++.dg/lto/pr92609 cp_lto_pr92609_0.o-cp_lto_pr92609_1.o link, -fPIC -flto FAIL: g++.dg/lto/pr93166 cp_lto_pr93166_0.o-cp_lto_pr93166_0.o link, -fPIC -O2 -flto -fvisibility=hidden FAIL: g++.dg/modules/pr99425-2_b.X -std=c++2b (test for excess errors) 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 FAIL: g++.dg/torture/tail-padding1.C -Os (internal compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:3027) FAIL: g++.dg/torture/tail-padding1.C -Os (test for excess errors) UNRESOLVED: g++.dg/torture/tail-padding1.C -Os compilation failed to produce executable FAIL: g++.old-deja/g++.law/cvt17.C -std=c++14 (test for errors, line 18) FAIL: g++.old-deja/g++.law/cvt17.C -std=c++14 (internal compiler error: Abort trap: 6) FAIL: g++.old-deja/g++.law/cvt17.C -std=c++14 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++14 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++14 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (test for excess errors) === g++ Summary === # of expected passes253360 # of unexpected failures87 # of expected failures 2778 # of unresolved testcases 1 # of unsupported tests 11382 /Users/fx/ibin-20240312/gcc/xg++ version 14.0.1 20240312 (experimental) [master 73dac51b325] (GCC) === gcc tests === Running target unix FAIL: gcc.dg/cpp/ucnid-1-utf8.c (test for excess errors) FAIL: gcc.dg/cpp/ucnid-1.c (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 -O (test
[PATCH] testsuite, darwin: improve check for -shared support
The undefined symbols are allowed for C checks, but when this is run as C++, the mangled foo() symbol is still seen as undefined, and the testsuite thinks darwin does not support -shared. Pushed after approval by Iain Sandoe in PR114233 FX 0001-testsuite-darwin-improve-check-for-shared-support.patch Description: Binary data
Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
> I think it's an obvious change ... Thanks, pushed. Dimitry, I suggest you post the second patch for review. FX
Results for 15.0.0 (clang-1500.3.9.4) testsuite on x86_64-apple-darwin23
e/tail-padding1.C -Os (internal compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:3027) FAIL: g++.dg/torture/tail-padding1.C -Os (test for excess errors) UNRESOLVED: g++.dg/torture/tail-padding1.C -Os compilation failed to produce executable FAIL: g++.target/i386/pr105980.C -std=gnu++98 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++98 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++14 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++14 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++17 (test for excess errors) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (internal compiler error: in insn_default_length, at config/i386/i386.md:23882) FAIL: g++.target/i386/pr105980.C -std=gnu++20 (test for excess errors) === g++ Summary === # of expected passes253197 # of unexpected failures73 # of expected failures 2778 # of unresolved testcases 1 # of unsupported tests 11391 /Users/fx/ibin-20240306/gcc/xg++ version 14.0.1 20240306 (experimental) [master b7d14310406] (GCC) === gcc tests === Running target unix FAIL: gcc.dg/cpp/ucnid-1-utf8.c (test for excess errors) FAIL: gcc.dg/cpp/ucnid-1.c (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20020220-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20020327-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr29609-2.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-2.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr36690-3.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr37616.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/tls-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/tls-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/tls-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/trivial.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/trivial.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/trivial.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/framework-1.c (test for excess errors) FAIL: gcc.dg/pr97172-2.c (test for excess errors) FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ t]+0x14d+[ t]+[#;]+[ t]+Pub Info Length FAIL: gcc.dg/pubtypes-3.c scan-assembler long+[ t]+0x14d+[ t]+[#;]+[ t]+Pub Info Length FAIL: gcc.dg/pubtypes-4.c scan-assembler long+[ t]+0x184+[ t]+[#;]+[ t]+Pub Info Length FAIL: gcc.dg/scantest-lto.c scan-assembler-not ascii FAIL: gcc.dg/scantest-lto.c scan-assembler-times ascii 0 FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "strlen" 0 FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times op
Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
> Hmm I recall trying it and finding a problem - was there some different fix > applied > in the end? The bug is still open, I don’t think a patch was applied, and I don’t find any email to the list stating what the problem could be. FX
Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
I would like to patch this patch from September 2023: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html This bug is now hitting macOS in the latest version of Xcode (it was originally seen on freebsd). I confirm that the patch is restoring bootstrap on x86_64-apple-darwin23 OK to push? FX > Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 > > When building gcc's C++ sources against recent libc++, the poisoning of > the ctype macros due to including safe-ctype.h before including C++ > standard headers such as , , etc, causes many compilation > errors, similar to: > > In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: > In file included from /home/dim/src/gcc/master/gcc/system.h:233: > In file included from /usr/include/c++/v1/vector:321: > In file included from > /usr/include/c++/v1/__format/formatter_bool.h:20: > In file included from > /usr/include/c++/v1/__format/formatter_integral.h:32: > In file included from /usr/include/c++/v1/locale:202: > /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute > only applies to structs, variables, functions, and namespaces > 546 | _LIBCPP_INLINE_VISIBILITY > | ^ > /usr/include/c++/v1/__config:813:37: note: expanded from macro > '_LIBCPP_INLINE_VISIBILITY' > 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI > | ^ > /usr/include/c++/v1/__config:792:26: note: expanded from macro > '_LIBCPP_HIDE_FROM_ABI' > 792 | > __attribute__((__abi_tag__(_LIBCPP_TOSTRING( > _LIBCPP_VERSIONED_IDENTIFIER > | ^ > In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: > In file included from /home/dim/src/gcc/master/gcc/system.h:233: > In file included from /usr/include/c++/v1/vector:321: > In file included from > /usr/include/c++/v1/__format/formatter_bool.h:20: > In file included from > /usr/include/c++/v1/__format/formatter_integral.h:32: > In file included from /usr/include/c++/v1/locale:202: > /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of > declaration list > 547 | char_type toupper(char_type __c) const > | ^ > /usr/include/c++/v1/__locale:553:48: error: too many arguments > provided to function-like macro invocation > 553 | const char_type* toupper(char_type* __low, const > char_type* __high) const > | ^ > /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note: > macro 'toupper' defined here > 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype > | ^ > > This is because libc++ uses different transitive includes than > libstdc++, and some of those transitive includes pull in various ctype > declarations (typically via ). > > There was already a special case for including before > safe-ctype.h, so move the rest of the C++ standard header includes to > the same location, to fix the problem. >
Re: [patch, libgfortran] Bug 105473 - semicolon allowed when list-directed read integer with decimal='point'
> OK for trunk and later backport to 13? OK. Thanks for the patch! FX
Re: [patch, libgfortran] PR107068 Run-time error when reading logical arrays with a namelist
> OK for trunk? > I think simple enough to backport to 13 as well. OK, but probably best to wait a few weeks before backporting. FX
Re: [patch, libgfortran] PR99210 X editing for reading file with encoding='utf-8'
> Regression tested on x86_64 and new test case. > OK for trunk? OK, and thanks! FX
[PATCH] i386, testsuite: adjust asm patterns
The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is partly because symbols are prefixed with underscore, and also because the order of operands in the addition is reversed (but I think it’s valid still). The code generated is this: _func: LFB0: pushq %rbp LCFI0: movq%rsp, %rbp LCFI1: # 8 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 1 @ _func # 0 "" 2 # 9 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 1 @ 4+_var # 0 "" 2 nop popq%rbp LCFI2: ret I’m adjusting the pattern accordingly. OK to push? FX 0001-i386-testsuite-adjust-asm-patterns.patch Description: Binary data
[pushed] Darwin, testsuite: skip some -mcmodel=large tests
Three new tests using -mcmodel=large, which darwin does not support. Skipping them. Pushed as obvious. FX 0001-Darwin-testsuite-skip-some-mcmodel-large-tests.patch Description: Binary data
[PATCH] Darwin, testsuite: -multiply_defined is obsolete
With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is obsolete The patches ignores the warning when present. OK to push? FX 0001-Darwin-testsuite-multiply_defined-is-obsolete.patch Description: Binary data
[PATCH] Darwin, testsuite: -bind_at_load is deprecated
With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning: ld: warning: -bind_at_load is deprecated on macOS The patches ignores the warning when present. OK to push? FX 0001-Darwin-testsuite-bind_at_load-is-deprecated.patch Description: Binary data
Analyzer test failures
Hi, I’m seeing the following analyzer test failures on darwin. They were introduced in December, when the tests were moved around: FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c FAIL: c-c++-common/analyzer/fd-symbolic-socket.c They all have an unexpected analyzer warning, like this: /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: In function 'int main()': /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17: warning: leak of file descriptor 'socket(2, 1, 0)' [CWE-775] [-Wanalyzer-fd-leak] /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17: note: (1) socket created here /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17: note: (2) when 'socket' succeeds /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17: note: (3) 'socket(2, 1, 0)' leaks here FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c -std=c++98 (test for excess errors) I see they’ve been xfail'ed off on AIX and HPUX in previous patches, so I’m wondering: are the tests glibc-specific? If so, should we mark them as suck? Or are they real failures of the analyzer? FX
Re: [PATCH] testsuite, gfortan: Update link flags [PR112862].
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? Looks good to me. Please leave 48h before pushing for other Fortran maintainers to comment if they see something I missed (in particular the coarrays part). FX
Re: [Fortran] half-cycle trig functions and atan[d] fixes
Hi, > Hopefully, FX sees this as my emails to gmail bounce. I am seeing this email. > Now, if > the OS adds cospi() to libm and it's in libm's symbol map, then the > cospi() used by gfortran depends on the search order of the loaded > libraries. We only include the fallback math functions in libgfortran when they are not available on the system. configure detects what is present in the libc being targeted, and conditionally compiles the necessary fallback functions (and only them). FX
Re: [Fortran] half-cycle trig functions and atan[d] fixes
Hi Steve, Thanks for the patch. I’ll take time to do a proper review, but after a first read I had the following questions: - "an OS's libm may/will contain cospi(), etc.”: do those functions conform to any standard? Are there plans to implement them outside FreeBSD at this point? - On systems where libquadmath is used for _Float128, does libquadmath contain the implementation of the q() variants for those functions? - If I get this right, to take one example, the Fortran front-end will emit a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper calling acospif(), which is called either from libm or from libgfortran. This is different from other math library functions, like ACOS() where the acosf() call is generated directly from the front-end (and then the implementation comes either from libm or from libgfortran). Why not follow our usual way of doing things? - On most targets, cospi() and friends are not available. Therefore, we end up doing the fallback (with limited precision as you noted) but with a lot of indirection. We could generate that code directly in the front-end, couldn’t we? Best, FX
Re: [PATCH] Fortran: bogus warnings with REPEAT intrinsic and -Wconversion-extra [PR96724]
Hi Harald, OK to push, thanks for picking it up! FX
[PATCH] libgfortran: avoid duplicate libraries in spec
When gfortran invokes the linker, it reads the linking spec from libgfortran. This ends up doing things like: -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This wasn’t a problem, until the new macOS linker, which gives a warning for this: the warning is innocuous, but having a warning for every time you call gfortran for linking clutters the terminal, and makes all the testsuite fail. And linking twice is superfluous, so removing it will not be a problem. I am the author of the original commit to the spec, in 2010, but honestly I have no memory: I think I vaguely remember saying “better safe than sorry”, but 13 years later it could just be a false memory ;) Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as *-*-solaris2.11 by Rainer. OK to commit? (seems admissible in stage 3 because it fixes regtesting on darwin22 and darwin23). FX libgfortran/ChangeLog: PR libfortran/110651 * libgfortran.spec.in: Remove duplicate libraries. --- libgfortran/libgfortran.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 0001-libgfortran-avoid-duplicate-libraries-in-spec.patch Description: Binary data
Re: [PATCH] i386: Fix missed APX_NDD check for shift/rotate expanders [PR 112943]
The testcase fails on darwin:
+FAIL: gcc.target/i386/pr112943.c (test for excess errors)
because it does not support _Decimal64.
/* { dg-do compile { target { ! ia32 } } } */
should be changed to:
/* { dg-do compile { target { dfp && { ! ia32 } } } } */
Thanks,
FX
Re: Backport of "fixincludes: Update darwin_flt_eval_method for macOS 14"
> Yes, OK (build fixes are on my list, but you got to it first). Backported to 13 as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=87e6cc0103369f8891c3c3a516f4d93187c2c12b Backported to 12 as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=65595b02668c99edcfd5aedac984ebcbb64a1685 FX
Backport of "fixincludes: Update darwin_flt_eval_method for macOS 14"
Hi, I’d like to backport the fixincludes for macOS 14 SDK at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=93f803d53b5ccaabded9d7b4512b54da81c1c616 to the active branches, i.e. 13, 12 and 11 (unless I am mistaken). The fix has been there for months, it’s stable and very specific. Without it, we can’t compile GCC for macOS 14. OK to backport? FX
Re: [PATCH v8] c++: implement P2564, consteval needs to propagate up [PR107687]
Hi Marek, The patch is causing three failures on x86_64-apple-darwin21: > FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler > _Z1gI1XEvT_ > FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler > _Z1gI1YEvT_ > FAIL: g++.dg/cpp2a/consteval-prop6.C -std=c++20 at line 58 (test for > warnings, line 57) How could I help debug this? FX
[PATCH] Testsuite, asan, darwin: Adjust output pattern
Since the last import from upstream libsanitizer, the output has changed and now looks more like this: READ of size 6 at 0x7ff7beb2a144 thread T0 #0 0x101cf7796 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) sanitizer_common_interceptors.inc:813 #1 0x101cf7b99 in memcmp sanitizer_common_interceptors.inc:840 #2 0x108a0c39f in __stack_chk_guard+0xf (dyld:x86_64+0x8039f) so let's adjust the pattern accordingly. Tested on x86_64-apple-darwin21. OK to push? FX 0001-Testsuite-asan-darwin-Adjust-output-pattern.patch Description: Binary data
[PATCH] Testsuite, i386: mark test as requiring dfp
Test currently fails on darwin with: error: decimal floating-point not supported for this target Pushed as obvious fix. FX 0001-Testsuite-i386-mark-test-as-requiring-dfp.patch Description: Binary data
[PATCH] Testsuite: restrict test to nonpic targets
The test is currently failing on x86_64-apple-darwin. This patch requires nonpic, as suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 by Andrew Pinski. OK to commit? FX 0001-Testsuite-restrict-test-to-nonpic-targets.patch Description: Binary data
Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64
>> Pushed as >> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b74981b5cf32ebf4bfffd25e7174b5c80243447a Somehow I pushed the wrong commit, we should skip the test and not xfail. This showed up in https://gcc.gnu.org/pipermail/gcc-testresults/2023-December/802839.html So, new commit push as obvious fixup: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=53e954a673a0d6ac80ab1f0591ea4f751e67374c FX
Re: [PATCH] strub: skip emutls after strubm errors
> Yes, GCC/nvptx ICEs gone with that, thanks! And on darwin as well, test results are back to the same state as before. Thanks! FX
Re: [PATCH] Fortran: allow NULL() for POINTER, OPTIONAL, CONTIGUOUS dummy [PR111503]
Hi Harald, > here's another fix for the CONTIGUOUS attribute: NULL() should > derive its characteristics from its MOLD argument; otherwise it is > "determined by the entity with which the reference is associated". > (F2018:16.9.144). Looking good to me, but leave 48 hours for someone else to object if they want. Best, FX
Re: Several test failures due to "Introduce strub: machine-independent stack scrubbing"
> However, I'm very surprised that you're hitting this with the initial > commit. It's as if strub support was disabled on the target, but even > if you were hitting this with e.g. offloading, only the followup commit > introduced code to disable strub for such targets as nvptx. Anyway, do > you by any chance have any offloading enabled? I may have misidentified the problem, my testing was done on: LAST_UPDATED: Wed Dec 6 16:01:43 UTC 2023 (revision 458e7c93792) https://gcc.gnu.org/pipermail/gcc-testresults/2023-December/802595.html I’m restarting a build right now, will report back. FX
Several test failures due to "Introduce strub: machine-independent stack scrubbing"
: c-c++-common/torture/strub-callable2.c -O3 -g (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-callable2.c -O3 -g (test for excess errors) +FAIL: c-c++-common/torture/strub-callable2.c -Os (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-callable2.c -Os (test for excess errors) +FAIL: c-c++-common/torture/strub-callable2.c -O2 -flto -flto-partition=none (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-callable2.c -O2 -flto -flto-partition=none (test for excess errors) +FAIL: c-c++-common/torture/strub-callable2.c -O2 -flto (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-callable2.c -O2 -flto (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -O0 (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -O0 (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -O1 (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -O1 (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -O2 (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -O2 (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -O3 -g (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -O3 -g (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -Os (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -Os (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -O2 -flto -flto-partition=none (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -O2 -flto -flto-partition=none (test for excess errors) +FAIL: c-c++-common/torture/strub-inlinable1.c -O2 -flto (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-inlinable1.c -O2 -flto (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O0 (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O0 (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O1 (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O1 (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O2 (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O2 (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O3 -g (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O3 -g (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -Os (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -Os (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O2 -flto -flto-partition=none (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O2 -flto -flto-partition=none (test for excess errors) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O2 -flto (internal compiler error: in verify_curr_properties, at passes.cc:2198) +FAIL: c-c++-common/torture/strub-ptrfn3.c -O2 -flto (test for excess errors) The output for one typical case is: $ /Users/fx/ibin-20231206/gcc/xgcc -B/Users/fx/ibin-20231206/gcc/ /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/strub-apply2.c -fdiagnostics-plain-output -Wc++-compat -fstrub=strict -S -o strub-apply2.s /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/strub-apply2.c:8:1: error: 'strub' mode 'disabled' selected for 'apply_args', when 'at-calls' was requested /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/strub-apply2.c:10:16: sorry, unimplemented: at-calls 'strub' does not support call to '__builtin_apply_args' during IPA pass: emutls /Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/strub-apply2.c:12:1: internal compiler error: in verify_curr_properties, at passes.cc:2198 Cheers, FX
Re: [PATCH, v3] Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]
Hi, > this patch extends the previous version by adding further code testing > the presence of an optional deferred-length character argument also > in the function initialization code. This allows to re-enable a > commented-out test in v2. Nice, that sounds logical. > Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. FX
Re: [11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]
> Thanks. I can't push it myself - could you do that for me? Pushed. FX
Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64
> mcmodel=large s not supported (yet) on any Darwin arch [PR90698], so the test > needs skipping or xfailing, I think (either way with a reference to the PR). Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b74981b5cf32ebf4bfffd25e7174b5c80243447a FX
Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64
That commit makes gcc.target/i386/libcall-1.c on darwin:
FAIL: gcc.target/i386/libcall-1.c scan-assembler globl\t__divti3
because the pattern is not found, the only mention of divti3 in the generated
assembly is:
LCFI0:
movabsq $_b@GOTOFF, %rdx
movabsq $___divti3@PLTOFF, %rax
leaqL2(%rip), %r15
pushq %rbx
The source code is:
---
/* Make sure that external refences for libcalls are generated even for
indirect calls. */
/* { dg-do compile { target int128 } } */
/* { dg-options "-O2 -mcmodel=large" } */
/* { dg-final { scan-assembler "globl\t__divti3" } } */
__int128 a, b; void foo () { a = a / b; }
---
Looking at, for example, gcc.target/i386/falign-functions-3.c it seems that
test avoids scanning for global references on darwin. Probably the new test
needs the same exception.
FX
Re: [PATCH] testsuite, x86: Handle a broken assembler.
Thanks Richard, Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d65eb8a6bbeae7533dd41cb307b427f3f8585d9b FX
Re: [PATCH] Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]
Hi Harald, The patch looks OK to me. Probably wait a bit for another opinion, since I’m not that active and I may have missed something. Thanks, FX
Re: [PATCH] testsuite, x86: Handle a broken assembler.
Hi,
I’d like to ping that patch from Iain Sandoe. It would clear up a number of
failures in the darwin testsuite.
Thanks,
FX
> --- 8< ---
>
> Earlier assembler support for complex fp16 on x86_64 Darin is broken. This
> adds an additional test to the existing target-supports that fails for the
> broken assemblers but works for the newer, fixed, ones.
>
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp: Test an asm line that fails on broken
> Darwin assembler versions.
>
> Signed-off-by: Iain Sandoe
> ---
> gcc/testsuite/lib/target-supports.exp | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index f0b692a2e19..61ab063afbe 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -10062,6 +10062,7 @@ proc check_effective_target_avx512fp16 { } {
> void foo (void)
> {
> asm volatile ("vmovw %edi, %xmm0");
> + asm volatile ("vfcmulcph %xmm1, %xmm2, %xmm3{%k1}");
> }
> } "-O2 -mavx512fp16" ]
> }
> --
> 2.39.2 (Apple Git-143)
Re: [PATCH v5] gcc: Introduce -fhardened
Hi Marek, The new test at gcc.target/i386/cf_check-6.c fails on darwin with: Excess errors: cc1: warning: '-fhardened' not supported for this target Other tests are only run on Linux, so I added this to gcc.target/i386/cf_check-6.c as well. Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e40a13eaca4d87ec33beb0d9d31985e0023bfe3e FX
Re: [committed] i386: Fix ICE with -fsplit-stack -mcmodel=large [PR112686]
Hi Uros,
The new test at gcc.target/i386/pr112686.c fails on darwin with:
Excess errors:
cc1: error: '-fsplit-stack' currently only supported on GNU/Linux
cc1: error: '-fsplit-stack' is not supported by this compiler configuration
It needs an /* { dg-require-effective-target split_stack } */
which I have added and pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c54ee4fc1667593081ce80030eeb70838267ad96
FX
Re: Darwin: Replace environment runpath with embedded [PR88590]
Hi, > I believe this can be applied as a partial reversion of a previously approved > patch, Yes, that makes sense. Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ce966ae66067d8d365431ef7a323f4207fcb729a FX
Re: [PATCH 1/4] libsanitizer: merge from upstream (c425db2eb558c263)
> I see that the fix was applied locally (and my bootstraps on various Darwin > versions worked OK), > but I’m not clear if you submitted a PR upstream (or just the bug report). > If the fix is to remain > local-only, it should be added to the list in LOCAL_PATCHES. Patch was submitted upstream: https://github.com/llvm/llvm-project/pull/72642 FX
Re: gfortran.dg/dg.exp debug messages pollute test output
> I suppose 'set t [...]' can be let go, too? Duh (x2). Pushed, on top of the previous patch. FX 0001-Testsuite-remove-unused-variables.patch Description: Binary data
Re: Darwin: Replace environment runpath with embedded [PR88590]
>> I have done a full rebuild, and having looked more at the structure of >> libtool.m4 I am now convinced that having that line outside of the scope of >> _LT_DARWIN_LINKER_FEATURES is simply wrong (probably a copy-pasto or >> leftover from earlier code). >> Having rebuilt everything, it only manifests itself in >> fixincludes/ChangeLog. Iain is traveling right now, but when he is back I >> would like to submit this patch if he agrees with the above. It was >> regtested on x86_64-apple-darwin21. With the correct patch attached. 0001-Build-fix-error-in-fixinclude-configure.patch Description: Binary data
Re: [PATCH 1/4] libsanitizer: merge from upstream (c425db2eb558c263)
> If they accept it say within a day, wait for it + cherry-pick to GCC, > otherwise apply to GCC as a local patch in anticipation they accept it. > If it is all that fixes Darwin support, great. With that patch, I can finish bootstrap, and regtesting is undergoing but I’m seeing no issue so far. FX
Re: Darwin: Replace environment runpath with embedded [PR88590]
Hi, > If I remove the line from libtool.m4 (innocent smile) I see that > fixincludes/configure is better, and it does not appear to change the > regenerated files in other directories (I didn’t do a build yet, just tried > to regenerate with some manual autoconf invocations). I have done a full rebuild, and having looked more at the structure of libtool.m4 I am now convinced that having that line outside of the scope of _LT_DARWIN_LINKER_FEATURES is simply wrong (probably a copy-pasto or leftover from earlier code). Having rebuilt everything, it only manifests itself in fixincludes/ChangeLog. Iain is traveling right now, but when he is back I would like to submit this patch if he agrees with the above. It was regtested on x86_64-apple-darwin21. Thomas, can you confirm that it also fixes things for you? Although I don’t see why it wouldn’t. FX 0001-libsanitizer-fix-build-on-darwin.patch Description: Binary data
Re: [PATCH 1/4] libsanitizer: merge from upstream (c425db2eb558c263)
I have reported the issue to llvm at https://github.com/llvm/llvm-project/issues/72639 There is a trivial one-line patch to fix it, which I hope they will accept. Not sure what our policy is here, in the meantime. FX
Re: [PATCH 1/4] libsanitizer: merge from upstream (c425db2eb558c263)
Heads-up: this broke bootstrap on darwin: > +typedef void (^dispatch_mach_handler_t)(dispatch_mach_reason reason, > +dispatch_mach_msg_t message, > +mach_error_t error); Blocks are an Apple/clang extension, not (yet) supported by GCC. FX
Re: [committed] libcpp: Regenerate config.in
Hi, I have a related question. When I bootstrap gcc in maintainer mode on x86_64-darwin, I get the following diff in the sources: diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in index c0aa51af3f0..17da7bb9867 100644 --- a/libstdc++-v3/config.h.in +++ b/libstdc++-v3/config.h.in @@ -167,7 +167,7 @@ /* Define to 1 if you have the `hypotl' function. */ #undef HAVE_HYPOTL -/* Define if you have the iconv() function. */ +/* Define if you have the iconv() function and it works. */ #undef HAVE_ICONV /* Define to 1 if you have the header file. */ which I think it due to commit db50aea62595452db12565186cb520728540d987 that modified config/iconv.m4. But I am wondering: why am I the only one to see that? It appears the bot builders and not catching it. Do you have any idea? Thanks, FX
Re: Darwin: Replace environment runpath with embedded [PR88590]
> So I currently see the following in my build logs: > >[...] >mkdir -p -- ./fixincludes >Configuring in ./fixincludes >configure: creating cache ./config.cache >[...]/source-gcc/fixincludes/configure: line 3030: > enable_darwin_at_rpath_--srcdir=[...]/source-gcc/fixincludes=no: No such file > or directory >checking build system type... x86_64-pc-linux-gnu >checking host system type... x86_64-pc-linux-gnu >checking target system type... nvptx-unknown-none >[...] > > I'm not convinced that's achieving what it means to achieve? I’ve tried to understand where that line gets expanded from: >>> +enable_darwin_at_rpath_$1=no It comes from: > _LT_TAGVAR(enable_darwin_at_rpath, $1)=no in the top-level libtool.m4. I can’t say that I understand why that line is there. All the other definitions using this structure are all inside the definition of _LT_ prefixed functions, defined by m4_defun. This one line is alone, outside of any function. If I remove the line from libtool.m4 (innocent smile) I see that fixincludes/configure is better, and it does not appear to change the regenerated files in other directories (I didn’t do a build yet, just tried to regenerate with some manual autoconf invocations). Food for thought. FX
Re: gfortran.dg/dg.exp debug messages pollute test output
> FX submitted the patch series, I can find the reference if you need it. Patch was submitted in this thread: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630096.html >> Besides, >> it's unclear if those messages can just be removed (they are pretty >> cryptic as is) or at least changed to use verbose instead of puts. >> Please fix. I don’t see value in this output, so I think it’s best to remove the puts calls entirely. Attached patch does that. Testing under progress, OK if it passes? (or does that count as obvious fix-up of the previous patch) FX 0001-Testsuite-silence-some-noise-in-output.patch Description: Binary data
Re: [PATCH] Testsuite, i386: Mark test as requiring dfp
kind ping for this easy patch > Le 30 oct. 2023 à 15:19, FX Coudert a écrit : > > Hi, > > The test is currently failing on x86_64-apple-darwin with "decimal > floating-point not supported for this target”. > Marking the test as requiring dfp fixes the issue. > > OK to push? > > FX > 0001-Testsuite-i386-Mark-test-as-requiring-dfp.patch Description: Binary data
Re: [PATCH] Testsuite, i386: Fix test by passing -march
> Well It can fail on x86_64-linux-gnu too if GCC was configured with > --with-arch=core2 for an example. > So having it, in this case, not being darwin specific would be > beneficial for all x86_64/i?86 targets. I pushed it as-is, meaning it will indeed apply to all x86_64/i?86 targets. FX
Re: Darwin: Replace environment runpath with embedded [PR88590]
Hi, > +enable_darwin_at_rpath_$1=no I actually don’t understand why this one would have $1 in the name, unlike all other regenerated configure files. What value do we expect for $1 at this point in the file? That’s just plain weird. FX
[PATCH] Testsuite, i386: Mark test as requiring ifunc
Hi, The test is currently failing on x86_64-apple-darwin. Marking the test as requiring ifunc fixes the issue. OK to push? FX 0001-Testsuite-i386-Mark-test-as-requiring-ifunc.patch Description: Binary data
[PATCH] Testsuite, i386: Mark test as requiring dfp
Hi, The test is currently failing on x86_64-apple-darwin with "decimal floating-point not supported for this target”. Marking the test as requiring dfp fixes the issue. OK to push? FX 0001-Testsuite-i386-Mark-test-as-requiring-dfp.patch Description: Binary data
