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.
> libgfortran/ChangeLog:
> * config/t-aix (all-local, libcaf_single): Explicitly reference
> caf/.libs/single.o
OK, and sorry for the breakage.
FX
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
> 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
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 @@
Hi Harald,
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
FX
> 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
Hi Harald,
Thanks for the patch.
> + if (attr.function)
> +{
> + gfc_error ("FPTR at %L to C_F_POINTER is a function returning a
> pointer",
> + >where);
> + return false;
> +}
> +
>if (fptr->rank > 0 && !is_c_interoperable (fptr, , false, true))
> return
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
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
> 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
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 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
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
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 math functions in
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
Hi Harald,
OK to push, thanks for picking it up!
FX
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
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
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,
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
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)
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
>> 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
> 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
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
> 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
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
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
> 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
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
Thanks Richard,
Pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d65eb8a6bbeae7533dd41cb307b427f3f8585d9b
FX
Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion, since I’m
not that active and I may have missed something.
Thanks,
FX
Hi,
I’d like to ping that patch from Iain Sandoe. It would clear up a number of
failures in the darwin testsuite.
Thanks,
FX
> --- 8< ---
>
> Earlier assembler support for complex fp16 on x86_64 Darin is broken. This
> adds an additional test to the existing target-supports that fails for
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
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 } */
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
> 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
> 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.
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
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
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
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
> 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:
>
> 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
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
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
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
Thanks a lot Alexandre for the review!
FX
Thanks Jeff, pushed as 94e68ce96c285e479736851f1ad8cc87c8c3ff0c
FX
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
>
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
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
> 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
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
>
> 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
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
>> 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
> 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 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
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
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
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
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
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]*)
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
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
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
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
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
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
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
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
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
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/602
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
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
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
> OK, thanks.
Committed at
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934
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
1 - 100 of 109 matches
Mail list logo
