Bug 29507 - [4.2 only] INDEX in an array initialization causes ICE
Summary: [4.2 only] INDEX in an array initialization causes ICE
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 31392 31221 31393
  Show dependency treegraph
 
Reported: 2006-10-18 20:46 UTC by kargl
Modified: 2007-04-15 13:08 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.1.3 4.2.0 4.3.0
Last reconfirmed: 2006-10-22 05:01:27


Attachments
Provisional general fix for the PR (1.50 KB, patch)
2006-10-23 10:02 UTC, Paul Thomas
Details | Diff
A better fix for the PR (1.27 KB, patch)
2007-04-04 16:15 UTC, Paul Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description kargl 2006-10-18 20:46:33 UTC
This code:

  module z
  character(8), parameter :: a(1:3)=(/'nint()  ', 'log10() ', 'sqrt()  '/)
  integer, parameter :: b(1:3) = index(a, '(')
  end module z

causes

troutmask:sgk[415] gfc4x -o z z.f90
z.f90:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:3470
Comment 1 patchapp@dberlin.org 2006-10-19 12:50:14 UTC
Subject: Bug number PR29507

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00984.html
Comment 2 Paul Thomas 2006-10-22 05:01:27 UTC
I have a general fix, in place of that of #1, more or less working. It'll be a day or two yet before it's ready for exposure.

Paul
Comment 3 Paul Thomas 2006-10-23 10:02:30 UTC
Created attachment 12479 [details]
Provisional general fix for the PR

This patch fixes the the following:
  real, parameter :: a(2,2) = reshape ((/1.0, 2.0, 3.0, 4.0/), (/2,2/))
  real, parameter :: b(2,2) = sin (a)
  character(6), parameter :: ch(3) = (/"animal", "person", "mantee"/)
  character(1), parameter :: ch2(3) = (/"n", "r", "t"/)
  integer, parameter :: i(3) = index (ch, ch2)
  print *, a, b
  print *, ch, i
end

There are still several things to do:
(i) Understand why *e needs to be copied to old and then freed; ideally, *e should be assigned to old and expr assigned to it, at exit;
(ii) Add conformance checks;
(iii) Check if the branch to the new function is in the correct place - it is certainly the earliest opportunity to identify an elemental intrinsic; and
(iv) Check that none of the non-elemental intrinsics are screwed up.

Paul
Comment 4 Paul Thomas 2007-02-16 18:22:40 UTC
Thanks for the reminder - I had not forgotten.  I am trying to work my way through the list with very limited time.  I'll get there though!

Paul
Comment 5 Francois-Xavier Coudert 2007-03-16 15:04:12 UTC
(In reply to comment #3)
Since this bug is related to PR31221, I tried your patch on the other testcase, and it fails:

$ cat a.f90 
  integer, parameter :: i2(1)=MODULO((/1/),5)
  call foo(i2)
  end
$ gfortran a.f90
a.f90:1.45:

  integer, parameter :: i2(1)=MODULO((/1/),5)
                                            1
Internal Error at (1):
check_init_expr(): Unknown expression type

I don't know if it exposes another bug or exposes something missing in your patch.
Comment 6 Paul Thomas 2007-04-04 08:19:31 UTC
                                        1
> Internal Error at (1):
> check_init_expr(): Unknown expression type
> I don't know if it exposes another bug or exposes something missing in your
> patch.

FX,

I have just returned to this and associated PRs. As noted originally, there are some perplexing problems with the first attempt at a patch.  In my first attempts last night, I made the problems even more perplexing.  Hanging diagnostic output on the patched stretch of code changes its behaviour!  This time, I am going to stick with this one until it is fixed.

Paul 
Comment 7 Paul Thomas 2007-04-04 16:15:40 UTC
Created attachment 13328 [details]
A better fix for the PR

This version of the patch has been moved to expr.c.  It seems that PR29507, PR31211 and PR31404 are all fixed.  PR29397 is due to something else.  I will have a look as soon as I have this one finished.

It needs:
(i) Checking for memory leaks - I do not think that the expressions are being cleaned up properly;
(ii) A rudimentary conformance check is need.  gfc_conformance_check segfaults on some of the expressions; and
(iii) I need to check what happens with implicit loop array constructors.

Anyway, this patch is halfway through regtesting, as I write, and is doing fine.

Paul
Comment 8 patchapp@dberlin.org 2007-04-05 13:05:21 UTC
Subject: Bug number PR29507

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00170.html
Comment 9 Paul Thomas 2007-04-14 15:10:11 UTC
Subject: Bug 29507

Author: pault
Date: Sat Apr 14 15:09:57 2007
New Revision: 123815

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123815
Log:
2007-04-14 Paul Thomas <pault@gcc.gnu.org>

	PR fortran/29507
	PR fortran/31404
	* expr.c (scalarize_intrinsic_call): New function to
	scalarize elemental intrinsic functions in initialization
	expressions.
	(check_init_expr): Detect elemental intrinsic functions
	in initalization expressions and call previous.


2007-04-14 Paul Thomas <pault@gcc.gnu.org>

	PR fortran/29507
	PR fortran/31404
	* gfortran.dg/initialization_6.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/initialization_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/testsuite/ChangeLog

Comment 10 Paul Thomas 2007-04-15 13:08:14 UTC
Fixed on trunk

Paul