[Patch, fortran] PR70853 - ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

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(). 2019-12-18 Harald Anlauf PR fortran/70853 * gfortran.dg/pr70853.f90: New test.

Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157

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

Aw: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157

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

[Patch, Fortran] PR92898 - [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157

. 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 PR fortran

[Patch,Fortran] PR92629 - ICE in convert_mpz_to_unsigned, at fortran/simplify.c:173

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

Re: [Patch, RFC] PR81651/Fortran - Enhancement request: have f951 print out fully qualified module file name

On 11/11/19 23:37, Janne Blomqvist wrote: > On Mon, Nov 11, 2019 at 11:54 PM Harald Anlauf wrote: >> >> Dear all, >> >> the attached patch prints the fully qualified path if an error occurs >> during module read. E.g., instead of a less helpful error message, &

[Patch, RFC] PR81651/Fortran - Enhancement request: have f951 print out fully qualified module file name

? Thanks, Harald 2019-11-11 Harald Anlauf PR fortran/81651 * module.c (gzopen_included_file, gzopen_included_file_1) (gzopen_intrinsic_module, bad_module, gfc_use_module): Use fully qualified module path for error reporting. Index: gcc/fortran/module.c

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

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 >> pre

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

oop 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 2019-08-28 Harald Anlauf

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

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: >> >>

[PR fortran/91496] !GCC$ directives error if mistyped or unknown

). 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

Re: [Patch, fortran] PR90903 - Implement runtime checks for bit manipulation intrinsics

argl > 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. >> >> -- >> steve

Re: [Patch, fortran] PR90903 - Implement runtime checks for bit manipulation intrinsics

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 >

[Patch, fortran] PR90903 - Implement runtime checks for bit manipulation intrinsics

x-gnu. 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.

Re: [Patch, fortran] PR90577, PR90578 - FAIL: gfortran.dg/lrshift_1.f90 & Wrong code with LSHIFT and optimization

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

[Patch, fortran] PR90577, PR90578 - FAIL: gfortran.dg/lrshift_1.f90 & Wrong code with LSHIFT and optimization

the 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

[Patch, fortran] PR89904 - ICE in gfortran starting with r270045

as 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

Re: [Patch, fortran] PR83515, PR85797 - ICE in gfc_element_size

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

[Ping] [Patch, fortran] PR83515, PR85797 - ICE in gfc_element_size

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 w

[Patch, fortran] PR83515, PR85797 - ICE in gfc_element_size

? 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

Re: [PR fortran/85797, patch] - ICE in gfc_element_size, at fortran/target-memory.c:126

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

[PR fortran/85797, patch] - ICE in gfc_element_size, at fortran/target-memory.c:126

. ... 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

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

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 >>

Re: [PR fortran/87045, patch] - pointer to array of character

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

Aw: Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

elated 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ères" > > Cc: gfortran ,

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

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

[PR fortran/87045, patch] - pointer to array of character

-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

[PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

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_remapping_3

Re: [PR fortran/71203, patch] - ICE on zero-length arrays or substrings

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.

[PR fortran/71203, patch] - ICE on zero-length arrays or substrings

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

Re: [PR fortran/77583, patch ]- ICE in pp_quoted_string, at pretty-print.c:966

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 Kargl) f

Re: [PR fortran/89516, patch] - ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506

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

[PR fortran/77583, patch ]- ICE in pp_quoted_string, at pretty-print.c:966

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

[PR fortran/89516, patch] - ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506

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-02-27

Re: [PR fortran/89492, patch] - [9 Regression] Endless compilation of an invalid TRANSFER after r269177

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: >

[PR fortran/89492, patch] - [9 Regression] Endless compilation of an invalid TRANSFER after r269177

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

