[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero

2022-04-19 Thread foreese at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310

Fritz Reese  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-19
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #1 from Fritz Reese  ---
Created attachment 52834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52834&action=edit
Patch which fixes the bug based on trunk

The bug is caused by gfc_conv_union_initializer in gcc/fortran/trans-expr.cc,
which accepts a pointer to a vector of constructor trees (vec*) as an argument, then appends one or two field constructors to the
vector. The problem is the use of CONSTRUCTOR_APPEND_ELT(v, ...) within
gfc_conv_union_initializer, which modifies the vector pointer v when a
reallocation of the vector occurs, but the pointer is passed by value.
Therefore, when a vector reallocation occurs, the vector caller's
(gfc_conv_structure) vector pointer is not updated and subsequently points to
freed memory. Chaos ensues.

The bug only occurs when gfc_conv_union_initializer itself triggers the
reallocation, which is whenever the vector is "full" (v->m_vecpfx.m_alloc ==
v->m_vecpfx.m_num). Since the vector defaults to allocating 8 elements and
doubles in size for every reallocation, the bug only occurs when there are 8,
16, 32, etc... fields with initializers prior to the union, causing the vector
of constructors to be resized when entering gfc_conv_union_initializer. The
-finit-derived and -finit-local-zero options together ensure each field has an
initializer, triggering the bug.

The patch fixes the bug by passing the vector pointer to
gfc_conv_union_initializer by reference, matching the signature of
vec_safe_push from within the CONSTRUCTOR_APPEND_ELT macro.

[Bug fortran/105310] New: ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero

2022-04-19 Thread foreese at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310

Bug ID: 105310
   Summary: ICE when UNION is after the 8th field in a DEC
STRUCTURE with -finit-derived -finit-local-zero
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52833&action=edit
Test case exhibiting the ICE

Consider:

$ cat testunion.for
  PROGRAM TESTU
IMPLICIT NONE
STRUCTURE /FOO/
  INTEGER(4) :: a,b,c,d,e,f,g,h
  UNION
  MAP
  ENDMAP
  ENDUNION
ENDSTRUCTURE
RECORD /FOO/ bar
bar.a = 1
  END

$ gfortran -O0 -c -ffixed-form -finit-local-zero -finit-derived -fdec-structure
testunion.for
testunion.for:15:0:

   end

internal compiler error: Segmentation fault
0xa72a2f crash_signal
/data/gcc-7.4.0/gcc/toplev.c:337
0xcb6a54 compute_reloc_for_constant(tree_node*)
/data/gcc-7.4.0/gcc/varasm.c:4120
0xcb6b5c compute_reloc_for_constant(tree_node*)
/data/gcc-7.4.0/gcc/varasm.c:4174
0xcbc802 get_variable_section(tree_node*, bool)
/data/gcc-7.4.0/gcc/varasm.c:1148
0xcc0cb7 assemble_variable(tree_node*, int, int, int)
/data/gcc-7.4.0/gcc/varasm.c:2225
0xcc4ce2 varpool_node::assemble_decl()
/data/gcc-7.4.0/gcc/varpool.c:588
0x7426fc output_in_order
/data/gcc-7.4.0/gcc/cgraphunit.c:2289
0x742ac3 symbol_table::compile()
/data/gcc-7.4.0/gcc/cgraphunit.c:2530
0x744b16 symbol_table::compile()
/data/gcc-7.4.0/gcc/cgraphunit.c:2629
0x744b16 symbol_table::finalize_compilation_unit()
/data/gcc-7.4.0/gcc/cgraphunit.c:2626
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


ICE occurs with 7.4 and higher, where the -fdec-structure and -finit-derived
options were introduced.

The ICE occurs at -O0 but not for higher optimization levels. The ICE occurs
only when there are (8*2^n) fields preceding the union, regardless of which
fields are in the union.

[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine

2021-01-01 Thread foreese at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986

--- Comment #3 from Fritz Reese  ---
(In reply to anlauf from comment #2)
...
> So I'd say the code in comment#0 is invalid, although the compiler is not
> required to diagnose this.
> 
> If you agree, we will close the issue as INVALID.

The error message blames fun_a() while neither fun_a() nor its containing
subroutine volatile_test() have a VOLATILE dummy argument. Do you think
15.4.2.2 still applies?

[Bug fortran/96986] New: [8 Regression] Explicit interface required: volatile argument for ENTRY subroutine

2020-09-08 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986

Bug ID: 96986
   Summary: [8 Regression] Explicit interface required: volatile
argument for ENTRY subroutine
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49200&action=edit
Testcase which exhibits the regression

GCC 8.3.1 does not accept the following program, but all versions 4.x through
7.x and <= 8.3.0 do:

$ cat volatile.for
  subroutine volatile_test ()
implicit none
integer(4), volatile :: va

entry fun_a()
return

entry fun_b(va)
  call fun_c()
return
  end

  subroutine fun_c ()
implicit none
call fun_a()
return
  end
$ gfortran -std=legacy -c volatile.for
volatile.for:15:18:

 call fun_a()
  1
Error: Explicit interface required for ‘fun_a’ at (1): volatile argument


It seems that because fun_b() has a volatile argument, the subroutine
volatile_test() is marked as such. Subsequently the call to fun_a() from
fun_c() within the same procedure trips the error.

The regression appears to have been introduced in r269895 on gcc-9 which fixed
PR 78865. The fix was backported to gcc-8 by r270032 and released as part of
8.3.1.

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-05-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

--- Comment #1 from Fritz Reese  ---
The regression is caused by r253156, which introduces the warning in the first
place. The relevant code is in frontend-passes.c (do_subscript). Apparently,
the FE is aware that when there is a conditional it cannot correctly simplify
the subscript bounds. However, in the testcase there is an inner DO-loop which,
when the bounds are reduced to the empty set, prevents the code from becoming
invalid. Therefore no warning should be issued.

The warning can be bypassed by guarding the inner DO-loop with any conditional,
including a vacuously true one:

$ diff -auw pascal.f03 pascal2.f03
--- pascal.f03  2020-05-06 19:14:50.966646632 -0400
+++ pascal2.f03 2020-05-06 19:23:48.209569659 -0400
@@ -9,9 +9,11 @@

 do i = 0, 8
   pascal(i,0) = 1
+  if (.true.) then
   do j = 1, i-1
 pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1)
   enddo
+  endif
   do j = i, 8
 pascal(i,j) = 0
   enddo
$ gfortran pascal2.f03


Normally the warning can be suppressed with -Wno-do-subscript, but the code in
do_subscript() determines that this is "definitely" an issue and therefore
moves the warning to category 0.

(An interesting note: moving the code in the testcase into a subroutine, rather
than the main program, suppresses the warning for GCC 8, but not GCC 9, 10, or
11.)

[Bug fortran/94978] New: [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-05-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

Bug ID: 94978
   Summary: [8/9/10/11 Regression] Bogus warning "Array reference
at (1) out of bounds in loop beginning at (2)"
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48472&action=edit
Testcase which exhibits the regression

The following issues a bogus warning which cannot be disabled except with -w.
The warning is not present in 7.x or earlier. Tried with 8.4.1, 9.3.1, 10 and
11.x (current trunk). Attached is a simple test case, which builds Pascal's
triangle of order 8 and exhibits the regression.

$ gfortran pascal.f03
pascal.f03:13:25:

   10 | do i = 0, 8
  |   2  
..
   13 | pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1)
  | 1
Warning: Array reference at (1) out of bounds (-1 < 0) in loop beginning at (2)
pascal.f03:13:41:

   10 | do i = 0, 8
  |   2  
..
   13 | pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1)
  | 1
Warning: Array reference at (1) out of bounds (-1 < 0) in loop beginning at (2)

[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'

2020-04-22 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586

Fritz Reese  changed:

   What|Removed |Added

 CC||foreese at gcc dot gnu.org

--- Comment #29 from Fritz Reese  ---
John, I wonder could you output your generated kinds.h? It will be in
$GCCBUILD/stageN-/libgfortran/kinds.h if your build has made it far
enough. If you have a functional gfortran you can also generate it with
"$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to
expose the core type which gfortran uses for REAL(16) according to the target.

I'd also like to know the results of building with the two patches in pr94694.
I think you should keep the target-specific portions of your patch, including
mods to gcc/fortran/trans-types.c, but I think you should then be able to drop
the changes to libgfortran/intrinsics/trigd.c and libgfortran/kinds-override.h.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-22 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Fritz Reese  changed:

   What|Removed |Added

  Attachment #48332|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #26 from Fritz Reese  ---
Created attachment 48351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48351&action=edit
Patch to protect trigd functions based on system availability (v2)

I've attached a new patch for trigd. Below is the delta on top of the old
patch. I'm building and testing now. Jakub, if you concur, I will commit these
patches and close the PR after successful testing.

diff --git a/libgfortran/intrinsics/trigd_lib.inc
b/libgfortran/intrinsics/trigd_lib.inc
index 66e22c3845e..e90f9deaa5a 100644
--- a/libgfortran/intrinsics/trigd_lib.inc
+++ b/libgfortran/intrinsics/trigd_lib.inc
@@ -128,9 +128,9 @@ PIO180L   -- lower bits of pi/180 for FMA
 #define mpz_cmp_ui(x, y) ((x) - (y))
 #define mpz_divisible_ui_p(n, d) ((n) % (d) == 0)

-#define D2R(x) (x = FMA((x), PIO180H, (x) * PIO180L))
+#define D2R(x) (x = FMA((x), PIO180H_LITERAL, (x) * PIO180L_LITERAL))

-#define SET_COSD30(x) (x = COSD30)
+#define SET_COSD30(x) (x = COSD30_LITERAL)

 #ifdef SIND
 extern FTYPE SIND (FTYPE);

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-22 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #25 from Fritz Reese  ---
(In reply to Jakub Jelinek from comment #24)
> The dec_math.f90 FAILs are at all opt levels:
> ( ) qsind( 60.00) 
> 0.866025403784438646763723170753  0.866025403784438596588302061718
> Note: The following floating-point exceptions are signalling:
> IEEE_INVALID_FLAG
> STOP 1
> 
> If I preprocess trigd.c before/after the #c21 patch, the difference (appart
> from lines/whitespace) are:
> -   (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f)));
> +   (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06));
> 
> -   (x = 8.66025388e-01f);
> +   (x = 8.66025388e-01);
> 
> -   (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f)));
> +   (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06));
> 
> -   (x = 8.66025388e-01f);
> +   (x = 8.66025388e-01);
> 
> ...
> -  static const volatile GFC_REAL_10 tiny = 0x1.p-16400L;
> +  static const volatile GFC_REAL_10 tiny = 0x1.p-16400l;
> ...
> -   (x = 8.66025403784438646787e-01L);
> +   (x = 8.66025403784438646787e-01);
> ...
> -   (x = fmal(((x)), (1.74532925229868851602e-02L), ((x) *
> -3.04358939097084072823e-12L)));
> +   (x = fmal((x), 1.74532925229868851602e-02, (x) *
> -3.04358939097084072823e-12));
> ...
> -   (x = 8.66025403784438646763723170752936183e-01q);
> +   (x = 8.66025403784438646763723170752936183e-01);
> 
> etc., so all that matters is that some float suffixes (f, , L, q) are gone
> from the constants (and the L -> l change on tiny and a few others), which
> of course matters a lot.

