On 1/24/25 12:25 AM, Andre Vehreschild wrote:
Hi Jerry,
the patch looks good to me.
One small nit: in write.c after the period of the first sentence should be two
space, when I am not mistaken.
Thanks for the patch,
Andre
Thanks for review. Pushed as:
commit r15-7181-g4daf088123b
Hello all,
The attached patch is straight forward. I spent more time on getting the
test case ready. Thanks Steve for finding this and narrowing down where
the problem was.
Regression tested on x86_64-linux-gnu.
OK for trunk? What about a backport to 14?
Regards,
Jerry
Author: Jerry DeLis
On 1/26/25 2:07 PM, Harald Anlauf wrote:
Dear all,
in the checking of imported interfaces we need to use the local names
of procedures that are renamed-on-use, as the original name becomes
inaccessible. Similarly, we should not compare interfaces of
non-bind(C) procedures against bind(C) interf
Hello all,
The attached patch is part 1 of my effort to fix these X and T edit
descriptor issues. This one cleans up some really ugly output.
Before the patch with the test case provided by the reporter:
PI.^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931
REAL(PI)
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.
I also installed flang and noticed this. I also received a auto patch
test on ARM that causes me
On 1/28/25 12:49 PM, Harald Anlauf wrote:
Dear all,
the attached simple and obvious patch fixes an issue found when running
a UBSAN instrumented compiler on a recent testcase, see PR. Also
verified when running f951 under gdb on that testcase.
I intend to commit within the next 24 hours unless
On 1/25/25 11:12 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes bogus errors with CLASS variables in BLOCK DATA
that showed up because some compiler-generated components were not
declared as artificial.
Furthermore, a warning can be emitted for variables declared but not in
a COMMO
e current code is fine.
* * *
On 1/7/25 12:06 PM, Jerry D wrote:
cannot understand why moving the forall_iterator from the sub-
structure 'concur' back to where it was at the 'ext' sub-structure of
typedef struct gfc_code. 'ext' is a union. I suspected there is an
Committed as:
commit 20b8500cfa522ebe0fcf756d5b32816da7f904dd (HEAD -> master,
origin/master, origin/HEAD)
Author: Anuj Mohite
Date: Mon Jan 13 16:28:57 2025 -0800
Fortran: Add LOCALITY support for DO_CONCURRENT
This patch provided by Anuj Mohite as part of the GSoC project
On 1/2/25 12:04 PM, Harald Anlauf wrote:
Dear all,
this patch addresses overeager optimization of Cray pointers when
used in comparisons. Cray pointers are non-standard, and odd in a
sense that they were introduced before modern Fortran pointers.
Comparisons with e.g. a "NULL" pointer are actua
On 12/23/24 9:19 AM, Harald Anlauf wrote:
Dear all,
while preparing the testcase null_actual_7.f90 for commit r15-6408,
I overlooked a corner case, leading to a regression (PR118179).
The obvious solution is to extend the suppression of copying back
the pointer also for NULL actual arguments to
On 1/15/25 1:13 PM, Thomas Koenig wrote:
Am 09.01.25 um 14:36 schrieb Thomas Koenig:
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
... with the
On 1/10/25 9:19 AM, Paul Richard Thomas wrote:
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his
name out of a total of 54 for fortran and libgfortran. It's time that
some of these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 1/7] Fortran: Move caf_get-rewrite to rewrite.cc [PR107635]
Add a rewriter to keep all expression tree manipulation that is not
optimization together. At the moment this is just a move from resolve.cc,
but will be extended to handle more cases
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
Regards,
Jerry
Author: Jerry DeLisle
Date: Tue Feb 11 20:57:50 2025 -0800
Fortran: gfortran allows type(C_ptr) in
On 2/13/25 7:09 PM, Jerry D wrote:
On 2/13/25 1:42 PM, Harald Anlauf wrote:
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635]
I have applied all patches. Regression tested OK here.
From patch 5 there was one reject:
patching file gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
Hunk #1 FAILED at 39
On 2/13/25 11:59 AM, Thomas Koenig wrote:
Hello world,
this was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine.
On 2/13/25 1:42 PM, Harald Anlauf wrote:
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is not a review, just some random
On 2/13/25 11:48 AM, Jerry D wrote:
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635]
I have applied all patches. Regression tested OK here.
From patch 5 there was one reject:
patching file gcc/testsuite/gfortran.dg/coarray
On 2/19/25 10:08 AM, Tobias Burnus wrote:
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passe
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
Author: Jerry DeLisle
Date: Wed Feb 26 17:26:26 2025 -080
On 2/25/25 9:18 AM, Andre Vehreschild wrote:
Hi all,
for some recreation after all the coarray stuff, I found this pr cc'ed to me.
Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the
assignment was doing the harm. The data seems to be not written back into the
vector shaped d
On 2/27/25 12:33 PM, Peter Hill wrote:
On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
On 2/27/25 7:38 AM, Peter Hill wrote:
Dear all,
The attached patch fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the
On 2/27/25 11:31 AM, Harald Anlauf wrote:
Am 27.02.25 um 02:58 schrieb Jerry D:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for t
On 2/27/25 7:38 AM, Peter Hill wrote:
Dear all,
The attached patch fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the original check, this patch fixes the case where the
other actual argument is an array literal (
On 2/26/25 5:58 PM, Jerry D wrote:
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
A
On 3/5/25 6:34 AM, Andre Vehreschild wrote:
Hi all,
attached patch fixes a gimplification error when a pointer remapping on derived
type's components with deferred arrays is made. The issue boiled down to the
dependency analysis being to loose. It saw a dependency as soon as both sides
of the =>
On 3/6/25 10:02 AM, Steve Kargl wrote:
Andre,
Here's a bit of wordsmith. I removed the abbreviation "Esp."
I'm not sure if there is additional markup needed; especially,
with the "-fcoarray=single" I inserted.
Coarray support has been reworked to allow access to components
in derived typ
On 3/10/25 1:08 AM, Andre Vehreschild wrote:
Hi Steve and Jerry,
thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you please
take another look?
Jerry, where do I find this check-script? In bin/ nothing ju
On 3/10/25 9:57 AM, Jerry D wrote:
On 3/10/25 1:08 AM, Andre Vehreschild wrote:
Hi Steve and Jerry,
thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you
please
take another look?
Jerry, where do I
Hi Herald,
Looks good to me. I have always preferred informative messages.
Thanks,
Jerry
On 7/14/22 1:34 PM, Harald Anlauf via Fortran wrote:
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
On 8/9/23 7:58 AM, Paul Richard Thomas via Fortran wrote:
I took a look at my calendar and decided to backport right away.
r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
BTW It is a regression :-)
Paul
On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas
wrote:
Committed to trunk as 'obvio
The attached patch is minor and self explanatory. I assume this should
wait for gfortran 14 since no regression involved. Please advise otherwise.
Regression tested on x86-64.
OK for trunk when the time is right?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Feb 25 20:30:35 2023 -0800
’
declared here
84 | index_type mstride[GFC_MAX_DIMENSIONS];
| ^~~
In a sense it is a regression. It showed up when builds started to use
-Wmaybe-unitialized.
Cheers,
Harald
Am 26.02.23 um 20:52 schrieb Jerry D via Gcc-patches:
The attached patch is minor and self
Pushed, thanks for feedback
On 2/26/23 11:54 PM, Tobias Burnus wrote:
Just side remarks, the 0 init in the patch is fine.
On 27.02.23 03:53, Jerry D via Gcc-patches wrote:
regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a
gc
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
libgfortran/caf/single.c |6 ++
libgfortran/io/async.c |6 ++
libgfortran/io/format.c |3 +--
libgfortran/io/transfer.c
On 3/3/23 3:32 PM, Iain Sandoe wrote:
On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran
wrote:
On 2 March 2023 02:23:10 CET, Jerry D wrote:
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote
On 3/9/23 10:08 AM, Harald Anlauf via Fortran wrote:
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
q
I plan to commit the following as simple.
The issue was a value was being modified on a short namelist read. After
tthe first read gives the correct EOF, a second read would give the
error but modify the variable.
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 82664dc5f98..3
On 5/17/23 11:52 AM, Harald Anlauf via Fortran wrote:
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 lea
On 4/4/22 12:04 PM, Harald Anlauf via Fortran wrote:
Dear all,
Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic. The standard allows such recursive references
(see e.g. F2018:19.3.1).
The attac
On 4/4/22 12:09 PM, Harald Anlauf via Fortran wrote:
Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran:
Dear all,
during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and cons
Remember the days when reading very old cryptic Fortran code? Remember
the fixed line lengths and cryptic variable names!
I fear the Standards committee has achieved history with the Standard
itself it is so difficult to understand sometimes.
Cheers to Paul and Harald for digging on this.
Je
For what it is worth.
On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagree
On 2/23/22 2:21 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four (4!) years ago,
but so far the frontend implementation was missing.
Furthermore, F2018 allows for
Yes, Thank you Mikael!
On 4/22/22 6:59 AM, Thomas Koenig via Fortran wrote:
Hi Mikael,
Ping for the four patches starting at
https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
https://gcc.gnu.org/pipermail/fortran/2022-
Harald,
Looks good. OK and thanks for your time and efforts.
Jerry
On 9/23/21 12:47 PM, Harald Anlauf via Fortran wrote:
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
expressi
Looks good and simple. Proceed. Thanks
Jerry
On 10/28/21 5:05 PM, Bernhard Reutner-Fischer via Fortran wrote:
ping
[Rebased, re-regtested cleanly. Ok for trunk?]
On Wed, 5 Sep 2018 14:57:31 +
Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
compiling gfortran.dg/typeboun
Looks OK.
Cheers
On 10/29/21 11:58 AM, Bernhard Reutner-Fischer via Fortran wrote:
ping
On Wed, 5 Sep 2018 14:57:04 +
Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
Aids debugging the fortran FE.
gcc/ChangeLog:
2017-11-12 Bernhard Reutner-Fischer
* gdbin
yes, please commit
On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote:
On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote:
Ping, ping!
Please find attached a rebased version of the patch for the RANDOM_INIT issue
with coarray Fortran. Nothing changed to the previous version, just
On 10/8/21 2:33 PM, Harald Anlauf via Fortran wrote:
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 r
This one looks OK. Sorry I missed it earlier. Thanks again for the patch!
Jerry
On 10/9/21 12:27 PM, Harald Anlauf via Fortran wrote:
*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
Looks OK Thomas,
Good for backport as well.
Regards,
Jerry
On 7/4/21 9:09 AM, Thomas Koenig via Fortran wrote:
Hello world,
after a bit of an absence, I am now back, at least for some regression
fixing (and for reviewing patches, if that is called for).
So, here's a regression fix to start
Good to go Tobias.
Jerry
On 7/14/21 5:50 AM, Burnus, Tobias wrote:
Ping**2
On Juli 8, 2021 I wrote:
*Ping*
I intent to incorporate Sandra's suggestions, except for the beginning of line
spacing - that's needed to avoid exceeding the 80 character line limit. I did
not include an updated pat
On 12/10/22 1:23 PM, Harald Anlauf via Fortran wrote:
Dear all,
I'm submitting the attached patch on behalf of Steve.
It fixes an ICE that occurs on an obscure use of a
statement function as argument to that function.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
OK, lo
Hi all,
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and
I will commit under the "simple" rule in a little while.
Thanks Steve for Patch. Thanks Harald for helping me get back up to
speed on the g
On 12/19/22 2:29 AM, Jakub Jelinek wrote:
On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote:
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and I
will commit under the "s
I have committed the obvious as simple.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:7e76cd96950f49ce21246d44780e972d86b2bcdd
commit r13-4862-g7e76cd96950f49ce21246d44780e972d86b2bcdd
Author: Steve Kargl
Date: Thu Dec 22 20:38:57 2022 -0800
Remove not need
On 12/17/22 1:21 PM, Harald Anlauf via Fortran wrote:
Dear all,
the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration. The reason was that we tried to simplify too early
the array element spec,
On 12/23/22 6:08 AM, Thomas Schwinge wrote:
Hi!
On 2022-11-11T15:35:44+0100, Richard Biener via Fortran
wrote:
On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote:
For example, for Fortran code like:
write (*,*) "Hello world"
..., 'gfortran' creates:
struct __st_parameter_dt
On 1/11/23 4:06 AM, Thomas Schwinge wrote:
Hi!
Ping -- the '-mframe-malloc-threshold' idea, at least.
Note that while this issue originally did pop up for Fortran I/O, it's
likewise relevant for other functions that maintain big frames, for
example in newlib:
libc/string/libc_a-memmem.o:.
On 1/18/23 7:42 AM, Tobias Burnus wrote:
Reported by nightstrike, who also tested this patch.
On Windows, we call system() which works as described at
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170
Namely, it only fails with "-1" if the command in
On 8/24/23 2:28 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adds stricter bounds-checking for DATA statements
with implied-do. I chose to allow overindexing (for arrays of rank
greater than 1) for -std=legacy, as there might be codes in the wild
that need this (and this is
On 9/18/23 1:27 PM, Harald Anlauf via Fortran wrote:
Dear all,
as correctly analyzed by Jerry, the code for checking the consistency
of character lengths in array constructors did not properly initialize
the auxiliary variable used in "bounds checking". The attached patch
resolves this by initi
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run in a location such
that a path in an error message showing in the tree-dump might
have accidentally matched "free" or "data", res
The attached patch adds a check for the invalid comma and emits a
runtime error if -std=f95,f2003,f2018 are specified at compile time.
Attached patch includes a new test case.
Regression tested on x86_64-linux-gnu.
OK for mainline?
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri May 5 20:
n standard conformance mode, or do we?
Cheers,
Harald
On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote:
On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote:
The attached patch adds a check for the invalid comma and emits a
runtime
error if -std=f95,f2003,f2018 are specified
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which turns
out to be too late when trying to assign a zero sized array.
To correct this, the check is moved to match_variable() in primary.cc
where
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which turns
out to be too late when trying to assign a zero sized array.
Correction, the chunk in data.cc must
On 1/20/23 9:16 PM, Jerry D wrote:
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which
turns out to be too late when trying to assign a zero sized array
On 1/20/23 6:13 PM, Jerry DeLisle via Fortran wrote:
Hi all,
The attached patch modifies the following tests to check for line
endings. Some test environments inject superfluous /r characters at
ends of lines. The expression matching in dg-output tests are changed from:
(\n|\r\n|\r)
to
(\r*\
On 1/22/23 5:38 AM, Mikael Morin wrote:
Hello,
Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit :
(...)
Proposed ChangeLog entry using git gcc-commit-mklog:
Author: Jerry DeLisle
Date: Sat Jan 21 15:47:19 2023 -0800
Revise the line end tests to pass on certain windows test
Committed:
It is not apparent to me that the testsuite/ChangeLog was updated. Maybe
there is a time delay on that?
Please be patient with me as I figure out how all this works.
ommit f963705752e9d0b79a340788166269af417e344e (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
On 1/24/23 1:48 PM, Harald Anlauf via Fortran wrote:
Dear all,
when checking expressions for array sections, we need to ensure
that these use only type INTEGER. However, it does not make sense
to generate an internal error when encountering wrong types,
but rather take the ordinary route of err
On 1/28/23 9:07 AM, Harald Anlauf via Fortran wrote:
Dear all,
a USE associated symbol shall not appear in a COMMON block
(F2018:C8121) and needs to be diagnosed. The patch is
fairly obvious.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As the PR is marked as a 10/11/12/13 regression,
On 2/5/23 11:33 AM, Harald Anlauf via Fortran wrote:
Early gentle ping.
Am 30.01.23 um 22:55 schrieb Harald Anlauf via Gcc-patches:
Dear Fortranners,
the subject says it all: in some cases we emit redundant integer division
truncation warnings (2 or 4), where just one would have been sufficien
On 2/6/23 12:10 PM, Harald Anlauf via Fortran wrote:
Dear all,
as the PR shows, it is likely not a good idea to try to make an
ASSOCIATE variable static when -fno-automatic is specified, so
rather keep it on the stack.
Attached patch regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
On 1/13/22 12:56 PM, Harald Anlauf via Fortran wrote:
Dear all,
there was a regression handling overloaded elemental intrinsics,
leading to an ICE on valid code. Reported by Urban Jost.
The logic for when we need to scalarize a call to an intrinsic
seems to have been broken during the 9-releas
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote:
Dear all,
when comparing formal and actual arguments of a procedure, there was no
check of rank for derived types from intrinsic module ISO_C_BINDING.
This could lead to a wrong resolution of generic procedures with dummy
argument of related t
101 - 180 of 180 matches
Mail list logo
