Bug 28176 - FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
Summary: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-27 01:44 UTC by John David Anglin
Modified: 2006-11-19 00:50 UTC (History)
2 users (show)

See Also:
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
Known to work:
Known to fail:
Last reconfirmed: 2006-10-18 20:49:47


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2006-06-27 01:44:01 UTC
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/
mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/actual_array_constructor_1.f90   -O0   -pedantic-errors  -L/mnt/gnu/
gcc/objdir/hppa64-hp-hpux11.00/./libgfortran/.libs -L/mnt/gnu/gcc/objdir/hppa64-
hp-hpux11.00/./libgfortran/.libs -L/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.00/./lib
iberty  -lm   -o ./actual_array_constructor_1.exe    (timeout = 300)
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90: In fu
nction 'redirect_':^M
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:21: in
ternal compiler error: Segmentation fault^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <URL:http://gcc.gnu.org/bugs.html> for instructions.^M
compiler exited with status 1
output is:
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90: In fu
nction 'redirect_':^M
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:21: in
ternal compiler error: Segmentation fault^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <URL:http://gcc.gnu.org/bugs.html> for instructions.^M
FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (test for excess errors)
Excess errors:
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:21: in
ternal compiler error: Segmentation fault

WARNING: gfortran.dg/actual_array_constructor_1.f90  -O0  compilation failed to
produce executable

# /opt/gnu64/bin/gdb ../../f951
GNU gdb 6.4.50.20051209-cvs
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa64-hp-hpux11.11"...
(gdb) r `cat xx.sh`
Starting program: /mnt/gnu/gcc/objdir/gcc/f951 `cat xx.sh`
Detaching after fork from child process 1902.
GNU F95 version 4.2.0 20060626 (experimental) (hppa64-hp-hpux11.00)
        compiled by GNU C version 4.2.0 20060626 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Program received signal SIGSEGV, Segmentation fault.
aggregate_value_p (exp=0x0, fntype=0x0) at ../../gcc/gcc/function.c:1750
1750      tree type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp);
(gdb) bt
#0  aggregate_value_p (exp=0x0, fntype=0x0) at ../../gcc/gcc/function.c:1750
#1  0x4000000000284214 in emit_library_call_value_1 (retval=0,
    orgfun=0x800003fffed5d8c0, value=0x0, fn_type=<value optimized out>,
    outmode=VOIDmode, nargs=<value optimized out>, p=0x800003fffeff2038)
    at ../../gcc/gcc/calls.c:3312
#2  0x4000000000284958 in emit_library_call_value (orgfun=0x0, value=0x8,
    fn_type=2640219, outmode=CCmode, nargs=128) at ../../gcc/gcc/calls.c:3967
#3  0x40000000003d60d0 in expand_binop (mode=TImode,
    binoptab=<value optimized out>, op0=0x800003fffedd8be0,
    op1=0x800003fffedd8ba0, target=<value optimized out>, unsignedp=0,
    methods=<value optimized out>) at ../../gcc/gcc/optabs.c:1888
#4  0x40000000002f5768 in expand_mult (mode=TImode,
    op0=<value optimized out>, op1=0x800003fffedd8ba0,
    target=0x800003fffedd8b80, unsignedp=1) at ../../gcc/gcc/expmed.c:3227
#5  0x4000000000305d18 in expand_expr_real_1 (exp=<value optimized out>,
    target=0x800003fffedd8b80, tmode=<value optimized out>,
    modifier=<value optimized out>, alt_rtl=0x800003fffeff1948)
    at ../../gcc/gcc/expr.c:8145
#6  0x400000000030ebc0 in expand_expr_real (exp=0x800003fffedf4288,
    target=0x800003fffedd8b80, tmode=TImode, modifier=EXPAND_NORMAL,
    alt_rtl=0x800003fffeff1948) at ../../gcc/gcc/expr.c:6690
#7  0x4000000000315ae4 in store_expr (exp=0x800003fffedf4288,
    target=0x800003fffedd8b80, call_param_p=0) at ../../gcc/gcc/expr.c:4370
