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

[FX Coudert via Gcc-patches]

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 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 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 libgcc.
> 
> Currently regtesting on x86_64 linux and darwin (it was fine before I split 
> up into three commits, so I’m re-testing to make sure I didn’t screw anything 
> up).
> 
> OK to commit?
> FX



0001-core-Support-heap-based-trampolines.patch
Description: Binary data


0002-target-Support-heap-based-trampolines.patch
Description: Binary data


0003-libgcc-support-heap-based-trampolines.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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

[FX Coudert via Gcc-patches]

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 libgcc.

Currently regtesting on x86_64 linux and darwin (it was fine before I split up 
into three commits, so I’m re-testing to make sure I didn’t screw anything up).

OK to commit?
FX




0001-core-Support-heap-based-trampolines.patch
Description: Binary data


0002-target-Support-heap-based-trampolines.patch
Description: Binary data


0003-libgcc-support-heap-based-trampolines.patch
Description: Binary data

[PATCH] aarch64: fix format specifier

[FX Coudert via Gcc-patches]

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

Testsuite: fix contructor priority test

[FX Coudert via Gcc-patches]

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] Testsuite: fix analyzer tests on Darwin

[FX Coudert via Gcc-patches]

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 redefine 
functions like memcpy and others to “checked”/fortified versions 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 Instead of correcting this 
on a case-by-case basis, add the -D_FORTIFY_SOURCE=0 flag systematically on 
Darwin.

With that, all 80 failures are silenced and that part of the testsuite is now 
clean:

# of expected passes 5238
# of expected failures 194
# of unsupported tests 12



OK to commit?
FX



0001-Testsuite-fix-analyzer-tests-on-Darwin.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 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 libgcc.
> 
> Currently regtesting on x86_64 linux and darwin (it was fine before I split 
> up into three commits, so I’m re-testing to make sure I didn’t screw anything 
> up).
> 
> OK to commit?
> FX



0001-core-Support-heap-based-trampolines.patch
Description: Binary data


0002-target-Support-heap-based-trampolines.patch
Description: Binary data


0003-libgcc-support-heap-based-trampolines.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 
/tmp/gcc-darwin-arm64/gcc/testsuite/gcc.dg/lto/20091013-1_2.c:140:13,
inlined from 'WineEngCreateFontInstance' at 
/tmp/gcc-darwin-arm64/gcc/testsuite/gcc.dg/lto/20091013-1_2.c:160:15:
/tmp/gcc-darwin-arm64/gcc/testsuite/gcc.dg/lto/20091013-1_2.c:107:8: warning: 
'memcmp' specified bound 4 exceeds source size 0 [-Wst
ringop-overread]
/tmp/gcc-darwin-arm64/gcc/testsuite/gcc.dg/lto/20091013-1_2.c: In function 
'WineEngCreateFontInstance':
/tmp/gcc-darwin-arm64/gcc/testsuite/gcc.dg/lto/20091013-1_2.c:66:20: note: 
source object allocated here

Now, the main file for the test has:

/* { dg-extra-ld-options "-flinker-output=nolto-rel -Wno-stringop-overread" } */

and I believe the intent of -Wno-stringop-overread is to silence this warning, 
but that only applies to the linker, and the warning on darwin is produced by 
the compiler (in addition to the linker). Adding the flag to the compilation of 
the source file makes the test pass on darwin.

OK to commit?
FX