Ah, yes, I missed some LITERAL(x) wrappings. Will fix and post an updated patch
shortly.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #21 from Fritz Reese  ---
Created attachment 48332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48332&action=edit
Patch to protect trigd functions based on system availability

Patch for trigd include pieces to check for HAVE_XXX[*]. If a required piece is
not defined, the function is replaced with simply a runtime_error().

@akrl and @ktkachov, please combine this with Jakub's patch and see how the
build goes. Like Jakub I am also on x86_64-linux and it is difficult to
exercise all the conditions.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #18 from Fritz Reese  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > I've missed that.  I'm afraid there is no way around missing sinl/cosl/tanl
> > etc.,
> > those aren't likely implemented inline by the compiler.  The only exception
> > would be for targets where long double and double are the same type.
> > What has libgfortran been doing before?  Seems to me it just wouldn't define
> > the _gfortran* entrypoint that use them.
> 
> But if long double is 64-bit, there is no really a point to use the *l
> suffixed functions, is it?

If long double is 64-bit, then neither REAL(10) nor REAL(16) will be available,
since the kinds are set by precision / 8. Then HAVE_GFC_REAL_16 and
HAVE_GFC_REAL_10 are not defined, in which case the *l suffixed version is not
built. The problem comes when REAL(10) or REAL(16) are supported by the system,
but the system's libm does not declare or define the math builtins for that
precision.

(In reply to Jakub Jelinek from comment #15)
> Thus, I think we can extend the patch I've attached (and fix the two fmaf to
> fmal spots), plus do the HAVE_INLINE_BUILTIN_* in configure.ac either
> through a config/math.m4 macro, or through a loop over the functions that
> can have such treatment with a likely inlined implementation.
> 

According to comments in pr94586, it seems that on HPUX __builtin_cosl is
available but a proper "cosl" is not. I'm not sure how this happens but it
suggests to me that a similar pattern might work for the trig functions, at
least sometimes.

