On Wed, Aug 23, 2023 at 09:16:08PM +0200, Harald Anlauf via Fortran wrote:
>
> here's a simple patch for a very old PR that suggests a more helpful
> error message for an automatic object in a COMMON. The patch also
> suppresses the less helpful old error message after the new one has
> been
On Thu, Jul 27, 2023 at 09:39:53PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> when passing a character actual argument to an assumed-type dummy
> (TYPE(*)), we should not pass the character length for that argument,
> as otherwise other hidden arguments that are passed as part of the
On Wed, Jul 26, 2023 at 09:33:22PM +0200, Harald Anlauf via Fortran wrote:
> I am going to get the brown bag for today... This is now the right
> corrected patch.
>
> Sorry for all the noise!
>
Third times a charm (as the saying goes).
Looks good to me. Thanks for the patch.
--
Steve
On Sun, Jul 16, 2023 at 10:30:59PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> some intrinsics may return character results with the same
> characteristics as their first argument (e.g. PACK, MINVAL, ...).
> If the first argument is of deferred-length, we need to derive
> the
On Tue, Jul 11, 2023 at 09:39:31PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> for intrinsic procedures we derive the typespec of the formal symbol
> attributes from the actual arguments. This can have an undesired
> effect for character actual arguments, as the argument passing
>
On Sat, Jul 08, 2023 at 03:23:31PM +0100, Paul Richard Thomas wrote:
> The attached patch incorporates two of Steve's "Orphaned Patches" -
> https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html
Thanks Paul for picking up the pieces I left behind.
A few nits below.
> They have in common
On Tue, Jul 04, 2023 at 11:26:26AM +0200, Mikael Morin wrote:
> Le 04/07/2023 à 01:56, Steve Kargl a écrit :
> > On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote:
> > >
> > > Indeed, this is a nice demonstration.
> > >
> > > While playing, I was wondering whether the
On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote:
>
> Indeed, this is a nice demonstration.
>
> While playing, I was wondering whether the following code is conforming:
>
> program p
> call s ((1))
> contains
> subroutine s (x)
> integer :: x
> x = 42
>
On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran
wrote:
> I have finished my testing, and updated my patch and relevant Changelogs. I
> added 4 new tests and all the existing tests in the current testsuite
> for gfortran passed or failed as expected. Do I need to attach
On Wed, Jun 21, 2023 at 05:12:22PM +0100, Paul Richard Thomas wrote:
> Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
>
> Thanks for the help and the review Harald. Thanks to Steve too for
> picking up Neil Carlson's bugs.
>
It's only natural. You fix bugs in a long desired
On Sat, Jun 17, 2023 at 10:14:43AM +0100, Paul Richard Thomas via Fortran wrote:
>
> PS This leaves 89645 and 99065 as the only real blockers to PR87477.
>
Hate to be the bearer of bad news, but Neil Carlson has added
a couple PRs about associate that may not be listed in 87447.
On Mon, Jun 12, 2023 at 11:12:45PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached - actually rather small - patch is the result of a
> rather intensive session with Mikael in an attempt to fix the
> situation that we did not create proper temporaries when passing
>
If anyone is so inclined, the patches in the following
PR's can be committed and the PR closed. These are
patches for gfortran.
69101 91960 95613 99139 99368 99798
100607 103795 103796 104626 105594 101967
101951 104649 106050 106500 107266 107406
107596
This is an opportunity for
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote:
> Hi FX,
>
> On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > 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
>
On Tue, Jun 06, 2023 at 09:35:26PM +0200, FX Coudert wrote:
> Hi Steve,
>
> I am not subscribed to the list (too little time, sadly), please keep me in
> CC of your responses.
>
Unfortunately, fx is using a gmail account. Emails from my
system to @gmail.com users are routinely and silently
On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote:
>
> Scratch 2. Another scan shows that you moduled the Fortran
s/you moduled/you added to
> module where interface are built. This will automatically
s/interface/interfaces
> catch and report the items in 2.
Complete
On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote:
> On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> > Hi,
> >
> > This patch adds four IEEE functions from the Fortran 2018
> > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> > and
On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> Hi,
>
> This patch adds four IEEE functions from the Fortran 2018
> standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> and IEEE_MAX_NUM_MAG.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32
> and 64-bit. OK to
On Sat, Jun 03, 2023 at 07:50:19AM +0200, Thomas Koenig via Fortran wrote:
> Hi Paul,
>
> > I propose to backport
> > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
> > soon.
>
> Is this something that we usually do?
>
> While finalization was basically broken before, some
On Sun, May 14, 2023 at 10:04:25PM +0200, Harald Anlauf via Fortran wrote:
>
> Fortran allows functions in variable definition contexts when the
> result variable is a pointer. We already handle this for the
> non-CLASS case (in 11+), but the logic that checks the pointer
> attribute was looking
On Tue, May 09, 2023 at 08:35:00PM +0200, Harald Anlauf wrote:
> On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote:
> >
> > It's not needed. See above. gfc_state_stack->previous is referenced
> > a few lines above the if-stmt. The reference will segfault if
On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
> > this testcase checked that finalizable derived types could
6 0
>
>
> So there seems to be a consensus that "," and ";" must be rejected,
> and tab is accepted (makes real sense), but already the termination
> character "/" and comment character "!" are treated differently.
> And how do we want to tre
On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote:
> The attached patch adds a check for the invalid comma and emits a runtime
> error if -std=f95,f2003,f2018 are specified at compile time.
>
> Attached patch includes a new test case.
>
> Regression tested on x86_64-linux-gnu.
On Sat, Apr 22, 2023 at 08:43:53PM +0200, Mikael Morin wrote:
> >
> OK, let's go with your patch as originally submitted then.
>
Mikael, thanks for looking at the original patch and
suggested an alternative location to attempt to fix
the bug. Halrald, thanks for following up on Mikael's
On Sat, Apr 22, 2023 at 05:17:30PM +0200, Mikael Morin wrote:
> Le 22/04/2023 à 15:52, Steve Kargl a écrit :
> > On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote:
> > >
> > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
> > > > Dear all,
> > > >
> > > > Fortran 2018
On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote:
>
> Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
> > Dear all,
> >
> > Fortran 2018 added a clarification that the *result* of a function
> > whose result *variable* has the ALLOCATABLE attribute is a *value*
> > that
On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via Fortran
wrote:
> Ping!
>
> Harald fixed the leak in set_exponent in the meantime.
> As stated in the cover-letter, it was bootstrapped and regtested
> without regression on x86_64-foo-linux.
>
> I consider it obvious, but
On Fri, Apr 14, 2023 at 09:49:22PM +0200, Harald Anlauf wrote:
>
> On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote:
> > I was wondering about the difference between set_exponent()
> > and scale(), and found that set_exponent() talks about IEEE
> > values while scale()
On Fri, Apr 14, 2023 at 12:33:18PM -0700, Steve Kargl via Fortran wrote:
>
>If X is an IEEE NaN, the result is the same NaN.
>
A better testcase as gfortran will quiet a NaN on assignment.
program foo
integer i
equivalence(i,y)
i = int(z'7FC0BEEF',4) ! Add payload to NaN.
On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote:
>
> the compile-time simplification of intrinsic SET_EXPONENT was
> broken since the early days of gfortran for argument X < 1
> (including negative X) and for I < 0. I identified and fixed
> several issues in the
On Thu, Mar 30, 2023 at 07:39:55PM +0200, Thomas Koenig via Fortran wrote:
> Hi Andrew,
>
> > "long long". This was just an oversight and a missing check.
> >
> > Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
>
> Thanks!
>
> I think this one is obvious enough that it
On Fri, Mar 10, 2023 at 07:01:29PM +0100, Richard Biener via Fortran wrote:
>
>
> > Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran
> > :
> >
> > Hello world, here's the patch that was discussed.
> >
> > Regression-tested. OK for trunk?
> >
> > Since this appeared only in gcc13, I
On Tue, Mar 07, 2023 at 03:58:32PM +0100, Thomas Koenig via Fortran wrote:
> Paul,
>
> first of all, thank you very much indeed for the hard work you put into
> this! This is a great step for gfortran.
Ditto**2
> > I can hurry this along to get the patch
> > into 13-branch or I can wait until
On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote:
> Hello,
>
> Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
> > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> > > - if (attr->class_ok)
> > > -/* Class container has already been built. */
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> - if (attr->class_ok)
> -/* Class container has already been built. */
> + /* Class container has already been built with same name. */
> + if (attr->class_ok
> + && ts->u.derived->components->attr.dimension
On Thu, Mar 02, 2023 at 01:07:32AM +0100, Bernhard Reutner-Fischer wrote:
> On Wed, 1 Mar 2023 07:39:40 -0800
> Steve Kargl via Gcc-patches wrote:
>
> > In fact, Hollerith should be hidden behind a -fallow-hollerith
> > option and added to -std=legacy.
>
> While i'd
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
> libgfortran/caf/single.c |6 ++
> libgfortran/io/async.c |6 ++
> libgfortran/io/format.c |3 +--
> libgfortran/io/transfer.c|6 ++
> libgfortran/io/unix.c
On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an
On Mon, Feb 27, 2023 at 09:54:38PM +0100, Harald Anlauf via Fortran wrote:
>
> as found by the reporter, the result of the intrinsic IBITS
> differed from other compilers (e.g. Intel, NAG) for the corner
> case that the LEN argument was equal to BIT_SIZE(I), which is
> explicitly allowed by the
On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote:
> I wonder if a relatively easy starting point would be enabling the
> declaration of do concurrent construct variables:
>
> do concurrent (integer :: i = 1:n)
>
> It’s a minor convenience and less exciting than adding locality
On Tue, Feb 21, 2023 at 10:18:58PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached simple patch detects and rejects CHARACTER components
> of derived types whose length specification is non-integer.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> This PR is also
On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote:
> On 17.02.23 17:27, Steve Kargl wrote:
> > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> > > OK for mainline?
> > Short version: no.
>
> Would you mind to write a reasoning beyond only a single word?
>
> > >
On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> Short version:
>
> This fixes potential and real bugs related to 'len=:' character variables
> as for the length/byte size an old/saved expression is used instead of
> the current value. - That's fine but not for allocatable/pointer
On Wed, Feb 15, 2023 at 10:28:00PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> I've committed the attached obvious and trivial patch for a NULL
> pointer dereference on behalf of Steve and after regtesting on
> x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c
On Fri, Feb 03, 2023 at 08:03:36PM +0100, Jakub Jelinek via Fortran wrote:
> Hi!
>
> The first testcase in the PR (which I haven't included in the patch because
> it is unclear to me if it is supposed to be valid or not) ICEs since extra
> hash table checking has been added recently. The problem
On Sat, Jan 28, 2023 at 06:07:50PM +0100, Harald Anlauf via Fortran wrote:
>
> a USE associated symbol shall not appear in a COMMON block
> (F2018:C8121) and needs to be diagnosed. The patch is
> fairly obvious.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> As the PR is marked as
On Wed, Jan 25, 2023 at 10:59:22PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch fixes two issues: first it addresses a NULL pointer
> dereference on invalid input, triggered by the provided testcase.
>
> Second, while analyzing the context of the affected code, I
On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote:
>
> the code in the PR demonstrates that dependency checking in the
> frontend optimization was not recovering well from invalid code,
> leading to a NULL pointer dereference. An easy and really obvious
> fix.
>
>
On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote:
>
> we did not check array element triplets for validity strictly enough
> (i.e. defensively in the case of invalid code), so we could encounter
> non-integer constant expressions that were passed to mpz_get_si.
>
> The
On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into
On Thu, Dec 22, 2022 at 10:13:04PM +0100, Harald Anlauf via Fortran wrote:
>
> the attached patch adds a check for statement function bodies for
> invalid uses of dummy arguments. This fixes an ICE-on invalid.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
Yes. Thanks for the
On Tue, Dec 20, 2022 at 09:40:23PM +0100, Harald Anlauf via Fortran wrote:
>
> we obviously forgot to extend the C interoperability check of the
> type of function results to CLASS variables and thus did not reject
> them. Wrong code could lead to an ICE, see testcase by Gerhard.
>
> Regtested
On Mon, Dec 12, 2022 at 08:49:50PM +0100, Harald Anlauf via Fortran wrote:
>
> Committed as r13-4623-gcf5327b89ab610.
>
To be clear, I have no problems with this commit.
But, just a FYI, there is gfc_peek_ascii_char(),
which allows you to look at the next character
without having to keep track
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch improves checking of array specs in two ways:
> - bad assumed size array spec
> - a bad first array element spec may already trigger an error,
> leading to a more consistent behavior
>
On Sat, Dec 10, 2022 at 10:14:06PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> we should not try to simplify ISHFTC if the SIZE argument
> is known to be outside the allowed range. It's better to
> generate an error by terminating the simplification.
>
> Regtested on
On Thu, Dec 08, 2022 at 10:59:42PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> a fairly obvious, or rather trivial fix that appeared while
> analyzing another pr and that can be treated independently:
> reject duplicate CONTIGUOUS attributes.
>
> (Intel and NAG reject this, Cray
On Wed, Dec 07, 2022 at 09:57:20PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> we need to be careful about zero-sized arrays in arithmetic
> reductions (unary & binary), as we otherwise may hit a NULL
> pointer dereference on valid code.
>
> The actual fix is straightforward, see
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote:
>
> @Steve: please close PR if you think everything is ok.
>
Thanks. I'll close the pr.
--
Steve
On Mon, Apr 25, 2022 at 09:26:26AM +0200, Richard Biener wrote:
> On Sat, Apr 23, 2022 at 8:40 PM Steve Kargl via Gcc-patches
> wrote:
> >
> > ping.
>
> I have tested the patch on x86_64-linux and pushed it.
>
Thanks.
--
Steve
ping.
On Fri, Apr 15, 2022 at 09:23:43AM -0700, Steve Kargl wrote:
> Can someone, anyone, please commit the attach patch, which is
> also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
> where one can read the audit trail. The original patch was
> submitted 2 years ago, and
Can someone, anyone, please commit the attach patch, which is
also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
where one can read the audit trail. The original patch was
submitted 2 years ago, and required manual intervention due to
the recent *.c to *.cc rename.
Back story:
On Sun, Oct 24, 2021 at 09:00:52PM +0200, Harald Anlauf wrote:
> Dear Fortranners, Steve,
>
> I've created PR 102917 for tracking this issue and packaged
> the attached patch.
>
> Regtested on x86_64-pc-linux-gnu. OK mainline?
>
Thanks for picking this up. The patch looks good to me,
but
On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote:
>
> I was asked to backport the patch for pr98301 to gcc-11. The patches have
> been in mainline for two weeks without any defect reports I could fined. The
> patch for mainline applied with a bit of shift cleanly.
>
> Regstested
On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote:
> Ping, ping!
>
> Please find attached a rebased version of the patch for the RANDOM_INIT issue
> with coarray Fortran. Nothing changed to the previous version, just rebased to
> current master.
>
> Regtested fine on
On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> Ping!
>
> Ok for trunk?
>
> I have looked at other patches, but none was patching any location I have
> worked on previously. Therefore I can't return the favor of reviewing any
> currently open patches and have to ask for
On Sat, Mar 27, 2021 at 03:11:05PM -0700, Jerry DeLisle wrote:
> Pushed:
>
> To git+ssh://gcc.gnu.org/git/gcc.git
> 651684b462f..01685676a93 master -> master
>
> Author: Steve Kargl
> Date: Sat Mar 27 15:02:16 2021 -0700
>
> fortran: Fix off-by-one in buffer sizes.
>
>
This patch fixes an off-by-one buffer overflow issue.
Please commit.
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 8a96243e80d..3d449ae17fe 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -124,8 +124,10 @@ gfc_basic_typename (bt type)
const char *
gfc_typename
On Tue, Jan 05, 2021 at 11:26:24AM -0700, Jeff Law wrote:
>
>
> On 1/4/21 3:28 PM, Steve Kargl wrote:
> > On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote:
> >> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
> >>> Can someone, anyone, please
On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote:
>
> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
> > Can someone, anyone, please commit the following trivially patch?
> > gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
> Why wil
Can someone, anyone, please commit the following trivially patch?
gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
diff --git a/gcc/testsuite/gfortran.dg/dec_math.f90
b/gcc/testsuite/gfortran.dg/dec_math.f90
index cc141aba412..d95233a5169 100644
---
On Wed, Aug 05, 2020 at 03:59:38PM +0100, Paul Richard Thomas wrote:
> The attached patch builds on a draft posted by Steve Kargl. I have left the
> gcc_assert in place just in case my imagination was too limited to generate
> an ICE.
>
> Regtests OK on FC31/x86_64 - OK for trunk?
>
Looks OK to
On Mon, Apr 06, 2020 at 04:10:24PM -0400, Fritz Reese wrote:
> On Sat, Apr 4, 2020 at 2:58 PM Steve Kargl via Fortran
> wrote:
> >
> > This patch fixes the ICE found in PR93686.
> >
> >
> > Index: gcc/fortran/decl.c
> > ===
> > ---
This one is a little bit wierd for me. It seems AS_DEFERRED
is overloaded and things get fixed up later. In array.c
one finds match_array_element_spec(), which set AS_DEFERRED
if the matchers sees (:) regardless of how the array is used.
Then in gfc_set_array_spec(), the array spec is attached
See
https://stackoverflow.com/questions/60972134/whats-wrong-with-the-following-fortran-code-gfortran-dtio-dummy-argument-at
Is A(:) a deferred-shape array or an assumed-shape array? The
answer of course depends on context.
This patch fixes the issue found at the above URL.
Index:
On Sat, Mar 28, 2020 at 08:10:38AM +0100, Tobias Burnus wrote:
> Two remarks:
>
> * As the file trigd_lib.inc is shared between libgfortran
> and gcc/fortran, I wonder whether it should be placed
> under include/ (under the GCC toplevel directroy)
The original name and location were chosen
77 matches
Mail list logo