0001-Testsuite-LTO-silence-warning-to-make-test-pass-on-D.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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]*) DW_TAG_formal_parameter[^(]*(DIE 
(0x[0-9a-f]*) DW_TAG_variable

That hideous regexp is trying to match (generated on Linux):

> .uleb128 0x4# (DIE (0x5c) DW_TAG_inlined_subroutine)
> .long   0xa0# DW_AT_abstract_origin
> .quad   .LBI4   # DW_AT_entry_pc
> .byte   .LVU2   # DW_AT_GNU_entry_view
> .quad   .LBB4   # DW_AT_low_pc
> .quad   .LBE4-.LBB4 # DW_AT_high_pc
> .byte   0x1 # DW_AT_call_file (u.c)
> .byte   0xf # DW_AT_call_line
> .byte   0x14# DW_AT_call_column
> .uleb128 0x5# (DIE (0x7d) DW_TAG_formal_parameter)
> .long   0xad# DW_AT_abstract_origin
> .long   .LLST0  # DW_AT_location
> .long   .LVUS0  # DW_AT_GNU_locviews
> .uleb128 0x6# (DIE (0x8a) DW_TAG_variable)

It is using the parentheses to check what is between  
DW_TAG_inlined_subroutine, DW_TAG_formal_parameter and DW_TAG_variable. There’s 
only one block of parentheses in the middle, that "(u.c)”. However, on darwin, 
the generated output is more compact:

> .uleb128 0x4; (DIE (0x188) DW_TAG_inlined_subroutine)
> .long   0x1b8   ; DW_AT_abstract_origin
> .quad   LBB4; DW_AT_low_pc
> .quad   LBE4; DW_AT_high_pc
> .uleb128 0x5; (DIE (0x19d) DW_TAG_formal_parameter)
> .long   0x1c6   ; DW_AT_abstract_origin
> .uleb128 0x6; (DIE (0x1a2) DW_TAG_variable)

I think that’s valid as well, and the test should pass (what the test really 
wants to check is that there is no DW_TAG_lexical_block emitted there, see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801 for its origin). It could be 
achieved in two ways:

1. making darwin emit the DW_AT_call_file
2. adjusting the regexp to match, making the internal block of parentheses 
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

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

[FX Coudert via Gcc-patches]

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

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

[FX Coudert via Gcc-patches]

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



0001-Testsuite-plugin-make-testcase-pattern-more-flexible.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 
-fplugin=./analyzer_kernel_plugin.so  (test for warnings, line 36)
XPASS: gcc.dg/plugin/taint-CVE-2011-0521-5-fixed.c 
-fplugin=./analyzer_kernel_plugin.so  (test for bogus messages, line 39)

Committed to trunk,
FX


0001-Testsuite-darwin-Fix-analyzer-testcases.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 aarch64-apple-darwin.
OK to commit?

FX



0001-libgomp-testsuite-Do-not-call-nonstandard-functions-.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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

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

[FX Coudert via Gcc-patches]

> 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 just for one test, though, no?

Another possibility would be to replace #if !defined(__APPLE__) by #if 
defined(__linux__), or glibc?

FX

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

[FX Coudert via Gcc-patches]

>> 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 --git a/libgomp/testsuite/lib/libgomp.exp 
b/libgomp/testsuite/lib/libgomp.exp
index 2f9e538278f..85d467434e9 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -377,6 +377,24 @@ proc offload_target_to_openacc_device_type { 
offload_target } {
 }
 }
  +# Return 1 if certain nonstandard math functions are available
+# on the target.
+proc libgomp_check_effective_target_nonstandard_math_functions { } {
+return [check_no_compiler_messages nonstandard_math_functions executable {
+#include 
+int main() {
+  float x = 42;
+  double y = 42;
+  x = gammaf (x);
+  x = __builtin_scalbf (x, 2.f);
+  x =__builtin_significandf (x);
+  y = gamma (y);
+  y = __builtin_scalb (y, 2.);
+  y =__builtin_significand (y);
+  return 0;
+} } "-lm" ]
+}
+
 # Return 1 if compiling for the specified offload target
 # Takes -foffload=... into account by checking OFFLOAD_TARGET_NAMES=
 # in the -v compiler output.

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

[FX Coudert via Gcc-patches]

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

[FX Coudert via Gcc-patches]

> 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] Testsuite, DWARF2: adjust regexp to match darwin output

