Dear all,
as correctly analyzed by Jerry, the code for checking the consistency
of character lengths in array constructors did not properly initialize
the auxiliary variable used in "bounds checking". The attached patch
resolves this by initializing this auxiliary variable with a length
obtained
Hi Paul,
On 9/15/23 11:13, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
The statement,
in array_bound_check_elemental is redundant since the call is
determined by a more restrictive condition.
+ if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS))
+return;
yeah, this was left over
Dear all,
array bounds checking was missing a few cases of array sections
that are handled via gfc_conv_expr_descriptor. Bounds checking
was done for the dimensions with ranges, but not for elemental
dimensions.
The attached patch implements that and fixes pr30802 and also
pr97039, maybe a few
Hi Mikael,
On 9/11/23 14:38, Mikael Morin via Gcc-patches wrote:
Hello,
this fixes a memory management issue in the fortran frontend.
I have included the (reduced) testcase from the PR, even if it wasn't failing
here on x86_64 with the test harness.
Tested on x86_64-pc-linux-gnu and manually
Am 08.09.23 um 12:04 schrieb Mikael Morin via Gcc-patches:
Hello,
this avoids some redundant work in the symbol deletion code, which is
used a lot by the parser to cancel statements that fail to match in the
end.
I haven't tried to measure the performance effect, if any, on a pathological
Hi Mikael,
On 9/1/23 10:41, Mikael Morin via Gcc-patches wrote:
Le 31/08/2023 à 22:42, Harald Anlauf via Fortran a écrit :
Dear all,
gfortran's array bounds-checking code does a mostly reasonable
job for array sections in expressions and assignments, but
forgot the case that (rank-1)
Dear all,
gfortran's array bounds-checking code does a mostly reasonable
job for array sections in expressions and assignments, but
forgot the case that (rank-1) expressions can involve array
constructors, which have a shape ;-)
The attached patch walks over the loops generated by the
Hi Mikael,
On 8/27/23 21:22, Mikael Morin via Gcc-patches wrote:
Hello,
this fixes an old error-recovery bug.
Tested on x86_64-pc-linux-gnu.
OK for master?
I have only a minor comment:
+/* Free the leading members of the gfc_interface linked list given in INTR
+ up to the END element
Dear all,
the attached patch adds stricter bounds-checking for DATA statements
with implied-do. I chose to allow overindexing (for arrays of rank
greater than 1) for -std=legacy, as there might be codes in the wild
that need this (and this is accepted by some other compilers, while
NAG is strict
Dear all,
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 emitted.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Hi Paul,
Am 22.08.23 um 08:32 schrieb Paul Richard Thomas via Gcc-patches:
Hi Harald,
It all looks good to me and does indeed make the code clearer. OK for trunk.
Thanks for the patch.
thanks for the review!
I was shocked to find that there are 217 older bugs than 49588. Does
anybody test
Dear all,
the attached patch implements vector sections in DATA statements.
The implementation is simpler than the size of the patch suggests,
as part of changes try to clean up the existing code to make it
easier to understand, as ordinary sections (start:end:stride)
and vector sections may
Dear all,
the attached simple patch fixes a memleak in the frontend when a
character literal is passed to a character,value dummy of a bind(c)
procedure, by relying on gfc_replace_expr to do the cleanup.
(This can be tested e.g. with gfortran.dg/bind_c_usage_13.f03
and running f951 under
Hi Martin,
Am 14.08.23 um 19:39 schrieb Martin Jambor:
Hello,
this patch addresses an issue uncovered by the undefined behavior
sanitizer. In function resolve_structure_cons in resolve.cc there is
a test starting with:
if (cons->expr->ts.type == BT_CHARACTER && comp->ts.u.cl
Hi Mikael,
Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches:
Hello,
I propose with this patchset a fix for the test value_9.f90 which has been
failing on 32 bits powerpc since it was added a few weeks back (see PR110360
and PR110419).
The problem is an argument type mismatch between
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
gfortran ABI will not be interpreted correctly. This is in line
with the current
I am going to get the brown bag for today... This is now the right
corrected patch.
Sorry for all the noise!
Harald
Am 26.07.23 um 21:17 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the original submission missed the adjustments of the expected
patterns of 2 tests. This is corrected
Dear all,
the original submission missed the adjustments of the expected
patterns of 2 tests. This is corrected in the new attachments.
Am 26.07.23 um 21:10 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the attached patch fixes an ICE-on-invalid after use of strings of
non-constant length
Dear all,
the attached patch fixes an ICE-on-invalid after use of strings of
non-constant length in DATA statements.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b5b13db48c169ef18a8b75739bd4f22f9fd5654e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Jul
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 character length of the result from the first argument, like
in the assumed-length case, but we
Hi Mikael,
Am 11.07.23 um 12:32 schrieb Mikael Morin via Gcc-patches:
Hello,
this is a followup to Harald's recent work [1] on the evaluation order
of arguments, when one of them is passed to an intent(out) allocatable
dummy and is deallocated before the call.
This extends Harald's fix to
Hi Andre,
I forgot to answer your other question:
Am 11.07.23 um 18:23 schrieb Andre Vehreschild via Gcc-patches:
I tried to use a pdt within a derived type as a component. Is that not allowed
by the standard? I know, I could hunt in the standard for it, but when someone
knows out of his head,
Hi Andre,
this looks much better now!
This looks mostly good to me, except for a typo in the testcase:
+ if (p% ci% len /= 42) stop 4
There is no component "ci", only "c". The testsuite would fail.
Regarding the memleak: replacing
// TODO: Fix leaking expr tmp, when simplify is done
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
conventions differ for deferred-length (length is passed by reference)
and otherwise
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter ::
Hi Paul,
thanks for taking this.
I have just a minor comment regards coding style:
+ if (tmp
+ && tmp->attr.generic
+ && (tmp = gfc_find_dt_in_generic (tmp)))
+ {
+ if (tmp->attr.flavor == FL_DERIVED)
Hi Mikael,
Am 08.07.23 um 14:07 schrieb Mikael Morin:
here is what I'm finally coming to. This patch fixes my example, but is
otherwise untested.
The patch has grown enough that I'm tempted to fix my example
separately, in its own commit.
alright. I've interpreted this as a green light for
Dear all,
I intend to commit the attached obvious patch within 24h unless
someone objects. gfc_compare_expr() did not handle the case of
complex constants, which may be compared for equality. This
case is needed in the simplification of the FINDLOC intrinsic.
Regtested on x86_64-pc-linux-gnu.
Hi Mikael,
Am 07.07.23 um 14:21 schrieb Mikael Morin:
I'm attaching what I have (lightly) tested so far, which doesn't work.
It seems gfc_conv_class_to_class reevaluates part of the original
expression, which is not correct after deallocation.
this looks much more elegant than my attempt that
Hi Mikael,
Am 05.07.23 um 16:54 schrieb Mikael Morin:
Here is an example, admittedly artificial. Fails with the above change,
but fails with master as well.
program p
implicit none
type t
integer :: i
end type t
type u
class(t), allocatable :: ta(:)
end type u
Hi Mikael, all,
I think I've found it: there is a call to gfc_conv_class_to_class
that - according to a comment - does a repackaging to a class array.
Deferring that repackaging along with the deallocation not only fixes
the regression, but also the cases I tested.
Attached is a "sneak
Hi Mikael,
Am 03.07.23 um 13:46 schrieb Mikael Morin:
A few thing to double check below.
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 30946ba3f63..16e8f037cfc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
(...)
@@ -6117,6 +6118,33 @@
Dear all,
the attached patch fixes a long-standing issue with the
order of evaluation of procedure argument expressions and
deallocation of allocatable actual arguments passed to
allocatable dummies with intent(out) attribute.
It is based on an initial patch by Steve, handles issues
pointed out
Hi Alex,
welcome to the gfortran community. It is great that you are trying
to get actively involved.
You already did quite a few things right: patches shall be sent to
the gcc-patches ML, but Fortran reviewers usually notice them only
where they are copied to the fortran ML.
There are some
Dear all,
the previous patches to this PR unfortunately caused a regression,
seen on Power big-endian systems/-m32 (pr110419), and while trying
to investigate on x86 also showed a regression (ICE) on cases that
were not covered in the testsuite before.
The original fix did not properly handle
Hi Paul,
this is much better now.
I have only a minor comment left: in the calculation of the
size of a character string you are using an intermediate
gfc_array_index_type, whereas I have learned to use
gfc_charlen_type_node now, which seems like the natural
type here.
OK for trunk, and thanks
Hi Paul!
On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote:
I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
extra blank line, introduced by my last patch. I played safe and went
exclusively for class functions with attr.class_pointer set on the
grounds that
Dear all,
the first part of the patch came with a testcase that also exercised
code for constant string arguments, which was not touched by that patch
but seems to have caused runtime failures on big-endian platforms
(e.g. Power-* BE) for all optimization levels, and on x86 / -m32
at -O1 and
Dear all,
gfortran's ABI specifies that actual arguments to CHARACTER(LEN=1),VALUE
dummy arguments are passed by value in the scalar case. That did work
for constant strings being passed, but not in several other cases, where
pointers were passed, resulting in subsequent random junk...
The
Hi Paul,
while I only had a minor question regarding gfc_is_ptr_fcn(),
can you still try to enlighten me why that second part
was necessary? (I believed it to be redundant and may have
overlooked the obvious.)
Cheers,
Harald
On 6/21/23 18:12, Paul Richard Thomas via Gcc-patches wrote:
Hi Paul,
On 6/20/23 12:54, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did
Hi Paul,
On 6/17/23 11:14, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
The attached patch is amply described by the comments and the
changelog. It also includes the fix for the memory leak in decl.cc, as
promised some days ago.
OK for trunk?
I hate to say it, but you forgot to add
Hi Steve,
On 6/13/23 19:45, Steve Kargl via Gcc-patches wrote:
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
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
zero-sized array arguments to procedures. When the dummy argument
was declared as OPTIONAL, in
Hi FX,
Am 06.06.23 um 21:29 schrieb FX Coudert via Gcc-patches:
Hi,
This is a repost of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html
which never really got green light, but I stopped pushing because stage 1 was
closing and I was out of time.
I just
On 6/8/23 09:46, Mikael Morin wrote:
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but
Hi Paul!
On 6/7/23 18:10, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the
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
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously
Hi FX,
On 6/6/23 15:19, FX via Gcc-patches 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
commit?
FX
it would
Hi Paul,
On 6/3/23 07:48, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
It looks good to me. Thanks to you and Steve for the fix. I suggest
that it is such and obvious one that it deserved back-porting.
alright, I'll check how far this makes sense.
Cheers,
Harald
Cheers
Paul
On
Hi Paul, all,
On 6/3/23 15:16, Paul Richard Thomas via Gcc-patches wrote:
Hi Thomas,
I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.
IMHO it is not only distros,
Dear all,
I've committed that attached simple patch on behalf of Steve
after discussion in the PR and regtesting on x86_64-pc-linux-gnu.
It fixes a duplicate error message and an ICE.
Pushed as r14-1505-gfae09dfc0e6bf4cfe35d817558827aea78c6426f .
Thanks,
Harald
From
Hi Mikael,
Am 01.06.23 um 22:33 schrieb Mikael Morin:
Hello,
Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use the
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use the existing error paths in
gfc_match_kind_spec and error return from gfc_match_decl_type_spec.
I'm still posting it here in case I
Dear all,
the attached almost obvious patch fixes an ICE on invalid that may
occur when we attempt to simplify an initialization expression with
SIZE for an out-of-range DIM argument. Returning gfc_bad_expr
allows for a more graceful error recovery.
Regtested on x86_64-pc-linux-gnu. OK for
Dear all,
checking and simplification of the RESHAPE intrinsic could fail in
various ways for sufficiently complicated arguments, like array
constructors. Debugging revealed that in these cases we determined
that the array arguments were constant but we did not properly
simplify and expand the
Dear all,
the attached patch is neat, because it fixes a bug by removing code ;-)
When generating the initializer for a parameter array, we excepted
the case of size 0, which however prevented the detection of array
bounds violations and lead to ICEs in various places. The solution
which
Dear all,
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 in the wrong place for the CLASS case.
Once found, the fix is simple and
On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote:
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
Hi Paul,
On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
This problem caused the gimplifier failure because the reference chain
ending in an inquiry_len still retained a full array reference. This had
already been corrected for deferred character lengths but the fix extends
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 not be specified
in a submodule. I have replaced the original test with a test of
Steve,
On 5/8/23 02:13, Steve Kargl via Gcc-patches wrote:
Harald,
Thanks for keeping us honest. I didn't check what other
separators might cause a problem.
After 2 decades of working on gfortran, I've come to conclusion
that -std=f2018 should be the default. When f2023 is ratified,
the
Hi Jerry,
I've made a small compiler survey how they behave on namelist read
from an internal unit when:
1.) there is a single input line of the type
"" // testchar // " n = 666/"
2.) the input spans 2 lines split after the testchar
3.) same as 2.) but first line right-adjusted
See attached
Hi Jerry, Steve,
I think I have to pour a little water into the wine.
The patch fixes the reported issue only for a comma after
the namelist name, but we still accept a few other illegal
characters, e.g. ';', because:
#define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
Hi Mikael,
On 5/5/23 13:43, Mikael Morin wrote:
Hello,
Le 01/05/2023 à 18:29, Harald Anlauf via Fortran a écrit :
+/* Given two expressions, check that their rank is conformable, i.e.
either
+ both have the same rank or at least one is a scalar. */
+
+bool
+gfc_op_rank_conformable
Dear all,
the attached patch is mostly self-explaining: we mishandled the
overloading of intrinsic binary operators in the case the actual
operands were of intrinsic numeric type and the ranks of the
operands were not conformable, i.e. both were of non-zero and
different ranks. In that case the
Hi Paul,
Am 22.04.23 um 10:32 schrieb Paul Richard Thomas via Gcc-patches:
Hi All,
As usual, I received a string of emails on retargeting for PRs for which I
was either responsible or was on the cc list. This time I decided to take a
look at them all, in order to reward the tireless efforts of
Hi Mikael,
Am 22.04.23 um 11:25 schrieb Mikael Morin:
Hello,
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 itself does not have
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE attribute is a *value*
that itself does not have the ALLOCATABLE attribute.
For those interested: there was a thread on the J3 mailing list
some time ago (for links see the
On 4/19/23 17:14, Bernhard Reutner-Fischer via Gcc-patches wrote:
On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran wrote:
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run in a location such
that a path in an error message showing in the tree-dump might
have accidentally matched "free" or "data", respectively.
For the testcase gfortran.dg/reshape_8.f90
Hi Steve,
On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote:
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 <
[Now with subject added...]
Dear all,
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 implementation. The testcase explores
argument space
Dear all,
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 implementation. The testcase explores
argument space comparing compile-time and
Hi Paul,
On 4/14/23 10:18, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
The fix was trivial. An updated patch and testcase are attached.
great, this works, and I couldn't break it again this time ...
Looks good!
Thanks,
Harald
Thanks
Paul
Fortran: Fix some deferred character
Dear all,
I've committed the attached patch which fixes a portability issue
when bootstrapping on Solaris. Discussed and confirmed in the PR
by Jonathan for Solaris and regtested by me on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:43816633afd275a9057232a6ebfdc19e441f09ec
(Unfortunately the
Hi Paul,
On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
I think that the changelog says it all. OK for mainline?
this looks almost fine, but still fails if one directly uses the
dummy argument as the ASSOCIATE target, as in:
program p
implicit none
character(4) ::
Dear all,
the testcase in the PR by Gerhard exhibited a mis-treatment of
the function decl of the entry master if the function result
had a pointer attribute and the translation unit was compiled
with -ff2c. We actually should not use the peculiar special
treatment for default-real functions in
Hi Jerry, all,
On 4/11/23 02:43, Jerry D via Gcc-patches wrote:
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote:
Dear all,
when comparing formal and actual arguments of a procedure, there was no
check of rank for derived types from intrinsic module ISO_C_BINDING.
This could lead to a
Dear all,
when comparing formal and actual arguments of a procedure, there was no
check of rank for derived types from intrinsic module ISO_C_BINDING.
This could lead to a wrong resolution of generic procedures with dummy
argument of related types, see PR. This was likely an oversight.
The
Hi Paul,
On 4/7/23 23:35, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
Well done on noticing the memory leak :-) I have a fix for it that I was
going to post separately. Actually, it is a trivial one liner, which I
could include with the patch.
thanks for addressing this! I can
Hi Paul,
On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote:
duuuh! Please find them attached.
the patch LGTM. Thanks!
However, I have comments on the new testcase associate_60.f90:
subroutine pr93813 is missing an allocation of x, e.g.:
allocate (t :: x)
otherwise it would be
Hi Paul,
I don't see the new testcases. Is this an issue on my side,
or did you forget to attach them?
Thanks,
Harald
On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote:
Dear All,
Please find attached a slightly updated version of the patch with a
consolidated testcase. The three
Hi Paul,
On 4/7/23 09:02, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Please find attached the patch to fix the dg directives and remove a lot of
trailing white space.
Unless there are any objections, I will commit as obvious over the weekend.
this is OK.
Thanks for the patch!
On 4/5/23 20:50, Harald Anlauf via Gcc-patches wrote:
can you have a look again at the logic in the hunk touching
trans-stmt.cc (gfc_trans_allocate)? I haven't checked in detail,
but it seems possible that you get a stale tmp in the
gfc_prepend_expr_to_block if (code
Hi Paul,
On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
This is a first in my recent experience - a very old bug that produces too
many finalizations! It results from a bit of a fix up, where class objects
are allocated using the derived typespec, rather than a source or
Hi Bernhard,
there is neither context nor a related PR with a testcase showing
that this patch fixes issues seen there.
On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
Cc: fort...@gcc.gnu.org
gcc/fortran/ChangeLog:
* array.cc
Dear all,
the attached patch fixes an ICE-on-invalid for a PARAMETER expression
where the character length was a MODULE variable. The ICE seemed
strange, as we were catching related erroneous code for declarations in
programs or subroutines. Removing a seemingly bogus check of restricted
Hi Paul,
> If you will excuse the British cultural reference, that's a Norwegian Blue
> alright! Good spot.
ROTFL!
I first had to look up the "Norwegian Blue", and then I remembered. :)
You're bringing back the fun to gfortran hacking!
Cheers,
Harald
On Sat, 25 Mar 2023 at 19:13,
Dear all,
I've committed the attached patch from the PR that removes
a dead code snippet, see discussion.
Regtested originally by Tobias, and reconfirmed on
x86_64-pc-linux-gnu.
Pushed as r13-6862-gb5fce899dbbd72 .
Thanks,
Harald
From b5fce899dbbd7246d003209b2fe3b04f8738 Mon Sep 17
Dear all,
while looking at variations of testcases in pr107560, I discovered
a minor FE memleak that was introduced in the BOZ rework and is
fixed by the attached simple patch.
Regtested on x86_64-pc-linux-gnu on OK'ed in the PR by Steve.
Thanks,
Harald
From
Dear all,
I've committed the attached simple patch after discussion with
Steve (see PR). We need to reject alternate return arguments
of FINAL subroutines.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From 3e791f45ded89626bc1f9f8013728f6e035801b2 Mon Sep 17 00:00:00 2001
From: Harald
Hi Tobias,
Am 21.03.23 um 09:31 schrieb Tobias Burnus:
On 20.03.23 21:57, Harald Anlauf via Gcc-patches wrote:
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -9998,6 +9998,7 @@ gfc_match_modproc (void)
if ((gfc_state_stack->state != COMP_INTERFACE
&& gfc_state_s
Hi Thomas,
Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches:
so it the general problem is not restricted to -O3 and not
to current trunk, it depends on the details.
I doubt that the result from 9.4.0 was expected, but rather
nobody noticed. Or, bringing out the pseudo-RNG into a
Dear all,
the attached trivial patch catches a MODULE PROCEDURE outside of a
module interface before we run into an internal error.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This PR is marked as an 11/12/13 regression, so this is a candidate
for backporting.
Thanks,
Harald
From
Dear all,
as reported, the implicit documentation of -funderscoring, which
is found under -fno-underscoring, has gone sideways long time ago.
The attached patch should fix it.
OK for mainline, or did I miss something?
Thanks,
Harald
From c296196044248f974b4907bb2f5bdeeea24adb5b Mon Sep 17
Dear all,
I intend to commit the attached obvious patch within 24h unless there
are comments.
The issue is an off-by-one error in setting up the maximum exponent
of the real kind that is passed to mpfr, so that model numbers between
huge(x)/2 and huge(x), when given as an argument to
Hi Thomas,
Am 19.03.23 um 08:34 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the Fortran standard requires an explicit procedure interface in
certain
situations, such as when they have a BIND(C) attribute
Hi Thomas,
Am 18.03.23 um 19:23 schrieb Thomas Koenig via Gcc-patches:
Hi,
Text says it all. OK for web pages?
Best regards
Thomas
Mention issues with integer owerflow for random number generators.
This mentions the issues with integer overflow and how to work
around them.
it's
Hi Thomas,
Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the Fortran standard requires an explicit procedure interface in certain
situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2).
The attached patch adds a check for this.
Regtested on
1 - 100 of 535 matches
Mail list logo
