public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426
@ 2021-03-02 19:01 gscfq@t-online.de
  2021-03-03  1:35 ` [Bug fortran/99349] " kargl at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: gscfq@t-online.de @ 2021-03-02 19:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

            Bug ID: 99349
           Summary: ICE in match_data_constant, at fortran/decl.c:426
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started with r9, between 20181028 and 20181104 :


$ cat z1.f90
function f()
   logical, parameter :: a((1.)/0) = .true.
   integer :: b
   data b /a%kind/
end


$ gfortran-11-20210228 -c z1.f90
f951: internal compiler error: Segmentation fault
0xc0666f crash_signal
        ../../gcc/toplev.c:327
0x66dab4 match_data_constant
        ../../gcc/fortran/decl.c:426
0x66dc63 top_val_list
        ../../gcc/fortran/decl.c:499
0x66df72 gfc_match_data()
        ../../gcc/fortran/decl.c:716
0x6d87e1 match_word
        ../../gcc/fortran/parse.c:65
0x6dca2e decode_statement
        ../../gcc/fortran/parse.c:469
0x6dd79c next_free
        ../../gcc/fortran/parse.c:1316
0x6dd79c next_statement
        ../../gcc/fortran/parse.c:1548
0x6dee0b parse_spec
        ../../gcc/fortran/parse.c:3967
0x6e1bdc parse_progunit
        ../../gcc/fortran/parse.c:5896
0x6e35e7 gfc_parse_file()
        ../../gcc/fortran/parse.c:6451
0x72fd7f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:212

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
@ 2021-03-03  1:35 ` kargl at gcc dot gnu.org
  2021-03-03  7:55 ` marxin at gcc dot gnu.org
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-03-03  1:35 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-03-03
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Tested against original code.  Not regression tested.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 723915822f3..deac4df1627 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -410,9 +410,7 @@ match_data_constant (gfc_expr **result)
       /* If a parameter inquiry ends up here, symtree is NULL but **result
         contains the right constant expression.  Check here.  */
       if ((*result)->symtree == NULL
-         && (*result)->expr_type == EXPR_CONSTANT
-         && ((*result)->ts.type == BT_INTEGER
-             || (*result)->ts.type == BT_REAL))
+         && (*result)->expr_type == EXPR_CONSTANT)
        return m;

       /* F2018:R845 data-stmt-constant is initial-data-target.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
  2021-03-03  1:35 ` [Bug fortran/99349] " kargl at gcc dot gnu.org
@ 2021-03-03  7:55 ` marxin at gcc dot gnu.org
  2022-09-01 19:57 ` anlauf at gcc dot gnu.org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-03  7:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r9-3803-ga5fbc2f36a291cbe.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
  2021-03-03  1:35 ` [Bug fortran/99349] " kargl at gcc dot gnu.org
  2021-03-03  7:55 ` marxin at gcc dot gnu.org
@ 2022-09-01 19:57 ` anlauf at gcc dot gnu.org
  2022-09-01 22:03 ` sgk at troutmask dot apl.washington.edu
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-09-01 19:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)
> The function is match_data_constant(), so we're looking for a
> constant.  My patch simply removes the type checking as it is
> unimportant here, and a type mismatch between a data-object and
> data-value is checked elsewhere.  I suspect my original code was
> being too cautious with type checks.

There's nothing wrong with being cautious.  Currently, the only valid
parameter inquiries are %kind, %len, %re, %im.  So checking for integer
or real makes sense.

Maybe, at some point in the future, gfc_match_rvalue() may be more strict
or differ in some way and handle the invalid decl in a different way.

That's why I think that keeping the type check may have some merit, even
if it is not clear which one.

> If your patch leads to a better error message(s), then by all 
> means use your patch.

It's just a different error message (a syntax error instead of another one
that does not give better insight...).

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
                   ` (2 preceding siblings ...)
  2022-09-01 19:57 ` anlauf at gcc dot gnu.org
