https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
--- Comment #7 from Harald Anlauf ---
> The simple patch in comment #2 also works.
I know. But it only covers the issue in gfc_simplify_transpose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
--- Comment #6 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
> With the following patch len_trim is accepted in a specification expression:
Just forget that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
--- Comment #3 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #2)
> Actually, the problem is not related to zero length arrays, but to the
> constructor [integer::]. I think this is related to several other PRs.
Looking at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045
--- Comment #2 from Harald Anlauf ---
With trunk it appears essential to have at least -fcheck=bounds
as option, otherwise the testcase passes for me.
The dump-tree for the critical code part (with -fcheck=bounds):
p = t;
p.span =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203
--- Comment #12 from Harald Anlauf ---
The issues related to zero-length strings and zero-size arrays are fixed
on trunk and 8-branch. Backport to 7-branch would require additional
efforts, and as this PR is not about a regression, not done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203
--- Comment #9 from Harald Anlauf ---
Patch submitted for the character-related issues:
https://gcc.gnu.org/ml/fortran/2019-03/msg00017.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203
--- Comment #8 from Harald Anlauf ---
The following obvious patch fixes the character-related issues
(z1,z2,z3,z3a,z3b):
Index: expr.c
===
--- expr.c (revision 269357)
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #13 from Harald Anlauf ---
On 03/02/19 12:48, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
>
> Dominique d'Humieres changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77604
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544
--- Comment #9 from Harald Anlauf ---
(In reply to kargl from comment #8)
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c (revision 266281)
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
--- Comment #6 from Harald Anlauf ---
Adding the option -fno-tree-sra to -O1 (or -Os for the original case)
makes the ICE go away for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492
--- Comment #4 from Harald Anlauf ---
Patch with slightly extended testcase posted here:
https://gcc.gnu.org/ml/fortran/2019-02/msg00218.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492
--- Comment #3 from Harald Anlauf ---
I found another issue for uses of transfer('',['']), so here's an updated
version with a clearer error message:
Index: gcc/fortran/check.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
--- Comment #5 from Harald Anlauf ---
With rev. 269177 and on x86_64-pc-linux-gnu, I now see the ICE only at -O1,
but no longer at -Os.
After a frustrating debugging session, I decided to look at the
-fdump-tree-all for all options -O0 ... -O2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #10 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #9)
> A patch that does this has been posted here:
>
> https://gcc.gnu.org/ml/fortran/2019-02/msg00153.html
This patch also fixes PR88326.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103
--- Comment #4 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #3)
> Patch at https://gcc.gnu.org/ml/fortran/2018-09/msg00044.html.
Status of this patch? (The ICE is still there).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057
--- Comment #5 from Harald Anlauf ---
Patch submitted:
https://gcc.gnu.org/ml/fortran/2019-02/msg00176.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
--- Comment #4 from Harald Anlauf ---
Some digging shows that the name mangling is done in trans-decl.c,
gfc_sym_mangled_identifier. Strangely, the funny name mangling comes
from the component fn_result_spec being set in resolve.c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #9 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #8)
> I have a 'half-patch' that tries to change gfc_target_expr_size()
> to return a bool which is true for success and false for failure,
> and then deal with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299
Harald Anlauf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #19 from Harald Anlauf ---
The issues reported in comment #0, #1 and #3 should be fixed on trunk.
The fix for comment #0 has been backported to 7- and 8-branches.
Can the OP please confirm that the reported issues have been fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #17 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #16)
> Regarding the unwanted padding with \0, the following patch seems to
> solve the issue with transfer.
Regtested cleanly and submitted here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #16 from Harald Anlauf ---
Regarding the unwanted padding with \0, the following patch seems to
solve the issue with transfer.
Index: decl.c
===
--- decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248
--- Comment #9 from Harald Anlauf ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248
--- Comment #7 from Harald Anlauf ---
Patch submitted:
https://gcc.gnu.org/ml/fortran/2019-02/msg00112.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248
--- Comment #6 from Harald Anlauf ---
Moving the check from gfc_define_st_label to gfc_reference_st_label:
Index: symbol.c
===
--- symbol.c(revision 268826)
+++ symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299
--- Comment #5 from Harald Anlauf ---
Patch passed regtesting and was submitted:
https://gcc.gnu.org/ml/fortran/2019-02/msg00097.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299
--- Comment #4 from Harald Anlauf ---
I'm currently regtesting the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 268778)
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #8 from Harald Anlauf ---
It's not as trivial as I had hoped.
The point is that gfc_element_size() and gfc_target_expr_size()
are returning size 0 for the source expression, which is an entirely
correct value. However, they also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #7 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #6)
> The problem might be here:
>
> check.c: gfc_calculate_transfer_sizes
>
> 5482 /* Calculate the size of the source. */
> 5483 *source_size =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #6 from Harald Anlauf ---
The problem might be here:
check.c: gfc_calculate_transfer_sizes
5482 /* Calculate the size of the source. */
5483 *source_size = gfc_target_expr_size (source);
5484 if (*source_size == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #5 from Harald Anlauf ---
Alternative versions to test case #2:
program test
implicit none
character(1), save :: z = transfer ([''], '*') ! ICE
! character(1), save :: z = transfer ([character(0) ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
--- Comment #4 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #1)
> Goes back a long time, at least to gcc 6.
>
> I also think that this is valid code, but if somebody can find
> language in the standard that says otherwise,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #12 from Harald Anlauf ---
Further variant:
==> f4.f90 <==
character(1), save :: y = transfer ([('a'(1:1),i=1,1)], 'x')
print *, y
end
generates exactly the same code as f3, although it passes along slightly
different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #11 from Harald Anlauf ---
I'm currently using the following minimal testcases for further debugging:
==> f1.f90 <==
character(1), parameter :: u = transfer ([('a'(i:i),i=1,1)], 'x')
print *, u
end
==> f2.f90 <==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #10 from Harald Anlauf ---
The ICE in comment #0 is fixed on trunk so far.
The ICE is comment #1 is occurring on a different path and is under
further investigation, as well as the other wrong-code issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #8 from Harald Anlauf ---
OK, here's another one for fun:
program pr89077_4
implicit none
character(*), parameter :: s = 7HForward
print *, '#', s, '#', len (s)
end program pr89077_4
prints:
#Forward # 8
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #7 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #6)
Playing around and getting completely lost during a gdb session,
I became suspicious that the second issue has to do with missed
padding that interestingly occurs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #6 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
It does not fix the issue in comment #3. In fact, the simpler testcase
program pr89077_3
implicit none
character(20), parameter :: input = 'Forward'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #5 from Harald Anlauf ---
The following patch fixes the testcase and seems to pass regression testing.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868
--- Comment #6 from Harald Anlauf ---
Another testcase suitable for debugging is the following, which better
shows correspondence for pre-F2008 and F2008+ variants:
program test
implicit none
integer, pointer :: t(:), u(:)
integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868
--- Comment #5 from Harald Anlauf ---
Better testcase for debugging:
program pr85858
implicit none
integer, pointer :: t(:)
integer :: i, lb
lb = -1
allocate (t(lb:5))
do i = lb, 5
t(i) = i
end do
call te (t( :))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868
--- Comment #4 from Harald Anlauf ---
Reduced testcase:
program pr85858
implicit none
! integer, allocatable, target :: t(:)
integer, pointer :: t(:) => null()
integer :: i, lb = 0 ! run under debugger, or set lb to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868
--- Comment #3 from Harald Anlauf ---
Something has changed recently in 9-trunk, I now get with rev.268162
for the testcase in comment #0:
2.
Printing the array bounds in subroutine te gives the expected values,
so it must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336
--- Comment #6 from Harald Anlauf ---
The patch in comment #3 seems to apply to gcc-8, but I haven't regtested it.
Paul, do you intend to backport it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553
--- Comment #7 from Harald Anlauf ---
Patch submitted for review:
https://gcc.gnu.org/ml/fortran/2019-01/msg00201.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579
--- Comment #4 from Harald Anlauf ---
Patch submitted here:
https://gcc.gnu.org/ml/fortran/2019-01/msg00163.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88776
--- Comment #3 from Harald Anlauf ---
Created attachment 45407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45407=edit
Self-contained testcase
I've been able to produce a self-contained testcase, which may aid
debugging.
While reducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88776
--- Comment #1 from Harald Anlauf ---
I wrote "loss of data" because the second (valid) namelist could not be
properly read because of stat /= 0.
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
Reading namelist from unit 5 may skip valid data later when an error is
encountered. This problem does not occur when another unit number is used.
Example:
% cat gfcbug154.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88748
Harald Anlauf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
The patch committed to fix to PR 45424 does not handle the examples given
there in comment 1:
type t
integer :: i, j
end type t
type(t) :: x(5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
Harald Anlauf changed:
What|Removed |Added
Attachment #45322|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
Harald Anlauf changed:
What|Removed |Added
Attachment #45292|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
--- Comment #6 from Harald Anlauf ---
Created attachment 45292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45292=edit
Update of Tobias' patch to 9-trunk (except for ChangeLog)
I've tried to update Tobias' patch so that it compiles with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
--- Comment #5 from Harald Anlauf ---
Looking at the F2k18 draft, I see some updates and clarifications:
16.9.105 IS_CONTIGUOUS (ARRAY)
Description. Array contiguity test (8.5.7).
Class. Inquiry function.
Argument. ARRAY may be of any type. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579
--- Comment #3 from Harald Anlauf ---
Suggested testcase for the patch in comment #1, derived from power_7.f90:
! { dg-do run }
! { dg-additional-options "-fdump-tree-original" }
! Test optimizations for bases that are powers of 2.
program p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80661
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579
--- Comment #1 from Harald Anlauf ---
OK, here's my proof-of-concept patch (not cleaned up):
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 267353)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544
--- Comment #13 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #12)
> (In reply to Harald Anlauf from comment #10)
>
> > Handling positive powers of 2 should be straightforward:
> >
> > The condition is sth. like
> >
> > if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544
--- Comment #10 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #8)
> * trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer,
> (2|4|8|16) ** integer and (-1) ** integer.
Handling positive powers of 2 should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #9 from Harald Anlauf ---
(In reply to Richard Biener from comment #8)
> Created attachment 45252 [details]
> patch
>
> Even though the patch doesn't hoist the invariant condition the speed is
> back with it.
>
> Can you verify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #4 from Harald Anlauf ---
Without CONTIGUOUS, I see -O3 brings gcc-9 to the level of gcc-7 or gcc-8:
baseline + -O3 -funroll-loops -fcheck=bounds :
7: 1.57
8: 1.40
9: 1.57
baseline + -O3 -funroll-loops -fcheck=bounds -fno-tree-ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #3 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #2)
> Strange.
>
> I ran the code (with the data) a few times on my Ryzen 7 home
> system.
>
> Here are some timings (run 10 times):
[snipped]
> Is it possible that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #1 from Harald Anlauf ---
Created attachment 45250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45250=edit
Sparse matrix meta-data
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
Created attachment 45249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88399
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87764
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
--- Comment #4 from Harald Anlauf ---
(In reply to Stephan Kramer from comment #0)
Workaround:
> function make_list(i)
> integer, intent(in) :: i
> type(ilist), dimension(2) :: make_list
make_list = ilist()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
--- Comment #4 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #3)
> The code in comment 2 compiles for me with -fdefault-integer-8 (I get the
> error without it).
Oh, now I see that the issue is -O1 and/or -Os,
whereas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88364
--- Comment #5 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #4)
> A simple fix is not to do the clobbers if there is a reference:
The fix in c#4 fixes the testcase in c#2 for me.
I'll give it a try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #1 from Harald Anlauf ---
Further data points:
- removing the asynchronous='yes' for the first OPEN has no effect,
- removing the asynchronous='yes' for the second OPEN makes the problem
disappear
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
Created attachment 45187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45187=edit
Compile with -fopenmp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #15 from Harald Anlauf ---
(In reply to Jakub Jelinek from comment #14)
> Author: jakub
> Date: Thu Dec 6 10:28:31 2018
> New Revision: 266847
>
> URL: https://gcc.gnu.org/viewcvs?rev=266847=gcc=rev
This fixes the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #7 from Harald Anlauf ---
(In reply to kargl from comment #6)
> (In reply to Harald Anlauf from comment #5)
> >
> > A derived type with component initialization (like t_fileinfo) should
> > implicitly get the SAVE attribute, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #5 from Harald Anlauf ---
(In reply to Richard Biener from comment #4)
> Confirmed. We do not expect
>
> CHAIN.10->gattr = {CLOBBER};
>
> I believe the FE inserts these now to better share stack slots:
Thanks for pointing to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
--- Comment #1 from Harald Anlauf ---
The problem appears here:
Breakpoint 1, gfc_resolve_cshift (f=0x2431950, array=0x23bc1f0,
shift=0x23bc880, dim=0x23bcce0) at ../../trunk/gcc/fortran/iresolve.c:836
836 gfc_resolve_dim_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299
--- Comment #1 from Harald Anlauf ---
The warning was introduced in:
r260705 | janus | 2018-05-25 08:09:10 +0200 (Fri, 25 May 2018) | 16 lines
2018-05-25 Janus Weil
PR fortran/85839
* match.c (gfc_match_block_data): Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #3 from Harald Anlauf ---
Created attachment 45147
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45147=edit
Minimal netcdf-fortran part for the reproducer
Compile the netcdf.f90 header before the testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #1 from Harald Anlauf ---
No special options used, just:
% gfc-trunk -c -I/opt/gcc/9/pkg/netcdf/include gfcbug152.f90
(where above path hold the gfortran-9 specific netcdf.mod & friends).
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
Created attachment 45136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45136=edit
Reproducer
Current 9-trunk crashes for
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
I get with 9-trunk:
% cat gfcbug151.f90
subroutine gfcbug151 ()
! goto 999
999 continue
end subroutine gfcbug151
% gfc-trunk -c -std
1 - 100 of 660 matches
Mail list logo
