[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 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 --- Comment #3 from Fritz Reese --- Under other DEC compilers, it seems STRUCTUREs are to be treated consistently with derived types in regards to I/O lists. That is to say, a structure variable is treated as if each of its named components was listed on the I/O list. (Even with UNIONs/MAPs, each named component is to be treated as having been listed in place of the DEC RECORD containing it, so that the last component written to within overlapping MAPs takes effect. Yikes.) I believe both the code in the attachment and the "intended code" (writing to bucket.c16 instead of bucket) should be accepted, whereas they both ICE currently. I will look into it.
[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 --- Comment #7 from Fritz Reese --- Author: foreese Date: Mon Oct 16 17:40:53 2017 New Revision: 253791 URL: https://gcc.gnu.org/viewcvs?rev=253791&root=gcc&view=rev Log: 2017-10-16 Fritz Reese PR fortran/82511 Treat UNION components as DT comp. in I/O lists. gcc/fortran/ChangeLog: PR fortran/82511 * trans-io.c (transfer_expr): Treat BT_UNION as BT_DERIVED. gcc/testsuite/ChangeLog: PR fortran/82511 * gfortran.dg/dec_structure_22.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Fritz Reese --- (In reply to Steve Kargl from comment #4) ... > > program bug > structure /bckt/ > union > map >character*16 c16 > end map > end union > end structure > record /bckt/ bucket > character(len=16) :: rec1 = 'ABCDEFGHIJKLMNOP' > 100 format(A16) > read(rec1, 100) bckt > end program bug > > where one is trying read into the definition of the structure. > Is the above suppose to compile? Because it does. [...] Steve- on second glance, the above program is correct, even though it is misleading. It compiles because there is no IMPLICIT NONE, so the variable BCKT is an implicit variable created at the point of use. The program above behaves equivalently if STRUCTURE /bckt/ is never declared, and issues an appropriate error with IMPLICIT NONE: program bug implicit none structure /bckt/ [...] read(rec1, 100) bckt end program bug $ gfortran -fdec-structure bug.for bug.for:12:26: read(rec1, 100) bckt 1 Error: Symbol ‘bckt’ at (1) has no IMPLICIT type
[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25297 Fritz Reese changed: What|Removed |Added CC||foreese at gcc dot gnu.org Resolution|WONTFIX |FIXED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #5 from Fritz Reese --- For the record: support for DEC STRUCTURE/RECORD was introduced in r235999 in gcc-7 and was also backported to gcc-6. Marking this as FIXED.
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 Fritz Reese changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #3 from Fritz Reese --- On it.
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #4 from Fritz Reese --- > https://gcc.gnu.org/ml/fortran/2017-11/msg00059.html Fix pending review.
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 --- Comment #5 from Fritz Reese --- Author: foreese Date: Sat Nov 11 00:47:53 2017 New Revision: 254648 URL: https://gcc.gnu.org/viewcvs?rev=254648&root=gcc&view=rev Log: 2017-11-10 Fritz Reese PR fortran/82886 gcc/fortran/ChangeLog: PR fortran/82886 * gfortran.h (gfc_build_init_expr): New prototype. * invoke.texi (finit-derived): Update documentation. * expr.c (gfc_build_init_expr): New, from gfc_build_default_init_expr. (gfc_build_default_init_expr): Redirect to gfc_build_init_expr(,,false) (component_initializer): Force building initializers using gfc_build_init_expr(,,true). gcc/testsuite/ChangeLog: PR fortran/82886 * gfortran.dg/init_flag_16.f03: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/init_flag_16.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 Fritz Reese changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/82972] [8 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|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #3 from Fritz Reese --- Yikes! I'll take a look, thanks for the report.
[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78240 Fritz Reese changed: What|Removed |Added Status|NEW |WAITING CC||foreese at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #4 from Fritz Reese --- > https://gcc.gnu.org/ml/fortran/2017-11/msg00076.html Patch pending.
[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78240 Fritz Reese changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78240 --- Comment #5 from Fritz Reese --- Author: foreese Date: Tue Nov 14 01:25:26 2017 New Revision: 254718 URL: https://gcc.gnu.org/viewcvs?rev=254718&root=gcc&view=rev Log: 2017-11-13 Fritz Reese PR fortran/78240 gcc/fortran/ChangeLog: PR fortran/78240 * decl.c (match_clist_expr): Replace gcc_assert with proper handling of bad result from spec_size(). * resolve.c (check_data_variable): Avoid NULL dereference when passing locus to gfc_error. gcc/testsuite/ChangeLog: PR fortran/78240 * gfortran.dg/dec_structure_23.f90: New. * gfortran.dg/pr78240.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90 trunk/gcc/testsuite/gfortran.dg/pr78240.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/82978] New: [PDT] [F2003] Paramaterized Derived Type LEN parameters take the latest value per-kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82978 Bug ID: 82978 Summary: [PDT] [F2003] Paramaterized Derived Type LEN parameters take the latest value per-kind Product: gcc Version: 8.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 42596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42596&action=edit test case exhibiting strange PDT behavior In the attached file I see what I believe is unusual behavior. I skimmed the F03/F08 specs and by all accounts I could see, this behavior is unexpected. To summarize/generalize the test file, with the following declarations: > type :: pdt_t(k, l) > integer, kind :: k > integer, len :: l > character(len=l) :: ch > end type > > type(pdt_t(k, l1)) :: t1 > type(pdt_t(k, l2)) :: t2 > ... > type(pdt_t(k, ln)) :: tn Then I see that len(t1%ch) == len(t2%ch) == ... == len(tn%ch) == ln. That is to say, every PDT variable gets ch with the last length defined for the same kind. If different kinds are passed, then the lengths seem to differ fine. Here is my output for the attached file: $ gfortran --version GNU Fortran (GCC) 8.0.0 20171107 (experimental) [...] $ gfortran pdtlens.f03 $ ./a.out exp. len act. len 1 2 2 2 4 5 5 5 9 7 7 7 100 200 200 200 Am I just misinterpreting the Fortran spec, or is this a real bug?
[Bug fortran/82979] New: [PDT] [F2003] [ice-on-invalid] ICE (segfault) on invalid type-param-name-list in PDT declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82979 Bug ID: 82979 Summary: [PDT] [F2003] [ice-on-invalid] ICE (segfault) on invalid type-param-name-list in PDT declaration Product: gcc Version: 8.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 42597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42597&action=edit test case which causes the ICE Currently the compiler ICEs due to a segmentation fault when given an invalid type-param-name-list, such as in the attached file (and shown here): $ gfortran --version | head -n1 GNU Fortran (GCC) 8.0.0 20171114 (experimental) $ cat ./test.f03 type :: pdt_t(k=4) integer, kind :: k end type end $ gfortran ./test.f03 ./test.f03:1:15: type :: pdt_t(k=4) 1 Error: Expected parameter list in type declaration at (1) f951: internal compiler error: Segmentation fault 0xca9a9f crash_signal /data/midas/foreese/src/gcc-dev/gcc/toplev.c:325 0x6d260a delete_root /data/midas/foreese/src/gcc-dev/gcc/fortran/bbt.c:150 0x6d27be gfc_delete_bbt(void*, void*, int (*)(void*, void*)) /data/midas/foreese/src/gcc-dev/gcc/fortran/bbt.c:197 0x789128 gfc_delete_symtree(gfc_symtree**, char const*) /data/midas/foreese/src/gcc-dev/gcc/fortran/symbol.c:2925 0x78a8bf gfc_restore_last_undo_checkpoint() /data/midas/foreese/src/gcc-dev/gcc/fortran/symbol.c:3694 0x74af47 reject_statement /data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:2546 0x74afa4 match_word /data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:70 0x74e30f decode_statement /data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:565 0x74f32c next_free /data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:1225 0x74f32c next_statement /data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:1457 0x7545f1 gfc_parse_file() /data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:6160 0x7987bf gfc_be_parse_file /data/midas/foreese/src/gcc-dev/gcc/fortran/f95-lang.c:204 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.
[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78240 Fritz Reese changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #7 from Fritz Reese --- *** Bug 83006 has been marked as a duplicate of this bug. ***
[Bug fortran/83006] [8 regression] gfortran.dg/pr78240.f90 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83006 Fritz Reese changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Fritz Reese --- > Author: kargl > Date: Wed Nov 15 18:14:14 2017 > New Revision: 254780 > > URL: https://gcc.gnu.org/viewcvs?rev=254780&root=gcc&view=rev > Log: > 2017-11-15 Steven G. Kargl > > PR fortran/78240 > gfortran.dg/pr78240.f90: Prune run-on errors. > > Modified: > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gfortran.dg/pr78240.f90 Consequence of faulty test case from fortran/78240 in r254718, fixed in r254780 *** This bug has been marked as a duplicate of bug 78240 ***
[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)
[Bug fortran/80668] wrong error message with -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80668 Fritz Reese changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org
[Bug fortran/80668] wrong error message with -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80668 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Fritz Reese --- Patch submitted, pending trunk: https://gcc.gnu.org/ml/fortran/2017-05/msg00030.html
[Bug fortran/80668] wrong error message with -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80668 --- Comment #3 from Fritz Reese --- Author: foreese Date: Wed May 17 15:13:58 2017 New Revision: 248158 URL: https://gcc.gnu.org/viewcvs?rev=248158&root=gcc&view=rev Log: 2017-05-17 Fritz Reese PR fortran/80668 gcc/fortran/ChangeLog: PR fortran/80668 * expr.c (component_initializer): Don't generate initializers for pointer components. * invoke.texi (-finit-derived): Document. gcc/testsuite/ChangeLog: PR fortran/80668 * gfortran.dg/pr80668.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pr80668.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug fortran/80668] wrong error message with -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80668 Fritz Reese changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/79968] diagnostics: merge similar diagnostics containing -fdec-structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79968 Fritz Reese changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Fritz Reese --- Sorry for the delay, I never noticed the email when it came around. I think this is obvious/trivial. I plan to commit the patch attached in the following message soon: https://gcc.gnu.org/ml/fortran/2017-05/msg00092.html
[Bug fortran/79968] diagnostics: merge similar diagnostics containing -fdec-structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79968 --- Comment #3 from Fritz Reese --- Author: foreese Date: Thu May 18 10:24:37 2017 New Revision: 248188 URL: https://gcc.gnu.org/viewcvs?rev=248188&root=gcc&view=rev Log: 2017-05-18 Fritz Reese PR fortran/79968 gcc/fortran/ChangeLog: PR fortran/79968 * decl.c (match_attr_spec, gfc_match_automatic, gfc_match_static, gfc_match_structure_decl): Unify diagnostic errors regarding -fdec options. * io.c (match_dec_etag, match_dec_vtag, match_dec_ftag): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/io.c
[Bug fortran/79968] diagnostics: merge similar diagnostics containing -fdec-structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79968 Fritz Reese changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327 --- Comment #9 from foreese at gcc dot gnu.org --- Author: foreese Date: Mon Aug 29 12:24:25 2016 New Revision: 239819 URL: https://gcc.gnu.org/viewcvs?rev=239819&root=gcc&view=rev Log: 2016-08-29 Fritz Reese Fix, reorganize, and clarify comparisons of anonymous types/components. PR fortran/77327 * interface.c (is_anonymous_component, is_anonymous_dt): New functions. * interface.c (compare_components, gfc_compare_derived_types): Use new functions. * gfortran.dg/dec_structure_13.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584 --- Comment #2 from foreese at gcc dot gnu.org --- Author: foreese Date: Mon Sep 19 11:32:09 2016 New Revision: 240230 URL: https://gcc.gnu.org/viewcvs?rev=240230&root=gcc&view=rev Log: 2016-09-19 Fritz Reese PR fortran/77584 * gcc/fortran/decl.c (match_record_decl, gfc_match_decl_type_spec): Fixes to handling of structure/record from declaration-type-spec. * gcc/testsuite/gfortran.dg/dec_structure_15.f90: New testcase. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584 --- Comment #8 from foreese at gcc dot gnu.org --- (In reply to Marek Polacek from comment #7) > You need to use your @gnu.gcc.org account to be able to modify BZs. Oh, thanks. Seems obvious now that I think about it. I didn't realize such an account was created for me.
[Bug fortran/77782] ICE in gfc_get_union_type, at fortran/trans-types.c:2387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77782 --- Comment #3 from foreese at gcc dot gnu.org --- Author: foreese Date: Fri Sep 30 11:37:23 2016 New Revision: 240651 URL: https://gcc.gnu.org/viewcvs?rev=240651&root=gcc&view=rev Log: 2016-09-30 Fritz Reese Fix ICE caused by union types comparing equal to structures. PR fortran/77782 * gcc/fortran/interface.c (gfc_compare_derived_types): Use gfc_compare_union_types to compare union types. PR fortran/77782 * gcc/testsuite/gfortran.dg/dec_structure_16.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77782] ICE in gfc_get_union_type, at fortran/trans-types.c:2387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77782 foreese at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||foreese at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #4 from foreese at gcc dot gnu.org --- Fixed in r240651.
[Bug fortran/77764] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77764 --- Comment #3 from foreese at gcc dot gnu.org --- Author: foreese Date: Fri Sep 30 11:42:31 2016 New Revision: 240652 URL: https://gcc.gnu.org/viewcvs?rev=240652&root=gcc&view=rev Log: 2016-09-30 Fritz Reese Fix ICE for maps with zero components. PR fortran/77764 * gcc/fortran/interface.c (gfc_compare_union_types): Null-guard map components. PR fortran/77764 * gcc/testsuite/gfortran.dg/dec_union_8.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/dec_union_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77764] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77764 foreese at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #4 from foreese at gcc dot gnu.org --- Fixed in r240652.
[Bug fortran/77783] ICE in gfc_compare_union_types, at fortran/interface.c:545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77783 foreese at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||foreese at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #3 from foreese at gcc dot gnu.org --- > https://gcc.gnu.org/ml/fortran/2016-10/msg8.html This is fixed as of r240810. 2016-10-05 Fritz Reese Fix ICE due to comparison between UNION components. gcc/fortran/ * interface.c (gfc_compare_types): Don't compare BT_UNION components until we know they're both UNIONs. * interface.c (gfc_compare_union_types): Guard against empty components. gcc/testsuite/gfortran.dg/ * dec_union_9.f90: New testcase. * dec_union_10.f90: New testcase.
[Bug fortran/78259] [7 Regression] ICE in gfc_trans_subcomponent_assign, at fortran/trans-expr.c:7330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78259 --- Comment #3 from foreese at gcc dot gnu.org --- Author: foreese Date: Wed Nov 9 17:31:27 2016 New Revision: 242010 URL: https://gcc.gnu.org/viewcvs?rev=242010&root=gcc&view=rev Log: Fix ICE in gfc_trans_subcomponent_assign due to NULL components. PR fortran/78259 * gcc/fortran/trans-expr.c (gfc_trans_subcomponent_assign): Guard against NULL values. PR fortran/78259 * gcc/testsuite/gfortran.dg/pr78259.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr78259.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78259] [7 Regression] ICE in gfc_trans_subcomponent_assign, at fortran/trans-expr.c:7330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78259 foreese at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from foreese at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) > Indeed, started with r241626. See https://gcc.gnu.org/ml/fortran/2016-11/msg00076.html Fixed in r242010.
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277
foreese at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2016-11-09 00:00:00 |2016-11-10
Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot
gnu.org
Target Milestone|--- |7.0
--- Comment #2 from foreese at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> Invalid code together with option -fdec, affects versions 6 and 7 :
>
...
> $ gfortran-7-20161106 -fdec -c z1.f90
> z1.f90:11:19:
>
> structure t.
>1
> Error: Syntax error in data declaration at (1)
> z1.f90:14:9:
>
>end structure
> 1
> Error: Expecting END SUBROUTINE statement at (1)
> f951: internal compiler error: Segmentation fault
> 0xc3a64f crash_signal
> ../../gcc/toplev.c:338
> 0x6952d0 is_anonymous_component
...
I'll have a patch soon.
For the curious reader:
The underlying cause is the fact that an anonymous structure declaration is
created at the line of error "structure t.", but the data declaration error
aborts the matcher and undoes the parse stack for the following structure
declaration which should become part of the anonymous definition. This doesn't
allow the matcher to finish the anonymous declaration.
Due to the abort, the following components are added to the enclosing
"structure /s/", and the anonymous inner structure is never completed. The ICE
is specifically because the "zero_comp" attribute is never set, even though the
abort of the matcher causes no components to be assigned to the inner
structure.
The correct solution is not just to add null-guards to compare_components;
rather to fix the error handling around the bad anonymous inner structure
declaration. The anonymous inner structure should continue being parsed as
normal, while an error is still emitted about the bad variable-decl ("t.").
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 --- Comment #3 from Fritz Reese --- Created attachment 40016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40016&action=edit patch for pr78277 > https://gcc.gnu.org/ml/fortran/2016-11/msg00087.html Patch proposed, will commit soon unless someone finds issue with it.
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 --- Comment #4 from Fritz Reese --- Author: foreese Date: Thu Nov 10 21:57:13 2016 New Revision: 242058 URL: https://gcc.gnu.org/viewcvs?rev=242058&root=gcc&view=rev Log: Fix ICE and improve errors for invalid anonymous structure declarations. PR fortran/78277 * gcc/fortran/decl.c (gfc_match_data_decl): Gracefully handle bad anonymous structure declarations. PR fortran/78277 * gcc/testsuite/gfortran.dg/dec_structure_17.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 Fritz Reese changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[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] 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 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 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/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 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 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 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 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 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/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/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/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/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 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/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 --- 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 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/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
--- 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 #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 #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 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/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 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/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/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/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/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 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 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
--- 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
--- 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/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/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 #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/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/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/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/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/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 Status|NEW |ASSIGNED
[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/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/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/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 --- 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 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Fritz Reese --- Fixed in r262221
[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
--- 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/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 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 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 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 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/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
