On Wed, 27 Oct 2021 21:44:52 +0200
Harald Anlauf via Fortran wrote:
> Hi Bernhard,
>
> Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran:
> > AFAICS current trunk still has this issue.
> > Any takers?
> > thanks,
>
> can you create a PR tracking this issue?
now https://gcc.gn
AFAICS current trunk still has this issue.
Any takers?
thanks,
On Sun, 2 Sep 2018 17:16:07 +0200
Bernhard Reutner-Fischer wrote:
>i spotted one
> (pre-existing) possible inconsistency that i did overlook back then:
>
> gfc_match_associate () reads
On 18.07.21 06:36, Sandra Loosemore wrote:
This patch fixes bugs I observed in tests for the CFI_section function
-- it turns out both the function and test cases had bugs. :-(
The bugs in CFI_section itself had to do with incorrect computation of
the base address for the result descriptor, plus
Hi Sandra,
On 21.07.21 20:01, Sandra Loosemore wrote:
Hmmm. CFI_establish explicitly says that the elem_len has to be
greater than zero. It seems somewhat confusing that it's inconsistent
with the other functions that take an elem_len argument.
Congratulation – we have found a bug in the spec
On 7/21/21 11:26 AM, Tobias Burnus wrote:
On 17.07.21 02:49, Sandra Loosemore wrote:
This patch is for PR101317, one of the bugs uncovered by the TS29113
testsuite. Here I'd observed that CFI_establish, etc was not
diagnosing some invalid-argument situations documented in the
standard, altho
On 17.07.21 02:49, Sandra Loosemore wrote:
This patch is for PR101317, one of the bugs uncovered by the TS29113
testsuite. Here I'd observed that CFI_establish, etc was not
diagnosing some invalid-argument situations documented in the
standard, although it was properly catching others. After f
This patch fixes bugs I observed in tests for the CFI_section function
-- it turns out both the function and test cases had bugs. :-(
The bugs in CFI_section itself had to do with incorrect computation of
the base address for the result descriptor, plus an ordering problem
that caused it not
This patch is for PR101317, one of the bugs uncovered by the TS29113
testsuite. Here I'd observed that CFI_establish, etc was not diagnosing
some invalid-argument situations documented in the standard, although it
was properly catching others. After fixing those I discovered a couple
small mi
On 6/13/21 12:36 PM, José Rui Faustino de Sousa via Gcc-patches wrote:
Hi All!
Proposed patch to:
Bug 100906 - Bind(c): failure handling character with len/=1
Bug 100907 - Bind(c): failure handling wide character
Bug 100911 - Bind(c): failure handling C_PTR
Bug 100914 - Bind(c): errors handling
*PING*
Forwarded Message
Subject: [Patch, fortran] PR fortran/96870 - Class name on error message
Date: Mon, 31 Aug 2020 16:09:32 +
From: José Rui Faustino de Sousa
To: fort...@gcc.gnu.org, gcc-patches@gcc.gnu.org
Hi all!
Proposed patch to PR96870 - Class name on error
*PING*
Forwarded Message
Subject: [Patch, fortran] PR fortran/96724 - Bogus warnings with the
repeat intrinsic and the flag -Wconversion-extra
Date: Thu, 20 Aug 2020 16:52:10 +
From: José Rui Faustino de Sousa
To: fort...@gcc.gnu.org, gcc-patches@gcc.gnu.org
Hi all
Hi all!
Proposed patch to:
Bug 94104 - Request for diagnostic improvement
Patch tested only on x86_64-pc-linux-gnu.
Error message improvement. In Fortran 2008 actual arguments to
procedures having a pointer, with intent attribute in, formal argument
can also have the target attribute not jus
Hi all!
Proposed partial patch to:
Bug 100948 - [12 Regression] ICE in gfc_conv_expr_val, at
fortran/trans-expr.c:9069
Patch tested only on x86_64-pc-linux-gnu.
Reuse previously calculated full string length to set string section
default upper bound.
This patch only fixes the ICE the code
On 13/06/21 15:46, José Rui Faustino de Sousa wrote:
Hi All!
Proposed patch to:
And again I forgot to add the patch...
Sorry for the inconvenience.
Best regards,
José Rui
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 93118ad..5670d18 100644
--- a/gcc/fortran/class.c
+++ b/gc
Hi All!
Proposed patch to:
Bug 101047 - Pointer explicit initialization fails
Bug 101048 - Class pointer explicit initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
This patch deals with implementation of explicit initialization for
pointer variables.
It basically relies
Hi José,
Patch tested only on x86_64-pc-linux-gnu.
Also tested on darwin20. The patch is OK for me provided the updated
PR94331.c test file replaces the original one.
Since the PRs are about wrong code, I think the patch should be
backported to at least GCC11 (applied and regtested OK).
Th
Since the PRs are about wrong code, I think the patch should be back
ported to at least GCC11.
Dominique
Le 2021-06-04 17:24, Paul Richard Thomas a écrit :
Hi José,
I can second Dominique's thanks. I applied it to my tree when you
first posted, set the regtest in motion and have not been able
Hi José,
I can second Dominique's thanks. I applied it to my tree when you first
posted, set the regtest in motion and have not been able to return to
gfortran matters since.
OK for master.
I am especially happy that you have tackled this area and have rationalised
it to a substantial degree. Th
Hi José,
Patch tested only on x86_64-pc-linux-gnu.
Also tested on darwin20. The patch is OK for me.
Thanks for the work,
Dominique
Hi all!
Proposed patch to:
Bug 100120 - associated intrinsic failure
Bug 100816 - Wrong span on widechar
Bug 100818 - A temporary is passed to associated
Bug 100819 - Wrong code generation with unlimited polymorphic objects
and character type
Bug 100821 - Deferred character with wrong length
Hi All!
And yes I forgot the patch...
Sorry...
Best regards,
José Rui
On 19/05/21 17:09, José Rui Faustino de Sousa wrote:
Hi all!
Proposed patch to:
PR100683 - Array initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing.
Th
Hi all!
Proposed patch to:
Bug 93308 - bind(c) subroutine changes lower bound of array argument in
caller
Bug 93963 - Select rank mishandling allocatable and pointer arguments
with bind(c)
Bug 94327 - Bind(c) argument attributes are incorrectly set
Bug 94331 - Bind(C) corrupts array descripto
Hi all!
Proposed patch to:
PR100683 - Array initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing.
Thank you very much.
Best regards,
José Rui
Fortran: Fix bogus error
gcc/fortran/ChangeLog:
PR fortran/100683
Hi José!
The fix is fine.
Note however that the testcase will pass even without the fix because you
haven't included the
! { dg-options "-fcheck=pointer" }.
In fact, I suggest that you use the version of the tescase that I have
attached that does not run but counts the number of occurrences of '
Hi All!
Proposed patch to:
PR100245 - ICE on automatic reallocation.
Patch tested only on x86_64-pc-linux-gnu.
Add an if clause for handling derived types in the left hand side.
Thank you very much.
Best regards,
José Rui
Fortran: Fix ICE with automatic reallocation [PR100136]
gcc/fortran/
Hi All!
Proposed patch to:
PR82376 - Duplicate function call using -fcheck=pointer
Patch tested only on x86_64-pc-linux-gnu.
Evaluate function result and then pass a pointer, instead of a reference
to the function itself, thus avoiding multiple evaluations of the function.
Thank you very mu
Hi All!
Proposed patch to:
PR100136 - ICE, regression, using flag -fcheck=pointer
Patch tested only on x86_64-pc-linux-gnu.
Add handling for pointer expressions.
Thank you very much.
Best regards,
José Rui
Fortran: Fix ICE with -fcheck=pointer [PR100136]
gcc/fortran/ChangeLog:
PR
Hi All!
Proposed patch to:
PR100132 - Optimization breaks pointer association.
Patch tested only on x86_64-pc-linux-gnu.
Correct pointer attributes when passing polymorphic pointers.
Thank you very much.
Best regards,
José Rui
Fortran: Fix function attributes [PR100132]
gcc/fortran/ChangeL
Hi All!
Proposed patch to:
PR100120 - associated intrinsic failure
Patch tested only on x86_64-pc-linux-gnu.
Add code to ensure that pointers have the correct dynamic type.
The patch depends on PR100097 and PR100098.
Thank you very much.
Best regards,
José Rui
Fortran: Fix associated intri
Hi All!
Proposed patch to:
PR100103 - Automatic reallocation fails inside select rank
Patch tested only on x86_64-pc-linux-gnu.
Add select rank temporary associated names as possible targets of
automatic reallocation.
The patch depends on PR100097 and PR100098.
Thank you very much.
Best r
Hi All!
Proposed patch to:
PR100097 - Unlimited polymorphic pointers and allocatables have
incorrect rank
PR100098 - Polymorphic pointers and allocatables have incorrect rank
Patch tested only on x86_64-pc-linux-gnu.
Pointers, and allocatables, must carry TKR information even when
undefined
On 15.04.21 13:56, José Rui Faustino de Sousa via Gcc-patches wrote:
Proposed patch to:
PR100094 - Undefined pointers have incorrect rank when using optimization
Patch tested only on x86_64-pc-linux-gnu.
LGTM - thanks!
Tobias
Pointers, and allocatables, must carry TKR information even when
Hi All!
Proposed patch to:
PR100094 - Undefined pointers have incorrect rank when using optimization
Patch tested only on x86_64-pc-linux-gnu.
Pointers, and allocatables, must carry TKR information even when
undefined. The patch adds code to initialize both pointers and
allocatables element
Hi José,
first, I think you did not yet commit the approved patch for PR100018,
did you?
On 11.04.21 02:34, José Rui Faustino de Sousa via Fortran wrote:
Proposed patch to:
PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
PR100027 - ICE on storage_size with polymorphic a
On 10.04.21 22:45, José Rui Faustino de Sousa via Fortran wrote:
On 10/04/21 17:37, Tobias Burnus wrote:
And you need an additional single-line summary for git – which should
be part of the patch submission.
In case you are waiting for me, I did write:
'LGTM – Thanks for the patch. Two nits:'
Hi All!
Proposed patch to:
PR100040 - Wrong code with intent out assumed-rank allocatable
PR100029 - ICE on subroutine call with allocatable polymorphic
assumed-rank argument
Patch tested only on x86_64-pc-linux-gnu.
Made sure the code also recognized assumed-rank arrays as full arrays.
Cha
Hi All!
Proposed patch to:
PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
PR100027 - ICE on storage_size with polymorphic argument
Patch tested only on x86_64-pc-linux-gnu.
Add branch to if clause to handle polymorphic objects, not sure if I got
all possible variation
Hi all!
Proposed patch to PR100024 & PR100025 - ICE on missing polymorphic argument.
Patch tested only on x86_64-pc-linux-gnu.
Remove assertion checking for possible assumed rank arrays and added an
explicit error message.
Change if clause to allow the handling of assumed-rank arrays as arra
On 10/04/21 17:37, Tobias Burnus wrote:
And you need an additional single-line summary for git – which should be
part of the patch submission.
Fortran: Fix ICE due to referencing a NULL pointer [PR100018]
gcc/fortran/ChangeLog:
PR fortran/100018
* resolve.c: Add association check be
Hi José,
On 10.04.21 18:58, José Rui Faustino de Sousa via Fortran wrote:
Proposed patch to PR100018 - ICE on missing polymorphic argument.
Patch tested only on x86_64-pc-linux-gnu.
LGTM – Thanks for the patch. Two nits:
If you don't want to rely on the author field of git and specify an
ext
Hi all!
Proposed patch to PR100018 - ICE on missing polymorphic argument.
Patch tested only on x86_64-pc-linux-gnu.
Add association check before de-referencing pointer in order to avoid ICE.
Thank you very much.
Best regards,
José Rui
2021-4-10 José Rui Faustino de Sousa
gcc/fortran
Looks good and I have tested. I will commit after one more double check
for regressions with the test case in the testsuite
I have been following Harris on this one for several days and tested the
patch before submitted here.
Thanks for patch Harris, much appreciated.
Regards,
Jerry
On 1/1
On Wed, Jan 13, 2021 at 1:34 AM Harris Snyder wrote:
>
> Hi everyone,
>
> Sorry, my previous email erroneously referred to unsigned chars / uint8_t,
> when I in fact meant signed chars / int8_t. The actual patch works, but the
> test case files have ‘uint’ in the file names. I’ll provide a correct
Hi Paul,
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Looks good. Thanks a lot for the patch!
Best regards
Thomas
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Paul
2020-12-12 Paul Thomas
gcc/fortran
PR fortran/98022
* data.c (gfc_assign_data_value): Handle inquiry references in
the data statement object list.
gc
Hi Tobias!
On 2020-10-30T12:16:05+0100, Tobias Burnus wrote:
> On 30.10.20 11:47, Thomas Schwinge wrote:
Fixed by introducing a new function; now one only needs to make sure
that no new code will re-introduce "lb->location":-)
>> ... another*existing instance* of this problem.
> ...
>>
Hi Thomas,
On 30.10.20 11:47, Thomas Schwinge wrote:
Fixed by introducing a new function; now one only needs to make sure
that no new code will re-introduce "lb->location":-)
... another*existing instance* of this problem.
...
gfc_set_backend_locus (locus * loc)
{
gfc_current_backend
Hi!
On 2020-10-30T11:35:15+0100, I wrote:
> On 2019-12-04T14:37:55+0100, Tobias Burnus wrote:
>> As reported internally by Frederik, gfortran currently passes
>> LOCATION_COLUMN == 0 to the middle end. The reason for that is how
>> parsing works – gfortran reads the input line by line.
>>
>> For
Hi!
On 2019-12-04T14:37:55+0100, Tobias Burnus wrote:
> As reported internally by Frederik, gfortran currently passes
> LOCATION_COLUMN == 0 to the middle end. The reason for that is how
> parsing works – gfortran reads the input line by line.
>
> For internal error diagnostic (fortran/error.c),
Hi Paul,
Regtests on FC31/x86_64 - OK for master?
OK.
You're quite right that trans-* is chock full of special-case
handling (which I also found out, again, working together
with Nicolas on the shared memory coarrays).
Cleaning that up would be a worthwile job, although probably
quite big :
Hi All,
The original testcase turned out to be relatively easy to fix - the chunks
in trans-expr.c and trans-stmt.c do this. However, I tested character
actual arguments to 'write_array' in the testcase and found that the _len
component of the unlimited polymorphic dummy was not being used for the
Hi all!
Proposed patch to PR96870 - Class name on error message.
Patch tested only on x86_64-pc-linux-gnu.
Make the error message more intelligible for the average user.
Thank you very much.
Best regards,
José Rui
2020-8-21 José Rui Faustino de Sousa
gcc/fortran/ChangeLog:
Hi Jose,
Proposed patch to PR96727 - ICE with character length specified using
specification function on assumed-rank array.
Patch tested only on x86_64-pc-linux-gnu.
Add missing default error message for the assumed-rank array case.
Looks good with an adjusted ChangeLog/git commit message.
Hi Jose,
Proposed patch to PR96726 - ICE with user defined specification function
on assumed-rank array.
OK, you'll need a to work on the ChangeLog format to commit this
(like I wrote in my previous mail).
Thanks for the patch!
Regards
Thomas
Hi Jose,
Proposed patch to PR95352 - ICE on select rank with assumed-size
selector and lbound intrinsic.
Patch tested only on x86_64-pc-linux-gnu.
Add check for NULL pointer before trying to access structure member,
patch by Steve Kargl.
this is OK, but you'll have to adjust your ChangeLog
Hi Jose,
Proposed patch to PR94110 - Passing an assumed-size to an assumed-shape
argument should be rejected.
OK for master.
Thanks a lot for the patch!
Best regards
Thomas
Hi all!
Proposed patch to PR95352 - ICE on select rank with assumed-size
selector and lbound intrinsic.
Patch tested only on x86_64-pc-linux-gnu.
Add check for NULL pointer before trying to access structure member,
patch by Steve Kargl.
Thank you very much.
Best regards,
José Rui
2020-8
Hi all!
Proposed patch to PR94110 - Passing an assumed-size to an assumed-shape
argument should be rejected.
Patch tested only on x86_64-pc-linux-gnu.
Add code to also check for deferred-shape and assumed-rank pointer
(allocatable arguments are checked elsewhere) dummy arguments being
passe
Hi all!
Proposed patch to PR96728 - Fatal Error: Reading module inquiry
functions on assumed-rank.
Patch tested only on x86_64-pc-linux-gnu.
The rank of the argument to specification functions gets written when
writing the module file, but, since the value will be negative for
assumed-rank
Hi all!
Proposed patch to PR96727 - ICE with character length specified using
specification function on assumed-rank array.
Patch tested only on x86_64-pc-linux-gnu.
Add missing default error message for the assumed-rank array case.
Thank you very much.
Best regards,
José Rui
2020-8-20 J
Hi all!
Proposed patch to PR96726 - ICE with user defined specification function
on assumed-rank array.
Patch tested only on x86_64-pc-linux-gnu.
Obvious fix, replace different operator with less than to avoid infinite
loop.
Thank you very much.
Best regards,
José Rui
2020-8-20 José Ru
Hi all!
Proposed patch to PR96724 - Bogus warnings with the repeat intrinsic and
the flag -Wconversion-extra.
Patch tested only on x86_64-pc-linux-gnu.
Add code to force conversion to the default wider integer type before
multiplication.
Thank you very much.
Best regards,
José Rui
2020-
Hi Dominique,
I am trying t...@tkoenig.net.
That works :-)
I'll try to use that address in the future for my mails to the
fortran mailing list, so it does not bounce for you.
Best regards
Thomas
Le 2020-07-25 13:54, Thomas Koenig a écrit :
Am 24.07.20 um 23:19 schrieb dhumieres.domini...@free.fr:
Le 2020-07-24 20:50, Thomas Koenig a écrit :
Hi Dominique,
I have committed the patch after regression-testing.
Thanks.
Dou you want to backport this, as well?
IMO it is worth the work
Am 24.07.20 um 23:19 schrieb dhumieres.domini...@free.fr:
Le 2020-07-24 20:50, Thomas Koenig a écrit :
Hi Dominique,
I have committed the patch after regression-testing.
Thanks.
Dou you want to backport this, as well?
IMO it is worth the work.
OK. The patch for PR 93592 is now committe
Le 2020-07-24 20:50, Thomas Koenig a écrit :
Hi Dominique,
I have committed the patch after regression-testing.
Thanks.
Dou you want to backport this, as well?
IMO it is worth the work.
(And if one of my e-mails bounced, you can try the other one.
What is the other one?
Dominique
Hi Dominique,
I have committed the patch after regression-testing.
Dou you want to backport this, as well?
(And if one of my e-mails bounced, you can try the other one.
Originally, I wanted to switch completely, but the bouncing
problem made that impossible...)
Best regards
Thomas
Hi Dominique,
also committed.
Regards
Thomas
I am not set up to commit on git, someone will have to do it for me.
TIA
Dominique
--- ../_clean/libgfortran/io/write_float.def 2020-06-13 03:11:55.0 +0200
+++ libgfortran/io/write_float.def 2020-07-21 23:03:08.0 +0200
@@ -987,16 +987,19 @@ determine_en_precision (st_parameter_dt
The fix is obvious (I have added a comment). The tests are probably an
overkill, but it does not hurt.
I am not set up to commit on git, someone will have to do it for me.
TIA
Dominique
--- ../_clean/libgfortran/io/write_float.def 2020-06-13 03:11:55.0 +0200
+++ libgfortran/io/write_fl
Hi Paul and Dominique,
The patch looks fine to me. If Dominique has nothing to report then it is
OK for trunk.
committed. Thanks!
Regards
Thomas
Hi Thomas and Dominique,
The patch looks fine to me. If Dominique has nothing to report then it is
OK for trunk.
Thanks
Paul
On Thu, 2 Jul 2020 at 11:15, wrote:
> Le 2020-06-30 23:39, Thomas Koenig a écrit :
> > OK,
> >
> > so here is an updated version, which includes the updated test cases
Le 2020-06-30 23:39, Thomas Koenig a écrit :
OK,
so here is an updated version, which includes the updated test cases.
Anything else? OK for trunk?
Nothing to report!-)
Thanks for the patch,
Dominique
OK,
so here is an updated version, which includes the updated test cases.
Anything else? OK for trunk?
(And will I "see" anybody at the Fortran Conference ? )
Best regards
Thomas
Test global identifiers against what is specified interfaces.
Apart from calling gfc_compare_interfaces
Am 14.06.20 um 12:10 schrieb Thomas Koenig:
Hello world,
this patch solves an PR which just had its 14th birthday,
continuing the mission of alerting the user to mismatches where
possible.
Regression-tested (which led to a few of the extra checks for errors).
OK for trunk?
Ping?
I'd like to
Hello world,
this patch solves an PR which just had its 14th birthday,
continuing the mission of alerting the user to mismatches where
possible.
Regression-tested (which led to a few of the extra checks for errors).
OK for trunk?
Regards
Thomas
Test global identifiers against what is
Hi Jose,
Proposed patch to PR95331 - Unlimited polymorphic arrays have wrong bounds.
Patch tested only on x86_64-pc-linux-gnu.
reviewed, ChangeLog reformatted, committed as
r11-1235-g2ee70f5d161edd99a7af97d166b251bcf83cd91b .
Thanks a lot for the patch!
Do you have interest in getting write
Hi Jose,
Proposed patch to PRs 52351, 85868 Wrong array section bounds when
passing to an intent-in pointer dummy.
First, thanks for working on this and for this patch.
Regarding the patch, there are a few style issues which I fixed
for the commit. If you could try to adhere to a few more of
Hi Jose,
Proposed patch to Bug 94022 - Array slices of assumed-size arrays.
Patch tested only on x86_64-pc-linux-gnu.
Reviewed, regression-tested and commited as
r11-1228-g6a07010b774cb5a0b1790b857e69d3d8534eebd2 .
Thanks for the patch!
Regards
Thomas
Hi Jose,
Proposed patch to PRs 66833, 67938 and 95214 ICE(s) on using assumed
rank character array in different situations.
Reviewed and committed with some trival changes:
It is better not to use STOP codes > 255, so I just
counted them up.
Some changes to the ChangeLog: Mentioned all PRs t
Hi All!
Proposed patch to Bug 94022 - Array slices of assumed-size arrays.
Patch tested only on x86_64-pc-linux-gnu.
Make sure that when passing array sections of assumed-size arrays to
procedures expecting an assumed-rank array the upper bound of the last
dimension of the array section does
Hi all!
Proposed patch to PR95331 - Unlimited polymorphic arrays have wrong bounds.
Patch tested only on x86_64-pc-linux-gnu.
When iterating over a class array use the bounds provided by the
transformed descriptor (in sym->backend_decl) instead of the original
bounds of the array (in the desc
Hi all!
Proposed patch to PRs 52351, 85868 Wrong array section bounds when
passing to an intent-in pointer dummy.
Patch tested only on x86_64-pc-linux-gnu.
Add code to allow for the creation a new descriptor for array sections
with the correct one based indexing.
Rework the generated descr
Hi all!
Proposed patch to PRs 66833, 67938 and 95214 ICE(s) on using assumed
rank character array in different situations.
Patch tested only on x86_64-pc-linux-gnu.
Simple patch only add assumed-rank to the list of possible attributes.
Thank you very much.
Best regards,
José Rui
2020-5-19
Am 19.04.20 um 20:03 schrieb José Rui Faustino de Sousa via Fortran:
Hi Thomas!
> ? In other words, maybe a check on the upper bound
> of the last dimension would be better?
>
You mean enforcing:
C928 (R921) The second subscript shall not be omitted from a
subscript-triplet in the last dim
Hi Thomas!
> ? In other words, maybe a check on the upper bound
> of the last dimension would be better?
>
You mean enforcing:
C928 (R921) The second subscript shall not be omitted from a
subscript-triplet in the last dimension of an assumed-size array.
right?
If I have correctly understood
Hi Jose,
first, thanks for coming on board!
A question: Do you have a copyright assignment yet? This patch is
probably short enough that it can be accepted without it, but if
you're planning to contribute more (which I certainly hope) then
it would make sense to do this.
Regarding your patch,
Hi all!
Proposed patch to Bug 90350 - ubound ICE on assumed size array even
though explicit bound is specified
Patch tested only on x86_64-pc-linux-gnu.
Bumped into the same problem.
Probably a better fix would be to add an extra step to the reference
chain reflecting that array-section are
On Fri, Apr 10, 2020 at 8:14 AM Rainer Orth
wrote:
>
> Hi Fritz,
[...]
> one new testcases comes up as UNRESOLVED everywhere:
>
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03 -O scan-tree-dump-not
> original "volatile.*?ivar_noasync"
> +UNRESOLVED: gfortran.dg/asynchronous_5.f03 -O scan-t
f it is about a PR, searching
>> for the PR
>>usually works, but also not al emails have the PR number in the subject.)
>>For this patch, you use:
>>email: "[PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving
>> I/O tags and simp
mails have the PR number in the subject.)
>For this patch, you use:
>email: "[PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving I/O
> tags and simplify io.c"
>GIT: "Fix fortran/87923 -- ICE(s) when resolving I/O tags."
Yes, that is a good point. I w
elps with doing patch archeology if they are the same – or if the GIT one
is a substring of the email subject. (If it is about a PR, searching for the
PR
usually works, but also not al emails have the PR number in the subject.)
For this patch, you use:
email: "[PATCH, Fortran] -- PR
All,
The attached patch fixes PR 87923 while also simplifying the code in
io.c. I do say this patch simplifies io.c because it is true. This
patch causes more deletions than insertions to the file -- a rare
sight:
gcc/fortran/io.c | 859 ---
1
Tobias,
Thank you for the information. I didn't think about translations. I'll
post a new version and commit shortly.
Cheers,
Fritz
On Thu, Apr 2, 2020 at 3:50 AM Tobias Burnus wrote:
>
> In principle, I like the patch. However, I think one should
> replace
>
> gfc_error ("Attribute at %L is n
In principle, I like the patch. However, I think one should
replace
gfc_error ("Attribute at %L is not allowed in a %s definition",
…, state_name
by something like:
bool is_type = gfc_current_state () == COMP_DERIVED;
gfc_error (is_type ? G_("Attribute at %L is not allowed in a TYPE d
On Wed, Apr 1, 2020 at 1:19 PM Fritz Reese wrote:
[...]
> is still good. Is this OK to commit to trunk and for backport? I'd
> like to port as far back as 7.
I realized 7 branch is closed. I would backport to 8.
> gcc/testsuite/ChangeLog:
> 2020-04-01 Fritz Reese
>
>PR fortran/85982
>
This simple patch was submitted some time ago (over 1 year), but got
lost without review. I have lately rebased and tested, and the patch
is still good. Is this OK to commit to trunk and for backport? I'd
like to port as far back as 7.
---
Fritz Reese
gcc/ChangeLog:
2020-04-01 Fritz Reese
Hi all!
Proposed patch to:
Bug 94327 - Bind(c) argument attributes are incorrectly set
and to:
Bug 94331 - Bind(C) corrupts array descriptors
Patch tested only on x86_64-pc-linux-gnu.
Sorry for the double patch but applying them separately would break things.
Fixing 94327 is simple, just fi
Hi all!
Proposed patch to Bug 93963 - Select rank mishandling allocatable and
pointer arguments with bind(c).
Patch tested only on x86_64-pc-linux-gnu.
cfi_desc_to_gfc_desc, in ISO_Fortran_binding.c, will likely store -1 (or
garbage) in the upper bound of the descriptor for unallocated, or
Hi all!
Proposed patch to solve ICE.
Patch tested only on x86_64-pc-linux-gnu.
The code currently calls gfc_trans_deferred_array even when it is not
necessary triggering an assertion error inside gfc_trans_deferred_array.
Please notice the addition of "sym->ts.type == BT_CLASS" to the
defin
1 - 100 of 959 matches
Mail list logo
