* [Bug fortran/36192] ICE: Segmentation fault
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
@ 2008-05-09 17:47 ` doko at ubuntu dot com
2008-05-09 18:05 ` kargl at gcc dot gnu dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: doko at ubuntu dot com @ 2008-05-09 17:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from doko at ubuntu dot com 2008-05-09 17:47 -------
Created an attachment (id=15622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15622&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE: Segmentation fault
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
2008-05-09 17:47 ` [Bug fortran/36192] " doko at ubuntu dot com
@ 2008-05-09 18:05 ` kargl at gcc dot gnu dot org
2008-05-09 18:16 ` kargl at gcc dot gnu dot org
` (8 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: kargl at gcc dot gnu dot org @ 2008-05-09 18:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from kargl at gcc dot gnu dot org 2008-05-09 18:04 -------
While gfortran should not ICE, this program is seriously flawed with
illegal Fortran. Just one example.
! Simulation parameters
real, parameter :: n = 2, d = 2
! Body masses
real, dimension(n), parameter :: m = (/ 1.0, 1.0 /)
! Body parameters
real, dimension(n,d) :: &
The arguments to dimension() should be integer type.
Fix your code and the ICE may go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE: Segmentation fault
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
2008-05-09 17:47 ` [Bug fortran/36192] " doko at ubuntu dot com
2008-05-09 18:05 ` kargl at gcc dot gnu dot org
@ 2008-05-09 18:16 ` kargl at gcc dot gnu dot org
2008-05-09 20:07 ` [Bug fortran/36192] ICE with wrong index types and bad parens jvdelisle at gcc dot gnu dot org
` (7 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: kargl at gcc dot gnu dot org @ 2008-05-09 18:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from kargl at gcc dot gnu dot org 2008-05-09 18:15 -------
Add -Wall to your compiler flags!
any(abs(v_hq - v_n > precision_goal))) then
1
Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
You have messed up parentheses.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (2 preceding siblings ...)
2008-05-09 18:16 ` kargl at gcc dot gnu dot org
@ 2008-05-09 20:07 ` jvdelisle at gcc dot gnu dot org
2008-05-11 16:40 ` dominiq at lps dot ens dot fr
` (6 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2008-05-09 20:07 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (3 preceding siblings ...)
2008-05-09 20:07 ` [Bug fortran/36192] ICE with wrong index types and bad parens jvdelisle at gcc dot gnu dot org
@ 2008-05-11 16:40 ` dominiq at lps dot ens dot fr
2008-10-01 12:11 ` dominiq at lps dot ens dot fr
` (5 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-05-11 16:40 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (4 preceding siblings ...)
2008-05-11 16:40 ` dominiq at lps dot ens dot fr
@ 2008-10-01 12:11 ` dominiq at lps dot ens dot fr
2009-12-29 16:38 ` debian-gcc at lists dot debian dot org
` (4 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-10-01 12:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (5 preceding siblings ...)
2008-10-01 12:11 ` dominiq at lps dot ens dot fr
@ 2009-12-29 16:38 ` debian-gcc at lists dot debian dot org
2009-12-29 18:38 ` kargl at gcc dot gnu dot org
` (3 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: debian-gcc at lists dot debian dot org @ 2009-12-29 16:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (6 preceding siblings ...)
2009-12-29 16:38 ` debian-gcc at lists dot debian dot org
@ 2009-12-29 18:38 ` kargl at gcc dot gnu dot org
2009-12-29 18:58 ` kargl at gcc dot gnu dot org
` (2 subsequent siblings)
10 siblings, 0 replies; 16+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-12-29 18:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (7 preceding siblings ...)
2009-12-29 18:38 ` kargl at gcc dot gnu dot org
@ 2009-12-29 18:58 ` kargl at gcc dot gnu dot org
2009-12-30 0:34 ` kargl at gcc dot gnu dot org
2009-12-30 0:44 ` kargl at gcc dot gnu dot org
10 siblings, 0 replies; 16+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-12-29 18:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (8 preceding siblings ...)
2009-12-29 18:58 ` kargl at gcc dot gnu dot org
@ 2009-12-30 0:34 ` kargl at gcc dot gnu dot org
2009-12-30 0:44 ` kargl at gcc dot gnu dot org
10 siblings, 0 replies; 16+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-12-30 0:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/36192] ICE with wrong index types and bad parens
2008-05-09 17:47 [Bug fortran/36192] New: ICE: Segmentation fault doko at ubuntu dot com
` (9 preceding siblings ...)
2009-12-30 0:34 ` kargl at gcc dot gnu dot org
@ 2009-12-30 0:44 ` kargl at gcc dot gnu dot org
10 siblings, 0 replies; 16+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-12-30 0:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 16+ messages in thread