[FX Coudert via Gcc-patches]

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 
> (0x[0-9a-f]*) DW_TAG_formal_parameter[^(]*(DIE 
> (0x[0-9a-f]*) DW_TAG_variable
> 
> That hideous regexp is trying to match (generated on Linux):
> 
>>.uleb128 0x4# (DIE (0x5c) DW_TAG_inlined_subroutine)
>>.long   0xa0# DW_AT_abstract_origin
>>.quad   .LBI4   # DW_AT_entry_pc
>>.byte   .LVU2   # DW_AT_GNU_entry_view
>>.quad   .LBB4   # DW_AT_low_pc
>>.quad   .LBE4-.LBB4 # DW_AT_high_pc
>>.byte   0x1 # DW_AT_call_file (u.c)
>>.byte   0xf # DW_AT_call_line
>>.byte   0x14# DW_AT_call_column
>>.uleb128 0x5# (DIE (0x7d) DW_TAG_formal_parameter)
>>.long   0xad# DW_AT_abstract_origin
>>.long   .LLST0  # DW_AT_location
>>.long   .LVUS0  # DW_AT_GNU_locviews
>>.uleb128 0x6# (DIE (0x8a) DW_TAG_variable)
> 
> It is using the parentheses to check what is between  
> DW_TAG_inlined_subroutine, DW_TAG_formal_parameter and DW_TAG_variable. 
> There’s only one block of parentheses in the middle, that "(u.c)”. However, 
> on darwin, the generated output is more compact:
> 
>>.uleb128 0x4; (DIE (0x188) DW_TAG_inlined_subroutine)
>>.long   0x1b8   ; DW_AT_abstract_origin
>>.quad   LBB4; DW_AT_low_pc
>>.quad   LBE4; DW_AT_high_pc
>>.uleb128 0x5; (DIE (0x19d) DW_TAG_formal_parameter)
>>.long   0x1c6   ; DW_AT_abstract_origin
>>.uleb128 0x6; (DIE (0x1a2) DW_TAG_variable)
> 
> I think that’s valid as well, and the test should pass (what the test really 
> wants to check is that there is no DW_TAG_lexical_block emitted there, see 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801 for its origin). It could 
> be achieved in two ways:
> 
> 1. making darwin emit the DW_AT_call_file
> 2. adjusting the regexp to match, making the internal block of parentheses 
> 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

Re: Analyzer failure due to missing header

[FX Coudert via Gcc-patches]

> 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-include-algorithm-header.patch
Description: Binary data

[PATCH] Darwin: homogenize spelling of macOS

[FX Coudert via Gcc-patches]

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




0001-Darwin-homogenize-spelling-of-macOS.patch
Description: Binary data

Re: [PATCH] Darwin: homogenize spelling of macOS

[FX Coudert via Gcc-patches]

Hi,

Thanks Sandra and Iain.
Patch pushed.

FX

Re: Testsuite: fix contructor priority test

[FX Coudert via Gcc-patches]

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
> 
> <0001-Testsuite-fix-contructor-priority-test.patch>


0001-Testsuite-fix-contructor-priority-test.patch
Description: Binary data

[PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

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 is now done systematically.

Bootstrapped and regtested on x86_64-pc-linux-gnu
OK to commit?

FX



0001-Add-__builtin_iseqsig.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 mention in them anywhere.

Actually, where is the kind=17 documented?

FX

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

[FX Coudert via Gcc-patches]

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(), 
which I posted for review at: 
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620801.html

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK to commit (once the 
middle-end patch is accepted)?

FX



0002-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 to the front-end, and use for code generation. In 
conv_intrinsic_ieee_minmax(), you can see we find the right function using 
things like: builtin_decl_explicit (BUILT_IN_ISSIGNALING)

Those built-ins are not exposed to the user: we don’t need any more 
GNU-specific intrinsics, methinks.


> 2. I did not see error handling or conversion, but on a
>quick scan I may have missed it.  What happens with
>IEEE_MAX_NUM(2.0_4, 3.0_8) or IEEE_MAX_NUM(2.0_4, INT(3))?
>17.11.17 has
> 
>X shall be of type real.
>Y shall be of the same type and kind type parameter as X.


As you saw, the module built as part of libgfortran deals with that. In the 
longer term, we would need a revamp of those modules to handle everything as 
intrinsic modules, which would give us more flexibility, but I never found the 
time to do this migration :(

Best,
FX

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

[FX Coudert via Gcc-patches]

> 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 description, Thomas. To be honest, it reinforces my 
feeling from when this was originally proposed and added: why are we doing so 
much extra work for a feature that is used by such a tiny fraction of our user 
base.

FX

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

[FX Coudert via Gcc-patches]

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 the middle-end part first, but I consider the 
Fortran part approved.

Thanks,
FX



0001-Add-__builtin_iseqsig.patch
Description: Binary data


0002-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 
enabled?
It’s not even clear to me what the IEEE kinds selected should be, in this case, 
depending on -mabi=ieeelongdouble


> Regarding FX's patch: I am not quite sure that I am
> actually testing the right thing if running the testsuite
> there, so POWER should not hold up this patch.  If it turns
> out that POWER needs additonal work on IEEE, we can always
> add that later.

Actually, it sounds like the situation is: the same target can have two ABIs 
based on a compile-time flag. That sounds like a job for multilib, i.e., we 
should compile libgfortran twice, one for each ABI. I am sure this was 
considered and rejected, do you remember what was the rationale?

Thanks,
FX

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

[FX Coudert via Gcc-patches]

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

gcc/config.in was not regenerated

[FX Coudert via Gcc-patches]

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 number of match.pd partitions to 
> make. */
> +#ifndef USED_FOR_TARGET
> +#undef DEFAULT_MATCHPD_PARTITIONS
> +#endif
> +
> +
>  /* Define to larger than zero set the default stack clash protector size. */
>  #ifndef USED_FOR_TARGET
>  #undef DEFAULT_STK_CLASH_GUARD_SIZE

which I think are because this commit 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a85544e1aaeca41133ecfc438cda913dbc0f122
should have regenerated and committed config.in 

Christina, can you please have a look?

FX

libgfortran: remove support for --enable-intermodule

[FX Coudert via Gcc-patches]

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

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

[FX Coudert via Gcc-patches]

> OK, thanks.

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

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

[FX Coudert via Gcc-patches]

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 and 
0c2d6aa1be2ea85e751852834986ae52d58134d3 all IEEE functions manipulating real 
or complex arguments are actually expanded fully inline (we retain functions in 
libgfortran for backward compatibility).

The only IEEE functions that depend on libgfortran runtime are the 
“IEEE_SUPPORT_*” functions.

FX

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

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 signaling NaNs, which is now done 
> systematically.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu
> OK to commit?
> 
> FX


0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

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 should really be tested 
> in the case of both quiet and signaling NaNs, which is now done 
> systematically.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu
> OK to commit?
> 
> FX
> 
> <0001-Add-__builtin_iseqsig.patch>


0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

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 FE_INVALID should really be tested 
>> in the case of both quiet and signaling NaNs, which is now done 
>> systematically.
>> 
>> Bootstrapped and regtested on x86_64-pc-linux-gnu
>> OK to commit?
>> 
>> FX



0001-Add-__builtin_iseqsig.patch
Description: Binary data

[PATCH] core: Support heap-based trampolines

[FX Coudert via Gcc-patches]

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 generation of these new trampolines is now a binary 
choice: -ftrampoline-impl=[stack|heap]
- some adjustments due to changes in the macOS build flags in GCC since last 
year

Regarding testing, this patch has had excellent exposure on darwin (both x86_64 
and aarch64) because it was part of Iain’s branch, distributed by many macOS 
distros/vendors (including Homebrew) for more than a year, and there was no bug 
report against the feature or implementation. On x86_64-linux, I have 
regression-tested it in three different configurations:
- a default build
- a build with --enable-heap-trampolines
- a build with --enable-heap-trampolines and heap trampolines forced by default 
(forcing HEAP_TRAMPOLINES_INIT = 1)

There are no regressions in any of these settings (apart from an expected 
missing warning in gcc.dg/Wtrampolines.c).

--

From the original review, one question asked (by Jeff Law) was: whether the two 
linux implementations should be dropped, and the configure time 
selectability as well. Regardless of the answer to the first question, I think 
we probably want to retain the later, even if only for darwin, as we want to 
implement this only on recent darwin versions.


OK to commit?

FX




0001-core-Support-heap-based-trampolines.patch
Description: Binary data

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

[FX Coudert via Gcc-patches]

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 other platforms requiring
> non-stack based trampolines
> does the system runtime provide means to deal with this issue like an
> alternate allocation method
> or a way to register cleanup?

There is an alternate mechanism relying on system libraries that is possible on 
darwin specifically (I don’t know for other targets) but it will only work for 
signed binaries, and would require us to codesign everything produced by gcc. 
During development, it was deemed too big an ask and the current strategy was 
chosen (Iain can surely add more background on that if needed).


> Was there ever an attempt to provide a "generic" trampoline driven by
> a more complex descriptor?
> (well, it could be a bytecode interpreter and the trampoline being
> bytecode on the stack?!)

My own opinion is that executable stack should go away on all targets at some 
point, so a truly generic solution to the problem would be great. Having 
something that works reliably across all targets, like you suggest, is a much 
bigger project that this patch, and I am not aware of any previous attempt at 
it.


> Otherwise I suggest to split the patch into libgcc, generic and target parts.

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

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 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 is now done 
> systematically.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu
> OK to commit?
> 
> FX
> 


0001-Add-__builtin_iseqsig.patch
Description: Binary data