@ 2022-09-01 22:03 ` sgk at troutmask dot apl.washington.edu
  2022-09-01 22:44 ` sgk at troutmask dot apl.washington.edu
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2022-09-01 22:03 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Sep 01, 2022 at 07:57:56PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #4)
> > The function is match_data_constant(), so we're looking for a
> > constant.  My patch simply removes the type checking as it is
> > unimportant here, and a type mismatch between a data-object and
> > data-value is checked elsewhere.  I suspect my original code was
> > being too cautious with type checks.
> 
> There's nothing wrong with being cautious.  Currently, the only valid
> parameter inquiries are %kind, %len, %re, %im.  So checking for integer
> or real makes sense.
> 

Ah, that rings a bell.  'git blame' shows that I added the
integer check and pault added the real check.  I suspect
only %kind and %len were available when I added the original
code, and pault added the real check when he implemented
%im and %re.

Keeping the checks is ok with me and your patch does the
job.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
                   ` (3 preceding siblings ...)
  2022-09-01 22:03 ` sgk at troutmask dot apl.washington.edu
@ 2022-09-01 22:44 ` sgk at troutmask dot apl.washington.edu
  2022-09-02 19:12 ` cvs-commit at gcc dot gnu.org
  2022-09-02 19:21 ` anlauf at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2022-09-01 22:44 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Sep 01, 2022 at 06:45:25PM +0000, anlauf at gcc dot gnu.org wrote:
>
> Alternatively, simply catching the NULL pointer dereference by
> 
> diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
> index b6400514731..0f9b2ced4c2 100644
> --- a/gcc/fortran/decl.cc
> +++ b/gcc/fortran/decl.cc
> @@ -423,7 +423,8 @@ match_data_constant (gfc_expr **result)
>          data-pointer-initialization compatible (7.5.4.6) with the initial
>          data target; the data statement object is initially associated
>          with the target.  */
> -      if ((*result)->symtree->n.sym->attr.save
> +      if ((*result)->symtree
> +         && (*result)->symtree->n.sym->attr.save
>           && (*result)->symtree->n.sym->attr.target)
>         return m;
>        gfc_free_expr (*result);
> 
> also fixes the ICE.  It's basically that the error message generated differs
> from the one I get with your patch.
> 
> Do you have additional thoughts?
> 

Now, that I've looked at the two patches again. I think I prefer
yours or mine.  A simple NULL pointer dereference can be committed
under the "Obviously correct" rule.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
                   ` (4 preceding siblings ...)
  2022-09-01 22:44 ` sgk at troutmask dot apl.washington.edu
@ 2022-09-02 19:12 ` cvs-commit at gcc dot gnu.org
  2022-09-02 19:21 ` anlauf at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-09-02 19:12 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:b6aa7d45b502c01f8703c8d2cee2690f9aa8e282

commit r13-2382-gb6aa7d45b502c01f8703c8d2cee2690f9aa8e282
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri Sep 2 21:07:26 2022 +0200

    Fortran: avoid NULL pointer dereference on invalid DATA constant [PR99349]

    gcc/fortran/ChangeLog:

            PR fortran/99349
            * decl.cc (match_data_constant): Avoid NULL pointer dereference.

    gcc/testsuite/ChangeLog:

            PR fortran/99349
            * gfortran.dg/pr99349.f90: New test.

    Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
  2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
                   ` (5 preceding siblings ...)
  2022-09-02 19:12 ` cvs-commit at gcc dot gnu.org
@ 2022-09-02 19:21 ` anlauf at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-09-02 19:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from anlauf at gcc dot gnu.org ---
Finally fixed on mainline for gcc-13.  Closing.

Thanks for the report!

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-09-02 19:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-02 19:01 [Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426 gscfq@t-online.de
2021-03-03  1:35 ` [Bug fortran/99349] " kargl at gcc dot gnu.org
2021-03-03  7:55 ` marxin at gcc dot gnu.org
2022-09-01 19:57 ` anlauf at gcc dot gnu.org
2022-09-01 22:03 ` sgk at troutmask dot apl.washington.edu
2022-09-01 22:44 ` sgk at troutmask dot apl.washington.edu
2022-09-02 19:12 ` cvs-commit at gcc dot gnu.org
2022-09-02 19:21 ` anlauf at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).