[Bug fortran/36192] ICE with wrong index types and bad parens

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |kargl at gcc dot gnu.org

--- Comment #12 from kargl at gcc dot gnu.org ---
I have a patch that cures at segfault on the reduced testcase.

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 26 17:39:07 2015
New Revision: 229387

URL: https://gcc.gnu.org/viewcvs?rev=229387&root=gcc&view=rev
Log:
2015-10-26  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/36192
        * array.c (gfc_ref_dimen_size): Check for BT_INTEGER before calling
        mpz_set.


2015-10-26  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/36192
        * gfortran.dg/pr36192.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr36192.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu.org]

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

--- Comment #14 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 30 16:46:20 2015
New Revision: 229590

URL: https://gcc.gnu.org/viewcvs?rev=229590&root=gcc&view=rev
Log:
2015-10-30  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/36192
        * interface.c (get_expr_storage_size):  Check for INTEGER type before
        calling gmp routines.

2015-10-30  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/36192
        * gfortran.dg/pr36192_1.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr36192_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/interface.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.3

--- Comment #16 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu dot org]

------- Comment #11 from kargl at gcc dot gnu dot org  2009-12-30 00:44 -------
The following patch "cures" the segfault but it sure feels like an ugly hack.
Note cut-n-paste tab corruption is likely.


troutmask:sgk[212] svn diff interface.c
Index: interface.c
===================================================================
--- interface.c (revision 155486)
+++ interface.c (working copy)
@@ -1700,7 +1700,9 @@ get_expr_storage_size (gfc_expr *e)
          {
            if (ref->u.ar.as->lower[i] && ref->u.ar.as->upper[i]
                && ref->u.ar.as->lower[i]->expr_type == EXPR_CONSTANT
-               && ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT)
+               && ref->u.ar.as->lower[i]->ts.type == BT_INTEGER
+               && ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT
+               && ref->u.ar.as->upper[i]->ts.type == BT_INTEGER)
              elements *= mpz_get_si (ref->u.ar.as->upper[i]->value.integer)
                          - mpz_get_si (ref->u.ar.as->lower[i]->value.integer)
                          + 1L;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu dot org]