---Type <return> to continue, or q <return> to quit---
#8  0x4000000000300384 in expand_assignment (to=0x800003fffedfbd10,
    from=<value optimized out>) at ../../gcc/gcc/expr.c:4249
#9  0x40000000003061a4 in expand_expr_real_1 (exp=<value optimized out>,
    target=<value optimized out>, tmode=<value optimized out>,
    modifier=<value optimized out>, alt_rtl=0x0) at ../../gcc/gcc/expr.c:8587
#10 0x400000000030ea88 in expand_expr_real (exp=0x800003fffedf4c18,
    target=0x800003fffed5a400, tmode=VOIDmode, modifier=EXPAND_NORMAL,
    alt_rtl=0x0) at ../../gcc/gcc/expr.c:6684
#11 0x400000000044b584 in expand_expr_stmt (exp=0x0) at expr.h:493
#12 0x400000000049a5d8 in expand_gimple_basic_block (bb=0x800003fffedfe258)
    at ../../gcc/gcc/cfgexpand.c:1368
#13 0x400000000049bb4c in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1634
#14 0x4000000000495394 in execute_one_pass (pass=0x800000010001b728)
    at ../../gcc/gcc/passes.c:864
#15 0x40000000004956b0 in execute_pass_list (pass=0x800000010001b728)
    at ../../gcc/gcc/passes.c:911
#16 0x40000000001e129c in tree_rest_of_compilation (fndecl=0x800003fffedefe00)
    at ../../gcc/gcc/tree-optimize.c:418
#17 0x4000000000192144 in gfc_expand_function (fndecl=0x800003fffedefe00)
    at ../../gcc/gcc/fortran/f95-lang.c:236
#18 0x40000000004e939c in cgraph_expand_function (node=0x800003fffedfb4d0)
    at ../../gcc/gcc/cgraphunit.c:1112
#19 0x40000000004eaf64 in cgraph_assemble_pending_functions ()
---Type <return> to continue, or q <return> to quit---
    at ../../gcc/gcc/cgraphunit.c:364
#20 0x40000000004ea3d0 in cgraph_finalize_function (decl=0x800003fffedefe00,
    nested=0 '\0') at ../../gcc/gcc/cgraphunit.c:490
#21 0x40000000001b4434 in gfc_generate_function_code (
    ns=<value optimized out>) at ../../gcc/gcc/fortran/trans-decl.c:3075
#22 0x400000000019c9e8 in gfc_generate_module_code (ns=0x80000001000c0178)
    at ../../gcc/gcc/fortran/trans.c:685
#23 0x400000000016fe18 in gfc_parse_file ()
    at ../../gcc/gcc/fortran/parse.c:3201
#24 0x400000000019c1a8 in gfc_be_parse_file (
    set_yydebug=<value optimized out>) at ../../gcc/gcc/fortran/f95-lang.c:303
#25 0x400000000045790c in toplev_main (argc=<value optimized out>,
    argv=<value optimized out>) at ../../gcc/gcc/toplev.c:999
#26 0x40000000001dcaf4 in main (argc=0, argv=0x0) at ../../gcc/gcc/main.c:35

Looks like a TImode problem.  Although this is a 64-bit target, it doesn't
support TImode.

From frame 6:

(gdb) p debug_tree (to)
 <var_decl 800003fffedfbd10 D.905
    type <integer_type 800003fffed62160 bit_size_type public unsigned sizetype TI
        size <integer_cst 800003fffed56a20 constant invariant 128>
        unit size <integer_cst 800003fffed56a50 constant invariant 16>
        align 128 symtab 0 alias set -1 precision 68 min <integer_cst 800003fffed56c60 0> max <integer_cst 800003fffed56b70 0xfffffffffffffffff>>
    used unsigned ignored TI file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 line 21 size <integer_cst 800003fffed56a20 128> unit size <integer_cst 800003fffed56a50 16>
    align 128 context <function_decl 800003fffedefe00 redirect_>
    (reg:TI 84 [ D.905 ]) chain <var_decl 800003fffedfbdc0 D.906>>
