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

Thanks Jeff, pushed as 94e68ce96c285e479736851f1ad8cc87c8c3ff0c FX

Re: Darwin: Replace environment runpath with embedded [PR88590]

Thanks a lot Alexandre for the review! FX

[PATCH] Testsuite, Darwin: skip PIE test

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-test.pat

[PATCH] Testsuite, i386: Fix test by passing -march

Hi, The newly introduced test gcc.target/i386/pr111698.c currently fails on Darwin, where the default arch is core2. Andrew suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112287 to pass a recent value to -march, and I can confirm that it fixes the testsuite failure on x86_64-apple-da

[PATCH] Testsuite, Darwin: Fix trampoline warning

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

[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

[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

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

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

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

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 think it's an obvious change ... Thanks, pushed. Dimitry, I suggest you post the second patch for review. FX

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

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

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

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", > + &fptr->where); > + return false; > +} > + >if (fptr->rank > 0 && !is_c_interoperable (fptr, &msg, false, true)) > return g

[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

[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

[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] 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:

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

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] 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: [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

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 l

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

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

Re: [PATCH] Fortran: bogus warnings with REPEAT intrinsic and -Wconversion-extra [PR96724]

Hi Harald, OK to push, thanks for picking it up! 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

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: [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: [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-li

Several test failures due to "Introduce strub: machine-independent stack scrubbing"

Hi Alexandre, The commit https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f0a90c7d7333fc7f554b906245c84bdf04d716d7 (Introduce strub: machine-independent stack scrubbing) has introduced many test failures on x86_64-apple-darwin21: +FAIL: c-c++-common/strub-apply2.c -std=gnu++98 (internal compiler

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

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 obje

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: [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 o

[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

[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, 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) saniti

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

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

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

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 cha

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

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 @

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)

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

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.

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 m

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]

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: [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 } */ whi

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

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 th

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.

Thanks Richard, Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d65eb8a6bbeae7533dd41cb307b427f3f8585d9b FX

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

ping**2 > 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] 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 (a

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 ca

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.

> 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

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 thin

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

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 al

[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] 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: 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

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.

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

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

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] 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 . Ot

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

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Hi, > I dropped a change to the test file, since you have fixed it appropriately, > and switched to Apple libm convention for flags, as you have suggested. > Please let me know if I should do anything further to improve it and make it > acceptable for a merge. The patch itself is OK. Please add

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

> 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

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thanks Sergey, I have pushed the patch at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669 FX

[PATCH] Libquadmath: update doc for some constants

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

Re: [PATCH] Libquadmath: update doc for some constants

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 push? > > FX > > > libquad

Re: [PATCH] Libquadmath: update doc for some constants

> 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

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

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

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/

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 cou

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

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. */ #

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: [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=3bd3ca05b519b99b5e

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] 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 @@ al

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 a

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*/Mak

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

[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. Tes

Re: [PATCH] jit: Ensure ssize_t is defined.

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

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 -

  1   2   >