Re: [PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor

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, > >>

Re: [PR fortran/83057, patch] - OPEN without a filename and without STATUS='SCRATCH' could produce a warning

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

[PR fortran/83057, patch] - OPEN without a filename and without STATUS='SCRATCH' could produce a warning

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

[PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor

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

Re: *Ping* [PR fortran/88299, patch] - [F18] COMMON in a legacy module produces bogus warnings in dependent code

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

Re: [PR fortran/89077, patch, part 3] - ICE using * as len specifier for character parameter

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 >

*Ping* [PR fortran/88299, patch] - [F18] COMMON in a legacy module produces bogus warnings in dependent code

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. &g

[PR fortran/89077, patch, part 3] - ICE using * as len specifier for character parameter

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

Re: [PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement

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 o

Re: [PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement

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

[PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement

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

[PR fortran/88299, patch] - [F18] COMMON in a legacy module produces bogus warnings in dependent code

-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

Re: [PR fortran/89077, patch, part 2] - ICE using * as len specifier for character parameter

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 attem

[PR fortran/89077, patch, part 2] - ICE using * as len specifier for character parameter

for 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

Re: [PR fortran/89077, patch] - ICE using * as len specifier for character parameter

y 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 did not check >> th

[PR fortran/89077, patch] - ICE using * as len specifier for character parameter

-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

Re: [PR fortran/57553, patch] - bad error message for invalid use of STORAGE_SIZE

Committed as Revision: 268303 URL: https://gcc.gnu.org/viewcvs?rev=268303=gcc=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 Harald Anlauf PR

[PR fortran/57553, patch] - bad error message for invalid use of STORAGE_SIZE

for 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-01-22

Re: [PR88579, patch] Calculating power of powers of two

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) ** &g

Re: [PR88579, patch] Calculating power of powers of two

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.dg/power_8.f90

[PATCH, fortran] PR85083 - [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915

The attached obvious one-liner adds a missing check for type compatibility in a structure constructor. Testcase from report. Changelogs below. Regtested on i686-pc-linux-gnu. Whoever reviews this, please feel free to commit. Thanks, Harald 2018-03-26 Harald Anlauf <anl...@gmx

[PATCH, fortran] PR84957 - [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

The attached obvious patch fixes a NULL pointer dereference. Testcase derived from report. Changelogs below. Regtested on i686-pc-linux-gnu. Whoever reviews this, please feel free to commit. Thanks, Harald 2018-03-21 Harald Anlauf <anl...@gmx.de> PR fortran/84957 *

[PATCH, fortran] PR71085 - ICE with some intrinsic functions specifying array function result dimension

The fix to the PR probably counts as obvious, but here it is, along with a testcase. Changelogs below. Regtested on i686-pc-linux-gnu. Whoever reviews this, please feel free to commit. Thanks, Harald 2018-03-02 Harald Anlauf <anl...@gmx.de> PR fortran/71085 * trans-

[PATCH, fortran] PR/83864 - ICE in gfc_apply_init, at fortran/expr.c:4271

value.integer, init->ts.u.cl->length->value.integer)) { Regtests without new failures on i686-pc-linux-gnu. Testcase derived from PR, see below. Changelog: 2018-01-17 Harald Anlauf <anl...@gmx.de> PR fortran/83864 * expr.c (add_init

[PATCH] PR/83874: ICE initializing character array from derived type

s, Harald --- Changelog: 2018-01-17 Harald Anlauf <anl...@gmx.de> PR fortran/83874 * decl.c (add_init_expr_to_sym): Do not dereference NULL pointer. Testsuite: 2018-01-17 Harald Anlauf <anl...@gmx.de> PR fortran/83874 * gfortran.dg/pr83874.f90

Ping [Patch, fortran] PR70071

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

Re: [Patch, fortran] PR70071

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

[Patch, fortran] PR70071

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 <anl...@gmx.de> PR fortran

Re: PR69741: Bad error in formal with array scalar loop counters

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

Re: PR69741: Bad error in formal with array scalar loop counters

ing my codes, but no promises. Harald 2016-11-19 Harald Anlauf <anl...@gmx.de> PR fortran/69741 * resolve.c (gfc_resolve_forall): Check for non-scalar index variables. 2016-11-19 Harald Anlauf <anl...@gmx.de> PR fortran/69741 * gfo

[Patch, fortran] PR69603 - ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

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 @@

[Patch, fortran] PR68566 ICE on using unusable array in reshape (double free or corruption)

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 @@ ||

Re: [PR fortran/60126] Internal compiler error with code using pointer reshaping (gfortran 4.8.2)

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

[PR fortran/60126] Internal compiler error with code using pointer reshaping (gfortran 4.8.2)

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 Anlauf

[patch, fortran] PR56007 Remarkably bad error message with DO array=1,2

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 <

Re: testsuite: missing or wrong dg-* directives?

On 01/14/13 00:10, Manfred Schwarb wrote: Am 13.01.2013 21:30, schrieb Harald Anlauf: On 01/12/13 22:02, Mikael Morin wrote: Le 08/01/2013 22:32, Harald Anlauf a écrit : On 12/28/12 21:49, Harald Anlauf wrote: Hello all, is there a default directive that is assumed when the testsuite is run

Re: testsuite: missing or wrong dg-* directives?

On 01/12/13 22:02, Mikael Morin wrote: Le 08/01/2013 22:32, Harald Anlauf a écrit : On 12/28/12 21:49, Harald Anlauf wrote: Hello all, is there a default directive that is assumed when the testsuite is run? Running an fgrep -L on the fortran testsuite, I found several files that are missing

<    4   5   6   7   8   9