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
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
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
ow 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
-if.
But I’d like to understand better what are the other new failures, and why
there arise?
FX
eed, 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
ilable, 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 includ
as 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/test
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
=commit;h=3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
FX
R”? “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
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
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 compi
> 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 fallback
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
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
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
it,
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-Adjust
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
commit 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
hours for someone else to object if they want.
Best,
FX
ill 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-supp
=gcc.git;a=commit;h=e40a13eaca4d87ec33beb0d9d31985e0023bfe3e
FX
} */
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
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
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
rated 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
>> crypt
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
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
Heap-based trampolines are enabled on darwin20 and later, meaning that no
warning is emitted.
Fixes the test failure on x86_64-apple-darwin21
OK to push?
FX
0001-Testsuite-Darwin-Fix-trampoline-warning.patch
Description: Binary data
-darwin21.
OK to push?
FX
0001-Testsuite-i386-Fix-test-by-passing-march.patch
Description: Binary data
Hi,
The recent commit of
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634347.html has made
this test invalid. We now don’t emit __PIE__, and the test should be skipped on
darwin.
Fixes the new failure on x86_64-apple-darwin21. OK to push?
FX
0001-Testsuite-Darwin-skip-PIE
Thanks a lot Alexandre for the review!
FX
Thanks Jeff, pushed as 94e68ce96c285e479736851f1ad8cc87c8c3ff0c
FX
es
> optional
>
> I chose the second approach. It makes the test pass on darwin. If someone can
> test it on linux, it’d be appreciated :) I don’t have ready access to such a
> system right now.
>
> Once that passes, OK to commit?
> FX
0001-Testsuite-DWARF2-adjust-regexp-to-match-darwin-outpu.patch
Description: Binary data
Pushed as obvious to fix two testsuite FAILs on darwin with recent macOS
linkers when -no_pie is passed.
FX
0001-testsuite-adjust-for-darwin-linker-warning.patch
Description: Binary data
Hi,
ping**2 on the revised patch, for Richard or another global reviewer. So far
all review feedback is that it’s a step forward, and it’s been widely used for
both aarch64-darwin and x86_64-darwin distributions for almost three years now.
OK to commit?
FX
> Le 5 août 2023 à 16:20,
Hi,
I was about to ping the attached patch, and realised it bordered on obvious, so
I pushed it directly.
FX
> Le 19 août 2023 à 22:40, FX Coudert a écrit :
>
> Bordering on obvious, tested on darwin where the test case fails before (and
> now passes).
>
> OK to commi
Hi,
Thanks Sandra and Iain.
Patch pushed.
FX
” as their
name, it was kept.
- All uses referring to powerpc*-apple-darwin* were kept as-is, because those
versions all predate the change to “macOS”.
- I did not touch Ada or D
- I did not touch testsuite comments
Tested by building on x86_64-apple-darwin, and generating the docs.
OK to push?
FX
> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not
> available because is not included.
I originally thought this was only seen in cross-compilers, but it actually
broke bootstrap on darwin.
Attached patch restores it, OK to commit?
FX
0001-Analyzer-i
es
> optional
>
> I chose the second approach. It makes the test pass on darwin. If someone can
> test it on linux, it’d be appreciated :) I don’t have ready access to such a
> system right now.
>
> Once that passes, OK to commit?
> FX
>
0001-Testsuite-DWARF2-adjust-regexp-to-match-darwin-outpu.patch
Description: Binary data
1 - 100 of 609 matches
Mail list logo
