Here's an update to the previous patch.
Upon reflection, I think it is better for performance to have two
versions of the loop so the test is only performed when it is
needed.
So, OK for trunk?
Regards
Thomas
Fix EOF handling for arrays.
2019-11-23 Thomas Koenig
Harald
Am 23.11.19 um 14:15 schrieb Thomas Koenig:
* gfortran.dg/eof_4.f90: New test.
This should be eof_6.f90 (and will be on commit).
Regards
Thomas
Actually, that was 92422. ChangeLog changed correspondingly.
Hi,
the PR is a gcc-9 only regression, for which I just committed a test
case to trunk.
We can then check what fixed this...
2019-11-23 Thomas Koenig
PR fortran/92442
* gfortran.dg/bounds_check_21.f90: New test.
! { dg-do compile }
! { dg-options "-Warray-bound
Koenig
Harald Anlauf
PR fortran/92569
* io/transfer.c (transfer_array_inner): If position is
at AFTER_ENDFILE in current unit, return from data loop.
2019-11-23 Thomas Koenig
Harald Anlauf
PR fortran/92569
* gfortran.dg/eof_4.f90: New
Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
+ char name[GFC_MAX_SYMBOL_LEN + 1];
+ snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
+ f->sym->name);
+
+ if (gfc_get_sym_tree (name, ns, , false) != 0)
(I) you should +
Hi Steve,
On Fri, Nov 15, 2019 at 10:40:56AM +, Mark Eggleston wrote:
This patch allows comparison of numeric values with Holleriths. This
feature is not guarded by a compiler option as it is preferred that
extra options should avoided, this seems reasonable as current Hollerith
support
"(?n)__attribute__\\(\\(oacc kernels parallelized, oacc
function \\(, , \\), oacc kernels, omp target entrypoint\\)\\)" 1
So, OK for trunk?
Regards
Thomas
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc
Am 11.11.19 um 22:55 schrieb Thomas König:
Regression-tested. OK for trunk?
Of course, better with a ChangeLog entry.
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc_namespace.
(show_code_node): Add INIT_ on dumping
Hi Janne,
Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
requirement one can still build GCC with the operating system provided
MPFR on old but still supported operating systems like SLES 12 (MPFR
3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).
OK for trunk.
Can you also
Hi,
I just committed the patch below as obvious to fix a 9/10 regression
when directly calling BLAS routines for matmul. Will backport
to gcc-9 soon.
Regards
Thomas
Commit symbol for external BLAS routine when translating MATMUL to *GEMM.
2019-11-09 Thomas Koenig
PR
Hi Steve,
OK for trunk/9/8?
OK for all three.
Thanks, committed to trunk as r277760.
I'll be AFK for a few days, so I will have to wait before
committing this to gcc-9. Given the convoluted history of
this bug, this might not be a bad thing.
> It is, as you have indicated, troublesome
there.
OK for trunk/9/8?
Regards
Thomas
2019-11-02 Thomas Koenig
PR fortran/92133
* trans-decl.c (gfc_get_symbol_decl): If __def_init actually
contains a value, put it into the read-only section.
Index: trans-decl.c
Hi Tobias,
OK for the trunk and GCC 9?
As far as I can see, this looks good.
So, OK for trunk. If it later turns out that there are problems
caused by this, I suspect we will hear about them soon enough :-)
Thanks for taking this on!
Regards
Thomas
However, passing a scalar instead of an array/array
element worked/works with (nearly?) all compilers. Hence, passing
a scalar is seemingly common pattern. Thus, I wonder whether we
should do something about this.
Maybe we could mention -fallow-argument-mismatch in the error message.
Committed, with that nitch, r276972.
OK with a minor nit. — Thanks for the patch.
Thanks a lot for the review!
Regards
Thomas
OK, so here's the update. There was a problem with uninitialized
variables, which for some reason was not detected on compilation.
OK for trunk?
2019-10-13 Thomas Koenig
PR fortran/92004
* array.c (expand_constructor): Set from_constructor on
expression
Hm, my trunk is doing strange things (debugging not working),
and I think I have found an additional problem. I'll need some
time to work this out, and will resubmit.
Regards
Thomas
.
As you can see in the test case, I tried to cover all relevant
cases.
Regression-tested. OK for trunk?
Regards
Thomas
2019-10-12 Thomas Koenig
PR fortran/92004
* array.c (expand_constructor): Set from_constructor on
expression.
* gfortran.h (gfc_symbol
Am 11.10.19 um 05:54 schrieb Steve Kargl:
The attach patch has been tested on x86_64-*-freebsd.
OK to commit.
Yes.
Again, thanks a lot for the patch"
Steve,
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
OK. Thanks a lot for the patch!
Regards
Thomas
Hi Tobias,
function ("o" missing); I think it is not clause 14 but paragraph 14.
Fixed. (That one was easy :-)
+ warning for this can be suppressed later. */
+
+bool
+maybe_dummy_array_arg (gfc_expr *e)
+{
+ gfc_symbol *s;
+
+ if (e->rank > 0)
+ return false;
+
+ if (e->ts.type ==
Hi,
this patch fixes an overzealous interpretation of F2018 15.5.2.4, where
an idiom of passing an array element to an array was rejected. This
also restores Lapack compilation without warning.
Regression-tested. OK for trunk?
Would it be possible to get a speedy review on this? I'd like to
Hi Steve,
Tested on x86_64-*-freebsd. OK to commit?
OK.
Thanks a lot for the patch!
Am 06.10.19 um 17:26 schrieb Thomas Koenig:
This
also restores Lapack compilation without warning.
Well, up to an error in the testing routines, at least.
TESTING/LIN/sdrvls.f has
REAL, ALLOCATABLE :: WORK (:)
...
REAL RESULT( NTESTS ), WQ
and calls
Hello world,
this patch fixes an overzealous interpretation of F2018 15.5.2.4, where
an idiom of passing an array element to an array was rejected. This
also restores Lapack compilation without warning.
Regression-tested. OK for trunk?
Regards
Thomas
2019-10-06 Thomas Koenig
Hi Steve,
The attached patch has been tested on x86_64-*-freebsd.
OK to commit.
OK.
Thanks a lot for the patch!
Since this seems to be a regression to before when %FILL was introduced,
also OK to backport as far as you care to do it.
Regards
Thomas
Steve,
The attach patch silences -Wconversion and -Wconversion-extra
warnings that had previously been issued for explicit conversions
(see testcase for examples).
The patch has been tested on x86-*-freebsd. OK to commit?
OK.
Thanks a lot for the patch!
Regards
Thomas
Hi,
Jakub, do you have any comments? After Seve's OK I plan to commit in a
couple of days unless I read anything to the contrary.
Regards
Thomas
this patch makes sure that the __def_init variables, which have been
generated for normal allocatable arrays for quite some time, do not
and the design improvement.
Test case... I'm not sure what to test for.
Regression-tested. OK for all affected branches?
Regards
Thomas
2019-09-25 Thomas Koenig
PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set
Hi David,
does this look sane?
Yes.
OK for trunk, and thanks a lot!
Regards
Thomas
Hi David,
I think technically I can self-approve this, but I'm not a
day-to-day user of fortran; does this look sane?
Very much so, I also find this more readable.
I'd wait another day or so for comitting this, so that other people
with different aesthetic sense can also chime in if they
Hi Steve,
s/previusly/previously
Fixed, committed. Thanks for the review!
Do you it gfortran should skip the front-end optimization pass
if error(s) have already been reported? On entry ito this pass,
you could test for the error count and simply return.
I thought about this for doing
Hello world,
the attached patch fixes an ICE on invalid, where the fact that
the step in do i = 1, 3, .1 is actually zero slipped through.
Regression-tested. OK for all affected branches (trunk, 9 and 8)?
Regards
Thomas
2019-09-15 Thomas Koenig
PR fortran/91550
ted branches.
After this, I think we can close PR 91556. Regression-tested. OK for
trunk?
2019-09-13 Thomas Koenig
PR fortran/91557
PR fortran/91556
* frontend-passes.c (check_externals_procedure): Reformat argument
list. Use gfc_compare_actual_formal instead
"make pdf".
OK for trunk?
Regads
Thomas
2019-08-25 Thomas Koenig
PR fortran/91390
PR fortran/91473
* frontend-passes.c (gfc_check_externals): Make
gfc_errors_to_warnings conditional on -fallow-argument-mismatch.
* invoke.texi: Docum
Am 20.08.19 um 22:32 schrieb Thomas König:
here is the next installment of checking for mismatched calls,
this time for mismatching CALLs.
The reorganization of the code also means that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519 (a rejects-valid
regression) is fixed by this patch.
I wrote:
Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom at one time. And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where
Hi Janne,
The patch itself looks Ok. One worry, are you introducing an
O(N**2)(?) algorithm (looping over all symbols for every symbol?), and
does this cause performance issues when compiling some gigantic F77
project?
This is a single pass over the code, so O(N) for the code size.
The lookup
-15 Thomas Koenig
PR fortran/91443
* frontend-passes.c (check_externals_expr): New function.
(check_externals_code): New function.
(gfc_check_externals): New function.
* gfortran.h (debug): Add prototypes for gfc_symbol * and
gfc_expr
branches.
Regards
Thomas
2013-08-13 Thomas Koenig
PR fortran/90563
* frontend-passes.c (insert_index): Suppress errors while
simplifying the resulting expression.
2013-08-13 Thomas Koenig
PR fortran/90563
* gfortran.dg/do_subsript_5.f90
Hi Steve,
Ok. If it regression cleanly on gcc9, go ahead an commit there as well.
Committed to both (after doing a regression test on gcc 9 and also
waiting for gcc-testresults containing the revision).
Thanks for the review!
-tested. OK for trunk? I also think that this is something
that could be safely backported to gcc-9.
2019-08-12 Thomas Koenig
PR fortran/91424
* frontend-passes.c (do_subscript): Do not warn for an
expression a second time. Do not warn about a zero-trip loop
Hi Steve,
OK to commit?
OK with
%s/rational/relational/g
and with Mark's nit.
Thanks a lot for going down that road. I like the approach of
-fallow-invalid-boz to downgrade the error to a warning, which
then cannot be turned off.
Regards
Thomas
Hi Steve,
The attach patch has been regression tested on x86_64-*-freebsd.
There were no regression.
The patch prevents an ICE when checking for aliasing and the
actual arguments are the real and imaginary parts of a complex
entity. See the testcase for more information.
OK to commit to both
Hi Paul,
That is very well done. Thanks for picking it up and running with it.
OK on both the fix and the dumping of the gsymbols.
Committed, thanks.
You might consider back porting both this patch and my fix for the
original bug to 9-branch.
Both patches apply cleanly together on gcc-9
for trunk?
Regards
Thomas
2019-07-28 Thomas Koenig
PR fortran/90813
* dump-parse-tree.c (show_global_symbol): New function.
(gfc_dump_global_symbols): New function.
* gfortran.h (gfc_traverse_gsymbol): Add prototype.
(gfc_dump_globa
Hi Steve,
Ah, I don't speak C++, and didn't know one could corrupt a
C prototype in this manner. A quick glance of gfortran.h
indeed shows a few more occurences of "bool xxx = false".
I suppose the patch is then OK.
I don't use many C++ features, but I use this one because I feel
it should
Hi Steve,
-int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *);
+int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool identical =
false);
This is changing the prototype. I would expect to see
int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool);
Usig C++'s
, I checked for the names of the variables which used to
be introduced by the matmul inlining code.
Regression-tested. OK for trunk?
Regards
Thomas
2019-07-25 Thomas Koenig
PR fortran/65819
* dependency.h (gfc_dep_resovler): Add optional argument identical
Hi Steve,
On Sun, Jul 14, 2019 at 12:07:58PM +0200, Thomas Koenig wrote:
OK, so here is a new version.
I think the discussion has shown that enlaring the buffer makes sense,
and that the buffer size for unformatted seems to be too bad.
I've reversed the names of the environment variables
... of course, better with the actual patch.
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 273183)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -611,6 +611,8 @@ Malformed environment variables are
OK, so here is a new version.
I think the discussion has shown that enlaring the buffer makes sense,
and that the buffer size for unformatted seems to be too bad.
I've reversed the names of the environment variables according to
Behnard's suggestion.
So, OK for trunk?
Also, what should we do
Hello world,
the attached patch sets the I/O block size for unformatted files to
2**17 and makes this, and the block size for formatted files,
adjustable via environment variables.
The main reason is that -fconvert=big-endian was quite slow on
some HPC systems. A bigger buffer should eliminate
Hi Martin,
LTO bytecode is not supposed to be a distributable format.
One of my dreams is to make libgfortran LTO-clean. There is
a lot of performance to be gained both in I/O (where a huge
number of special cases could be shortcut by LTO, because
hardly any program uses them all) and in
.
Regards
Thomas
2019-06-20 Thomas Koenig
PR fortran/90937
* trans-types.c (get_formal_from_actual_arglist): Get symbol from
current namespace so it will be freed later. If symbol is of type
character, get an empty character length.
2019-06-20 Thomas Koenig
Am 20.06.19 um 11:07 schrieb Martin Liška:
On the contrary, decompression
of zstd with zlib will end with:
lto1: internal compiler error: compressed stream: data error
Sogenerating object files on one system and trying to read them
on another system which does not happen to have a particular
Hi,
I just committed the attached patch as obvious ans simple. No impact
on user code, just to make internal debugging easier.
Regards
Thomas
2019-06-16 Thomas Koenig
* dump_parse_tree (debug): Add verison for formal arglist.
Do not crash when a gfc_expr is NULL
Hi Paul,
I cannot see anything wrong with the optimized code and valgrind gives
a clean bill of health on x86_64.
We need help of somebody with access to an arm/aarch64 device.
I'm currently running a bootstrap on an aarch64 machine. These
are not known to be the fastest of machines, but it
ng version of the
patch was done by Tomáš Trnka (thanks!).
I will also backport, since this is a 7/8/9/10 regression.
Regards
Thomas
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90744
* trans-types.c (get_formal_from_actual_arglist): Unset typespec
flags
call foo(a,b,size(a))
end subroutine bar
end module y
Test case is only for the first part - making one for the second
part would have been a bit too much.
Regression-tested. OK for trunk?
Regards
Thomas
2019-06-02 Thomas Koenig
PR fortran/90539
* trans-expr.c
Hi Steve,
Thomas, with the above fixes, I think this a great
addition to manual. OK to commit.
Committed with your fixes (sometimes I think my fingers
are going blind :-) as r271786.
Best regards
Thomas
quot;.
OK for trunk?
Regards
Thomas
2019-05-30 Thomas Koenig
* gfc-internals.texi (Translating to GENERIC): New chapter.
Index: gfc-internals.texi
===
--- gfc-internals.texi (Revision 271629)
+++ gfc-internals
Hi Jakub,
As I said earlier in the PR, I don't like -fbroken-callers option much,
as the option name doesn't hint what it is doing at all.
The following patch renames the option and makes it into a 3 state option,
with the default being a middle-ground, where it avoids the tail calls in
how performance is with
this version).
OK for trunk?
Regards
Thomas
2019-05-29 Thomas Koenig
PR fortran/90539
* gfortran.h (gfc_has_dimen_vector_ref): Add prototype.
* trans.h (gfc_conv_subref_array_arg): Add argument check_contiguous
as obvious and simple,
r271630.
Regards
Thomas
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-types.c (get_formal_from_actual_arglist): Set rank
and lower bound for assumed size arguments.
Index: trans-types.c
: ChangeLog
===
--- ChangeLog (Revision 271375)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,11 @@
+2019-05-19 Thomas Koenig
+
+ PR fortran/90329
+ * invoke.texi: Document -fbroken-callers.
+ * lang.opt: Add -fbroken-callers.
+ * trans
Am 11.05.19 um 15:10 schrieb Thomas Koenig:
Hello world,
this new version of the inlie argument packing patch (PR 88821)
avoids the ICE on the test case for PR 61968. Otherwise it is
unchanged.
Regression-tested. OK for trunk?
Ping?
uot; all
passed. OK for trunk?
Regards
Thomas
2019-05-18 Thomas Koenig
PR fortran/90329
* invoke.texi: Document -fbroken-callers.
* lang.opt: Add -fbroken-callers.
* trans-decl.c (create_function_arglist): Only set
DECL_HIDDEN_STRING_LENGTH if fla
Hi Jakub,
Could we easily detect at resolve time whether a subroutine/function
makes any implicitly prototyped calls and limit this workaround to those
cases (i.e. only old-style Fortran)? I've mentioned it in the PR, but not
sure how exactly to check that.
I think we could to that. We
Hi Jakub,
I've found that gfortran.map doesn't export these 3 symbols (while it does
export other variants, with i1, i4, i8, i16, etc.).
Do we want to export them from both GCC 9.2 and 10 the following way, or
just on the trunk using GFORTRAN_10?
Both, please.
Tested on x86_64-linux.
Hi Janne,
I differ there.
A longer explanation:
fork() is standard POSIX. Not all systems have posix_spawn. For
those systems which do not have it, we would cause a regression
by simply removing that functionality for this.
The patch is OK from my side if you add fork() as a fallback
Am 16.05.19 um 22:10 schrieb Janne Blomqvist:
On Thu, May 16, 2019 at 10:59 PM Thomas Koenig wrote:
Hi Janne,
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https
Hi Janne,
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
This replaces the one use of fork in
Am 12.05.19 um 10:29 schrieb Janne Blomqvist:
Thanks, committed as r271106. I prefixed the macros with __GFORTRAN_,
as that seems clearer to users where those come from as gfc seems used
mostly in the compiler internals.
Sounds good.
Any opinions whether it should be committed to 9 as well?
Am 12.05.19 um 00:02 schrieb Jakub Jelinek:
Is it correct to use macros in user namespace? Shouldn't they be say __
prefixed, or even have __GFC_ or __GFORTRAN_ in them?
I think Jakub has a point there -- something like __GFC_DOUBLE_COMPLEX
would probably be better.
So, OK with that change.
Hi Dominique,
How ever adding the new tests is a real PITA!-(
Could you improve the naming scheme for them
What should be the preferrred naming scheme for a
test that is split? I'm open to suggestions (but also,
the naming convention should not matter once the test
cases are committed).
Hello world,
this new version of the inlie argument packing patch (PR 88821)
avoids the ICE on the test case for PR 61968. Otherwise it is
unchanged.
Regression-tested. OK for trunk?
Regards
Thomas
2019-05-11 Thomas Koenig
PR fortran/88821
* expr.c
Hi,
ping?
Not for me, I still get
% gfc pr61968.f90 -c -O3
pr61968.f90:32:0:
32 | call test_lib (a, int (sizeof (a), kind=c_size_t))
|
internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:1265
You're right, I will clear this up separately.
In
Hi Steve,> dicsouraged?
Fixed.
Otherwise, looks ok to me.
Committed, thanks.
Let's see where this leads...
Regards
Thomas
, with their transition
to something that does not violate gfortran's ABI.
Tested with "make dvi" and "make info". Otherwise, since these flags
are not tested in the testsuite (maybe they should be, I just don't
know how), regression test passed.
OK?
2019-05-08 Thomas Koenig
Thomas
2019-05-05 Thomas Koenig
PR fortran/90344
* frontend-passes.c (create_var): Bring into sync with gcc 8.
2019-05-05 Thomas Koenig
PR fortran/90344
* gfortran.dg/pr90344.f90: New test.
Index: frontend-passes.c
.
In the meantime, here is the one-line patch with the test case above
with -O3 added, so any failure will be noted soon.
OK for trunk?
Regards
Thomas
2019-05-02 Thomas Koenig
PR fortran/61968
* interface.c (compare_actual_formal): Do not create a vtab
Hello world,
the attached patch fixes an error where TYPE(*) ended up in a vtab,
with not-so delectable results. The solultion is simple - do not
create a vtab if the actual argument is TYPE(*).
This also clears the ICE for my inline packing patch which
was reported by Dominique.
Hi Andrew,
Fixing this seems to be simple:
--- gcc/fortran/module.c(revision 270772)
+++ gcc/fortran/module.c(working copy)
@@ -6052,6 +6052,9 @@ write_module (void)
{
int i;
+ /* Initialize the column counter. */
+ module_column = 1;
+
/* Write the operator
Hi Roman,
FAIL: gfortran.dg/inline_matmul_1.f90 scan-tree-dump-times optimized
"_gfortran_matmul" 0
With matmul, there are three versions you can get: The library version
(called as _gfortran_matmul), the inline version or a direct call
to the corresponding BLAS routine. Which one is called,
Hi Paul,
Could you provide the patch, please, or was it already posted?
Actually, no. I was so intent on providing the test cases that
I missed the patch itself :-)
Here it is.
Regards
Thomas
Index: fortran/expr.c
===
? (Not for backporting)
Regards
Thomas
2019-04-28 Thomas Koenig
PR fortran/88821
* expr.c (gfc_is_simply_contiguous): Return true for
an EXPR_ARRAY.
* trans-array.c (is_pointer): New function.
(gfc_conv_array_parameter): Call gfc_conv_subref_array_arg
Hi Paul,
Please find attached the updated patch, which fixes the problem with
-m32 in PR90022, eliminates the temporary creation for INTENT(IN)
dummies and fixes PR89846.
While it looks like it should be intrusive because of its size, I
believe that the patch is still safe for trunk since it
and the Fortran part?
Regards
Thomas
2019-04-13 Thomas Koenig
PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): Mark _def_init as
artificial.
2019-04-13 Thomas Koenig
PR fortran/84487
* varasm.c (bss_initializer_p): If we are compiling
Hello world,
I have just committed the attached patch as obvious and simple. It
fixes an error message so that it can be extracted for translation.
No test case because it does not change anything (which was verified
by regression-testing).
Regards
Thomas
2019-04-11 Thomas Koenig
Am 31.03.19 um 18:16 schrieb Thomas Koenig:
Am 31.03.19 um 18:10 schrieb Thomas Koenig:
Hello world,
the attached patch
Now really attached.
Ping?
were already in place,
I simply added the condition for the entry itself.
I will wait a week or so before committing to gcc-8, the only
other affected branch.
Regards
Thomas
2019-04-06 Thomas Koenig
PR fortran/89981
* resolve.c (resolve_global_procedure): If the global
Hi Harald,
OK for trunk (and affected backports)?
Yes, OK. Thanks!
(For cases like this, it often makes sense to wait a week
or so before backporting something, to see if anything
comes up).
Regards
Thomas
Am 31.03.19 um 18:10 schrieb Thomas Koenig:
Hello world,
the attached patch
Now really attached.
! { dg-do compile }
! { dg-additional-options "-fdump-tree-original" }
! PR 87352 - this used to cause an excessive number of deallocations.
module testmodule
implicit none
publ
for trunk and backporting?
Regards
Thomas
2019-03-31 Thomas Koenig
PR fortran/87352
* gfortran.h (gfc_component): Add finalized field.
* class.c (finalize_component): If the component is already
finalized, return early. Set component->finalized on e
Hi Paul,
Bootstrapped and regtested on FC29/x86_64 - OK for trunk?
OK - looks obvious enough, and, IMO, is quite unlikely to cause
a regressions.
Thanks for the patch!
Regards
Thomas
Am 27.03.19 um 22:54 schrieb Thomas Koenig:
I do not think this is correct.
... and I missed the point that this was specifically about
initializations.
So, OK from my side. Thanks!
Regards
Thomas
Hi Janus,
the attached patch implements some missing constraints from Fortran
2008 concerning procedure pointer initialization (cf. the standard
quote in comment #18), thus fixing two accepts-invalid and
ICE-on-invalid problems.
I do not think this is correct.
F2008:
# 12.2.2.4 Procedure
Hi Dominique,
Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html
I think the patch is OK. I think the patch is probably appropriate for
stage 1 once that reopens.
Regards
Thomas
401 - 500 of 1351 matches
Mail list logo