Comment 1 John David Anglin 2006-06-27 01:53:16 UTC
FAIL: gfortran.dg/actual_array_substr_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/actual_array_substr_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/actual_array_substr_1.f90  -O0  compilation failed to produ
ce executable

fails in the some way.  I guessing but probably the following also
fail in the same way:

FAIL: gfortran.dg/auto_char_pointer_array_result_1.f90  -O0  (internal compiler
error)
FAIL: gfortran.dg/auto_char_pointer_array_result_1.f90  -O0  (test for excess er
rors)
WARNING: gfortran.dg/auto_char_pointer_array_result_1.f90  -O0  compilation fail
ed to produce executable
FAIL: gfortran.dg/auto_pointer_array_result_1.f90  -O0  (internal compiler error
)
FAIL: gfortran.dg/auto_pointer_array_result_1.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/auto_pointer_array_result_1.f90  -O0  compilation failed to
 produce executable
FAIL: gfortran.dg/character_array_constructor_1.f90  -O0  (internal compiler err
or)
FAIL: gfortran.dg/character_array_constructor_1.f90  -O0  (test for excess error
s)
WARNING: gfortran.dg/character_array_constructor_1.f90  -O0  compilation failed
to produce executable
FAIL: gfortran.dg/pr15324.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/pr15324.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/pr15324.f90  -O0  compilation failed to produce executable
FAIL: gfortran.dg/pr17612.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/pr17612.f90  -O0  (test for excess errors)
WARNING: gfortran.dg/pr17612.f90  -O0  compilation failed to produce executable
FAIL: gfortran.fortran-torture/execute/pr19269-1.f90,  -O0  (internal compiler e
rror)
FAIL: gfortran.fortran-torture/execute/strarray_3.f90,  -O0  (internal compiler
error)
FAIL: gfortran.fortran-torture/execute/strarray_4.f90,  -O0  (internal compiler
error)

These fails are related to the libgomp fails noted in PR fortran/27885.
Comment 2 Paul Thomas 2006-06-28 13:22:33 UTC
(In reply to comment #1)
John,

Have all these errors just appeared or do they go back to the era of actual_array_constructor_1.f90; ie 04/04/06?

The reason that I ask is that I am wondering if this is an incipient bug that is exposed by the fixes or if we are progressively adding fixes that are wrong in some way.

Paul
Comment 3 John David Anglin 2006-07-06 16:49:47 UTC
There seem to be more files now but they might be new tests. See <http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00445.html>.
Comment 4 Steve Ellcey 2006-10-18 18:16:26 UTC
Looking at my old logs it looks like gfortran.dg/actual_array_constructor_1.f90 has been failing on hppa64 since it first went in on April 21, 2006.  Someone is creating a TImode variable even though hppa64 doesn't support them.  I haven't been able to figure out who though.
Comment 5 dave 2006-10-18 18:51:18 UTC
Subject: Re:  FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (ICE)

> Looking at my old logs it looks like gfortran.dg/actual_array_constructor_1.f90
> has been failing on hppa64 since it first went in on April 21, 2006.  Someone
> is creating a TImode variable even though hppa64 doesn't support them.  I
> haven't been able to figure out who though.

Right.  I think figuring out who is creating the variable will
help to understand and fix the bug.

Dave
Comment 6 Steve Ellcey 2006-10-18 20:49:47 UTC
Well, I have tracked it back a little ways.  gfc_trans_vla_type_sizes_1 calls gfc_trans_vla_one_sizepos with:

gfc_trans_vla_one_sizepos (&TYPE_SIZE (type), body);

If I print out type->type.size I see:

gdb) p debug_tree(type->type.size)
 <save_expr 800003ffbfe3d2c0
    type <integer_type 800003ffbfdaa160 bit_size_type public unsigned sizetype T
I
        size <integer_cst 800003ffbfd9fdb0 constant invariant 128>
        unit size <integer_cst 800003ffbfd9fde0 constant invariant 16>
        align 128 symtab 0 alias set -1 precision 68 min <integer_cst 800003ffbf
db8000 0> max <integer_cst 800003ffbfd9ff00 0xfffffffffffffffff>>
    side-effects invariant