------- Comment #10 from kargl at gcc dot gnu dot org  2009-12-30 00:33 -------
(In reply to comment #9)
> Some addition information from valgrind.
> 
> Error: Different shape for array assignment at (1) on dimension 1 (0 and 2)
> ==13911== Invalid read of size 8
> ==13911==    at 0x1C108F8: __gmpz_get_si (in /usr/local/lib/libgmp.so.8)
> ==13911==    by 0x4B426F: compare_actual_formal (interface.c:1704)

The order code is invalid code to say the least.  However, in interface.c
we end up at

        for (i = 0; i < ref->u.ar.as->rank; i++)
          {
            if (ref->u.ar.as->lower[i] && ref->u.ar.as->upper[i]
                && ref->u.ar.as->lower[i]->expr_type == EXPR_CONSTANT
                && ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT)
              elements *= mpz_get_si (ref->u.ar.as->upper[i]->value.integer)
                          - mpz_get_si (ref->u.ar.as->lower[i]->value.integer)
                          + 1L;
            else

The segfault occurs because ref->u.ar.as->upper[i]->expr->ts.type is BT_REAL.
Somewhere up the call chain, gfortran is not checking that array
bounds are integers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2009-12-29 18:58 -------
Some addition information from valgrind.

Error: Different shape for array assignment at (1) on dimension 1 (0 and 2)
==13911== Invalid read of size 8
==13911==    at 0x1C108F8: __gmpz_get_si (in /usr/local/lib/libgmp.so.8)
==13911==    by 0x4B426F: compare_actual_formal (interface.c:1704)
==13911==    by 0x4B52D7: gfc_procedure_use (interface.c:2407)
==13911==    by 0x4F89AF: resolve_call (resolve.c:3045)
==13911==    by 0x4FBFD2: resolve_code (resolve.c:8067)
==13911==    by 0x4FD7CB: gfc_resolve_blocks (resolve.c:7722)
==13911==    by 0x4FBE59: resolve_code (resolve.c:7943)
==13911==    by 0x4FD93F: resolve_codes (resolve.c:12293)
==13911==    by 0x4F1954: gfc_resolve (resolve.c:12320)
==13911==    by 0x4E7C27: gfc_parse_file (parse.c:4198)
==13911==    by 0x51B8C7: gfc_be_parse_file (f95-lang.c:239)
==13911==    by 0x7FB635: toplev_main (toplev.c:1049)
==13911==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==13911== 

homework-2.f90: At top level:
homework-2.f90:8:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
==13911== 
==13911== HEAP SUMMARY:
==13911==     in use at exit: 712,926 bytes in 2,347 blocks
==13911==   total heap usage: 4,585 allocs, 2,238 frees, 1,218,623 bytes
allocated
==13911== 
==13911== LEAK SUMMARY:
==13911==    definitely lost: 520 bytes in 14 blocks
==13911==    indirectly lost: 0 bytes in 0 blocks
==13911==      possibly lost: 18,256 bytes in 67 blocks
==13911==    still reachable: 694,150 bytes in 2,266 blocks
==13911==         suppressed: 0 bytes in 0 blocks
==13911== Rerun with --leak-check=full to see details of leaked memory


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu dot org]

------- Comment #8 from kargl at gcc dot gnu dot org  2009-12-29 18:37 -------
(In reply to comment #7)
> this appears to be fixed, at least in 4.3.5 and 4.4.2
> 

The problem still exist on at least x86_64-*-freebsd.

troutmask:sgk[216] gfc4x -c  homework-2.f90
...
Error: Different shape for array assignment at (1) on dimension 1 (0 and 2)
homework-2.f90:8:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

troutmask:sgk[217] gfc4x -v
Using built-in specs.
COLLECT_GCC=/home/sgk/work/4x/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/home/sgk/work/4x/bin/../libexec/gcc/x86_64-unknown-freebsd9.0/4.5.0/lto-wrapper
Target: x86_64-unknown-freebsd9.0
Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x
--enable-languages=c,fortran
Thread model: posix
gcc version 4.5.0 20091222 (experimental) (GCC) 

Note, you need to rename homework-2.f to  homework-2.f90, or
explicitly tell gfortran that  homework-2.f is free-form code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[debian-gcc at lists dot debian dot org]

------- Comment #7 from debian-gcc at lists dot debian dot org  2009-12-29 16:38 -------
this appears to be fixed, at least in 4.3.5 and 4.4.2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2008-10-01 12:09 -------
Reduced code:

program three_body
  real, parameter :: n = 2, d = 2
  real, dimension(n,d) :: x

  x(1,:) = (/ 1.0, 0.0 /)

end program three_body

gives

pr36192_ice.f90:3.18:

  real, dimension(n,d) :: x
                 1
Error: Expression at (1) must be of INTEGER type
pr36192_ice.f90:3.20:

  real, dimension(n,d) :: x
                   1
Error: Expression at (1) must be of INTEGER type
pr36192_ice.f90:3.27:

  real, dimension(n,d) :: x
                          1
Error: The module or main program array 'x' at (1) must have constant shape
f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

The ICE disappears if the line

  x(1,:) = (/ 1.0, 0.0 /)

is commented.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[dominiq at lps dot ens dot fr]

------- Comment #5 from dominiq at lps dot ens dot fr  2008-05-11 16:40 -------
For the record: after fixing the syntax errors, the executable gives an
infinite loop when compiled with gfortran 4.3.0 on *i-apple-darwin9 and 4.4.0
(patched) on i686-apple-darwin9, but not on 4.4.0 (also patched) on
powerpc-apple-darwin9.  The infinite loop comes from a nasty (even for trained
eyes) typo which leaves the intent(out) dummies xn and vn unset on return of
subroutine step (since the code seems to be some homework, I leave the reporter
complete the debugging himself).

The points of interest for the gfortran maintainers are: 

(1) are there other platforms on which there is no infinite loop? and if yes
why?
(2) I think the problem could be diagnosed at compiled time (possibly with -O
only). If it can now, I did not find the right option. If not, should I open a
pr along this line or would it deemed too difficult to implement?

Final note, the code has at least another bug (hint: set n=2, d=3 and compile
with -fbounds-check).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192

[Bug fortran/36192] ICE with wrong index types and bad parens

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-05-09 20:06 -------
I can confirm that fixing the code as suggested does allow this to compile
fine.  Also confirming this is an ICE on invalid  


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-invalid-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-09 20:06:57
               date|                            |
            Summary|ICE: Segmentation fault     |ICE with wrong index types
                   |                            |and bad parens


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192