Hello,
the above bug appears to have been fixed over 2.5 years ago.
It does not trigger with 4.9, 5 and 6 trunk, but does with 4.8.0 and
before.
I recommend to close the bug, while adding a testcase to the trunk's
testsuite. See e.g. the attached example.
Harald
2016-02-24 Harald A
On 02/24/16 20:42, Harald Anlauf wrote:
> Hello,
>
> the above bug appears to have been fixed over 2.5 years ago.
> It does not trigger with 4.9, 5 and 6 trunk, but does with 4.8.0 and
> before.
>
> I recommend to close the bug, while adding a testcase to the trunk's
Hi,
the above ICE is fixed by the following simple/trivial fix:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 234170)
+++ gcc/fortran/simplify.c (working copy)
@@ -5163,6 +5163,9 @@
|| !is_co
Hi,
the above ICE is fixed by the following simple/trivial fix:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 234170)
+++ gcc/fortran/interface.c (working copy)
@@ -2006,7 +2006,7 @@ compare_paramet
Hi,
the simple patch below rejects arrays as do loop index
variable before another (confusing) error message is emitted.
Two new testcases derived from the PR, plus adaption of one
testcase that relies on the old error message.
Whoever wants to take it...
Harald
2016-02-08 Harald Anlauf
ons affecting my codes, but no promises.
Harald
2016-11-19 Harald Anlauf
PR fortran/69741
* resolve.c (gfc_resolve_forall): Check for non-scalar index
variables.
2016-11-19 Harald Anlauf
PR fortran/69741
* gfortran.dg/forall_
Sorry, forgot to mention: regtested on i686-pc-linux-gnu
Harald
On 11/19/16 15:42, Harald Anlauf wrote:
> Hi Steve, all,
>
> On 11/19/16 02:18, Steve Kargl wrote:
>> The error message is still not clear. 42 is a scalar integer. Why
>> not use the language in the stand
).
OK for trunk, and backport to 9?
Thanks,
Harald
2019-08-26 Harald Anlauf
PR fortran/91496
* gfortran.h: Extend struct gfc_iterator for loop annotations.
* array.c (gfc_copy_iterator): Copy loop annotations by IVDEP,
VECTOR, and NOVECTOR pragmas
, so that this can be used in the 9.3 release.
Applies/regtests cleanly. Will wait for a week or so.
Harald
On 08/27/19 10:33, Paul Richard Thomas wrote:
> Hi Harald,
>
> This is OK for trunk.
>
> Thanks!
>
> Paul
>
> On Mon, 26 Aug 2019 at 22:13, Harald Anlauf wrote:
>
ly control loop fusion, loop
blocking, which are very important in (my) practice.
The current implementation also does not support array notation,
which I consider a major limitation. I'll have to learn how this
could be done.
> thanks and cheers,
>
Thanks for the feedback!
Harald
20
same.
OK for trunk?
Thanks,
Harald
2019-06-13 Harald Anlauf
PR fortran/90577
PR fortran/90578
* trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly
distinguish logical/arithmetic shifts.
* intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA
Committed as svn rev. 272309.
Thanks for the quick review!
Harald
On 06/14/19 00:18, Steve Kargl wrote:
> On Thu, Jun 13, 2019 at 11:50:23PM +0200, Harald Anlauf wrote:
>>
>> it was already discussed in the above PRs that the testcase
>> lrshift_1.f90 needs to be correct
u. OK for trunk?
Harald
2019-06-23 Harald Anlauf
PR fortran/90903
* libgfortran.h: Add mask for -fcheck=bits option.
* options.c (gfc_handle_runtime_check_option): Add option "bits"
to run-time checks selectable via -fcheck.
Committed to trunk as rev. 268726. after adding a comment that a check
for negative substring length is already present. The updated version
is attached.
Thanks for the review. Will not backport unless requested.
Harald
On 02/08/19 21:36, Harald Anlauf wrote:
> The attached patch attempt
-11 Harald Anlauf
PR fortran/88299
* resolve.c (resolve_common_blocks,resolve_common_vars): Move
check for obsolent COMMON feature in F2018 to better place.
2019-02-11 Harald Anlauf
PR fortran/88299
* gfortran.dg/pr88299.f90: New test.
Index: gcc
The attached patch moves the check for labeled DO statements to
the place where a label is referenced instead of where a label
was defined, which lead to false positives.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks,
Harald
2019-02-13 Harald Anlauf
PR fortran/88248
Sorry, forgot to attach the patch to the revised testcase f2018_obs.f90.
Here it is.
Regards,
Harald
Adjusted ChangeLog:
2019-02-13 Harald Anlauf
PR fortran/88248
* gfortran.dg/pr88248.f90: New test.
* gfortran.dg/f2018_obs.f90: Updated test.
On 02/13/19 23:38
transaction...
Committed revision 268895.
Thanks for the review, Jerry.
Harald
On 02/14/19 01:45, Jerry DeLisle wrote:
> On 2/13/19 2:38 PM, Harald Anlauf wrote:
>> The attached patch moves the check for labeled DO statements to
>> the place where a label is referenced instead of where
ved.
As a result, the original string could be used with trailing
garbage instead of the properly space-padded string. The patch
simply clears expr->representation in that case.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks,
Harald
2019-02-15 Harald Anlauf
PR fortran
Ping!
On 02/11/19 23:09, Harald Anlauf wrote:
> The attached patch moves the check for this F2018 obsolescent feature
> to a better place where the warning is only emitted when the COMMON is
> declared. No warning should be emitted when such a legacy module is
> simply used.
>
Committed as rev. 268973.
Thanks for the review!
Harald
On 02/17/19 21:45, Thomas Koenig wrote:
> Hi Harald,
>
>> OK for trunk?
>
> OK.
>
> Thanks for the patch!
>
> Regards
>
> Thomas
>
Committed as rev. 268974.
Thanks for the review!
Harald
On 02/17/19 21:40, Thomas Koenig wrote:
> Hi Harald,
>
>> Ping!
>
>> On 02/11/19 23:09, Harald Anlauf wrote:
>>> The attached patch moves the check for this F2018 obsolescent feature
>>> to a
for code that would have generated an ICE before.
Since the above fix also works for non-character arrays of length 0,
I added a suitable test.
Regtested on x86_64-pc-linux-gnu.
OK for trunk? Or rather wait for post-9.1?
Thanks,
Harald
2019-02-18 Harald Anlauf
PR fortran/89266
There was a rather obvious bug in the logic for checking the arguments
to the OPEN statement when NEWUNIT= was specified, which prohibited
the generation of the appropriate error message.
Regtested successfully.
OK for trunk?
Thanks,
Harald
2019-02-20 Harald Anlauf
PR fortran/83057
Committed to trunk as rev. 269134.
Thanks for the review!
Harald
On 02/22/19 06:28, Jerry DeLisle wrote:
> On 2/20/19 2:34 PM, Harald Anlauf wrote:
>> There was a rather obvious bug in the logic for checking the arguments
>> to the OPEN statement when NEWUNIT= was specified, w
Committed as rev. 269177. As this patch also fixed PR88326,
I added the testcase below.
Thanks for the review,
Harald
2019-02-24 Harald Anlauf
PR fortran/88326
* gfortran.dg/pr88326.f90: New test.
On 02/23/19 19:10, Thomas Koenig wrote:
> Hi Harald,
>
>> OK fo
Anlauf
PR fortran/89492
* check.c (gfc_calculate_transfer_sizes): Handle cases where
storage size of elements of MOLD is 0.
2019-02-25 Harald Anlauf
PR fortran/89492
* gfortran.dg/pr89492.f90: New test.
Index: gcc/fortran/check.c
Committed as rev. 269227 after confirmation by Dominique:
https://gcc.gnu.org/ml/fortran/2019-02/msg00229.html
Thanks for the quick review.
Harald
@Dominique: I am unable to close PRs in bugzilla that I do not own
due to insufficient privileges.
On 02/25/19 22:49, Harald Anlauf wrote:
>
array arguments. I adjusted the corresponding testcase.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Harald
2019-02-27 Harald Anlauf
PR fortran/89516
* check.c (gfc_calculate_transfer_sizes): Correct checks for cases
where storage size of elements of MOLD is 0.
2019-
The attached patch (originally by Steve Kargl) fixes a NULL pointer
dereference that may occur when checking for a conflict.
Regtested successfully.
OK for trunk? Backport to active branches?
Thanks,
Harald
2019-03-02 Harald Anlauf
Steve Kargl
PR fortran/77583
Committed as rev. 269341 on trunk.
On 03/02/19 16:17, Thomas Koenig wrote:
> Hi Harald,
>
>> Adding -Wsurprising as option to gfortran exercised a code path
>> that I hadn't seen when working on simplifications for the TRANSFER
>> intrinsic. While regtesting, I realized that one of the checks wa
I didn't see any disagreement, so committed to trunk (rev.269353)
and "backported" to 7- and 8-branches.
Thanks,
Harald
On 03/02/19 00:15, Steve Kargl wrote:
> On Sat, Mar 02, 2019 at 12:12:10AM +0100, Harald Anlauf wrote:
>> The attached patch (originally by Steve Kar
and regtests cleanly on x86_64-pc-linux-gnu.
OK for trunk? Backports?
Thanks,
Harald
P.S.: the PR has another ICE with integer array constructors which is
unrelated and under investigation.
2019-03-05 Harald Anlauf
PR fortran/71203
* expr.c (simplify_const_ref): Avoid null
Committed as rev.269444 to trunk, rev.269445 to 8-branch.
Thanks for the review!
Harald
On 03/06/19 00:07, Thomas Koenig wrote:
> Hi Harald,
>
>> To the reviewer: I am not 100% sure that my solution is correct, but it
>> solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu.
>>
.
OK for trunk?
Thanks,
Harald
2019-03-07 Harald Anlauf
PR fortran/60091
* expr.c (gfc_check_pointer_assign): Correct and improve error
messages for invalid pointer assignments.
2019-03-07 Harald Anlauf
PR fortran/60091
* gfortran.dg/pointer_remapp
-10 Harald Anlauf
PR fortran/87045
* trans-expr.c (gfc_trans_pointer_assignment): Move check for same
string length so that we do not get false errors for deferred
length.
2019-03-10 Harald Anlauf
PR fortran/87045
* gfortran.dg/pr87045.f90: New
Hi Dominique,
how about the attached version? It is quite verbose and produces
messages like
Error: Expected list of 'lower-bound-expr:' or list of
'lower-bound-expr:upper-bound-expr' at (1)
(I did check other compilers. E.g. Intel and Oracle do print messages
using the 'legalese'. But user-f
ht, which is why I think the related
error messages should be more technical and concise.
I'll think for another day or two.
Thanks,
Harald
> Gesendet: Dienstag, 12. März 2019 um 23:19 Uhr
> Von: "Thomas Koenig"
> An: "Harald Anlauf" , "Dominique d'Humiè
Committed as r269664.
Thanks for the review!
Harald
On 03/13/19 01:41, Steve Kargl wrote:
> On Sun, Mar 10, 2019 at 10:19:03PM +0100, Harald Anlauf wrote:
>> The code in the testcase died due to a run-time bounds-check
>> generated slightly too early, leading to a cra
I've committed a slightly rewritten version of the error messages
to trunk as rev.269717, see attached.
Thanks for the review and the comments.
Harald
On 03/12/19 23:19, Thomas Koenig wrote:
> Hi Harald,
>
>> how about the attached version? It is quite verbose and produces
>> messages like
>>
. ...
I was struggling for some moment with the idea that SOURCE could be
a procedure pointer (technically), but finally dismissed it.
The patch thus rejects procedures as arguments.
Regtests cleanly on x86_64-pc-linux-gnu.
OK for trunk?
Harald
2019-03-17 Harald Anlauf
PR fortran/85797
Hi Thomas,
based on your comments I'll withdraw the patch, but read on...
On 03/20/19 17:14, Thomas Koenig wrote:
> Hi Harald,
>
>> My reading of the standard suggests that this is not allowed:
>>
>>SOURCE shall be a scalar or array of any type.
>>
>>MOLD shall be a scalar or array of any
?
Thanks,
Harald
2019-03-20 Harald Anlauf
PR fortran/83515
PR fortran/85797
* trans-types.c (gfc_typenode_for_spec): Handle conversion for
procedure pointers.
* target-memory.c (gfc_element_size): Handle size determination
for procedure pointers
Ping!?
On 03/20/19 23:20, Harald Anlauf wrote:
> The PRs originated in gfc_element_size lacking a treatment of
> procedure pointers, which has been added. The testcase is currently
> a pure compile test. When a reduced run-time test for PR83515
> becomes available, it will be
Committed to trunk as svn rev. 270045.
Since the patch is considered safe, I also committed to open branches (7/8).
Thanks for the review!
Harald
On 03/20/19 23:20, Harald Anlauf wrote:
> The PRs originated in gfc_element_size lacking a treatment of
> procedure pointers, which has been
discussed in the PR, and adjusts the testcase accordingly.
Regtests cleanly on x86_64-pc-linux-gnu. Could someone with access to
powerpc64*-unknown-linux-gnu please verify? (Thomas?)
OK for trunk (and affected backports)?
Thanks,
Harald
2019-04-02 Harald Anlauf
PR fortran/89004
Ping!
On 06/23/19 23:36, Harald Anlauf wrote:
> Dear all,
>
> the attached patch provides run-time checks for the bit manipulation
> intrinsic functions (IBSET/IBCLR/BTEST/SHIFT[RLA]/ISHFT/ISHFTC).
> I am using only one testcase whose purpose is mainly to verify that
>
eve Kargl
> wrote:
>>
>> Harald, thanks for the patch. I'm that the best person
>> for reading the trans-* file, but your patch and changes
>> look good to me. If no one else speaks up, in the next
>> day or so, please commit.
>>
>> --
>
Ping!
On 08/28/19 21:58, Harald Anlauf wrote:
> Hi Bernhard,
>
> On 08/28/19 20:57, Bernhard Reutner-Fischer wrote:
>> I see that you copied the unfortunate error-message "commence a loop"
>> and i see that i completely forgot to adjust it as per Mike's
>>
ebody else take care
of it after review.
Thanks,
Harald
2019-01-20 Harald Anlauf
PR fortran/88579
* trans-expr.c (gfc_conv_power_op): Handle cases of (2**e) ** integer
and (- 2**e) ** integer.
2019-01-20 Harald Anlauf
PR fortran/88579
* gfortran
I was too anxious pressing the send button so that I forgot to mention:
Regtested with no new regressions on x86_64-pc-linux-gnu.
Sorry for that.
Harald
On 01/20/19 23:18, Harald Anlauf wrote:
> Dear all,
>
> here's my revised patch for the treatment of (2**e) ** n and (- 2**e)
trunk?
Note: I don't have commit rights, so please somebody else take care
of it after review.
Thanks,
Harald
2019-01-22 Harald Anlauf
PR fortran/57553
* expr.c (check_inquiry): Add list of inquiry functions allowed in
constant expressions for F2008+.
2019-
Committed as Revision: 268303
URL: https://gcc.gnu.org/viewcvs?rev=268303&root=gcc&view=rev
Log:
2019-01-26 Harald Anlauf
PR fortran/57553
* expr.c (check_inquiry): Add list of inquiry functions allowed in
constant expressions for F2008+.
2019-01-26 Haral
-code issue to be addressed separately.
OK for trunk? And shall this fix be backported?
Thanks,
Harald
2019-02-03 Harald Anlauf
PR fortran/89077
* decl.c (add_init_expr_to_sym): Copy length of string initializer
to declared symbol.
2019-02-03 Harald Anlauf
PR
ication. :-(
Any hint is highly welcome!
Thanks,
Harald
> Thanks
>
> Paul
>
> On Sun, 3 Feb 2019 at 21:04, Harald Anlauf wrote:
>>
>> The attached patch fixes an ICE-on-valid that probably goes back to
>> rev.128130. Apparently the patch applied back then di
trunk? And for backports to 8/7?
Thanks,
Harald
2019-02-08 Harald Anlauf
PR fortran/89077
* resolve.c (gfc_resolve_substring_charlen): Check substring
length for constantness prior to general calculation of length.
2019-02-08 Harald Anlauf
PR fortran/89077
While trying to clean up my working copy, I found that the trivial
patch for the ICE-on-invalid as described in the PR regtests cleanly
for 7-release on i686-pc-linux-gnu.
Here's the cleaned-up version (diffs attached).
2017-05-04 Harald Anlauf
PR fortran/70071
* ar
On 05/04/17 18:15, Steve Kargl wrote:
> On Thu, May 04, 2017 at 05:26:17PM +0200, Harald Anlauf wrote:
>> While trying to clean up my working copy, I found that the trivial
>> patch for the ICE-on-invalid as described in the PR regtests cleanly
>> for 7-release on i686-pc-li
The patch below has not been applied to the best of my knowledge.
Just a reminder for whoever cares.
Harald
On 05/04/17 20:19, Harald Anlauf wrote:
> On 05/04/17 18:15, Steve Kargl wrote:
>> On Thu, May 04, 2017 at 05:26:17PM +0200, Harald Anlauf wrote:
>>> While trying to c
-linux-gnu. OK for master?
Thanks,
Harald
2020-05-04 Steve Kargl
Harald Anlauf
PR fortran/93366
* check.c (gfc_check_associated, invalid_null_arg): Factorize
check for presence of invalid NULL() argument.
(gfc_check_kind, gfc_check_merge
e it LGTM.
>
> Tobias
Thanks for the review!
Harald
Here's what I actually committed. Hopefully this is close to what it should
be...
PR fortran/93366 - ICE on invalid, reject invalid use of NULL() as argument
gcc/fortran/ChangeLog:
2020-05-05 Steve Kargl
Har
declaration statements
Division by zero in declaration statements could sometimes
generate NULL pointers being passed around that lead to ICEs.
gcc/fortran/ChangeLog:
2020-05-09 Harald Anlauf
PR fortran/93499
* arith.c (gfc_divide): Catch division by zero
/fortran/
2020-05-11 Harald Anlauf
PR fortran/95053
* arith.c (gfc_divide): Do not error out if operand 2 is
non-numeric. Defer checks to later stage.
gcc/testsuite/
2020-05-11 Harald Anlauf
PR fortran/95053
* gfortran.dg/pr95053.f: New test.
diff
d PDT KIND and LEN
expressions at a later stage.
gcc/fortran/
2020-05-15 Harald Anlauf
PR fortran/95053
* arith.c (gfc_divide): Revert hunk introduced by patch for
PR93499.
* decl.c (variable_decl): Generate error for array shape not being
, leading to bogus warnings about COMMON block
mismatches. Provide sufficiently large temporaries.
gcc/fortran/
2020-05-22 Harald Anlauf
PR fortran/95106
* trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries
for name-mangling.
gcc/testsuite/
2020
prohibited.
Generate useful runtime errors instead instead of misleading ones.
libgfortran/
2020-05-24 Harald Anlauf
PR fortran/95195
* io/transfer.c (finalize_transfer): Generate runtime error for
namelist input/output to unformatted file.
gcc/testsuite/
2020-05-24 Har
generated name-mangled symbol did not fit into a buffer when
coarrays were enabled. Provide sufficiently large temporary.
gcc/fortran/
2020-05-25 Harald Anlauf
PR fortran/95089
* trans-types.c (gfc_get_derived_type): Enlarge temporary to hold
mangled name
sufficiently large temporary.
2020-05-26 Harald Anlauf
gcc/fortran/
PR fortran/95090
* iresolve.c (gfc_get_string): Enlarge temporary for
name-mangling.
gcc/testsuite/
PR fortran/95090
* gfortran.dg/pr95090.f90: New test.
diff --git a/gcc/fortran
before
resulted in a NULL pointer dereference. Check for this condition.
2020-05-26 Harald Anlauf
libgfortran/
PR libfortran/95104
* io/transfer.c (st_wait_async): Do not dereference NULL pointer.
gcc/testsuite/
PR libfortran/95104
* gfortran.dg/pr95104.f90: New
Hi Thomas,
thanks for the hint:
> Von: "Thomas Koenig"
> Am 26.05.20 um 23:33 schrieb Harald Anlauf:
> > Will backport in a few days, when I figure out how to do it now.
>
> The way to backport now is to first run contrib/gcc-git-customization.sh
> from current
The fix for
> PR fortran/95104 - Segfault on a legal WAIT statement
>
> Referencing a unit in a WAIT statement that has not been opened before
> resulted in a NULL pointer dereference. Check for this condition.
>
> 2020-05-26 Harald Anlauf
>
> libgfortran/
>
95104 - Segfault on a legal WAIT statement
The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library. Add check for valid unit.
2020-05-28 Harald Anlauf
libgfortran/
PR libfortran/95104
* io/unit.c (unlock_unit): Guard by check
applicable intrinsic
types is valid only for suffienctly new Fortran standards. Add appropriate
check.
2020-05-28 Harald Anlauf
gcc/fortran/
PR fortran/95373
* primary.c (is_inquiry_ref): Check validity of inquiry
references against selected Fortran standard.
gcc
to master.
Thanks,
Harald
PR fortran/95090 - ICE: identifier overflow
The initial fix for this PR uncovered several latent issues with further
too small string buffers which showed up only when testing on i686.
Provide sufficiently large temporaries.
2020-05-29 Harald Anlauf
gcc/fortran/
build_reference_type, at tree.c:7942
The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic
types is valid only for suffienctly new Fortran standards. Add appropriate
checks in the appropriate place.
2020-05-28 Harald Anlauf
gcc/fortran/
PR fortran/95373
Hi H.J.,
> Gesendet: Freitag, 29. Mai 2020 um 23:57 Uhr
> Von: "H.J. Lu"
> This breaks bootstrap:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072642.html
>
> ../../src-master/gcc/fortran/class.c:487:13: error: ‘char*
> strncpy(char*, const char*, size_t)’ specified bound 67 equal
> > > This breaks bootstrap:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072642.html
> > >
> > > ../../src-master/gcc/fortran/class.c:487:13: error: ‘char*
> > > strncpy(char*, const char*, size_t)’ specified bound 67 equals
> > > destination size [-Werror=stringop-truncatio
len < sizeof (dt_name));
> + memcpy (dt_name, upper, len);
> + dt_name[len] = '\0';
> +}
> does detect it before overflowing it.
OK. Here's what I committed:
PR fortran/95090 - ICE: identifier overflow
Implement buffer overrun check for temporar
> Thanks. Though, see Andreas' mail, I think he is right that there is really
> no reason to have that dt_name local buffer at all, just changing
> dt_name from an array to const char *dt_name; and changing the strcpy to
> dt_name = "STAR";
> and the former strncpy (dt_name, ...) to
> dt_name = gf
2019-11-24 Harald Anlauf
PR fortran/92629
* simplify.c (convert_mpz_to_unsigned): Skip assert for argument
range when -fno-range-check is specified.
2019-11-24 Harald Anlauf
PR fortran/92629
* gfortran.dg/pr92629.f90: New testcase.
Index: gcc
ng PR91641.
Regtested on x86_64-pc-linux-gnu.
OK for trunk and 9 ?
Thanks,
Harald
2019-12-10 Harald Anlauf
PR fortran/92898
* check.c (gfc_check_is_contiguous): Adjust check to handle NULL()
argument without an actual argument.
2019-12-10 Harald Anlauf
Hi Thomas,
> Gesendet: Dienstag, 10. Dezember 2019 um 23:34 Uhr
> Von: "Thomas Koenig"
> An: "Harald Anlauf" , gfortran ,
> gcc-patches
> Betreff: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in
> gfc_check_is_contiguous, at fortran/check.c:7
Hi Tobias,
> Gesendet: Donnerstag, 12. Dezember 2019 um 09:01 Uhr
> Von: "Tobias Burnus"
> An: "Harald Anlauf" , "Thomas Koenig"
> Cc: gfortran , gcc-patches
> Betreff: Re: Aw: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in
> gfc_che
t;pointer target shall not be NULL" }
+ z(2:1) => null() ! { dg-error "pointer target shall not be NULL" }
+end
2019-12-18 Harald Anlauf
PR fortran/92898
* trans-expr.c (gfc_trans_pointer_assignment): Reject bounds
remapping if pointer target is NULL
r error message, we'd need to know that we come here from
a NULLIFY statement. Can you file a PR?
Thanks,
Harald
> On 12/18/19 5:07 PM, Harald Anlauf wrote:
>> The patch is self-explaining and practically obvious: pointer bounds
>> remapping to NULL is not allowed, thus we shal
NULLIFY vs. pointer assignment (PR70853)
+program p
+ integer, pointer :: x(:)
+ type t
+ integer, pointer :: y(:)
+ end type t
+ type(t) :: z
+ nullify (x(1:2)) ! { dg-error "does not allow bounds remapping" }
+ nullify (z%y(:)) ! { dg-error "does not allow bounds remap
> Gesendet: Samstag, 21. Dezember 2019 um 17:16 Uhr
> Von: "Thomas Koenig"
> An: "Harald Anlauf" , fortran ,
> gcc-patches
> Betreff: Re: [Patch] PR92990 - fix error message for invalid argument of
> NULLIFY
>
> Am 20.12.19 um 22:33 schrieb Harald An
by Thomas König.
Thanks,
Harald
2019-12-21 Harald Anlauf
PR fortran/91661
* gfortran.dg/pr91661.f90: New test.
Index: gcc/testsuite/gfortran.dg/pr91661.f90
===
--- gcc/testsuite/gfortran.dg/pr91661.f90 (nicht ex
More NULL pointer dereferences on invalid code, detected by Gerhard.
Regtested on x86_64-pc-linux-gnu.
OK for master?
Thanks,
Harald
PR fortran/96086 - ICE in gfc_match_select_rank, at fortran/match.c:6645
Handle NULL pointer dereference on SELECT RANK with an invalid
assumed-rank array decla
As Dominique pointed out in the PR, the committed patch (part 1) fixed only
one of the provided testcases, but not the original one. That turned out
to be a long and winding road, requiring further checks for NULL pointer
dereferences.
The resulting attached changes have been regtested on x86_64-
Committed as obvious. Check whether the target of a legacy ASSIGN statement
is a parameter and reject if this is the case.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
PR fortran/96085 - ICE in gfc_finish_var_decl, at fortran/trans-decl.c:694
Legacy ASSIGN requires a scalar integer variab
Hi Thomas,
> This is not a regression, so I don't think we will need a backport.
understood.
On the downside, another patch I was working on unfortunately partially overlaps
with the present one in resolve.c. At some point, there will be a conflict
between the work involved in either producing
As Fortran allows to rename a symbol on use, we need to be careful to
check whether a name we are looking for is a global one or belongs to
a different module. Check for this condition.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports after some time for a proper burn-in?
Thanks,
Har
**ping**
> Gesendet: Dienstag, 14. Juli 2020 um 23:20 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/89574 - [8/9/10/11 Regression] ICE in
> conv_function_val, at fortran/trans-expr.c:3792
>
> As Fort
Hi,
a missing check in gfc_set_array_spec for for sum of rank and corank
not exceeding GFC_MAX_DIMENSIONS could trigger an assert on invalid code.
The attached patch fixes that. OK for mainline / backport to 9-branch?
Harald
2020-04-19 Harald Anlauf
PR fortran/93364
Hi again,
I was so focussed on whether I got this correct for the gcc git repository that
I forgot to mention that this has been cleanly regtested on x86_64-pc-linux-gnu.
Sorry for the added noise.
Harald
> Gesendet: Sonntag, 19. April 2020 um 22:49 Uhr
> Von: "Harald Anlauf"
simply
contiguous at compile time to a contiguous pointer does not need to be
invoked if the lhs of the assignment is known to have conflicting attributes.
2020-06-04 Harald Anlauf
gcc/fortran/
PR fortran/95503
* expr.c (gfc_check_pointer_assign): Skip contiguity check of rhs
Converting an expression so that it can be passed by reference could
result in a NULL pointer dereference.
2020-06-04 Steven G. Kargl
Harald Anlauf
gcc/fortran/
PR fortran/95500
* trans-expr.c (gfc_conv_expr_reference): Do not dereference NULL
pointer.
gcc
for PR95090 and PR95106 trigger buffer overflows with long
symbols that were found with an instrumented compiler. Enlarge the
affected buffers, and add checks that the buffers will suffice.
2020-06-05 Harald Anlauf
gcc/fortran/
PR fortran/95530
PR fortran/95537
* decl.c
with submodules and long symbols
With submodules, name mangling results in long internal symbols. This
requires adjustment of the sizes of temporaries to avoid buffer overflows.
2020-06-06 Harald Anlauf
gcc/fortran/
PR fortran/95091
* class.c (get_unique_type_string, gfc_hash_
1 - 100 of 917 matches
Mail list logo