So I have a TImode here.  How it got here, I don't yet know.
Comment 7 dave 2006-10-19 01:56:31 UTC
Subject: Re:  FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (ICE)

> So I have a TImode here.  How it got here, I don't yet know.

I checked that pa_scalar_mode_supported_p is called and rejects
TImode, so it looks like a fortran problem.

Dave
Comment 8 Steve Ellcey 2006-10-19 18:09:32 UTC
Well, I found that the TImode is getting introduced in layout_type.  For an ARRAY_TYPE tree there is this line:

            TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size,
                                           fold_convert (bitsizetype,
                                                         length));

If you look at bitsizetype, you will find that it is TImode and thus the resulting expression is TImode.  bitsizetype is set in set_sizetype based on 2 * BITS_PER_UNIT_LOG which is 64 for hppa64.  Thus our problem.
Comment 9 dave 2006-10-22 16:18:14 UTC
Subject: Re:  FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (ICE)

> ------- Comment #8 from sje at cup dot hp dot com  2006-10-19 18:09 -------
> Well, I found that the TImode is getting introduced in layout_type.  For an
> ARRAY_TYPE tree there is this line:
> 
>             TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size,
>                                            fold_convert (bitsizetype,
>                                                          length));
> 
> If you look at bitsizetype, you will find that it is TImode and thus the
> resulting expression is TImode.  bitsizetype is set in set_sizetype based on 2
> * BITS_PER_UNIT_LOG which is 64 for hppa64.  Thus our problem.

It appears bitsizetype gets set to a precision that requires TImode here:

void
set_sizetype (tree type)
{
  int oprecision = TYPE_PRECISION (type);
  /* The *bitsizetype types use a precision that avoids overflows when
     calculating signed sizes / offsets in bits.  However, when
     cross-compiling from a 32 bit to a 64 bit host, we are limited to 64 bit
     precision.  */
  int precision = MIN (oprecision + BITS_PER_UNIT_LOG + 1,
		       2 * HOST_BITS_PER_WIDE_INT);

In the above, I don't think a precision larger than MAX_FIXED_MODE_SIZE
should be used.  This is currently 64 on hppa64.  However, oprecision
is 64 and BITS_PER_UNIT_LOG is 3, so the first argument of MIN is 68.
The second argument is 128.  Thus, precision ends up as 68 and the
following re layout uses TImode.

I'm trying the patch below.  I think other limits come into play
long before a calculation overflow would bit.

The other alternative is to add TImode support.  This is much more
complicated and probably not suitable for stage3.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: stor-layout.c
===================================================================
--- stor-layout.c	(revision 117956)
+++ stor-layout.c	(working copy)
@@ -1934,7 +1934,8 @@
      calculating signed sizes / offsets in bits.  However, when
      cross-compiling from a 32 bit to a 64 bit host, we are limited to 64 bit
      precision.  */
-  int precision = MIN (oprecision + BITS_PER_UNIT_LOG + 1,
+  int precision = MIN (MIN (oprecision + BITS_PER_UNIT_LOG + 1,
+			    MAX_FIXED_MODE_SIZE),
 		       2 * HOST_BITS_PER_WIDE_INT);
   tree t;
 
Comment 10 John David Anglin 2006-11-18 23:17:45 UTC
Subject: Bug 28176

Author: danglin
Date: Sat Nov 18 23:17:33 2006
New Revision: 118977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118977
Log:
	PR fortran/27885
	PR middle-end/28176
	* stor-layout.c (set_sizetype): Limit precision of *bitsizetypes types
	to MAX_FIXED_MODE_SIZE.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/stor-layout.c

Comment 11 John David Anglin 2006-11-19 00:44:16 UTC
Subject: Bug 28176

Author: danglin
Date: Sun Nov 19 00:44:04 2006
New Revision: 118984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118984
Log:
	PR fortran/27885
	PR middle-end/28176
	* stor-layout.c (set_sizetype): Limit precision of *bitsizetypes types
	to MAX_FIXED_MODE_SIZE.


Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/stor-layout.c

Comment 12 John David Anglin 2006-11-19 00:50:11 UTC
Fixed by patch.