eat to fix this issue in
GCC, one way or another, to minimise the amount of patches needed for modern
darwin targets.
Best,
FX
Hi Jerry,
This looks okay to me, but maybe leave 48 hours for others to comment?
Best,
FX
I’ve pushed the attached patch as obvious, taking into account the newly
released macOS 15 (darwin24). It makes the test pass.
FX
0001-Testsuite-darwin-account-for-macOS-15.patch
Description: Binary data
ure to build libgcc_s.1.dylib on macOS 15
for Intel, is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Best,
FX
Thanks, pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fe1ed68000d5e9d41ed48ef1202fd21c8b8c9ff8
FX
Can I please get an approval on that one? It’s been there since January, I’ve
amended it following review, but cannot get a definite ok. It is five lines.
Bootstrapped on x86_64-apple-darwin23. OK to push?
FX
> Le 7 sept. 2024 à 19:35, FX Coudert a écrit :
>
> ping**many on t
you stated it is a desirable goal. I dream
> of a day where we no longer have to use fixincludes.
Have you had the opportunity to test he amended patch (attached) on older
platforms? If so, is it OK to push (along with suitable ChangeLog)?
Best,
FX
test.diff
Description: Binary data
ping**many on this patch, originally from January.
In latest round, Richard suggested that David should have the last say, I’ve
never had any response.
> Le 27 juin 2024 à 19:08, FX Coudert a écrit :
>
> Among the review comments from the last round, Jakub suggested:
>
>> P
> I agree. I don't have a preference for which is better, but being consistent
> with other documentation might be a winning argument.
Pushed as attached.
FX
0001-Libquadmath-update-doc-for-some-constants.patch
Description: Binary data
kind ping
Give it’s a doc patch, I think it might fall under the obvious rule, and will
commit in a week if there is no objection.
FX
> As reported by Peter Randall, the description of three constants in
> libquadmath is wrong. Attached patch fixes them.
>
> OK to p
As reported by Peter Randall, the description of three constants in libquadmath
is wrong. Attached patch fixes them.
OK to push?
FX
libquadmath/ChangeLog:
* libquadmath.texi (M_LOG2Eq, M_LOG10Eq, M_2_PIq): Fix
description of these constants.
0001-Libquadmath-update-doc
Thanks Sergey,
I have pushed the patch at
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669
FX
> Thank you for responding.
> I have added a changelog (is this a correct way?).
Content seems ok, lines are maybe too long. Check with
contrib/gcc-changelog/git_check_commit.py before pushing.
Once that is fine, OK to push.
FX
s OK. Please add a ChangeLog entry fitting the GCC format
(see prior commits in libgfortran/ for examples).
FX
Can you post an updated version of the patch, following the first round of
review?
FX
dream of a
day where we no longer have to use fixincludes.
FX
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
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
Thanks, pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8326956159053b215b5cfe6cd41bfceff413491e
FX
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
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
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.
-if.
But I’d like to understand better what are the other new failures, and why
there arise?
FX
e 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
> 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
ble, 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
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.
* inclha
ms have this header. */
#include
FX
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
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
> :-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
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
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
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
Seems good, thanks Tobias!
FX
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 . Ot
Hi Tobias,
> OK for mainline?
Seems reasonable, OK to push in 48 hours unless someone has suggestions related
to wording.
FX
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
.
Tested on x86_64-darwin and x86_64-linux. OK to push?
FX
0001-jit-Ensure-ssize_t-is-defined.patch
Description: Binary data
> libgfortran/ChangeLog:
> * config/t-aix (all-local, libcaf_single): Explicitly reference
> caf/.libs/single.o
OK, and sorry for the breakage.
FX
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
bgfortran are now gone.
Push as affd24bfc62203db9f9937c0d6cf8f1f75b80d72
FX
4e847b2dec..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
Hi Harald,
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
FX
=gcc.git;a=commit;h=3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
FX
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
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
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
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
> I think it's an obvious change ...
Thanks, pushed.
Dimitry, I suggest you post the second patch for review.
FX
> 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
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
> OK for trunk and later backport to 13?
OK. Thanks for the patch!
FX
> 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
> Regression tested on x86_64 and new test case.
> OK for trunk?
OK, and thanks!
FX
:
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
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
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
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
> 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
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 f
y 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
Hi Harald,
OK to push, thanks for picking it up!
FX
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
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
> 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
,
we can’t compile GCC for macOS 14.
OK to backport?
FX
-prop6.C -std=c++20 at line 58 (test for
> warnings, line 57)
How could I help debug this?
FX
)
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-A
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
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
mmit push as obvious fixup:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=53e954a673a0d6ac80ab1f0591ea4f751e67374c
FX
> 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
8 hours for someone else to object if they want.
Best,
FX
ld right now, will report back.
FX
/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
ed on x86_64-pc-linux-gnu. OK for mainline?
OK.
FX
> Thanks. I can't push it myself - could you do that for me?
Pushed.
FX
> 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
ler "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
Thanks Richard,
Pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d65eb8a6bbeae7533dd41cb307b427f3f8585d9b
FX
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
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
org/git/?p=gcc.git;a=commit;h=e40a13eaca4d87ec33beb0d9d31985e0023bfe3e
FX
e-target split_stack } */
which I have added and pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c54ee4fc1667593081ce80030eeb70838267ad96
FX
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
h was submitted upstream: https://github.com/llvm/llvm-project/pull/72642
FX
> 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
>> 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 m
ue so far.
FX
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-libs
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
not (yet) supported by GCC.
FX
ue 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
he
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
> 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
>>
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
> 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
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
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
1 - 100 of 633 matches
Mail list logo
