[PATCH, pushed] testsuite: adjust for darwin linker warning

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

Re: [PATCH] core: Support heap-based trampolines

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, FX

Re: Testsuite: fix contructor priority test

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 commit? > FX > >

Re: [PATCH] Darwin: homogenize spelling of macOS

Hi, Thanks Sandra and Iain. Patch pushed. FX

[PATCH] Darwin: homogenize spelling of macOS

This patch homogenizes to some extent the use of “Mac OS X” or “OS X” or “Mac OS” in the gcc/ folder to “macOS”, which is the modern way of writing it. It is not a global replacement though, and each use was audited. - When referring to specific versions that used the “OS X” or “Mac OS” as

Re: Analyzer failure due to missing header

> 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

Re: [PATCH] Testsuite, DWARF2: adjust regexp to match darwin output

ping > Hi, > > This was a painful one to fix, because I hate regexps, especially when they > are quoted. On darwin, we have this failure: > >FAIL: gcc.dg/debug/dwarf2/inline4.c scan-assembler > DW_TAG_inlined_subroutine[^(]*([^)]*)[^(]*(DIE >

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

> Revised patch. I does the job on darwin, can you check that it still tests > the functions on Linux? > And if so, OK to commit? With the correct file, sorry. 0001-libgomp-testsuite-Do-not-call-nonstandard-functions.patch Description: Binary data

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

Revised patch. I does the job on darwin, can you check that it still tests the functions on Linux? And if so, OK to commit? FX 0001-Testsuite-DWARF2-adjust-regexp-to-match-darwin-outpu.patch Description: Binary data

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

>> I understand, I wanted to not just report the issue but propose an option. >> It seems a bit heavy to design an effective target just for one test, >> though, no? > > It has the advantage of getting it right on all current and future targets. Something like this? (not tested yet) diff

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

> I don't like the #if !defined(__APPLE__) conditionals everywhere in the > test, I think much cleaner would be to add an effective target to test > for those functions I understand, I wanted to not just report the issue but propose an option. It seems a bit heavy to design an effective target

[committed] Testsuite, darwin: account for macOS 13 and 14

Committed as obvious, making gcc.dg/darwin-minversion-link.c pass on macOS 13 and 14 (darwin22 and darwin23, respectively). FX 0001-Testsuite-darwin-account-for-macOS-13-and-14.patch Description: Binary data

[PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

Hi, testsuite/libgomp.c/simd-math-1.c calls nonstandard functions that are not available on darwin (and possibly other systems?). Because I did not want to disable their testing completely, I suggest we simply use preprocessor macros to avoid them on darwin. This fixes the test failure on

[PATCH, committed] Testsuite, darwin: Fix analyzer testcases

Committed as obvious, fixing three more darwin-specific failures in analyzer testsuite. This fixes: FAIL: gcc.dg/plugin/taint-CVE-2011-0521-5.c -fplugin=./analyzer_kernel_plugin.so (test for warnings, line 39) FAIL: gcc.dg/plugin/taint-CVE-2011-0521-6.c

Re: [PATCH] Testsuite: mark IPA test as requiring alias support

Hi, > IMO, changes like this qualify as obvious, so I’d go ahead (thanks for this > test fail triage) Makes sense. I’ve committed, as well as another one, attached, slightly amending the expected pattern of a sarif plugin test. FX

[PATCH] Testsuite: mark IPA test as requiring alias support

Hi, The fact that this test needs alias support was indicated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656 but never committed. Without it, the test fails on darwin. OK to commit? FX 0001-Testsuite-mark-IPA-test-as-requiring-alias-support.patch Description: Binary data

[PATCH] Testsuite, DWARF2: adjust regexp to match darwin output

Hi, This was a painful one to fix, because I hate regexps, especially when they are quoted. On darwin, we have this failure: FAIL: gcc.dg/debug/dwarf2/inline4.c scan-assembler DW_TAG_inlined_subroutine[^(]*([^)]*)[^(]*(DIE (0x[0-9a-f]*)

[PATCH] Testsuite, LTO: silence warning to make test pass on Darwin

Hi, On darwin (both x86_64-apple-darwin and aarch64-apple-darwin) we see the following test failure: FAIL: gcc.dg/lto/20091013-1 c_lto_20091013-1_2.o assemble, -fPIC -r -nostdlib -O2 -flto which is due to this extra warning: In function 'fontcmp', inlined from 'find_in_cache' at

Re: [PATCH] core: Support heap-based trampolines

Hi, A gentle ping on the revised patch, for Richard or another global reviewer. Thanks, FX > Le 5 août 2023 à 16:20, FX Coudert a écrit : > > Hi Richard, > > Thanks for your feedback. Here is an amended version of the patch, taking > into consideration your requests and the following

[PATCH] Testsuite: fix analyzer tests on Darwin

Hi, gcc.dg/analyzer/ currently has 80 failures on Darwin (both x86_64-apple-darwin and aarch64-apple-darwin). All those come from two issues: 1. Many tests use memset() without including the header. We can fix that easily. 2. Other tests fail because of the use of macOS headers, which

Testsuite: fix contructor priority test

Bordering on obvious, tested on darwin where the test case fails before (and now passes). OK to commit? FX 0001-Testsuite-fix-contructor-priority-test.patch Description: Binary data

[PATCH] aarch64: fix format specifier

A rather trivial fix for fprintf() specifier of a HOST_WIDE_INT value. Tested on aarch64-apple-darwin. OK to commit? FX 0001-aarch64-fix-format-specifier.patch Description: Binary data

Re: [PATCH] core: Support heap-based trampolines

Hi Richard, Thanks for your feedback. Here is an amended version of the patch, taking into consideration your requests and the following discussion. There is no configure option for the libgcc part, and the documentation is amended. The patch is split into three commits for core, target and

Re: [PATCH] Add __builtin_iseqsig()

6 weeks later, I’d like to ask a global maintainer to review this. The idea was okay’ed previously by Joseph Myers, but he asked for testing of both the quiet and signalling NaN cases, which is now done. FX > Le 6 juin 2023 à 20:15, FX Coudert a écrit : > > Hi, > > (It took me a while to

Re: [PATCH] core: Support heap-based trampolines

Hi, > Since this affects the ABI of libgcc I think we don't want that part > to be user configurable but rather determined by > some static list of targets that opt-in to this config. If I do that, do the Linux maintainers want Linux in or out? > You mention setjmp/longjmp - on darwin and

[PATCH] core: Support heap-based trampolines

Hi, This is a reworked version (following review) of the patch by Maxim Blinov and Iain Sandoe enabling heap-based trampolines. What has changed since the last version: - wording changes, preferring to use “heap-based trampolines” rather than “off-stack trampolines” - the option triggering

Re: [PATCH] Add __builtin_iseqsig()

ping**3 >> Le 6 juin 2023 à 20:15, FX Coudert a écrit : >> >> Hi, >> >> (It took me a while to get back to this.) >> >> This is a new and improved version of the patch at >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html >> It addresses the comment from Joseph that

Re: [PATCH] Add __builtin_iseqsig()

ping**2 > Le 6 juin 2023 à 20:15, FX Coudert a écrit : > > Hi, > > (It took me a while to get back to this.) > > This is a new and improved version of the patch at > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html > It addresses the comment from Joseph that FE_INVALID

Re: [PATCH] Add __builtin_iseqsig()

ping > Hi, > > (It took me a while to get back to this.) > > This is a new and improved version of the patch at > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html > It addresses the comment from Joseph that FE_INVALID should really be tested > in the case of both quiet and

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi, > Running > nohup make -j7 check-fortran > RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"& > from the gcc subdirectory yielded only a single failure: I dug more into the code and I understand why all tests are running: since db630423a97ec6690a8eb0e5c3cb186c91e3740d

Re: libgfortran: remove support for --enable-intermodule

> OK, thanks. Committed at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934

libgfortran: remove support for --enable-intermodule

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373 I don’t believe it is widely used, and it was removed from everywhere else in gcc. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX 0001-libgfortran-remove-support-for-enable-intermodule.patch Description: Binary data

gcc/config.in was not regenerated

Hi, Building GCC in maintainer mode leads to changes in gcc/config.in : > diff --git a/gcc/config.in b/gcc/config.in > index 4cad077bfbe..25442c59aec 100644 > --- a/gcc/config.in > +++ b/gcc/config.in > @@ -67,6 +67,12 @@ > #endif > +/* Define to larger than one set the

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Given the agreement that the patch is not making things for powerpc worse, and the review by Steve, I have committed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17bccd1d2c0fa1f08e0483c8ed841994a95febb0 Best, FX

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi Thomas, > The KIND=17 is a bit of a kludge. It is not visible for > user programs, they use KIND=16, but this is then translated > to library calls as if it was KIND=17 if the IEEE 128-bit floats > are selected Can you check what the IEEE test results are when -mabi=ieeelongdouble is

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

Hi Harald, > I just looked at that thread. I guess if you answer Mikael's > questions at > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601744.html > the patch will be fine. Amended patch, adding the required testing of signalling vs. quiet behaviour. I still need to get an OK on

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

> Having a POWER system isn't enough, it also needs the IBM "advance > toolchain", and (at least with current distros, which default to > ibm long double), you need to dance counterclockwise three > times... I mean you need to invoke configure with some special magic Thanks for the frank

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi Steve, I am not subscribed to the list (too little time, sadly), please keep me in CC of your responses. > 1. You added fmin, fmax, and friends. Are these used >internally by gfortran in support of the IEEE_* >functions or are these exposed to the user? The math builtins are added

[PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

Hi, This is a repost of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html which never really got green light, but I stopped pushing because stage 1 was closing and I was out of time. It depends on a middle-end patch adding a type-generic __builtin_iseqsig(),

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi, > I cannot see if there is proper support for kind=17 in your patch; > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not > seem to have any related code. Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong happened, because the IEEE modules have no kind=17

[PATCH] Add __builtin_iseqsig()

Hi, (It took me a while to get back to this.) This is a new and improved version of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html It addresses the comment from Joseph that FE_INVALID should really be tested in the case of both quiet and signaling NaNs, which