[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero
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
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
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
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)"
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)"
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'
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)
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)
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)
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)
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)
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)
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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)
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
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)
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
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
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
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)
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
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
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
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)
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
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
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
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
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
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
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)
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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)
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
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)
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
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
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)
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)
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
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
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
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)
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
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
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)