https://gcc.gnu.org/g:3d05b9ac1c6ad950339f9487702c3165c189fe9e
commit r11-11305-g3d05b9ac1c6ad950339f9487702c3165c189fe9e
Author: Mikael Morin
Date: Thu Mar 21 17:27:54 2024 +0100
fortran: Ignore use statements on error [PR107426]
This fixes an access to freed memory
https://gcc.gnu.org/g:38dd703d368c9e60159e6f19cfc8303ad639b557
commit r12-10305-g38dd703d368c9e60159e6f19cfc8303ad639b557
Author: Mikael Morin
Date: Thu Mar 21 17:27:54 2024 +0100
fortran: Ignore use statements on error [PR107426]
This fixes an access to freed memory
https://gcc.gnu.org/g:fc5c603da3c9b186308fb3afef7bcf3f3bf695e8
commit r13-8543-gfc5c603da3c9b186308fb3afef7bcf3f3bf695e8
Author: Mikael Morin
Date: Thu Mar 21 17:27:54 2024 +0100
fortran: Ignore use statements on error [PR107426]
This fixes an access to freed memory
https://gcc.gnu.org/g:7f233feafd657250340be3b3500d2697948ae3ed
commit r14-9703-g7f233feafd657250340be3b3500d2697948ae3ed
Author: Mikael Morin
Date: Wed Mar 27 16:30:42 2024 +0100
fortran: Fix specification expression check in submodules [PR114475]
The patch fixing PR111781 made
Hell(o),
it didn't take long for my recent patch for PR111781 to show a regression.
The fix proposed here is actually the one Harald posted in the PR.
I can't imagine a case where it wouldn't do the right thing.
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The patch fixing
https://gcc.gnu.org/g:a44d7e8a52007c2d45217709ca02947c6600de87
commit r14-9619-ga44d7e8a52007c2d45217709ca02947c6600de87
Author: Mikael Morin
Date: Thu Mar 21 17:27:54 2024 +0100
fortran: Ignore use statements on error [PR107426]
This fixes an access to freed memory
https://gcc.gnu.org/g:44c0398e65347def316700911a51ca8b4ec0a411
commit r14-9618-g44c0398e65347def316700911a51ca8b4ec0a411
Author: Mikael Morin
Date: Fri Mar 22 12:32:34 2024 +0100
fortran: Fix specification expression error with dummy procedures [PR111781]
This fixes a spurious
https://gcc.gnu.org/g:ebace32a26424884789ccf585a24ac6a5703a323
commit r14-9617-gebace32a26424884789ccf585a24ac6a5703a323
Author: Mikael Morin
Date: Fri Mar 22 12:32:17 2024 +0100
testsuite: Declare fortran array bound variables
This fixes invalid undeclared fortran array bound
Hello,
here is a fix for an ICE caused by dangling pointers to ISO_C_BINDING's
C_PTR symbol in the global intrinsic symbol for C_LOC.
I tried to fix it by making the intrinsic symbol use its own copy of
C_PTR, but it regressed heavily.
Instead, I propose this which is based on a patch I attached
Le 20/03/2024 à 21:24, Harald Anlauf a écrit :
Hi Mikael, all,
here's now the third version of the patch that implements the following
scheme:
On 3/15/24 20:29, Mikael Morin wrote:
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
OK, that sounds interesting. To clarify the options
This fixes a spurious invalid variable in specification expression error.
The error was caused on the testcase from the PR by two different bugs.
First, the call to is_parent_of_current_ns was unable to recognize
correct host association and returned false. Second, an ad-hoc
condition coming next
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90:
log text from second patch
- Target current stage (stage4) instead of next (stage1)
v1 -> v2 changes:
- Fix condition guarding sym->result access.
Mikael Morin (2):
testsuite: Declare fortran array bound variables
fortran: Fix specification expression error with dummy p
Le 17/03/2024 à 23:10, Harald Anlauf a écrit :
Hi Mikael,
On 3/17/24 22:04, Mikael Morin wrote:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 3673fa40720..a7717a8107e 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7526,6 +7526,17
Hello,
Le 22/02/2024 à 19:29, Anbazhagan, Karthiban a écrit :
(...)
gcc/config/i386/{znver4.md => zn4zn5.md} | 858 +-
looks like the patch pushed to master lost the file rename.
I get a bootstrap failure caused by the missing zn4zn5.md file.
Can you have a look?
it before stage 1 so that I can get rid of it sooner.
On 3/17/24 17:57, Mikael Morin wrote:
* expr.cc (check_restricted): Remove the case where symbol is dummy
and declared in the current ns. Use gfc_get_spec_ns to get the
right namespace.
Looking at the original and new code, I
Le 15/03/2024 à 20:32, Harald Anlauf a écrit :
Dear all,
as there has been some good progress in the handling of optional dummy
arguments, I looked again at this PR and a patch for it that I withdrew
as it turned out incomplete.
It turned out that it now needs only a minor adjustment for
This fixes a spurious invalid variable in specification expression error.
The problem is caused by improper restoration of formal_arg_flag to false
(instead of restoring it to its previous value). This happens with the
testcase from the PR where a dummy argument is itself a procedure with dummy
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90:
for master when stage1
opens?
Mikael
v1 -> v2 changes:
- Fix condition guarding sym->result access.
Mikael Morin (2):
testsuite: Declare fortran array bound variables
fortran: Fix specification expression error with dummy procedures
[PR111781]
gcc/fortran/e
This fixes a spurious invalid variable in specification expression error.
The problem is caused by improper restoration of formal_arg_flag to false
(instead of restoring it to its previous value). This happens with the
testcase from the PR where a dummy argument is itself a procedure with dummy
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90:
is
involved, and enables more valid ones, as visible in the testcases from the
first patch.
The patch is not completely trivial, and fix what is not really a regression,
so it is more for stage1, I think.
Tested for regression on x86_64-pc-linux-gnu. Ok for master when stage1
opens?
Mikael Morin (2
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
Hi Mikael,
On 3/15/24 17:31, Mikael Morin wrote:
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler
On 1/30/24 11:46, Mikael Morin wrote:
Le 30/01/2024 à 11:38, Mikael Morin a écrit :
Another (easier) way to clarify the data reference would be rephrasing
the message so that the array part is separate from the scalar part,
like so (there are too many 'of', but I lack inspiration):
Index '0
Le 30/01/2024 à 11:38, Mikael Morin a écrit :
Another (easier) way to clarify the data reference would be rephrasing
the message so that the array part is separate from the scalar part,
like so (there are too many 'of', but I lack inspiration):
Index '0' of dimension 1 of component 'zz
Le 29/01/2024 à 21:50, Harald Anlauf a écrit :
Am 29.01.24 um 18:25 schrieb Harald Anlauf:
I was talking about the generated format strings of runtime error
messages.
program p
implicit none
type t
real :: zzz(10) = 42
end type t
class(t), allocatable :: xx(:)
integer :: j
Le 25/01/2024 à 22:26, Harald Anlauf a écrit :
Dear all,
this is the third patch in a series that addresses dummy arguments
with the VALUE attribute, now handling the passing of NULL actual
arguments. It is based on the refactoring in the previous patch
and reuses the handling of absent
Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental. Adjustments
were necessary when the missing dummy has the VALUE
Hello,
Le 20/01/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
here's the first part of an attempt to fix issues with optional
dummy arguments as actual arguments to optional dummies. This patch
rectifies the case of scalar dummies with the VALUE attribute,
which in gfortran's argument
Hello,
I tested this on x86_64-pc-linux-gnu without regression.
There is no new test, as the problem is visible on an
existing test with valgrind or an asan-instrumented compiler.
OK for master?
-- >8 --
This change is a followup to the fix for PR48776 (namely
Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.
Regtested on x86_64-pc-linux-gnu.
Hello,
Le 23/11/2023 à 22:59, Harald Anlauf a écrit :
Dear all,
the PR is about a redundant obsolescence warning for COMMON when
a symbols appears in the scope of a submodule. As we did not warn
for use-associated symbols, it seemed natural to extend this to
symbols that are used in a
Hello,
Le 22/11/2023 à 22:02, Harald Anlauf a écrit :
Dear all,
testcases assumed_rank_8.f90 and assumed_rank_10.f90 are invalid:
NULL() is passed without MOLD to an assumed-rank dummy argument.
This is detected by NAG, but not yet by gfortran (see pr104819).
gfortran even ignores the MOLD
Le 22/11/2023 à 21:36, Harald Anlauf a écrit :
Hi Mikael!
On 11/22/23 10:36, Mikael Morin wrote:
(...)
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 2ac51e95e4d..be715b50469 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -980,7 +980,11 @@ char const
Le 21/11/2023 à 23:09, Harald Anlauf a écrit :
Uhh, it happened again. Attached a wrong patch.
Only looked at the -v3 ... My bad.
Sorry!
Harald
On 11/21/23 22:54, Harald Anlauf wrote:
Hi Mikael, Steve,
On 11/21/23 12:33, Mikael Morin wrote:
Harald, you mentioned the lack
Hello,
Le 20/11/2023 à 20:02, Steve Kargl a écrit :
Harald,
Sorry about delayed response. Got side-tracked by Family this weekend.
On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote:
On 11/19/23 01:04, Steve Kargl wrote:
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf
Le 17/11/2023 à 12:38, Tobias Burnus a écrit :
Unless there are follow up comments, I will commit it later today.
I skimmed quickly through the patch, and noticed one typo to fix:
> diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
> index 10387e39501..5f87b330a22 100644
> ---
Le 07/11/2023 à 19:16, Harald Anlauf a écrit :
Hi Mikael,
this is OK.
Thanks for the patches!
Harald
Patches pushed.
Thanks for the (fruitful) review.
Remove the early return present in function templates for transformational
functions doing a (masked) reduction of an array along a dimension.
This early return, which triggered if the extent in the reduction dimension
was zero, was wrong because even if the reduction operation degenerates to
a
://gcc.gnu.org/pipermail/fortran/2023-November/059896.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635305.html
Changes from version 1:
* Add patch 1/3 to the series fixing the unallocated empty result issue.
* In patch 2/3 (formerly 1/2) clamp negative extent to zero.
Mikael Morin (3
Le 06/11/2023 à 19:20, Harald Anlauf a écrit :
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
Remove the forced overwrite of the first dimension of the result array
descriptor to set it to zero extent, in the function templates for
transformational functions doing an array reduction
Le 06/11/2023 à 19:12, Harald Anlauf a écrit :
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
Remove the early return present in function templates for
transformational
functions doing a (masked) reduction of an array along a dimension.
This early return, which triggered if the extent
Remove the early return present in function templates for transformational
functions doing a (masked) reduction of an array along a dimension.
This early return, which triggered if the extent in the reduction dimension
was zero, was wrong because even if the reduction operation degenerates to
a
Hello,
while preparing a testcase, I encountered a bug which I filed as
PR112371. Investigating further, I found two different problems which I
propose to fix with the followup patches.
Those have been bootstraped and regression tested on x86_64-pc-linux-gnu.
OK for master?
Mikael
Mikael
Le 26/10/2023 à 11:29, Richard Biener a écrit :
On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote:
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 40767736389..2a2a90230f5 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15047,15 +15047,33 @@
Hello,
Le 27/09/2023 à 12:46, Jakub Jelinek a écrit :
--- gcc/vec.h.jj2023-09-27 10:38:50.635845540 +0200
+++ gcc/vec.h 2023-09-27 12:11:56.665586490 +0200
@@ -1028,13 +1050,17 @@ template
inline void
vec::truncate (unsigned size)
{
- gcc_checking_assert (length () >= size);
+
Hello,
Harald reminded me recently that there was a working patch attached to the PR.
I added a documentation comment with the hope that it may help avoid
making the same mistake in the future.
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Remove one reference count
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 checked the testcase with
valgrind.
OK for master?
-- >8 --
Remove
Le 08/09/2023 à 23:22, Harald Anlauf via Fortran a écrit :
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
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
example;
just passed the fortran testsuite on
Le 01/09/2023 à 22:48, Harald Anlauf a écrit :
Hi Mikael,
On 9/1/23 10:41, Mikael Morin via Gcc-patches wrote:
May I suggest to handle functions the same way?
I'll have a look at them, but will need to gather a few
suitable testcases first.
I have just opened PR111339
(https://gcc.gnu.org
Hello,
this is a fix for a small memory leak in the fortran frontend.
Tested on x86_64-pc-linux-gnu, nothing stands out besides the
apparently well-known guality instability.
OK for master ?
-- >8 --
Delete m_client_data_hooks before it is reassigned in
tree_diagnostics_defaults. This fixes a
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) expressions can involve array
constructors, which have a shape ;-)
The
Le 28/08/2023 à 21:17, Harald Anlauf via Fortran a écrit :
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
Hello,
this fixes an old error-recovery bug.
Tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Keep memory of the content of the current interface body being parsed
and restore it to its previous state if it has been modified at the time
a parse attempt fails.
This fixes memory errors
Hello,
Le 13/08/2023 à 23:16, Harald Anlauf via Fortran a écrit :
Hi Mikael,
Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches:
Hello,
(...)
I have regression tested this on x86_64-unknown-linux-gnu, and
powerpc64-unknown-linux-gnu (both -m32 and -m64).
OK for master?
this looks
Hello,
I ran into a bug recently, running dg-cmp-results.sh with variant
unix/-m32. This fixes it.
OK for master?
-- >8 --
Escape slash characters in $header variable (coming from the variant
argument). This avoids runs with say "unix/-m32" as variant resulting
in sed errors "unknown
Use distinct error codes, so that we can spot directly from the
testsuite log which case is failing.
gcc/testsuite/ChangeLog:
* gfortran.dg/value_9.f90 (val, val4, sub, sub4): Take the error
codes from the arguments.
(p): Update calls: pass explicit distinct error codes.
Introduce a new predicate to simplify conditionals checking for
a character type whose length is the constant one.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_length_one_character_type_p): New inline
function.
* check.cc (is_c_interoperable): Use
Revision r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa
changed the argument passing convention for length 1 value dummy
arguments to pass just the single character by value. However, the
procedure declarations weren't updated to reflect the change in the
argument types.
This change does the
, and
powerpc64-unknown-linux-gnu (both -m32 and -m64).
OK for master?
[1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
Mikael Morin (3):
fortran: New predicate gfc_length_one_character_type_p
fortran: Fix length one character dummy arg type [PR110419]
testsuite: Use
Hello,
Le 31/07/2023 à 19:07, Andrew Pinski via Gcc-patches a écrit :
diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc
index a71c0727b0b..ddaf22f2179 100644
--- a/gcc/generic-match-head.cc
+++ b/gcc/generic-match-head.cc
@@ -121,3 +121,45 @@ bitwise_equal_p (tree expr1, tree
Pass already evaluated class container argument from
gfc_conv_procedure_call down to gfc_add_finalizer_call through
gfc_deallocate_scalar_with_status and gfc_deallocate_with_status,
to avoid repeatedly evaluating the same data reference expressions
in the generated code.
PR fortran/110618
Add the possibility to provide a pre-evaluated class container argument
to gfc_add_finalizer to avoid repeatedly evaluating data reference
expressions in the generated code.
PR fortran/110618
gcc/fortran/ChangeLog:
* trans.h (gfc_add_finalizer_call): Add class container
The variable has_finalizer is only used in one place, inline its
definition there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Inline definition of
variable has_finalizer. Merge nested conditions.
---
gcc/fortran/trans.cc | 16 +++-
1 file changed, 7
get_var_descr get passed as argument both expr and expr->ts.
Remove the type argument which can be retrieved from the other
argument.
gcc/fortran/ChangeLog:
* trans.cc (get_var_descr): Remove argument ts. Use var->ts
instead.
(gfc_add_finalizer_call): Update caller.
---
Final procedure pointer expression is generated in gfc_build_final_call
and only used in get_final_proc_ref. Move the generation there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Remove local variable
final_expr. Pass down expr to get_final_proc_ref and move
The same scalar descriptor generation code is present twice, in the
case of derived type entities, and in the case of polymorphic
non-coarray entities. Factor it in preparation for a future third case
that will also need the same code for scalar descriptor generation.
gcc/fortran/ChangeLog:
Move cleanup code for the data descriptor after the finalization code
as it makes more sense to have it after.
Other cleanup blocks should be empty (element size and final pointer
are just data references), but add them by the way, just in case.
gcc/fortran/ChangeLog:
* trans.cc
Reuse twice the same final procedure pointer expression instead of
translating it twice.
Final procedure pointer expressions were translated twice, once for the
final procedure call, and once for the check for non-nullness (if
applicable).
gcc/fortran/ChangeLog:
* trans.cc
and partially tested
with RUNTESTFLAGS="dg.exp=*final*".
The complete set has been fully tested on x86_64-pc-linux-gnu.
OK for master?
[1] https://gcc.gnu.org/pipermail/fortran/2023-July/059582.html
[2] https://gcc.gnu.org/pipermail/fortran/2023-July/059583.html
Mikael Morin (14):
fortra
gcc/fortran/ChangeLog:
* trans.cc (get_vptr): New function.
(gfc_add_finalizer_call): Move virtual table pointer evaluation
to get_vptr.
---
gcc/fortran/trans.cc | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git
Function gfc_build_final_call has been simplified, inline it.
gcc/fortran/ChangeLog:
* trans.cc (gfc_build_final_call): Inline...
(gfc_add_finalizer_call): ... to its one caller.
---
gcc/fortran/trans.cc | 66 +---
1 file changed, 25
gcc/fortran/ChangeLog:
* trans.cc (get_elem_size): New function.
(gfc_build_final_call): Outline the element size evaluation
to get_elem_size.
---
gcc/fortran/trans.cc | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
gcc/fortran/ChangeLog:
* trans.cc (get_var_descr): New function.
(gfc_build_final_call): Outline the data reference descriptor
evaluation code to get_var_descr.
---
gcc/fortran/trans.cc | 149 ---
1 file changed, 83 insertions(+),
gfc_add_finalizer_call creates one expression which is only used
by the get_final_proc_ref function. Move the expression generation
there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Remove local variable
elem_size. Pass expression to get_elem_size and move the
gcc/fortran/ChangeLog:
* trans.cc (get_final_proc_ref): New function.
(gfc_build_final_call): Outline the pointer evaluation code
to get_final_proc_ref.
---
gcc/fortran/trans.cc | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git
Hello,
I saw the light regarding this PR after Paul posted a comment yesterday.
Regression test in progress on x86_64-pc-linux-gnu.
I plan to push in the next hours.
Mikael
-- >8 --
Release symbols in reversed order wrt the order they were allocated.
This fixes an error recovery ICE in the
In the case of an array actual arg passed to a polymorphic array dummy
with INTENT(OUT) attribute, reorder the argument evaluation code to
the following:
- first evaluate arguments' values, and data references,
- deallocate data references associated with an allocatable,
intent(out) dummy,
-
In the case of a scalar actual arg passed to a polymorphic assumed-rank
dummy with INTENT(OUT) attribute, avoid repeatedly evaluating the actual
argument reference by saving a pointer to it. This is non-optimal, but
may also be invalid, because the data reference may depend on its own
content.
-gnu. OK for master?
[1] https://gcc.gnu.org/pipermail/fortran/2023-July/059562.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
Mikael Morin (3):
fortran: defer class wrapper initialization after deallocation
[PR92178]
fortran: Factor data references for scalar class argument
If an actual argument is associated with an INTENT(OUT) dummy, and code
to deallocate it is generated, generate the class wrapper initialization
after the actual argument deallocation.
This is achieved by passing a cleaned up expression to
gfc_conv_class_to_class, so that the class wrapper
Hello,
Le 07/07/2023 à 20:23, Harald Anlauf a écrit :
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
Le 05/07/2023 à 22:36, Harald Anlauf a écrit :
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
Le 04/07/2023 à 21:37, Mikael Morin a écrit :
Le 04/07/2023 à 21:00, Harald Anlauf a écrit :
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
Le 04/07/2023 à 21:00, Harald Anlauf a écrit :
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
Le 03/07/2023 à 22:49, Harald Anlauf a écrit :
Hi Mikael,
Am 03.07.23 um 13:46 schrieb Mikael Morin:
These look good, but I'm surprised that there is no similar change at
the 6819 line.
This is the class array actual vs class array dummy case.
It seems to be checked by the "bar"
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 following code is conforming:
program p
call s ((1))
contains
subroutine s (x)
Hello,
Le 02/07/2023 à 22:38, Harald Anlauf via Fortran a écrit :
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.
Le 22/06/2023 à 22:23, Harald Anlauf via Fortran a écrit :
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
Le 20/06/2023 à 18:30, Tobias Burnus a écrit :
On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote:
Is there a better way to detect a type(c_ptr) formal argument?
u.derived->intmod_sym_id == ISOCBINDING_PTR ?
&& u.derived->from_intmod == INTMOD_ISO_C_BINDING ?
Le 10/06/2023 à 22:28, FX Coudert via Fortran a écrit :
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373
I don’t believe it is widely used, and it was removed from everywhere else in
gcc.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?
FX
OK, thanks.
Le 08/06/2023 à 11:58, Tamar Christina via Gcc-patches a écrit :
Hi,
New version of the patch, I've omitted the explanation again
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Hello,
this is not my area of expertise, but I saw the following:
+ /*
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 his comment was about the case
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 existing error paths in
gfc_match_kind_spec and error
Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit :
Hi All,
This started out as the search for a fix to pr109948 and evolved to roll in
5 other prs.
Basically parse_associate was far too clunky and, in anycase, existing
functions in resolve.cc were well capable of doing the
Le 21/05/2023 à 22:48, Harald Anlauf via Fortran a écrit :
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
Le 24/05/2023 à 21:16, Harald Anlauf via Fortran a écrit :
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
1 - 100 of 959 matches
Mail list logo
