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
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 exi
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 fae09dfc0e6bf4cfe35d8175588
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, b
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 F
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 b
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 w
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 .diff
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 h
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 looke
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 m
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 di
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 suppo
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
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 2
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
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,
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 way
Hi Tobias,
Am 30.06.22 um 11:58 schrieb Tobias Burnus:
The initial patch is by Steve. I adjusted and moved
it slightly so that it also handles CLASS(*)
(unlimited polymorphic) at the same time.
Shouldn't you then also acknowledge him, e.g. via Co-authored-by?
yeah, I noticed that right after
Dear all,
poor error recovery while trying to simplify intrinsics with given
invalid arguments seems to be a recurrent theme in testcases submitted
by Gerhard. In the present case, simplification of PACK() chokes on
the array argument being a bad decl.
The most general approach that came to my m
As there were no comments, committed as r13-1650.
Am 05.07.22 um 22:31 schrieb Harald Anlauf via Fortran:
Dear all,
poor error recovery while trying to simplify intrinsics with given
invalid arguments seems to be a recurrent theme in testcases submitted
by Gerhard. In the present case, simplif
Dear all,
the attached patch introduces error recovery for two cases of using
an invalid array in a declaration of an implied-shape array instead
of hitting internal errors.
Initial patch by Steve. The final version was approved in the PR
by Steve.
Committed as:
https://gcc.gnu.org/g:748f8a8b1
Dear all,
the attached patch by Steve fixes a regression under -ff2c for functions
where the result is not set. There would otherwise be conflicting
declarations of the returned result, which gimple doesn't like.
I've committed this as obvious after discussion with Steve for him,
see PR, as
com
Dear all,
I intend to commit the attached patch as obvious to mainline
within the next 24h unless someone complains. It replaces a
lazy gfc_internal_error by an explicit error message and an
error recovery path.
As a side-effect, we now diagnose a previously missed error
in testcase gfortran.dg/
Hi Mikael,
Am 19.07.22 um 11:03 schrieb Mikael Morin:
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..dacd33561d0 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/f
Hi Mikael,
Am 19.07.22 um 22:53 schrieb Mikael Morin:
It could be anything better than the (unhelpfull) internal error it is
replacing.
I suggest for example "Invalid array reference of a non-array entity at
%L".
yes, that's much better! The attached updated patch uses this.
Committed: r13-1
Dear all,
there was some left-over code - likely from development - that could
lead to a compiler segfault when given invalid input. Steve found
the offending line. Removing it solves the issue.
The fix was acknowledged by Tobias in the PR.
Regtested on x86_64-pc-linux-gnu.
Pushed as: r13-176
Dear all,
the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
rank combinations that were allowed in pointer assignment for
newer versions of the Fortran standard (F2008+). Fix the logic.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 338b43aefece04435d32
Hi Mikael, all,
a discussion in the Intel compiler forum suggests that the F2018
standard prohibits such use of the ASSOCIATED intrinsic.
https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159
As a cons
Hi Mikael,
> > https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159
> >
>
> I disagree with the conclusion. Quoting Steve Lionel’s post:
> > What you're missing is this:
> >
> > TARGET (optional) sh
Dear all,
we currently may ICE when array bounds of a dummy argument have
a non-integer type, and the procedure with the bad declaration is
referenced. The same applies to bad character length of dummies.
We could simply punt in such a situation, as the causing error
seems to be reliably diagnose
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
If somebody else convinces me to accept that NAG has it wrong this
time, I would be happy to proceed.
Dear all,
in free-form mode, blanks are significant, so they cannot appear
in literal constants, especially not before or after the "_" that
separates the literal and the kind specifier.
The initial patch from Steve addressed numerical literals, which
I completed by adjusting the parsing of strin
Hi Mikael,
Am 29.07.22 um 13:11 schrieb Mikael Morin:
Hello,
Le 28/07/2022 à 22:11, Harald Anlauf via Fortran a écrit :
Dear all,
in free-form mode, blanks are significant, so they cannot appear
in literal constants, especially not before or after the "_" that
separates the literal and the ki
Am 28.07.22 um 22:19 schrieb Mikael Morin:
Hello,
Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :
ok, I have thought about your comments in the review process,
and played with the Cray compiler. Attached is a refined version
of the patch that now rejects in addition these cases for
Hi Mikael,
Am 29.07.22 um 22:36 schrieb Mikael Morin:
Indeed, I overlooked that, but my opinion remains that we shouldn’t play
with fixed vs free form considerations here.
So the options I can see are:
- handle the locus in get_kind; we do it a lot already in matching
functions, so it wouldn’t
Hi Thomas,
Am 30.07.22 um 09:46 schrieb Thomas Koenig via Fortran:
Hi Harald,
This introduces the helper function gfc_match_next_char, which is
your second option.
I would be a little bit concerned about compilation times
with the additional function call overhead.
the function it replace
Hi Mikael,
Am 30.07.22 um 10:28 schrieb Mikael Morin:
Meh! We killed one check for gfc_current_form but the other one is still
there.
OK, match_kind_param calls two functions that also gobble space, so
there is work remaining here.
So please make match_small_literal_constant and gfc_match_name
s
Hi Mikael,
Am 31.07.22 um 10:35 schrieb Mikael Morin:
Le 30/07/2022 à 21:40, Harald Anlauf a écrit :
Hi Mikael,
Am 30.07.22 um 10:28 schrieb Mikael Morin:
Meh! We killed one check for gfc_current_form but the other one is still
there.
OK, match_kind_param calls two functions that also gobble
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 a
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
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 valgrind)
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 actu
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 the
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 reme
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:
Committ
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 attac
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 highe
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 these
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
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 the
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 ge
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 b
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 @@ gfc_c
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 preview",
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
type(
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
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 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 v
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 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 ::
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 (leng
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
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,
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
Thanks,
Harald
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
Hi Rimvydas,
Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
Von: "Rimvydas Jasinskas"
An: "Harald Anlauf"
Cc: "fortran"
Bet
Dear all,
the attached simple and obvious patch fixes a NULL pointer dereference
on an invalid use of a CLASS variable.
Committed to mainline after regtesting on x86_64-pc-linux-gnu as
https://gcc.gnu.org/g:2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a
Thanks,
Harald
From 2ce7e2a83e18a27fe9c659f866
Hi Thomas,
On 2/14/23 10:35, Thomas Schwinge wrote:
Hi!
On 2023-02-13T18:50:23+0100, Harald Anlauf via Gcc-patches
wrote:
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
There is one thing I cannot test, which is the
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
Thanks,
Harald
From a418129273725fd02e881e6fb5e0877287a1356c Mon Sep 17 00:00:00 200
Dear all,
I've committed the attached obvious and trivial patch for another
NULL pointer dereference on behalf of Steve and after regtesting on
x86_64-pc-linux-gnu as r13-6067-gc75cbeba81e5b4737a9ab7dd28cce650965535a9
Thanks,
Harald
From c75cbeba81e5b4737a9ab7dd28cce650965535a9 Mon Sep 17 00:00:
Dear all,
the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations. It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.
Regtested on x86_64-pc-linux-gnu. OK for
Hi Thomas,
Am 21.02.23 um 08:19 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations. It appears that the error handling was
already in place (mostly) and we need to e
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 marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems rea
Dear all,
as reported by Richard - although without a testcase - we leak
gmp memory in do_subscript(). The attached patch was derived
by inspection of the code pointed at by valgrind and regtested
on x86_64-pc-linux-gnu.
Committed as obvious as
commit r13-6336-g45f406c4f62e516b58dcda20b5a7aa43f
Hi Tobias,
Am 24.02.23 um 12:31 schrieb Tobias Burnus:
(B) The attached patch:
With 'intent(out)' there is no reason to do the conversions. While for
nullified
pointers the bounds-conversion loop is skipped, it may still be executed
for undefined
pointers. (Which is usually harmless.) In either
Hi Rimvydas,
Am 24.02.23 um 06:16 schrieb Rimvydas Jasinskas via Gcc-patches:
On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf wrote:
the patch is mostly fine, but there is a minor style issue:
+ if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+ gfc_error ("Symbol %qs at %L has the WE
Hi Mikael,
Am 25.02.23 um 17:35 schrieb Mikael Morin:
Hello,
Harald found a testcase with memory still leaking despite my previous
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the
attached patch fixes a leak caused by pointer overwrite.
I haven't invest
Dear all,
while checking f951 for memory leaks on testcases that appeared
relevant during work on pr108924, I found that the conversion
warning triggered by do_subscript_6.f90 uses a code path that
forgot to mpfr_clear a used variable.
The attached obvious patch fixes this - verified by valgrind.
Hi Jerry,
regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a
gcc_assert (dim >= 1);
in the right place achieve the same effect, since the first argument
must be an array?
(It's different for SPREAD, though, where SOURCE may be scalar).
Che
Dear all,
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 standard.
We actually had an inconsistency for this case between
code genera
Dear all,
the attached patch fixes a long-standing issue with CLASS attributes
when a declaration is scattered over multiple statements.
The major part ("draft") of the patch is by Tobias, which I took up
before it started to bit-rot too much, see PR. It is mainly about
a proper updating and boo
Hi Steve,
Am 03.03.23 um 20:57 schrieb Steve Kargl via Gcc-patches:
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-
Hi Mikael!
Am 04.03.23 um 14:56 schrieb Mikael Morin:
I have found the time finally. It's not as bad as it seemed. See below.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index eec0314cf4c..72d8c6f1c14 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
+ sym->attr.p
Hi Mikael!
Am 04.03.23 um 14:56 schrieb Mikael Morin:
I have found the time finally. It's not as bad as it seemed. See below.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index eec0314cf4c..72d8c6f1c14 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
+ sym->attr.p
Sorry, attached the wrong patch.
Here's the correct one.
Harald
Am 04.03.23 um 17:02 schrieb Harald Anlauf via Gcc-patches:
The attached revised version uses the above proven changes,
and extends the new testcase class_74.f90 by variations of
the failures remaining with version 1 so
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613354.html
I think Tobias might be the better person to answer this.
But when playing with variations o
Hi Mikael,
Am 04.03.23 um 23:29 schrieb Mikael Morin:
Le 04/03/2023 à 22:20, Harald Anlauf a écrit :
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613
Dear all,
the attached almost obvious patch fixes a NULL pointer dereference
in a check of a symbol with the bind(c) attribute.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This PR is marked as 10/11/12/13 regression, thus it should
qualify for a backport. It's simple enough anyway.
Tha
Dear all,
I've committed the attached patch to mainline as obvious after
regtesting on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:2cf5f485e0351bb1faf46196a99e524688f3966e
commit r13-6605-g2cf5f485e0351bb1faf46196a99e524688f3966e
Author: Harald Anlauf
Date: Sat Mar 11 15:37:37 2023 +0100
Dear all,
the attached patch, which is based on a draft by Tobias, fixes
an old rejects-valid issue with rank checking for CLASS arrays
by using the proper array spec of CLASS variables.
The testcase covers only non-coarray cases, as playing with
coarray variants hit pre-exisiting issues in gfort
Hi Tobias,
Am 15.03.23 um 10:10 schrieb Tobias Burnus:
Hi Harald,
On 14.03.23 20:38, Harald Anlauf wrote:
The testcase covers only non-coarray cases, as playing with
coarray variants hit pre-exisiting issues in gfortran that
are very likely unrelated to the interface checks.
I concur (but wou
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 o
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 removes
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 co
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 main
Dear all,
the attached patch is pretty much self-explaining: check for bounds violation
when initializing a substring in a data statement and treat the resulting error.
If more detailed information should be emitted with the error message, I'm
open for suggestions.
Regtested on x86_64-pc-linux-g
Hi Thomas,
> Gesendet: Montag, 25. Januar 2021 um 19:58 Uhr
> Von: "Thomas Koenig"
> a.f90:3:10:
>
> 3 | print a(0:3)
>| 1
> Error: Substring start index at (1) is less than one
> a.f90:4:10:
>
> 4 | print a(1:4)
>| 1
> Error: Substring end index a
Dear all,
the fix for this ICE is obvious: make gfc_call_malloc behave as documented.
Apparently the special case in question was not exercised in the testsuite.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports?
Should the testcase be moved to the gomp/ subdirectory?
Thanks,
Harald
Hi Thomas,
> > Should the testcase be moved to the gomp/ subdirectory?
> Yes. It's a compile-time test, and it will then only be run
> if the the compiler can do OpenMP.
>
> You will not need the
>
> +! { dg-options "-fopenmp" }
>
> line, then.
Adjusted and committed as r11-6950-g33a7a93218b1393d
Dear all,
the PR reports an issue detected with an ASAN instrumented compiler,
which can also be verified with valgrind. It appears that the state
of gfc_new_block could be such that it should not be dereferenced.
Reversing the order of condition evaluation helped.
I failed to find out why this
Dear all,
we should not clobber the pointer in case of an allocatable scalar being
an intent(out) dummy argument to a procedure.
Regtested on x86_64-pc-linux-gnu.
OK for master? Since this is a regression, also for backports to 10/9?
Thanks,
Harald
PR fortran/99169 - Do not clobber allocatab
1 - 100 of 535 matches
Mail list logo