(In reply to Jakub Jelinek from comment #17)
> (In reply to rguent...@suse.de from comment #16)
> > Maybe they can be implemented like
> > 
> > long double _gfortran_xyz (long double x)
> > {
> >   __sorry_fortran_intrinsic_xyz_is_not_available_because_cosl_is_not ();
> > }
> > 
> > instead of simply not providing them.  Coordination between the FE
> > and (the various multilibs of) libgfortran and emitting diagnostics
> > from the FE would of course be even better.
> 
> libgfortran has runtime_error or internal_error and other functions that can
> deliver messages to the user, sure.

Yes, I think we should use this approach at least. It is not immediately clear
to me how to properly check this in the FE. I think checking HAVE_* at compiler
compile time in the FE is wrong. I don't know what/how the FE can inquire about
the library at compile (run) time.

> But still, the trig*.inc needs to check HAVE_* macros of everything that it
> uses and just don't provide the definitions if it can't be implemented.

I will provide a patch which handles the checks in trigd*.inc. I have no
experience writing m4/autoconf so I would appreciate help streamlining that
side. The best I could do quickly is to simply extend your patch with copy |
paste | sed and touching up c99_functions.c. I expect there is probably some
better way to reduce duplication, thus opportunities for typos.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #12 from Fritz Reese  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 48326 [details]
> gcc10-pr94694.patch
> 
> Completely untested full patch.  Will try to test it on x86_64-linux where
> it hopefully shouldn't change anything, but have no (easy) way to test on
> targets where it is actually needed.

There is a typo under "#ifndef HAVE_FMAL" (c99_functions.c:2151). fmaf is
re-defined where fmal should be defined.


(In reply to Jakub Jelinek from comment #11)
> (In reply to Fritz Reese from comment #8)
> > I like this solution in principle but we would need to add fabsl, fmal, and
> > copysignl, right? And then we are still left with the question: what do we
> > do if HAVE_INLINE_BUILTIN_COPYSIGN, HAVE_FMOD, or similar are not satisfied
> > at the lowest level?
> 
> I don't know what else is missing, I understood the problem is with
> copysign, fma, fmaf and fmal.
> copysignl can be handled like copysign just using __builtin_copysignl,
> fabs and fabsf can be handled like copysign too, again gcc will usually
> expand those inline.
> One needs to have very weird floating point format, and such arches will
> likely either not support libgfortran, or will have support in libm.  So we
> can defer further fallback until somebody reports it doesn't work somewhere.

According to the OP, none of fabsl, fmal, copysignl, cosl, sinl, tanl are
defined. The patch should be extended to provide all of these, utilizing
__builtin_cosl, __builtin_sinl, etc... What you say is right: if those aren't
available, the intrinsic is FUBAR and should not be available for that kind.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Fritz Reese  changed:

   What|Removed |Added

 CC||foreese at gcc dot gnu.org

--- Comment #8 from Fritz Reese  ---
(In reply to Jakub Jelinek from comment #7)
> So, I meant something like:
> --- libgfortran/configure.ac.jj   2020-01-24 22:34:36.340641225 +0100
> +++ libgfortran/configure.ac  2020-04-21 18:03:02.494598615 +0200
> @@ -392,6 +392,9 @@ GCC_CHECK_MATH_FUNC([cabsl])
>  GCC_CHECK_MATH_FUNC([floorf])
>  GCC_CHECK_MATH_FUNC([floor])
>  GCC_CHECK_MATH_FUNC([floorl])
> +GCC_CHECK_MATH_FUNC([fmaf])
> +GCC_CHECK_MATH_FUNC([fma])
> +GCC_CHECK_MATH_FUNC([fmal])
>  GCC_CHECK_MATH_FUNC([fmodf])
>  GCC_CHECK_MATH_FUNC([fmod])
>  GCC_CHECK_MATH_FUNC([fmodl])
[...]
> 
> except that the test in configure for HAVE_INLINE_BUILTIN_COPYSIGN still
> needs to be written.

I like this solution in principle but we would need to add fabsl, fmal, and
copysignl, right? And then we are still left with the question: what do we do
if HAVE_INLINE_BUILTIN_COPYSIGN, HAVE_FMOD, or similar are not satisfied at the
lowest level?

(In reply to Richard Biener from comment #2)
> Note in another bug it was said that libgfortran requires a C99 runtime,
> when that's not available you should disable gfortran build.  GCC (or
> libgfortran)
> is in no position to disable parts of its features and AFAICS for QOI issues
> the _frontend_ would need to reject programs making use of disabled library
> functionality, otherwise programs are going to only fail to link.
> 
> IMHO failure at runtime when the disabled functionality is actually invoked
> isn't good QOI either.
[...]

Yes, I agree. The FE should notify the user for intrinsics which would not be
implemented in the library, if we indeed selectively disable such intrinsics. 

Note that, there is currently precedent for this in the library without
concurrence of the FE: libgfortran/intrinsic/symlnk.c contains the definitions
of the SYMLNK intrinsic (symlnk_iX_sub) guarded by "#ifdef HAVE_SYMLINK". There
is no parallel check in the FE, so I imagine that on a system for which
HAVE_SYMLINK is not defined one would experience a link failure (if there is
any such system on which gfortran can be built).

(In reply to Richard Earnshaw from comment #5)
> (In reply to Richard Biener from comment #2)
> > [...]
> > Since Fortran isn't release critical the only P1-ish part is that fortran
> > build is enabled on aarch64-elf and thus we can resolve this by adding
> > aarch64-elf-*) to
> > [...]
> > technically aarch64-elf isn't a primary architecture.
> 
> Well in that case it should *test* the run time for compatibility.  It
> shouldn't assume it's incompatible just because of the target triplet.
> 
> aarch64-elf is a secondary platform.  It should still build.

I concur. Perhaps a narrower solution is to disable REAL(1[06]) support on the
platform if the *l math functions are not available... Though I prefer Jakub's
solution of providing the missing functions in c99_functions.c so long as the
core functionailty is available on the system.

[Bug libfortran/93871] COTAN is slow for complex types

2020-04-20 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

--- Comment #49 from Fritz Reese  ---
(In reply to ktkachov from comment #48)
> (In reply to CVS Commits from comment #45)
[...]
> 
> I think this broke the build for bare-metal (newlib) targets like
> aarch64-none-elf:
> 
> libgfortran/intrinsics/trigd_lib.inc:55:56: error: implicit declaration of
> function 'copysignl' [-Werror=implicit-function-declaration]
>55 | #define mpfr_copysign(rop, op1, op2, rnd) rop =
> SUFFIX(copysign)((op1), (op2))
>   |^~~~
> 
> I think newlib doesn't support long double functions well so likely doesn't
> have copysignl. Is there some way this use can be conditionalised on library
> support?

I believe I should use HAVE_* macros from libgfortran/config.h to check
availability of the required functions fmod[x], fabs[x], and copysign[x]. I
will check this out and patch a fix shortly, thanks for the report.

[Bug fortran/87923] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

2020-04-09 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87923

Fritz Reese  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Fritz Reese  ---
Fixed on master.

[Bug libfortran/93871] COTAN is slow for complex types

2020-04-07 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

Fritz Reese  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #46 from Fritz Reese  ---
Fixed on trunk.

[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor

2020-04-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657

Fritz Reese  changed:

   What|Removed |Added

  Known to fail||10.0
 CC||foreese at gcc dot gnu.org
   Last reconfirmed|2018-07-24 00:00:00 |2020-4-6

--- Comment #5 from Fritz Reese  ---
I can confirm using valgrind that the invalid read is still present on trunk:

[...]
$ gfortran --version |& head -n1
GNU Fortran (GCC) 10.0.1 20200406 (experimental)
$ valgrind --track-origins=yes f951 -fdec dec_type_print_2.f03
==16491== Invalid read of size 1
==16491==at 0x8721CA: gfc_add_flavor(symbol_attribute*, sym_flavor, char
const*, locus*) (symbol.c:1775)
==16491==by 0x8724E8: gfc_add_generic(symbol_attribute*, char const*,
locus*) (symbol.c:1710)
==16491==by 0x7C2BDD: gfc_match_derived_decl() [clone .part.0]
(decl.c:10434)
==16491==by 0x7C3518: gfc_match_derived_decl (decl.c:10339)
==16491==by 0x7C3518: gfc_match_type(gfc_statement*) (decl.c:10311)
==16491==by 0x8293C8: decode_statement() (parse.c:418)
==16491==by 0x82EC84: next_free (parse.c:1279)
==16491==by 0x82EC84: next_statement() (parse.c:1511)
==16491==by 0x8307BC: parse_spec(gfc_statement) (parse.c:3922)
==16491==by 0x8334FC: parse_progunit(gfc_statement) (parse.c:5851)
==16491==by 0x834BE6: gfc_parse_file() (parse.c:6392)
==16491==by 0x88529F: gfc_be_parse_file() (f95-lang.c:210)
==16491==by 0xDEA153: compile_file() (toplev.c:458)
==16491==by 0x78E62B: do_compile (toplev.c:2273)
==16491==by 0x78E62B: toplev::main(int, char**) (toplev.c:2412)
==16491==  Address 0x5f93a38 is 280 bytes inside a block of size 344 free'd
==16491==at 0x4C2AF9D: free (vg_replace_malloc.c:540)
==16491==by 0x8758C1: gfc_restore_last_undo_checkpoint() (symbol.c:3697)
==16491==by 0x8293B1: decode_statement() (parse.c:414)
==16491==by 0x82EC84: next_free (parse.c:1279)
==16491==by 0x82EC84: next_statement() (parse.c:1511)
==16491==by 0x8307BC: parse_spec(gfc_statement) (parse.c:3922)
==16491==by 0x8334FC: parse_progunit(gfc_statement) (parse.c:5851)
==16491==by 0x834BE6: gfc_parse_file() (parse.c:6392)
==16491==by 0x88529F: gfc_be_parse_file() (f95-lang.c:210)
==16491==by 0xDEA153: compile_file() (toplev.c:458)
==16491==by 0x78E62B: do_compile (toplev.c:2273)
==16491==by 0x78E62B: toplev::main(int, char**) (toplev.c:2412)
==16491==by 0x7921DE: main (main.c:39)
==16491==  Block was alloc'd at
==16491==at 0x4C2BFB9: calloc (vg_replace_malloc.c:762)
==16491==by 0x18A48C0: xcalloc (xmalloc.c:162)
==16491==by 0x874EBE: gfc_new_symbol (symbol.c:3131)
==16491==by 0x874EBE: gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) (symbol.c:3365)
==16491==by 0x875283: gfc_get_symbol(char const*, gfc_namespace*,
gfc_symbol**) (symbol.c:3418)
==16491==by 0x801D46: gfc_match_label() (match.c:614)
==16491==by 0x804770: gfc_match_forall(gfc_statement*) (match.c:2555)
==16491==by 0x8293A3: decode_statement() (parse.c:412)
==16491==by 0x82EC84: next_free (parse.c:1279)
==16491==by 0x82EC84: next_statement() (parse.c:1511)
==16491==by 0x8307BC: parse_spec(gfc_statement) (parse.c:3922)
==16491==by 0x8334FC: parse_progunit(gfc_statement) (parse.c:5851)
==16491==by 0x834BE6: gfc_parse_file() (parse.c:6392)
==16491==by 0x88529F: gfc_be_parse_file() (f95-lang.c:210)
==16491== 
==16491== Invalid read of size 1
==16491==at 0x8721CA: gfc_add_flavor(symbol_attribute*, sym_flavor, char
const*, locus*) (symbol.c:1775)
==16491==by 0x7C2C4A: gfc_match_derived_decl() [clone .part.0]
(decl.c:10478)
==16491==by 0x7C3518: gfc_match_derived_decl (decl.c:10339)
==16491==by 0x7C3518: gfc_match_type(gfc_statement*) (decl.c:10311)
==16491==by 0x8293C8: decode_statement() (parse.c:418)
==16491==by 0x82EC84: next_free (parse.c:1279)
==16491==by 0x82EC84: next_statement() (parse.c:1511)
==16491==by 0x8307BC: parse_spec(gfc_statement) (parse.c:3922)
==16491==by 0x8334FC: parse_progunit(gfc_statement) (parse.c:5851)
==16491==by 0x834BE6: gfc_parse_file() (parse.c:6392)
==16491==by 0x88529F: gfc_be_parse_file() (f95-lang.c:210)
==16491==by 0xDEA153: compile_file() (toplev.c:458)
==16491==by 0x78E62B: do_compile (toplev.c:2273)
==16491==by 0x78E62B: toplev::main(int, char**) (toplev.c:2412)
==16491==by 0x7921DE: main (main.c:39)
==16491==  Address 0x5f93a38 is 280 bytes inside a block of size 344 free'd
==16491==at 0x4C2AF9D: free (vg_replace_malloc.c:540)
==16491==by 0x8758C1: gfc_restore_last_undo_checkpoint() (symbol.c:3697)
==16491==by 0x8293B1: decode_statement() (parse.c:414)
==16491==by 0x82EC84: next_free (parse.c:1279)
==16491==by 0x82EC84: next_statement() (parse.c:1511)
==16491==by 0x8307BC: parse

[Bug fortran/93686] [9/10 Regression] ICE in gfc_match_data, at fortran/decl.c:702

2020-04-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686

--- Comment #6 from Fritz Reese  ---
Backported to 9.

[Bug fortran/93686] [9/10 Regression] ICE in gfc_match_data, at fortran/decl.c:702

2020-04-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686

Fritz Reese  changed:

   What|Removed |Added

 CC||foreese at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2020-4-6
 Resolution|--- |FIXED

--- Comment #4 from Fritz Reese  ---
Fixed by Steve's patch from
https://gcc.gnu.org/pipermail/fortran/2020-April/054192.html .

[Bug fortran/87923] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

2020-04-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87923

Fritz Reese  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Status|ASSIGNED|WAITING

--- Comment #3 from Fritz Reese  ---
Patch submitted at https://gcc.gnu.org/pipermail/fortran/2020-April/054195.html
. Awaiting review.

[Bug fortran/87644] [8/9/10 Regression] ICE due to variable named "parameters"

2020-04-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644

Fritz Reese  changed:

   What|Removed |Added

  Known to fail||7.1.0, 7.2.0, 7.3.0, 8.1.0,
   ||8.2.0, 8.3.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||10.0, 8.4.0, 9.1.0, 9.2.0,
   ||9.3.0

--- Comment #7 from Fritz Reese  ---
This ICE appears to have been fixed between gcc 8.3.0 and 8.4.0, and is fixed
for all gcc 9s and 10s.

I don't know exactly which commit fixed this, but it's possible the fix may be
due to:

commit 9a8c5d2d7d4ce515a961f19f8012f165044ebbe8
Author: Thomas Koenig 
Date:   Sun Mar 10 10:28:14 2019 +

re PR fortran/87734 (ICE in is_illegal_recursion check for character len=
pa
rameter)

2019-03-10  Thomas Koenig  
Steven G. Kargl  

PR fortran/87734
Backort from trunk
* symbol.c (gfc_add_procedure): Only throw an error if the
procedure has not been declared either PUBLIC or PRIVATE.
* resolve.c (is_illegal_recursion): Remove an assert().

2019-03-10  Thomas Koenig  

PR fortran/87734
Backport from trunk
* gfortran.dg/public_private_module_10.f90: New test.


Co-Authored-By: Steven G. Kargl 

From-SVN: r269548

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

2020-04-02 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982

Fritz Reese  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Fritz Reese  ---
Fixed in master and backported to gcc-8 and gcc-9.

[Bug libfortran/93871] COTAN is slow for complex types

2020-04-01 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

[Bug libfortran/93871] COTAN is slow for complex types

2020-04-01 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

Fritz Reese  changed:

   What|Removed |Added

  Attachment #47883|0   |1
is obsolete||
  Attachment #47913|0   |1
is obsolete||

--- Comment #44 from Fritz Reese  ---
Created attachment 48164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48164&action=edit
Patch for trunk

Final version of patch submitted, pending final review.

cf. https://gcc.gnu.org/pipermail/fortran/2020-March/054162.html and the
containing thread for details.

The patch includes and extends Steve's changes which rework the degree-valued
trigonometric functions.

COTAN is implemented as -TAN(x+pi/2) for REAL values, and COS(x)/SIN(x) for
complex values. COTAND is implemented as -TAND(x+90). These are equivalent to
1/TAN[D] but should be faster than division. SIND, COSD, and TAND are rewritten
to use Steve's range folding technique into [0, 45] both at runtime from
libgfortran and at simplification time for constant expressions.

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

2020-04-01 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919

Fritz Reese  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Fritz Reese  ---
Yes, this was FIXED since the patches applied 2018-12-03.

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

2020-04-01 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #5 from Fritz Reese  ---
PINGed at https://gcc.gnu.org/pipermail/fortran/2020-April/054171.html

[Bug libfortran/93871] COTAN is slow for complex types

2020-02-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

Fritz Reese  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-21
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Fritz Reese  ---
Thomas, thank you for discovering this. Steve, thanks for your investigative
work and the patch. I will try to look at this and get a patch in within the
next week or so.

[Bug fortran/91310] Read overflow generated by character array assignment to self

2019-07-31 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310

--- Comment #4 from Fritz Reese  ---
Created attachment 46651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46651&action=edit
intermediate code for test case 2

You can see the central loop described in the original report from lines 18-25.
The bounds of the loop are problematic, as iterations 509-511 will overflow the
source buffer. The optimized version is able to detect the overflow and issue a
warning.

[Bug fortran/91310] Read overflow generated by character array assignment to self

2019-07-31 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310

--- Comment #3 from Fritz Reese  ---
Created attachment 46650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46650&action=edit
intermediate code for test case 1

You can see the central condition described in the original report from lines
17-25, and the problematic __builtin_memmove on line 24, which in the optimized
version of the tree causes the warning.

> __builtin_memmove ((void *) &str, (void *) &str[D.3853]{lb: 1 sz: 1}, 512);

[Bug fortran/91310] Read overflow generated by character array assignment to self

2019-07-31 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310

--- Comment #2 from Fritz Reese  ---
Created attachment 46649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46649&action=edit
test case 2

[Bug fortran/91310] Read overflow generated by character array assignment to self

2019-07-31 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310

--- Comment #1 from Fritz Reese  ---
Created attachment 46648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46648&action=edit
test case 1

[Bug fortran/91310] New: Read overflow generated by character array assignment to self

2019-07-31 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310

Bug ID: 91310
   Summary: Read overflow generated by character array assignment
to self
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

The following simple test cases read_overflow1.for and read_overflow2.for
generate warnings when compiled with -O2 (in gfortran 9.1.0) which allude to
the bug which is a read overflow generated from a character array assignment
within a single variable where the bounds of the LHS and RHS are known.

> $ cat read_overflow1.for
>   subroutine s(len)
> implicit none
> character str*512
> integer(4) :: offset
> integer(4), intent(in) :: len
> 
> offset = 4
> str(1:) = str(offset:len+3)
> print *, str
>   end subroutine
> $ diff read_overflow1.for read_overflow2.for
> 3c3
> < character str*512
> ---
> > character str(512)
> $ gfortran -c -O0 read_overflow1.for # no warning
> $ gfortran -c -O2 read_overflow1.for
> read_overflow1.for:9:0:
> 
> 9 |   str(1:) = str(offset:len+3)
>   | 
> Warning: ‘__builtin_memmove’ reading 512 bytes from a region of size 509 
> [-Wstringop-overflow=]
> $ gfortran -c -O0 read_overflow2.for # no warning
> $ gfortran -c -O2 read_overflow2.for
> read_overflow2.for:9:0:
> 
> 9 |   str(1:) = str(offset:len+3)
>   | 
> Warning: iteration 509 invokes undefined behavior 
> [-Waggressive-loop-optimizations]
> read_overflow2.for:9:0: note: within this loop

The issue can be seen in the trees dumped by -fdump-tree-original and
-fdump-tree-optimized, both at -O0 and -O2 for both test cases. The
intermediate code generated is equivalent for both optimization levels. For
read_overflow1.for it boils down to the following:

> _read_length = len - 3;
> if (_read_length < 512) {
>   __builtin_memmove(&str, &str+3, _read_length);
>   __builtin_memset(&str, ' ', 512 - _read_length);
> } else {
>   __builtin_memmove(&str, &str+3, 512);
> }

The trees for read_overflow2.for are similar but are expanded into a loop
equivalent to the following:

> idx = 0;
> while (idx < 512) {
>   str[idx][1] = str[idx + 3][1];
>   ++idx;
> }

Clearly, code is generated to avoid overflow when _writing_ to str, but there
is no code generated to avoid overflow when _reading_ from str, though both the
source and destination sizes are known. In fact if len is > 509, the last three
characters would result in a read overflow of the str character array and
garbage would be written to the end of the array.

The warnings are only issued in -O2 because the intermediate code is simplified
enough for the overflow to be obvious.

A workaround from the user perspective is to replace the assignment with two
explicitly bounded assignments:

> s(1:len) = s(offset:len+3)
> s(len+1:) = ' '

In this case no overflow can occur from the generated code.


AFAICT the standard does not specify what to do when an assignment occurs among
array sections of differing sizes, so it is up to the compiler to be sensible.
One might argue it is not against the standard to ignore the source size and
always write the destination size -- however, I rather think of it as blatant
negligence on the compiler's part in this case, since the bounds of both are
known and it already tries to avoid overflow of one operation (write) but not
the other (read). If the behavior is intentional and the code _should_ result
in an overflow, then a consistent and obvious warning should be issued for all
optimization levels - but I don't think that it should.

[Bug fortran/87644] [7/8/9 Regression] ICE due to variable named "parameters"

2019-03-11 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||foreese at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

2018-12-03 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919

--- Comment #2 from Fritz Reese  ---
Author: foreese
Date: Mon Dec  3 15:42:51 2018
New Revision: 266745

URL: https://gcc.gnu.org/viewcvs?rev=266745&root=gcc&view=rev
Log:
2018-12-03  Fritz Reese  
Mark Eggleston 

PR fortran/87919

gcc/fortran/ChangeLog:

PR fortran/87919
* options.c (SET_FLAG, SET_BITFLAG, SET_BITFLAG2): New macros.
(set_dec_flags): Set/unset DEC and std flags according to value.
(set_init_local_zero): New helper for -finit-local-zero flag group.
(gfc_init_options): Fix disabling of init flags, array temporaries
check, and dec flags when value is zero (from -fno-*).

gcc/testsuite/ChangeLog:

PR fortran/87919
* gfortran.dg/array_temporaries_5.f90: New test.
* gfortran.dg/dec_bitwise_ops_3.f90: Ditto.
* gfortran.dg/dec_d_lines_3.f: Ditto.
* gfortran.dg/dec_exp_4.f90: Ditto.
* gfortran.dg/dec_exp_5.f90: Ditto.
* gfortran.dg/dec_io_7.f90: Ditto.
* gfortran.dg/dec_structure_24.f90: Ditto.
* gfortran.dg/dec_structure_25.f90: Ditto.
* gfortran.dg/dec_structure_26.f90: Ditto.
* gfortran.dg/dec_structure_27.f90: Ditto.
* gfortran.dg/dec_type_print_3.f90: Ditto.
* gfortran.dg/init_flag_20.f90: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
trunk/gcc/testsuite/gfortran.dg/dec_bitwise_ops_3.f90
trunk/gcc/testsuite/gfortran.dg/dec_d_lines_3.f
trunk/gcc/testsuite/gfortran.dg/dec_exp_4.f90
trunk/gcc/testsuite/gfortran.dg/dec_exp_5.f90
trunk/gcc/testsuite/gfortran.dg/dec_io_7.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_24.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_25.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_26.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_27.f90
trunk/gcc/testsuite/gfortran.dg/dec_type_print_3.f90
trunk/gcc/testsuite/gfortran.dg/init_flag_20.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/88025] [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468

2018-11-20 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88025

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

[Bug fortran/87923] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

2018-11-20 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87923

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |7.5

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

2018-11-12 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Fritz Reese  ---
Patch submitted at https://gcc.gnu.org/ml/fortran/2018-11/msg00069.html

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

2018-11-07 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2018-05-31 00:00:00 |2018-11-7
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
  Known to fail||6.4.0, 9.0

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

2018-11-07 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-07
 CC||foreese at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

[Bug fortran/86543] [9 Regression] FAIL: gfortran.dg/dec_structure_23.f90 -O (test for errors, line 16)

2018-07-17 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83184,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83633
 Resolution|--- |FIXED

--- Comment #3 from Fritz Reese  ---
Fixed in r262828.

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-07-17 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

--- Comment #8 from Fritz Reese  ---
Author: foreese
Date: Tue Jul 17 16:02:03 2018
New Revision: 262828

URL: https://gcc.gnu.org/viewcvs?rev=262828&root=gcc&view=rev
Log:
2018-07-17  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/83184
* gfortran.dg/dec_structure_23.f90: Oops, "un-fix" error messages.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90

[Bug fortran/86543] [9 Regression] FAIL: gfortran.dg/dec_structure_23.f90 -O (test for errors, line 16)

2018-07-17 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543

Fritz Reese  changed:

   What|Removed |Added

 CC||foreese at gcc dot gnu.org

--- Comment #2 from Fritz Reese  ---
(In reply to janus from comment #0)
> I'm seeing the following failures on trunk:
> 
> FAIL: gfortran.dg/dec_structure_23.f90   -O   (test for errors, line 16)
> FAIL: gfortran.dg/dec_structure_23.f90   -O   (test for errors, line 17)
> FAIL: gfortran.dg/dec_structure_23.f90   -O   (test for errors, line 18)
> FAIL: gfortran.dg/dec_structure_23.f90   -O  (test for excess errors)
> ...
> 
> 
> Sounds like the error message changed?

Oops, I thought I fixed that. I’ll patch it today.

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

--- Comment #7 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 23:35:39 2018
New Revision: 262759

URL: https://gcc.gnu.org/viewcvs?rev=262759&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/83184
Backport from trunk.
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.

gcc/fortran/ChangeLog:

PR fortran/83184
Backport from trunk.
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
  - copied unchanged from r262747,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
  - copied unchanged from r262747,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_structure_23.f90
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_structure_8.f90

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325

--- Comment #4 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 22:25:54 2018
New Revision: 262751

URL: https://gcc.gnu.org/viewcvs?rev=262751&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/83183] Out of memory with option -finit-derived

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83183

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 22:25:54 2018
New Revision: 262751

URL: https://gcc.gnu.org/viewcvs?rev=262751&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417

--- Comment #17 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 22:25:54 2018
New Revision: 262751

URL: https://gcc.gnu.org/viewcvs?rev=262751&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

--- Comment #6 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 20:55:32 2018
New Revision: 262748

URL: https://gcc.gnu.org/viewcvs?rev=262748&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

  gcc/testsuite/ChangeLog:

PR fortran/83184
* gfortran.dg/dec_structure_23.f90: Oops, "un-fix" error messages.


Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_structure_23.f90

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 19:10:39 2018
New Revision: 262747

URL: https://gcc.gnu.org/viewcvs?rev=262747&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/83184
Backport from trunk.
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.

gcc/fortran/ChangeLog:

PR fortran/83184
Backport from trunk.
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
  - copied unchanged from r262744,
trunk/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
  - copied unchanged from r262744,
trunk/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_structure_23.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_structure_8.f90

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/83183] Out of memory with option -finit-derived

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83183

--- Comment #4 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:59:44 2018
New Revision: 262746

URL: https://gcc.gnu.org/viewcvs?rev=262746&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

Backport r262442 and r262743.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/fortran/module.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417

--- Comment #16 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:59:44 2018
New Revision: 262746

URL: https://gcc.gnu.org/viewcvs?rev=262746&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

Backport r262442 and r262743.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/fortran/module.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:59:44 2018
New Revision: 262746

URL: https://gcc.gnu.org/viewcvs?rev=262746&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

Backport r262442 and r262743.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/fortran/module.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/82865] Option -fdec collides with PDT

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

Fritz Reese  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Fritz Reese  ---
Marking as resolved again since the 7-branch backport was reverted; the patch
is applied to trunk and 8-branch.

[Bug fortran/82173] [meta-bug] Parameterized derived type errors

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
Bug 82173 depends on bug 82865, which changed state.

Bug 82865 Summary: Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83183,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86417
 Resolution|--- |FIXED

--- Comment #2 from Fritz Reese  ---
Fixed in r262442.

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Fritz Reese  ---
Fixed in 262744.

[Bug fortran/83183] Out of memory with option -finit-derived

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83183

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86417
 Resolution|--- |FIXED

--- Comment #3 from Fritz Reese  ---
Fixed in r262442 (note: exposed PR 86417, which has since been fixed as well in
r262743)

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Fritz Reese  ---
(In reply to janus from comment #13)
> (In reply to Fritz Reese from comment #12)
> > If we set the component's locus when it is loaded from a module, the
> > following patch fixes the issue and retains sane location information for
> > the component and its initializer:
> > 
> > diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
> > index b120501beb7..27d68f6b1b5 100644
> > --- a/gcc/fortran/module.c
> > +++ b/gcc/fortran/module.c
> > @@ -2848,6 +2848,8 @@ mio_component (gfc_component *c, int vtype)
> >if (c->attr.proc_pointer)
> >  mio_typebound_proc (&c->tb);
> >  
> > +  c->loc = gfc_current_locus;
> > +
> >mio_rparen ();
> >  }
> >  
> > [..]
> > 
> > I am currently running regression tests to verify these patches. If both
> > pass and I have not missed something obvious I would prefer adding location
> > info to the component when loading from a module (the first patch).
> 
> I agree that this is probably the best way to fix it. If the patch regtests
> well, it's ok for trunk from my side. Thanks for having a look!

Thanks for the confirmation. I have committed to trunk (without a new testcase,
as alloc-comp-3.f90 exposes the regression).

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:24:50 2018
New Revision: 262744

URL: https://gcc.gnu.org/viewcvs?rev=262744&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

Fix handling of invalid assumed-shape/size arrays in legacy initializer
lists.

gcc/fortran/ChangeLog:

PR fortran/83184
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.

gcc/testsuite/ChangeLog:

PR fortran/83184
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
trunk/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_8.f90

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

2018-07-16 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417

--- Comment #14 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:16:00 2018
New Revision: 262743

URL: https://gcc.gnu.org/viewcvs?rev=262743&root=gcc&view=rev
Log:
2018-07-16  Fritz Reese  

gcc/fortran/ChangeLog:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

2018-07-10 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417

--- Comment #12 from Fritz Reese  ---
(In reply to Thomas Koenig from comment #11)
> (In reply to janus from comment #10)
...
> 
> If possible, I would prefer to set the locus where it is generated,
> not conditionally later.
> 
> Unfortunately, I cannot currently look into this due to PR 86450 :-(
> 
> If I had a bootstrapping gcc, I would probably look at
> 
>   /* Fetch or generate an initializer for the component.  */
>   tmp = component_initializer (comp, generate);
> 
> and see if the locus is set correctly at that point, then
> (possibly) go back to component_initializer to see where this is
> missing.

I agree. I traced the issue and it appears locus info is not set for
gfc_components which are created from a module definition, so c->loc is empty.
Given that, this line is erroneous:

> static gfc_expr *
> component_initializer (gfc_component *c, bool generate)
> [...]
>  init = gfc_get_null_expr (&c->loc);

Before r262442 the locus for the NULL expression was originally copied from the
derived type to which the component belonged. (This is less than ideal when the
message actually refers to the component, which is why this behavior was
"fixed" in r262442.)

If we set the component's locus when it is loaded from a module, the following
patch fixes the issue and retains sane location information for the component
and its initializer:

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index b120501beb7..27d68f6b1b5 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -2848,6 +2848,8 @@ mio_component (gfc_component *c, int vtype)
   if (c->attr.proc_pointer)
 mio_typebound_proc (&c->tb);

+  c->loc = gfc_current_locus;
+
   mio_rparen ();
 }

However if we prefer not to set the component's locus for whatever reason, the
following alternative patch also fixes the issue, where the component's
initializer has its locus set to that of the derived type declaration:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 6a7e09589a7..c63b41c36e4 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -,7 +,7 @@ comp_pointer (gfc_component *comp)
Only generate an initializer if generate is true.  */

 static gfc_expr *
-component_initializer (gfc_component *c, bool generate)
+component_initializer (gfc_typespec *derived, gfc_component *c, bool generate)
 {
   gfc_expr *init = NULL;

@@ -4453,7 +4453,10 @@ component_initializer (gfc_component *c, bool generate)
  do not already have an initializer.  */
   if (comp_allocatable (c) || (generate && comp_pointer (c) &&
!c->initializer))
 {
-  init = gfc_get_null_expr (&c->loc);
+  if (c->loc.nextc && c->loc.lb)
+   init = gfc_get_null_expr (&c->loc);
+  else
+   init = gfc_get_null_expr (&derived->declared_at);
   init->ts = c->ts;
   return init;
 }
@@ -4588,7 +4591,7 @@ gfc_generate_initializer (gfc_typespec *ts, bool
generate)
   gfc_constructor *ctor = gfc_constructor_get();

   /* Fetch or generate an initializer for the component.  */
-  tmp = component_initializer (comp, generate);
+  tmp = component_initializer (ts->u.derived, comp, generate);
   if (tmp)
{
  /* Save the component ref for STRUCTUREs and UNIONs.  */


I am currently running regression tests to verify these patches. If both pass
and I have not missed something obvious I would prefer adding location info to
the component when loading from a module (the first patch).

[Bug bootstrap/86450] Bootstrap failure due to -Wabi

2018-07-09 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-10
 CC||foreese at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Fritz Reese  ---
+1

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

2018-07-05 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325

--- Comment #1 from Fritz Reese  ---
Author: foreese
Date: Thu Jul  5 15:39:27 2018
New Revision: 262442

URL: https://gcc.gnu.org/viewcvs?rev=262442&root=gcc&view=rev
Log:
2018-07-05  Fritz Reese  

gcc/fortran/ChangeLog:

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83183] Out of memory with option -finit-derived

2018-07-05 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83183

--- Comment #2 from Fritz Reese  ---
Author: foreese
Date: Thu Jul  5 15:39:27 2018
New Revision: 262442

URL: https://gcc.gnu.org/viewcvs?rev=262442&root=gcc&view=rev
Log:
2018-07-05  Fritz Reese  

gcc/fortran/ChangeLog:

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82865] Option -fdec collides with PDT

2018-07-02 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #14 from Fritz Reese  ---
(In reply to Rainer Orth from comment #13)
> 
> It seems the backport caused a caused quite a number on testsuite failures
> on the gcc-7 branch:
> ...

I reverted the backport in r262260. Are you certain that you still see those
errors after the reversion? That testcase file should no longer exist in the
tree.

> 
> Besides, all those svn property changes are at least unrelated.
> 
>   Rainer

That is what I suspected. ‘svn merge’ added them for some reason (even from a
clean tree). I’ll make sure to keep those out of future merges.

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-29 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #12 from Fritz Reese  ---
Author: foreese
Date: Fri Jun 29 20:29:34 2018
New Revision: 262260

URL: https://gcc.gnu.org/viewcvs?rev=262260&root=gcc&view=rev
Log:
Revert r262224 (backport of r262221) as PDTs are not supported in 7-branch.

gcc/fortran/ChangeLog:
-2018-06-28  Fritz Reese  
-
-   PR fortran/82865
-   Backport from trunk.
-   * decl.c (gfc_match_type): Refactor and check for PDT declarations.
-

gcc/testsuite/ChangeLog:
-2018-06-28  Fritz Reese  
-
-   PR fortran/82865
-   Backport from trunk.
-   * gfortran.dg/dec_type_print_2.f03: New testcase.
-

Removed:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb   (props changed)

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' modified)

Propchange: branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb
('svn:mergeinfo' modified)

[Bug testsuite/86365] Backported fortran test case gfortran.dg/dec_type_print_2.f03 in r262224 problems

2018-06-29 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86365

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Fritz Reese  ---
Reverted in r262260

[Bug testsuite/86365] Backported fortran test case gfortran.dg/dec_type_print_2.f03 in r262224 problems

2018-06-29 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86365

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-29
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Fritz Reese  ---
Oops, I forgot PDTs are not implemented as of gfortran-7. I will revert this
patch on 7-branch.

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-28 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #11 from Fritz Reese  ---
Author: foreese
Date: Thu Jun 28 16:51:23 2018
New Revision: 262224

URL: https://gcc.gnu.org/viewcvs?rev=262224&root=gcc&view=rev
Log:
2018-06-28  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/82865
Backport from trunk.
* gfortran.dg/dec_type_print_2.f03: New testcase.

gcc/fortran/ChangeLog:

PR fortran/82865
Backport from trunk.
* decl.c (gfc_match_type): Refactor and check for PDT declarations.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
  - copied unchanged from r262221,
trunk/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb   (props changed)

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' modified)

Propchange: branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb
('svn:mergeinfo' modified)

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-28 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #10 from Fritz Reese  ---
Author: foreese
Date: Thu Jun 28 16:47:19 2018
New Revision: 262223

URL: https://gcc.gnu.org/viewcvs?rev=262223&root=gcc&view=rev
Log:
2018-06-28  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/82865
Backport from trunk.
* gfortran.dg/dec_type_print_2.f03: New testcase.

gcc/fortran/ChangeLog:

PR fortran/82865
Backport from trunk.
* decl.c (gfc_match_type): Refactor and check for PDT declarations.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/contrib/mklog.pl   (props changed)
branches/gcc-8-branch/gcc/ada/libgnarl/s-interr__hwint.adb   (props
changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

Propchange: branches/gcc-8-branch/contrib/mklog.pl
('svn:mergeinfo' modified)

Propchange: branches/gcc-8-branch/gcc/ada/libgnarl/s-interr__hwint.adb
('svn:mergeinfo' modified)

[Bug fortran/82173] [meta-bug] Parameterized derived type errors

2018-06-28 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
Bug 82173 depends on bug 82865, which changed state.

Bug 82865 Summary: Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-28 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Fritz Reese  ---
Fixed in r262221

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-28 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #8 from Fritz Reese  ---
Author: foreese
Date: Thu Jun 28 15:31:24 2018
New Revision: 262221

URL: https://gcc.gnu.org/viewcvs?rev=262221&root=gcc&view=rev
Log:
2018-06-28  Fritz Reese  

gcc/fortran/ChangeLog:

PR fortran/82865
* decl.c (gfc_match_type): Refactor and check for PDT declarations.

gcc/testsuite/ChangeLog:

PR fortran/82865
* gfortran.dg/dec_type_print_2.f03: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

--- Comment #7 from Fritz Reese  ---
(In reply to Fritz Reese from comment #6)
> ... Though I agree -fdec should rarely be mixed with new
> Fortran, it is actually simple to patch gfc_match_type() so that it does
> match PDTs as a TYPE/PRINT statement. ...

s/does/does NOT/

[Bug fortran/82865] Option -fdec collides with PDT

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

Fritz Reese  changed:

   What|Removed |Added

   Last reconfirmed|2017-11-06 00:00:00 |2018-6-27
   Assignee|pault at gcc dot gnu.org   |foreese at gcc dot 
gnu.org

--- Comment #6 from Fritz Reese  ---
Actually this is due to gfc_match_type() failing to account for PDT
declarations. The function was introduced in r241518 to allow using TYPE as an
alias for PRINT with -fdec but was not updated when PDT support was introduced
in r251925. Though I agree -fdec should rarely be mixed with new Fortran, it is
actually simple to patch gfc_match_type() so that it does match PDTs as a
TYPE/PRINT statement. I will submit a patch shortly.

[Bug fortran/69654] ICE in gfc_trans_structure_assign

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654

Fritz Reese  changed:

   What|Removed |Added

   Last reconfirmed|2016-02-04 00:00:00 |2018-6-27

--- Comment #5 from Fritz Reese  ---
Ah, indeed, the original case does still segfault (even since 7.2.1), only the
reduced case from Comment #2 was fixed in r254427. My mistake.

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

--- Comment #2 from Fritz Reese  ---
This is really two separate bugs; the first being that the locus of the
variable expression is unset from match_old_style_init(), which can be seen in
the simpler test case:

$ cat z1.f90 
integer n1(..) /1/
end

$ gfortran z1.f90 
z1.f90:1:13:

 integer n(..) /1/
 1
Error: Assumed-rank array at (1) must be a dummy argument
f951: internal compiler error: Segmentation fault
0xd9b2af crash_signal
/data/midas/foreese/src/gcc-trunk/gcc/toplev.c:325
0x8c868c traverse_data_list
/data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:15450
0x8c868c traverse_data_var
/data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:15530
0x8ba7c3 resolve_data
/data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:15587
0x8ba7c3 resolve_types
/data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:16405
0x8bf4ac gfc_resolve(gfc_namespace*)
/data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:16494
0x8ad424 resolve_all_program_units
/data/midas/foreese/src/gcc-trunk/gcc/fortran/parse.c:6042
0x8ad424 gfc_parse_file()
/data/midas/foreese/src/gcc-trunk/gcc/fortran/parse.c:6292
0x8f326f gfc_be_parse_file
/data/midas/foreese/src/gcc-trunk/gcc/fortran/f95-lang.c:204


The second bug is the out-of-memory issue from within match_clist_expr().

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/69654] ICE in gfc_trans_structure_assign

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||foreese at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
   Target Milestone|--- |7.2

--- Comment #3 from Fritz Reese  ---
This was apparently fixed by Paul in r254427 for 7.2.1 as a side-effect of
fixing PR 81447 and PR 82783.

[Bug fortran/83184] Out of memory or ICE with option -fdec

2018-06-27 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184

Fritz Reese  changed:

   What|Removed |Added

   Last reconfirmed|2017-11-27 00:00:00 |2018-6-27
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |8.2

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

2018-06-26 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-26
 CC||foreese at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |8.2
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.1.0

[Bug fortran/86325] New: Error on valid code with pointer class components using -finit-derived

2018-06-26 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325

Bug ID: 86325
   Summary: Error on valid code with pointer class components
using -finit-derived
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

gfortran reports an error for valid code which uses class pointer components
when compiling with -finit-derived:

$ cat init_flag_19.f03

implicit none

type :: ty1
  integer :: ival
  real:: rval
end type

type :: ty2
  type(ty1)   :: bt
  type(ty1), allocatable  :: bt_alloc
  type(ty1), pointer  :: bt_ptr
  class(ty1), allocatable :: class_alloc
  class(ty1), pointer :: class_ptr
end type

type(ty2) basic
class(ty1), allocatable :: calloc

print *, basic%bt%ival
print *, calloc%ival

end

$ gfortran -finit-derived init_flag_19.f03

init_flag_19.f03:9:11:

 type :: ty1
   1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
init_flag_19.f03:19:38:

   class(ty1), pointer :: class_ptr
  1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
init_flag_19.f03:9:11:

 type :: ty1
   1
Error: The element in the structure constructor at (1), for pointer component
‘bt_ptr’ should be a POINTER or a TARGET
init_flag_19.f03:9:11:

 type :: ty1
   1
Error: Pointer initialization target at (1) must have the SAVE attribute



The issue is present from the introduction of -finit-derived in 7.1 through 8.x
and trunk.

[Bug fortran/83183] Out of memory with option -finit-derived

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83183

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2017-11-27 00:00:00 |2018-6-25
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |8.2

[Bug fortran/83088] [8/9 Regression] ICE with -init-derived

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83088

--- Comment #6 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 19:23:49 2018
New Revision: 262107

URL: https://gcc.gnu.org/viewcvs?rev=262107&root=gcc&view=rev
Log:
2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_17.f90
  - copied unchanged from r262104,
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' added)

[Bug fortran/82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

--- Comment #10 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 19:23:49 2018
New Revision: 262107

URL: https://gcc.gnu.org/viewcvs?rev=262107&root=gcc&view=rev
Log:
2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_17.f90
  - copied unchanged from r262104,
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' added)

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851

--- Comment #6 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 19:23:49 2018
New Revision: 262107

URL: https://gcc.gnu.org/viewcvs?rev=262107&root=gcc&view=rev
Log:
2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_17.f90
  - copied unchanged from r262104,
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' added)

[Bug fortran/83088] [8/9 Regression] ICE with -init-derived

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83088

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 19:07:03 2018
New Revision: 262106

URL: https://gcc.gnu.org/viewcvs?rev=262106&root=gcc&view=rev
Log:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_17.f90
  - copied unchanged from r262104,
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 19:07:03 2018
New Revision: 262106

URL: https://gcc.gnu.org/viewcvs?rev=262106&root=gcc&view=rev
Log:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_17.f90
  - copied unchanged from r262104,
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

--- Comment #9 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 19:07:03 2018
New Revision: 262106

URL: https://gcc.gnu.org/viewcvs?rev=262106&root=gcc&view=rev
Log:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
Backport from trunk.
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_17.f90
  - copied unchanged from r262104,
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851
Bug 85851 depends on bug 82972, which changed state.

Bug 82972 Summary: [8/9 Regression] ICE with -finit-derived in 
gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Fritz Reese  ---
Fixed in r262104.

Planning to backport to gcc-7-branch and gcc-8-branch since this bug has been
present for a while.

[Bug fortran/83088] [8/9 Regression] ICE with -init-derived

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83088
Bug 83088 depends on bug 82972, which changed state.

Bug 82972 Summary: [8/9 Regression] ICE with -finit-derived in 
gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Fritz Reese  ---
Fixed in r262104.

*** This bug has been marked as a duplicate of bug 82972 ***

[Bug fortran/82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

Fritz Reese  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #7 from Fritz Reese  ---
*** Bug 85851 has been marked as a duplicate of this bug. ***

[Bug fortran/82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

Fritz Reese  changed:

   What|Removed |Added

 CC||valeryweber at hotmail dot com

--- Comment #6 from Fritz Reese  ---
*** Bug 83088 has been marked as a duplicate of this bug. ***

[Bug fortran/83088] [8/9 Regression] ICE with -init-derived

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83088

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Fritz Reese  ---
Fixed in r262104.

*** This bug has been marked as a duplicate of bug 82972 ***

[Bug fortran/83088] [8/9 Regression] ICE with -init-derived

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83088

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 18:33:11 2018
New Revision: 262104

URL: https://gcc.gnu.org/viewcvs?rev=262104&root=gcc&view=rev
Log:

Fix -finit-derived for c_ptr and c_funptr in programs which use
iso_c_binding.

gcc/fortran/ChangeLog:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

gcc/testsuite/ChangeLog:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 18:33:11 2018
New Revision: 262104

URL: https://gcc.gnu.org/viewcvs?rev=262104&root=gcc&view=rev
Log:

Fix -finit-derived for c_ptr and c_funptr in programs which use
iso_c_binding.

gcc/fortran/ChangeLog:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

gcc/testsuite/ChangeLog:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

2018-06-25 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jun 25 18:33:11 2018
New Revision: 262104

URL: https://gcc.gnu.org/viewcvs?rev=262104&root=gcc&view=rev
Log:

Fix -finit-derived for c_ptr and c_funptr in programs which use
iso_c_binding.

gcc/fortran/ChangeLog:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
* expr.c (component_initializer): Assign init expr to c->initializer.
(generate_isocbinding_initializer): New.
(gfc_generate_initializer): Call generate_isocbinding_initializer to
generate initializers for c_ptr and c_funptr with -finit-derived.

gcc/testsuite/ChangeLog:

2018-06-25  Fritz Reese  

PR fortran/82972
PR fortran/83088
PR fortran/85851
* gfortran.dg/init_flag_17.f90: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

2018-05-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85851

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2018-05-20 00:00:00 |2018-5-21
 Depends on||82972
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #2 from Fritz Reese  ---
Probable duplicate of pr82972 and pr83088. Sorry I have not tracked this issue
down yet. My solution for -finit-derived requires special consideration for the
iso-c-binding structures such as c_ptr since the structure intialization
expression currently generated is invalid for those structures. Something in
the middle-end changed with 8.x that has further invalidated my solution for
-finit-derived. I am [still] working on this and a few other issues with
-finit-derived.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972
[Bug 82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at
fortran/trans-expr.c:7733 (and others)

[Bug fortran/83088] [8 Regression] ICE with -init-derived

2017-11-21 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83088

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82972
 Depends on||82972
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972
[Bug 82972] [8 Regression] ICE with -finit-derived in gfc_conv_structure, at
fortran/trans-expr.c:7733 (and others)

  1   2   >