[EMAIL PROTECTED] wrote:
Jeff,
thanks again for suggestions.
As I understand it (perhaps wrongly), actual splitting only occurs after
combine pass (by split1 pass).
Combine has some limited splitting capabilities. For example it can
try to combine 3 insns, which might not match a pattern
[EMAIL PROTECTED] wrote:
Dave and Jeff,
(sorry if you get more than one copy of this email, it's playing up!)
Here are more details and I have include testcase, splitter patterns and
RTL dump to show problem in more detail.
[ ... ]
Can you send the .combine dump as well as the dum
much like it used to eliminate nop-moves and the like.
3. Investigate emitting better code in the splitters.
Jeff
ike either solution --
extending local to do something other passes do quite well is
duplication, but adding another pass isn't ideal either.
Jeff
Dave Korn wrote:
On 20 February 2008 16:34, Jeff Law wrote:
Paolo Bonzini wrote:
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
I would be looking in combine and simplify
s are going to benefit and how big those benefits might be.
You're going to see this kind of problem raise its ugly head anytime
a port chooses keep operations at a higher level early in the RTL
optimizers, then lower them to their component operations in the
split_all_insns pass.
Jeff
simplification & nop problem, but I'm pretty sure
that can be trivially fixed within local without resorting to running
another forwprop pass after splitting.
Jeff
needed a paradoxical subreg of a hard reg in a
partial integer mode.
Jeff
ndrew's patch. There are some thorny issues in this space and I'm
far from 100% sure that blindly propagating a pointer type into
REG_POINTER is always valid, particularly for compiler generated
temporaries.
Can you describe better what you're seeing in the 2.7.2.2 build that's
causing problems?
Jeff
7.2.2 build that's
causing problems?
Jeff
I am having trouble figuring out exactly what change in the generated
code is causing the failure. The code still compiles but it aborts when
I run the compiled code. In talking to David Anglin I do think it is a
problem with a base reg and inde
ht were identical, but where in one thread of control
you've got %r8/%r19 as the base/index and in the other thread of control
you've got %r19/%r8 as the base/index (they are identical in
functionality on any sane target :-). I fixed that eons ago, but it's
always possible it's reared its ugly head again.
Jeff
3... Hmmm, does 4.3 have POINTER_PLUS_EXPR?
(search tree.def for POINTER_PLUS_EXPR).
Jeff
afoul muck things up in the
way we're seeing, but obviously something isn't working the way we
expect it to :-)
jeff
consistent within a machine mode.
Mohamed, without more details, there's not much we can do to help you.
Jeff
Mohamed Shafi wrote:
On Wed, May 21, 2008 at 1:42 AM, Jeff Law <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote:
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
For the 16 bit target that i am currently porting can have only
positive offsets less than 0x100. (unsi
o
factor that code into reload itself and do away with a significant hunk
of the existing L_R_A implementations.
Jeff
I am writing a new backend for GCC 4.3.1 and have run into the
following issue with GCC 4.3.1's support for the
fixed-point 'long _Fract' type when used in a 'typedef'.
I believe this issue is generic to GCC and not to the backend.
See the (very short) testcase below and the output from GCC.
Basic
r *only*
in libjava? I think you have to weigh the cost of the build of that
library against the number of bugs that it finds.
Happened to me multiple times.
Similarly.
The thing to tackle is to make libjava build more parallel.
I think this applies across the board, including the testsuites.
jeff
well as trimming the set of transformations performed by DOM.
jeff
7;re ripping
too much out of DOM.
When I last looked, the only common case left where the RTL version was
still useful were cases where our tree aliasing code sucked horribly bad
causing DOM/PRE to miss stuff which we later caught in the RTL jump
threading code.
jeff
r the h8 and I'll also take the v850. I'll
be starting them once I nail down this latent bug in the mn103 port.
jeff
degen issues that I'd
like to be able to come back and work on further once we've got the
ports converted to IRA. Having a tag which allows me to checkout and do
comparisons of IRA vs the old allocator would make that process much easier.
Jeff
Ian Lance Taylor wrote:
Jeff Law <[EMAIL PROTECTED]> writes:
Joseph S. Myers wrote:
The new Integrated Register Allocator is now in GCC trunk, and the
old allocator is scheduled for removal on or shortly after 25
September.
[ ... ]
One more note, I would strongly recomm
tch has a positive benefit, but until
we know why, I'd rather wait.
Peter
Agreed. Let's at least have a reasonable explanation of why this is
affecting performance so much. In theory, this kind of change ought to
be in the noise.
Jeff
, nor IRA, nor the backend port in
question. For my specific problem the root cause is actually subreg
lowering.While I could fix my regression by twiddling regmove and/or
the port itself, neither change is actually solving the problem. I
would *STRONGLY* suggest you take the time to do a root cause analysis
or at least avoid installing this bandaid patch.
Jeff
he m68k as
well....
Jeff
Andreas Schwab wrote:
Jeff Law <[EMAIL PROTECTED]> writes:
Andreas Schwab wrote:
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4 /cvs/gcc/li
Andreas Schwab wrote:
Jeff Law <[EMAIL PROTECTED]> writes:
Strange as I didn't trip this at all. I wonder if I've got something
out-of-date in my tree
I've only seen the crash during native testing. Since it's accessing an
array beyond its bounds it
result in build failures in one of the
target libraries.
Presumably you're discussing these with Vlad?
Jeff
might have a useful suggestion or two.
Jeff
nly problem here is we need op0 and op1 to
match which can be accomplished by reloading op1 into r0.
Jeff
class for
reload. ISTM that alternatives which consist solely of CR_REGS ought to
have a '!' prefix in their constraint. Adding that gets me to the same
failure you're seeing building m32cm mallocr.
Jeff
to pass "-Wl,-wrap,_malloc" NOT -Wl,-wrap,malloc".
Where is the leading underscore not getting dealt with
so the wrap functions get invoked.
FWIW I didn't see any h8300-elf results since last year
and wonder if this is a known issue.
I ran into it as well when testing IRA. Hell if I can remember what I
did to fix it though
jeff
-ms is far more meaningful.
jeff
On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
> The key to converting repositories of this size is RAM. 4GB minimum,
> more would be better. git-repack is not multi-threaded. There were a
> few attempts at making it multi-threaded but none were too successful.
> If I remember right, w
On Thu, Dec 06, 2007 at 09:18:39AM -0500, Nicolas Pitre wrote:
> > The downside is that the threading partitions the object space, so the
> > resulting size is not necessarily as small (but I don't know that
> > anybody has done testing on large repos to find out how large the
> > difference is).
On Thu, Dec 06, 2007 at 01:02:58PM -0500, Nicolas Pitre wrote:
> > What is really disappointing is that we saved
> > only about 20% of the time. I didn't sit around watching the stages, but
> > my guess is that we spent a long time in the single threaded "writing
> > objects" stage with a thrashin
On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> > So it is about 5% bigger. What is really disappointing is that we saved
> > only about 20% of the time. I didn't sit around watching the stages, but
> > my guess is that we spent a long time in the single threaded "writing
> > objec
On Thu, Dec 06, 2007 at 10:35:22AM -0800, Linus Torvalds wrote:
> > What is really disappointing is that we saved only about 20% of the
> > time. I didn't sit around watching the stages, but my guess is that we
> > spent a long time in the single threaded "writing objects" stage with a
> > thra
On Fri, Dec 07, 2007 at 01:50:47AM -0500, Jeff King wrote:
> Yes, but balanced by one thread running out of data way earlier than the
> other, and completing the task with only one CPU. I am doing a 4-thread
> test on a quad-CPU right now, and I will also try it with threads=1 and
> t
e the pros and cons of going highly customized vs as
generic as possible. In my opinion Chris & Frank are doing the right thing here
and I would not support reverting or revisiting the decisions they made as part
of this upgrade. Yes it means a slight bit of pain as everyone gets used to the
new system, but it's the right long term direction.
jeff
On Sat, 2020-03-28 at 18:46 +, Maciej W. Rozycki wrote:
> On Fri, 27 Mar 2020, Jeff Law via Gcc wrote:
>
> > As an ex IT guy, I've gone both directions depending on the project I was
> > supporting and certainly see the pros and cons of going highly customized v
> removal of HSAIL offloading in the course of GCC 11 development cycle
> > and I would like to formally deprecate it.
>
> LGTM.
Me too.
Jeff
>
inux-gnu. See
http://gcc.gnu.org/jenkins
The Linux kernel is currently broken, but I suspect it's a transient issue as it
was fine until a week ago -- my tester usually builds the kernel too, but that's
been temporarily disabled for SH targets.
jeff
On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote:
>
>
> On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote:
> > On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote:
> > > Hi
> > >
> > > Over at RTEMS, we were discussing ports to deprecate/obsolete
sonable for AVR as well as the
alternative would be dropping the AVR port.
Jeff
On Wed, 2020-04-22 at 19:52 +0200, Moritz Strübe wrote:
> Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
> > [..] as the
> > alternative would be dropping the AVR port.
>
> Shouldn't that work be sponsored by Microchip (or whoever currently owns
> AVR)? Ardu
On Thu, 2020-04-23 at 07:41 +0530, Senthil Kumar wrote:
> On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote:
> > On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote:
> > > Hi,
> > >
> > > I'm thinking about attempting to do the CC0 transitio
he release process. Ultimately I want to be able to
use
workflows where I can push a button on something that's gone through a CI cycle
or "git am" and not have to go back and fix things *by hand*.
What we do with ChangeLogs is (*&@#$*)(*&^ insane from an efficient workflow
standpoint.
jeff
og entry in the commit
message. It also implies that if we muck one up, then we live with it rather
than going back and rewriting them.
jeff
into a commit message), because they are
> largely not useful and are just make-work. Again IMNSHO -- I know there
> are some folks who read them, but I basically never have since switching
> to git.
I read them less and less. At this point I think I read them to see if a
particular patch in my queue has already been applied. Otherwise I'm using the
git info.
jeff
s generate the files from that).
That's where I lean as well. I could also live with the ChangeLog being
generated by a commit hook and the like. Ultimately it's the manual steps in
applying patches that I want to eliminate from our workflows and the ChangeLog
file consistently results in the need for manual intervention.
jeff
s 1
> FAIL: gcc.c-torture/execute/2112-1.c -O0 (test for excess errors)
> Excess errors:
> xgcc: error: : No such file or directory
> xgcc: error: : No such file or directory
>
Sadly there's no additional output that would help us figure out what went
wrong.
jeff
ils now.
I'd like to flip it to fail for stuff like you've shown above, but we're having
enough trouble keeping things green when only looking at regressions :(
jeff
prove instruction parallelism.
It's a possibility -- it'd need to be tested of course.
I don't think anyone is actively working on improving predication support, so
it's possible that you're going to find more issues. Also note you were looking
at gcc-7.3.0. Work like this should be done on the trunk -- that's what you'll
need to test against and produce patches against.
jeff
On Tue, 2020-06-09 at 20:35 +, sotrdg sotrdg via Gcc wrote:
> What’s wrong with eliminating unused virtual functions in the binary?
Nothing inherently wrong with the concept. But the implementation left a lot to
be desired and I think it was ultimately scrapped as unmaintainable.
jeff
CFG cleanups are typically signaled by
returning TODO_cleanup_cfg at the end of the pass. There should be numerous
examples throughout the GCC source code.
jeff
he CONST_DOUBLE ridiculously high (like 10 insns)
Hi Alan, it's been a long time...
We'd probably need to set the RTL. A variety of things can get in the way of
LICM. For example, I'd expect subregs to be problematical because they can look
like RMW operations.
jeff
On Fri, 2020-06-26 at 01:24 +, Alan Lehotsky wrote:
> > On Jun 25, 2020, at 6:37 PM, Jeff Law wrote:
> >
> > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
> > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit
> > > da
ly going
to
use in a memory dereference, pointer arithmetic, etc. This distinction comes up
in trampolines because they have to pull a pointer out of memory, then use it.
So there's some parts that use ptr_mode and others in Pmode.
Few targets have to deal with this stuff, so it's a bit fragile and not
terribly
well documented.
jeff
. It's worth noting that showing a clobber for the
CC
register even when the bits aren't clobbered is safe.
So I started with that on the H8, even though it did result in some code
efficiency regressions. Then I started pulling apart those patterns when
testing
showed it was worth the effort.
Jeff
er to fix those optimizations?
>
> The post-reload splitter introduces the clobber. The wiki
> suggests that approach if most insns clobber REG_CC, perhaps because of
> the missed optimizations you describe below?
If most patterns set/clobber the flags, then yes, it's slightly better to only
expose them after reload. Various passes that directly grub through RTL rather
than using helpers like single_set will optimize things better.
That's the approach I've taken with the H8 conversion, which is basically
working
at this point and when I have the time I walk through various minor codegen
inefficiences.
Jeff
uses stack-smash protection
>
> (b) a “protected” caller further up the call stack
>
> (c) canary values left around by previous calls, if the canary value
> happens to occupy “dead space” in the current frame
>
> And being on the stack is of course fundamental to the whole scheme.
Yea, but these you have to go and find ;-)
>
Jeff
On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote:
> On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > > The post-reload splitter introduces the clobber. The wiki
> > > suggests
On Wed, 2020-08-26 at 11:18 +, Pip Cet wrote:
> On Mon, Aug 24, 2020 at 6:18 PM Jeff Law wrote:
> > > The post-reload splitter introduces the clobber. The wiki
> > > suggests that approach if most insns clobber REG_CC, perhaps because of
> > > the missed op
On Thu, 2020-08-27 at 16:31 +0530, Senthil Kumar Selvaraj wrote:
> Pip Cet writes:
>
> > On Mon, Aug 24, 2020 at 6:18 PM Jeff Law wrote:
> > > > The post-reload splitter introduces the clobber. The wiki
> > > > suggests that approach if most insns clobber RE
d, then you'll have to hack the sources yourself and build your own
compilers.
Jeff
pEpkey.asc
Description: application/pgp-keys
546b64" is deleted by
> df_remove_dead_eq_notes,
> but r120:DI is not REG_DEAD here, so is it correct here to check insn use and
> find that
> r118:DI is dead then do the delete?
It doesn't matter where the death occurs, any REG_DEAD note will cause
the REG_EQUAL note to be rem
goto bb 12;
>>>> else
>>>> goto bb 17;
>>>>
>>>> bb 20:
>>>> bb 18:
>>>>_27 = d[k_28][m_46];
>>>> if (ivtmp_12 != 0)
>>>> goto bb 19;
>>>> else
>>>> goto bb 21;
>>>>
>>>> Vectorization will do some conversions in this case. We can see
>>>> ‘ _89 = d[k_28][m_46];’ and ‘_27 = d[k_28][m_46];’ are loop invariant
>>>> relative to loop l. We can move ‘d[k_28][m_46]’ to the front of
>>>> ‘if (_59 <= 2)’ to get rid of loading data from memory in both
>>>> branches.
>>>>
>>>> The one at at the end of the loop pipeline can't handle this situation.
>>>> If we move d[k_28][m_46] from loop l to loop m before doing
>>>> vectorization, we can get rid of this situation.
>>> But we can't run every pass after every other. With multiple passes having
>>> ordering issues is inevitable.
>>>
>>> Now - interchange could trigger a region based invariant motion just for
>>> the nest it interchanged. But that doesn't exist right now.
>> With data reference/dependence information in the pass, I think it
>> could be quite straightforward. Didn't realize that we need it
>> before.
> FYI, attachment is a simple fix in loop interchange for the reported
> issue. It's untested, neither for GCC10.
>
> Thanks,
> bin
>> Thanks,
>> bin
>>> Richard.
>>>
>>> linterchange-invariant-dataref-motion.patch
>>>
So it looks like Martin and Richi are working on this right now. I'm
going to drop this from my queue.
jeff
On 11/13/20 6:55 AM, Segher Boessenkool wrote:
> Hi guys,
>
> On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote:
>> On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote:
>>> The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by
>>> df_r
ia Gcc-patches
> ", etc.
>
> ... which occasionally then ends up in Git commit author:
>
> On 2020-11-17T00:15:36+, Jeff Law via Gcc-cvs wrote:
>> https://gcc.gnu.org/g:a019766f996f57e53a8d1a9e72033e1e1487a150
>>
>> commit r11-5068-ga019766f996f57e53a8d1a9e7203
this affects the testsuite, but before going further I would
> like to ask: is this the right direction now? To me it looks a
> little-bit more heavy-handed than the original approach, but maybe it's
> worth it.
It seems a bit heavy-handed. But that's not based on any hard data,
just a sense that we may not want to disable threading this aggressively.
jeff
dwarf32/64 side), is it likely that choice will tend to be adopted
> by GCC? I'd rather not get out of sync, but I expect a bit hard to get
> a conclusion on the GCC side without patches in progress, etc. Got a
> sense of who are the people who would likely be deciders/patch
> approvers for such a naming choice on the GCC side?
Historically debugging options belong under -g on the GCC side and
options that twiddle code generation are under -f. So -gdwarf32
/-gdwarf64 or -g32/-g64 seem like the right options for GCC.
jeff
On 11/23/20 8:03 PM, David Blaikie wrote:
> On Mon, Nov 23, 2020 at 6:59 PM Jeff Law wrote:
>>
>>
>> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
>>> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
>>> wrote:
>>>> On Sat, Nov 21, 2020
eration when using -gdwarf32/64? My preference
>> would be that any option starting with -g enables debuginfo generation
>> and no additional -g is needed to keep things consistent.
> I think we lost that consistency already, I think -gsplit-dwarf has been
> changed quite recently not to imply -g.
>
> That said, for -gdwarf32/64, I think it is more sensible to enable debug
> info than not to.
That works for me.
jeff
se).
>
> I've ran a quick test on an AArch64 native configuration I had handy
> and that fortran test still passed, but don't have the time to look
> into it fully (especially given how I'm not familiar with this area).
Seems like a gcc-12 thing to me.
jeff
On 11/24/20 6:16 AM, Thomas Schwinge wrote:
> Hi!
>
> Ping. Anybody got an opinion on the approach we should take?
Could we set warning_threshold to a value to inhibit this behavior
completely. It seems backwards to me that warnings have this effect.
Jeff
> or whatever command to enable support for draft extensions.
It seems reasonable to me. The worst thing that happens is you find
it's not terribly better than what we're currently doing and we scramble
the process again to work better.
jeff
ring)"
> + }
> + -re "PASSED .*" {
> + pass "pytest $expect_out(0,string)"
> + }
> + }
> +}
>
> as Pytest can provide a reasonable close output:
>
> ===
> short test summary info
>
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
I thought we already approved using python elsewhere (JIT? Analyzer?)
jeff
;s dead code. The peepholes a shouldn't be included by the main .md
file. I've got a partial conversion of those here. Still lots of
cleanup and improvements queued up. Don't let anything H8 related get
in the way :-) If it breaks, I'll take care of it.
jeff
e assignment should be for "gcc" since presumably the final
goal is to get the Rust front-end integrated into GCC, right?
jeff
www.gnu.org.
If it's a problem with gcc.gnu.org, then the details should be sent to
overse...@gcc.gnu.org
Jeff
On 1/4/21 10:40 AM, Salah Mosbah wrote:
> Hi Jeff,
>
> Does gnu.org <http://gnu.org/> has a bug bounty program or reporting
> bugs reward policy?
I have no idea.
jeff
>
t a way to scan a file
> in the build directory, but I have a mild amount of hope that someone
> has solved this before. Thanks for any help!
Yea, I don't see any indication this has ever been done before. I'm a
bit surprised that ./ doesn't work since gengtype runs from
the build directory and has to reference things in the source directory
and ./ would seem to naturally reference the build directory
Jeff
>>> Last time I assigned the copyright paper, I noticed that the paper
>>> mentioned the project name. But Rust-GCC hasn't been recognized by GCC
>>> community yet, so I'm not sure if it's the correct time to consider this
>>> issue.
>>>
>&
str" points.
>
> GCC is wrong. It is unable to figure out how far into the buffer
> "def_str" can point.
Can you get a .i file, command line and file a report. It'd be appreciated.
jeff
On 1/24/21 6:04 PM, zheng via Gcc wrote:
> I'd like to report a typo on page
> https://gcc.gnu.org/onlinedocs/gfortran/ANINT.html#ANINT . In the last table
> on this webpage, AINT should be ANINT.
Thanks. This is what I pushed to the trunk to fix the typo:
I am pleased to announce that the GCC Steering Committee has appointed
David Malcolm as maintainer of the GCC static analyzer.
David, please update your listing in the MAINTAINERS file.
Thanks,
Jeff
I am pleased to announce that the GCC Steering Committee has appointed
Dimitar Dimitrov as maintainer of the TI PRU port in GCC.
Dimitar, please update your listing in the MAINTAINERS file. Sorry it's
taken so long to make this happen. It just kept slipping off my radar.
Thanks,
Jeff
sures.
To those on the receiving end, I'm terribly sorry that some people can't
disagree in a civil manner and I hope their behavior does not discourage
you from continuing to contribute to GCC.
Jeff
ering
committee or Tachyum, I also fully support Nathan's request.
jeff
It's more historical than anything. The majority of members on the
committee were there since its inception back in the late 90s. We are
looking at how to increase diversity on the committee, but that's a
separate and distinct issue from removal of RMS.
Jeff
name is a problem, rename the projects to be simply "GCC",
"Glibc", "GDB" etc without being an initialism.
Speaking strictly for myself, that works for me as well and I'd support
such a proposal.
jeff
7;s a baby step towards
eventually deleting it.
Agreed. I'd bet AIX is the outlier here and that most, if not all,
other ports that may currently be stabs-by-default can switch to
dwarf-by-default with no significant fallout. So we fix everything we
can while we wait for AIX to move forward.
jeff
working through.
An EGCS-like split like we had in the late 90s is, IMHO, a definite
possibility here and judging the mood of the GCC development community
is vital to guiding decisions we need to make as a project.
Jeff
. Without strong support from the development community splits li
can't yet.
Jeff
On 4/13/2021 10:52 AM, Thomas Koenig wrote:
On 13.04.21 16:40, Jeff Law via Gcc wrote:
An EGCS-like split like we had in the late 90s is, IMHO, a definite
possibility here
Such a move would, in all probability, leave both parts of the split
GCC with too few developers to compete against
On 4/13/2021 11:32 AM, Thomas Koenig via Gcc wrote:
On 13.04.21 19:19, Jeff Law via Gcc wrote:
I'm not sure there'll be that much of a community split. Based on
what I've seen *so far* it'd be less of a split than we had with
EGCS. But that's precisely why
ts that have been made I
don't think they've risen to the level of wanting/needing to ban those
individuals from posting.
Jeff
On 4/14/2021 6:08 AM, Richard Biener via Gcc wrote:
On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
wrote:
N.B. Jeff is no longer @redhat.com so I've changed the CC
On Wed, 14 Apr 2021 at 11:03, Thomas Koenig
wrote:
- All gfortran developers move to the new branch.
1201 - 1300 of 1421 matches
Mail list logo
