Dear all,
when playing around with the issues exposed by PR93340, particularly visible
in the tree dump, I tried to find ways to simplify substrings in those cases
where they are eligible as designator, which is required e.g. in DATA
statements.
Given my limited understanding, I finally arrived
Dear all,
ICE-on-invalid: testcase by Arseny, draft patch by Steve,
slightly polished and regtested by me on x86_64-pc-linux-gnu.
OK for master?
Thanks,
Harald
PR fortran/98284 - ICE in get_array_index
Reject DATA elements with the ALLOCATABLE attribute also when they are
components of a
Dear all,
since the introduction of check_forall_dependencies() we mishandled the
dependencies of ALLOCATABLE components of derived types, while POINTER
was dealt with. Fix that.
Regtested on x86_64-pc-linux-gnu.
OK for master? Since we generate wrong code under the given circumstances,
what
ICE on valid code.
Original patch by Steve, slightly adjusted and regtested on x86_64-pc-linux-gnu.
OK for master? Backports? Should be safe everywhere, as it replaces an assert
by an if condition.
Thanks,
Harald
PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687
Fix
Dear all,
the patch is almost self-explaining. We mishandled the case of initializing
pointer components to derived types of type CHARACTER via DATA, which screwed
up both legal and illegal uses. The attached patch fixes that, and checks
that the legal cases work.
Regtests cleanly on
Dear all,
the PR contains a lengthy discussion of several testcases, some which were
considered invalid and thus removed from the testsuite (charlen_03.f90,
charlen_10.f90), charlen_15.f90 was resolved elsewhere, so that only
class_61.f90 was left with an invalid access after error recovery with
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
Dear all,
the former Fortran testcase charlen_03.f90, which some time ago used to
ICE, could still display issues during error recovery. As Dominique
pointed out, this required either an instrumented compiler, or valgrind.
The issue turned out to not have anything to do with CHARACTER, but
with
Dear all,
happy New Year!
The testcase committed with the fix for PR93337 uncovered a latent issue
with an invalid read that was discovered with an ASAN instrumented compiler
but which could also be verified by running f951 under valgrind.
According to my gdb sessions the invalid read happens
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
*PING*
BTW this patch also addresses PR95501, so I'll update the Changelog.
Thanks,
Harald
> Gesendet: Freitag, 04. Juni 2021 um 23:12 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/95502 - ICE in gfc_check_do_variable, at
> fortran/parse.c:4446
>
>
A recent change to the checking of legacy FORMAT tags did not handle
cases where the type is not set. Adjust the check.
Regtested on x86_64-pc-linux-gnu.
OK for mainline / 11- / 10-branch?
Thanks,
Harald
Fortran: reject FORMAT tag of unknown type.
gcc/fortran/ChangeLog:
PR
Hi Bernhard,
> > +static bool
> > +substring_has_constant_len (gfc_expr *e)
> > +{
> > + ptrdiff_t istart, iend;
> > + size_t length;
> > + bool equal_length = false;
> > +
> > + if (e->ts.type != BT_CHARACTER
> > + || !(e->ref && e->ref->type == REF_SUBSTRING)
>
> iff we ever can get
*PING*
> Gesendet: Mittwoch, 09. Juni 2021 um 23:39 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field,
> at varasm.c:5514
>
> Dear Fortranners,
>
> we should be able to simplify the length of a substring
As confirmed in the PR by Jakub, there was a bad conversion of the result
of min0/max0 to the result type. We should just unconditionally convert
in all cases.
As a benefit, this also fixes pr100283.
Committed after regtesting.
Thanks,
Harald
Fortran - fix conversion to result type for the
Dear Fortranners,
we should be able to simplify the length of a substring with known
constant bounds. The attached patch adds this.
Regtested on x86_64-pc-linux-gnu.
OK for mainline? Since this should be rather safe, to at least 11-branch?
Thanks,
Harald
Fortran - simplify length of
The generation of the new runtime check picked up the wrong attributes
in the case of CLASS array arguments. There is related new code in
gfc_conv_procedure_call which served as reference for the fix.
Regtested on x86_64-pc-linux-gnu.
OK for mainline / 11-branch?
Thanks,
Harald
Fortran: Fix
A simple, self-explaining patch to avoid a wrong warning.
Regtested on x86_64-pc-linux-gnu.
OK for mainline? Affected branches?
Thanks,
Harald
PR fortran/98411 - Pointless warning for static variables
Variables with explicit SAVE attribute cannot end up on the stack.
There is no point in
The fix for PR93924/5 has caused a regression for code such as given
in the present PR. This can be remedied by adjusting the check when
to invoke the implicit conversion of actual argument to an unlimited
polymorphic procedure argument.
Regtested on x86_64-pc-linux-gnu.
OK for mainline and
Hi Tobias,
> @All, Harald: Does the attached patch make sense?
first of all: sorry for the really badly designed testcase.
The best solution has already been discussed in this thread,
which is to replace
integer(16), parameter :: m1 = 9007199254740992_16!2**53
Dear Fortranners,
frontend optimization tries to inline matmul, but then it also needs
to take care of the assignment to the result array. If that one is
not of canonical type, we currently get an ICE. The straightforward
solution is to simply punt in those cases and avoid inlining.
Regtested
ICE-on-invalid issues during error recovery. Testcase by Gerhard,
initial patch by Steve. I found another variant which needed an
additional fix for a NULL pointer dereference.
Regtested on x86_64-pc-linux-gnu.
OK for mainline / 11-branch?
Thanks,
Harald
Fortran - ICE in
*PING*
> Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in
> inline_matmul_assign, at fortran/frontend-passes.c:4234
>
> Dear Fortranners,
>
> frontend optimization tries
Dear Fortranners,
Gerhard found a case where bounds-checking for an optional,
allocatable character dummy resulted in an ICE. We'd better
not call the presence check on a non-dummy symbol, as this
will hit an assert...
Regtested on x86_64-pc-linux-gnu.
OK for mainline? And backport to 11?
*PING*
> Gesendet: Dienstag, 18. Mai 2021 um 20:36 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer
> argument is not associated" runtime error
>
> The generation of the new runtime check picked up the
*Ping*
> Gesendet: Dienstag, 15. Juni 2021 um 21:31 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/101084 - [10/11/12 Regression] ICE in
> gfc_typenode_for_spec, at fortran/trans-types.c:1124
>
> A recent change to the checking of legacy FORMAT tags
Hi Tobias,
> On 10.06.21 20:52, Harald Anlauf via Fortran wrote:
> > +static bool
> > +substring_has_constant_len (gfc_expr *e)
> > +{
> > + ptrdiff_t istart, iend;
> > + size_t length;
> > + bool equal_length = false;
> > +
> > + if (e->ts.type != BT_CHARACTER
> > + || !e->ref
> > +
Dear Fortranners,
Gerhard found a case where the mismatch of actual and formal argument lead
to an ICE instead of the relevant warning. Furthermore, the special case
of character argument avoided the check that the actual argument must be
definable if the formal one is INTENT-OUT or -INOUT. The
Hi Paul,
> Is there a test for an error with -std=f2003? If not, you should, perhaps,
> include one.
after checking for the corresponding error message, I found that
ptr-func-2.f90 already covers this case. Considering this, I'll
rename the current testcase from pr100218.f90 to ptr-func-4.f90.
PING!
---
Dear Fortranners,
Gerhard found a case where the mismatch of actual and formal argument lead
to an ICE instead of the relevant warning. Furthermore, the special case
of character argument avoided the check that the actual argument must be
definable if the formal one is INTENT-OUT or
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
Dear all,
the simplification of the TRANSPOSE of a zero-sized array would lead to
an ICE if the result was used in a subsequent simplification of a MATMUL.
The reason was the lack of the proper initialization of the shape, which
is mpz_t. Use mpz_init_set instead of mpz_set.
Regtested on
Dear all,
the addition of runtime checks for the SIZE intrinsic created a regression
that showed up for certain CLASS arguments to procedures. Paul did most of
the work (~ 99%), but asked me to dig into an issue with an inappropriately
selected error message. This actually turned out to be a
Hi Tobias,
> I do not see any reason why 'tmp' is replaced by 'temp' in this
> code. Also for doing patch archeology, it helps if there are no
> changes unless it makes sense. Adding an -e- does not count ;-)
>
> Hence, OK with that change.
I've corrected that. This also reduces the size of
Hi Tobias,
> Shouldn't there be also a testcase which triggers this run-time error?
The testcase is there, it simply has the wrong dg-foo:
! { dg-do compile }
which should be
! { dg-do run }
*-*-*
There are certainly more cases which should insert checks but currently don't,
like:
Dear Tobias,
thanks for your comments.
> > A variable that is a data statement object shall be a designator,
> > thus a character variable shall have a constant length.
>
> This comment is wrong: A designator does not imply this – nor is
> F2018:C875 violated, not even the substring
Dear Tobias, all,
> The reason that it is not permitted is the "automatic data object"
> (see *...* highlighted parts in the quote):
>
> C876 (R839) A *variable* whose *designator* appears as a
> *data-stmt-object* or a data-i-do-object hall not be a
> dummy argument, accessed by use or host
Dear all,
character variables with undefined length are not allowed as
objects in DATA statements. We better reject them.
Regtested on x86_64-pc-linux-gnu. OK for master / backport?
Thanks,
Harald
PR fortran/99205 - Out of memory with undefined character length
A variable that is a data
Dear all,
the present PR has two issues. The first one, addressed by this patch,
was about accepting invalid code where a variable appeared both in a
declaration with PARAMETER as well as in a DATA statement, which could
lead to an ICE. We now reject this.
(There is a separate issue about
Early ping.
Harald
> Gesendet: Dienstag, 23. Februar 2021 um 22:46 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on
> temporary array accesses invalid memory
>
> Dear all,
>
> under certain circumstances a
Hi Jerry,
> Yes, OK, however, have you been able to test performance. I am only
> curious. There was a test program we used back when this code was first
> implemented in bugzilla. I do not remember the PR number off hand.
as you mentioned in a private mail, it was PR51119, and the timing
Dear all,
under certain circumstances a call to MATMUL for rank-2 times rank-1
would invoke a highly tuned rank-2 times rank-2 algorithm which could
lead to invalid reads and writes. The solution is to check the rank
of the second argument to matmul and fall back to a regular algorithm
for
Hello everybody,
we currently write the interface for intrinsic procedures to module
files although that should not be necessary. (F2018:15.4.2.1 actually
states that interfaces e.g. of intrinsic procedures are 'explicit'.)
This lead to bogus errors due to an apparently bogus ambiguity.
A simple
Hi Paul, all,
having really enjoyed the review process, I've now committed Paul's version
including his comment. See also attached.
Thanks,
Harald
Gesendet: Freitag, 16. April 2021 um 13:02 Uhr
Von: "Paul Richard Thomas"
An: "Bernhard Reutner-Fischer"
Cc: "Harald Anlauf via Fortran" ,
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
Dear all,
when simplifying the RESHAPE intrinsic we lost the string length when
the resulting array had size zero. The attached patch sets the resulting
length from the source.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
PR fortran/99206 - ICE in add_init_expr_to_sym,
Dear Fortranners,
we need to check the arguments to the affected GNU intrinsic extensions
properly, and - as pointed out in the PR by Tobias - we need to allow
function references that have a data pointer result. Also the argument
names of the character arguments of the subroutine versions
Now with the correct patch attached ...
Sorry for the confusion!
---
Dear Fortranners,
we need to check the arguments to the affected GNU intrinsic extensions
properly, and - as pointed out in the PR by Tobias - we need to allow
function references that have a data pointer result. Also the
Dear Fortranners,
while analyzing a different PR (PR100154), Tobias pointed out that the
target of a pointer from the evaluation of function-reference is allowed
to be used in a variable definition context and thus as an actual
argument to a function or subroutine.
This seems to be a more
Hi Jakob,
thanks for the detailed explanation!
> The other much easier but uglier option is to use a temporary buffer:
> char buffer[21];
> sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> gfc_error ("... %s ...", ... buffer ...);
> This works, as it uses the host sprintf i.e.
Dear all,
I've just pushed the fix for the bootstrap breakage as confirmed by Jakub.
commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1
Author: Harald Anlauf
Date: Fri Aug 20 13:38:00 2021 +0200
Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error
> Gesendet: Freitag, 20. August 2021 um 12:12 Uhr
> Von: "Jakub Jelinek"
> I have verified it fixes i686-linux bootstrap.
> But the new testcase doesn't trigger any of those new errors, is something
> else in the testsuite covering those or do you have some short snippet that
> could verify the
> Gesendet: Freitag, 20. August 2021 um 14:01 Uhr
> Von: "Tobias Burnus"
> On 20.08.21 12:53, Harald Anlauf wrote:
>
> > I played with variations of the testcase by specifying illegal
> > substring bounds, but all these cases were caught in a different
> > spot with similar error messages.
>
>
Hi!
> Gesendet: Freitag, 20. August 2021 um 02:21 Uhr
> Von: "H.J. Lu"
> This may have broken bootstrap on 32-bit hosts:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
I do not understand the error message:
../../src-master/gcc/fortran/simplify.c: In function ‘bool
Hi Tobias,
> Gesendet: Mittwoch, 18. August 2021 um 12:22 Uhr
> Von: "Tobias Burnus"
> > Note, however, that gfc_simplify_len still won't handle neither
> > deferred strings nor their substrings.
> >
> > I think there is nothing to simplify at compile time here.
>
> Obviously, nonsubstrings
Dear all,
the ICE in the original testcase does no longer occur but leads to an
error in a later stage of compilation, and we accepted invalid code.
(Cross-checked with other compilers, such as Intel and NAG).
F2018 states:
15.6.2.6 ENTRY statement
(3) ... If the characteristics of the result
I intend to commit the fix to the error message using the patch below
within the next 24h unless there are objections or better suggestions.
The unchanged part of the error message is already covered by
gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 and does
not need to be adapted.
PING!
> Gesendet: Dienstag, 24. August 2021 um 22:36 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in
> trans_caf_is_present, at fortran/trans-intrinsic.c:8469
>
> Dear Fortranners,
>
> here's a pretty obvious one:
Dear Fortranners,
here's a pretty obvious one: we didn't properly check the arguments
for intrinsics when these had to be ALLOCATABLE and in the case that
argument was a coarray object. Simple solution: just reuse a check
that was used for pointer etc.
Regtested on x86_64-pc-linux-gnu. OK for
The check of arguments to ALLOCATE did not properly implement
F2008:C628 / F2018:C932, as it excluded unlimited polymophics,
in contrast to the standard text. Fix this.
Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran - correct check for
A whitespace issue during parsing.
Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran - fix whitespace issue during parsing of assigned goto
gcc/fortran/ChangeLog:
PR fortran/102113
* match.c (gfc_match_goto): Allow for
There was an issue when trying to use an element from an array constructor
which was a broken in a way probably only Gerhard could conceive.
We hit an assert that can be replaced by more robust code.
Patch is basically Steve's.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Hi Tobias,
> LGTM – I am fine with either variant, but I am slightly inclined to
> removing the gcc_assert*
> – as I believe that the existing checks come early enough and do seem to
> work well.
I played some more and found additional cases that we hadn't discussed
before. (At least I hadn't
Hi Tobias,
> I am inclined to say that the Intel compiler has a bug by not
> accepting it – but as written before, I regard sub-string length
> (esp. with const expr) inquiries as an odd corner case which
> is unlikely to occur in real-world code.
ok.
> Still does not work – or rather:
Hi Tobias,
> Consider:
>
> type t
>integer, allocatable :: a
> end type t
>
> type(t) :: var[*]
> print *, allocated(var%a)
> print *, allocated(var[1]%a)
> end
what is the problem here? Can you elaborate?
BTW: Intel accepts it, we (currently) accept it, my patch does not change
The following patch by Steve was lingering in the PR for some time.
For an implied do loop within an array constructor we would generate an
additional, bogus substring bounds check for the index variable before it
actually became defined. The check thus depended on the previous value of
the
Early *PING*.
> Gesendet: Dienstag, 07. September 2021 um 23:44 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/82314 - ICE in gfc_conv_expr_descriptor, at
> fortran/trans-array.c:6972
>
> When adding the initializer for an array, we need to make sure
Dear all,
in find_substring_ref we erroneously handled given substring start and end
indices as unsigned integers. However, gives indices could be negative,
which is legal as long as end < start, leading to a string of length zero.
The current behavior could lead to a wrong length as well as an
As nicely described in the PR, we mishandled the case of passing
optional allocatable DT arguments with allocatable components
when the INTENT was declared as INTENT(OUT), as we unconditionally
tried to deallocate these components even when the argument was not
present. The obvious solution is to
Hi Tobias,
I think I can follow now what you are thinking, and I also had some
thoughts about what you be done in principle.
I was struggling the way I did because of:
(1) Intel rejects the code in the PR. For my previous patch,
% ifort coarray_allocated.f90 -coarray
coarray_allocated.f90(8):
When adding the initializer for an array, we need to make sure that
array bounds are properly simplified if that array is a PARAMETER.
Otherwise the generated initializer could be wrong and screw up
subsequent simplifications, see PR.
The minimal solution is to attempt simplification of array
PING.
> Gesendet: Montag, 30. August 2021 um 23:40 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/101327 - ICE in find_array_element, at
> fortran/expr.c:1355
>
> There was an issue when trying to use an element from an array constructor
> which was a
The attempt to fix a misleading warning lead to a regression that prevented
putting large variables in the main into static storage. So instead of
preventing the move, we now disable the useless warning for variables in
the main.
Regtested on x86_64-pc-linux-gnu. The patch was ok'ed in the PR
Committed as obvious as r12-3533.
The fix to PR87737 did work for the given testcase, but could lead
to a bad internal compiler state for a variation of the testcase.
(Found by Gerhard...)
The solution was to not return too early after emitting the error
message but going through a 'cleanup'
Hello world,
we rather shouldn't consider a presence check for a non-dummy variable.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
Thanks,
Harald
Fortran - ICE in gfc_conv_expr_present while initializing a non-dummy
class variable
gcc/fortran/ChangeLog:
PR
Here's now my third attempt to fix this PR, taking into account
the comments by Tobias and Bernhard.
> > On 10.06.21 20:52, Harald Anlauf via Fortran wrote:
> > > +static bool
> > > +substring_has_constant_len (gfc_expr *e)
> > > +{
> > > + ptrdiff_t istart, iend;
> > > + size_t length;
> > > +
Dear all,
here's the second part that should fix this regression for good.
The patch also adjusts the warning message to make it easier to
understand, using the suggestion by Tobias (see PR).
Since F2018 in principle makes RECURSIVE the default, which might
conflict with the purpose of the
Dear Fortranners,
I intend to commit the following pretty obvious fix within the next
24 hours unless there are objections.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran: ICE with automatic character object, save, and various options
gcc/fortran/ChangeLog:
PR fortran/68568
*Ping*
> Gesendet: Mittwoch, 04. August 2021 um 23:09 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH, part2] PR fortran/98411 [10/11/12 Regression] Pointless:
> Array larger than ‘-fmax-stack-var-size=’, ...
>
> Dear all,
>
> here's the second part that should
Dear all,
the checks for the STAT= and ERRMSG= arguments to the coarray SYNC statements
did not properly handle several cases, such as named constants (parameters).
While fixing this, I adjusted the code similarly to what was recently done
for (DE)ALLOCATE. We now also accept function references
*Ping*
> Gesendet: Dienstag, 03. August 2021 um 23:17 Uhr
> Von: "Harald Anlauf"
> An: "Harald Anlauf"
> Cc: "Tobias Burnus" , "Bernhard Reutner-Fischer"
> , "Harald Anlauf via Gcc-patches"
> , "fortran"
> Be
Dear Fortranners,
we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
expression with an initializer. The intrinsics in question are listed in
F2018:10.1.2.
As discussed in the PR, Steve recommended to
Hi Jerry,
> Gesendet: Samstag, 09. Oktober 2021 um 00:28 Uhr
> Looks all good Harald, OK and thanks for the support!
Thanks for the quick review!
Harald
*Ping*
Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when initializing parameter arrays from scalars, we did handle only
the case init->expr_type == EXPR_CONSTANT, which misses the case of
derived types. As a consequence the constructor for the r.h.s. was
not set
Hi Tobias,
Am 01.10.21 um 02:43 schrieb Tobias Burnus:
Hi all,
this patch fixes a bunch of issues with CLASS.
* * *
besides my previous minor remarks I do not have further comments.
I played around a little but did not find any (new) obstacles.
OK for mainline?
OK from my side.
Hi Tobias,
just some random remarks from initially browsing your patch.
- leftover from debugging?
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1c24556c299..8a82e55d1f9 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1,3 +1,4 @@
+#pragma GCC
Dear Fortranners,
the attached patch adds a check for the shape of arrays in derived type
constructors. This brings it in line with other major brands.
Example:
type t
integer :: a(1)
end type
type(t), parameter :: y(2) = t([1,2])
end
This was silently accepted before, but now
Hi Tobias, all,
> > In developing the patch I encountered a difficulty with testcase
> > dec_structure_6.f90, which uses a DEC extension, namelist "old-style
> > CLIST initializers in STRUCTURE". I could not figure out how to
> > determine the shape of the initializer; it seemed to be always
Dear Fortranners,
F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style
relational operators. We internally distinguish between old and new style,
but try to map appropriately when used.
This mapping was missing when reading a module via
USE module, ONLY: OPERATOR(op)
Dear Fortranners,
another simple and obvious fix: we need to reorder the argument checks
to the SHAPE intrinsic so that invalid KIND arguments can be detected.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As I consider this a safe fix, I'd like to backport to suitable branches.
Thanks,
Dear Fortranners,
when simplifying RESHAPE we hit a gcc_assert for negative entries in the
SHAPE array. Obvious solution: replace gcc_assert by an error message.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a safe fix, I'd like to backport to suitable branches.
Thanks,
Hi Tobias,
Am 13.10.21 um 18:01 schrieb Tobias Burnus:
Dear all,
a minor update [→ v3].
this has become an impressive work.
I searched for XFAIL in Sandra's c-interop/ and found
two remaining true** xfails, now fixed:
- gfortran.dg/c-interop/typecodes-scalar-basic.f90
The conversion of
Hi Tobias,
let me first reach for my brown bag...
> Otherwise, the quote from F2018 of my previous email applies:
>
> F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim'
> argument the following. The case without 'dim' just iterates
> through case (i) for each dim. Thus:
>
> "If DIM is
Dear Fortranners,
Gerhard's testcase triggers a NULL pointer dereference during the
attempt to expand an invalid constructor. The simple and obvious
solution is to catch that case.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
Thanks,
Harald
Fortran: fix error recovery for
Hi Tobias,
Am 29.09.21 um 10:53 schrieb Tobias Burnus:
Found when looking at F2018:C839 / PR54753.
For INTENT(OUT) the dummy variable (might) also be default initialized
or deallocated. However, with assumed rank, that causes issues, which
C839 prevents. In the current GCC implementation,
Dear Fortranners,
I think I have solved the remaining issue in PR 102458 that prevented the
simplification of an expression involving a static initialization and the
evaluation of the SIZE of an automatic array which has provable constant
size. My previous related query to the ML has thus become
Hi Tobias,
Am 20.09.21 um 22:33 schrieb Tobias Burnus:
And v3 – I realized that testcases would be useful. Thus, now with added
testcases. :-)
I was about to recommend a testcase I prepared when your revised patch
arrived. Will not bother you with it, as you seem to provide really
good
Hi Tobias,
Am 21.09.21 um 21:22 schrieb Tobias Burnus:
While the previous patch fixed -Wno-missing-include-dirs and sorted
out some inconsistencies with libcpp warnings, it had two issues:
* Some superfluous warnings were printed, e.g. for
gfortran nonexisting/file.f90
there was a
1 - 100 of 535 matches
Mail list logo
