Development

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • New: ICE in operand_subword_force, at emit-rtl.c:1353

    12 answers - 792 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    $cat ice.f90
    PRGRAM test_ice
    CHARACTER(len=255), DIMENSIN(1,2) :: a
    a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))
    CNTAINS
    CHARACTER(32) FUNCTIN to_string(x)
    REAL, INTENT(in) :: x
    WRITE(to_string, FMT="(F6.3)") x
    END FUNCTIN
    END PRGRAM
    $gfortran-4.2 -g -Wall ice.f90
    ice.f90: In function ‘MAIN__’:
    ice.f90:3: internal compiler error: in operand_subword_force, at
    emit-rtl.c:1353
    Please submit a full bug report,
    $gfortran -v
    Using built-in specs.
    Target: i686-pc-linux-gnu
    Configured with: /gcc/configure
    /
    ,c++,fortran
    Thread model: posix
    gcc version 4.2.0 20060914 (experimental)
    Initially reported here:
    (the testcase above is a reduced version of that posted to the ML)
  • No.1 | | 1929 bytes | |

    Comment #1 from rguenth at gcc dot gnu dot org 2006-09-28 13:09
    Confirmed.

    (gdb) bt
    #0 fancy_abort (
    file=0xc80d78 "/", line=1353,
    function=0xc80ef0 "operand_subword_force")
    at /
    #1 0x000000000061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0,
    mode=QImode) at /
    #2 0x00000000006351a6 in store_bit_field (str_rtx=0x2b22e2375ba0,
    bitsize=256, bitnum=0, fieldmode=QImode, value=0x2b22e2362f40)
    at /
    #3 0x000000000065441b in store_field (target=0x2b22e2375ba0, bitsize=256,
    bitpos=0, mode=BLKmode, exp=0x2b22e23639a0, type=0x2b22e2359d10,
    alias_set=0) at /
    #4 0x000000000064d0e2 in expand_assignment (to=0x2b22e235a300,
    from=0x2b22e23639a0) at /
    #5 0x000000000066d9cf in expand_expr_real_1 (exp=0x2b22e235b870, target=0x0,
    tmode=VIDmode, modifier=EXPAND_NRMAL, alt_rtl=0x0)
    at /
    #6 0x000000000065a675 in expand_expr_real (exp=0x2b22e235b870,
    target=0x2b22e2284400, tmode=VIDmode, modifier=EXPAND_NRMAL, alt_rtl=0x0)
    at /
    (gdb) up
    #1 0x000000000061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0,
    mode=QImode) at /
    1353 gcc_assert (result);
    (gdb) list
    1348 else
    1349 op = force_reg (mode, op);
    1350 }
    1351
    1352 result = operand_subword (op, offset, 1, mode);
    1353 gcc_assert (result);
    1354
    1355 return result;
    1356 }
    1357 ^L

    We're asking for a QImode subword at offset 0 of
    (mem/s/j:BLK (plus:DI (reg:DI 112)
    (reg:DI 96 [ D.1297 ])) [0 S32 A8])

    in expansion of

    (*D.1297)[S.20D.1298] = D.1302

    4.0 fails differently:

    gcc40-g/gcc./f951 -quiet //gcc41-g/gcc/t.f90
    //gcc41-g/gcc/t.f90: In function 'MAIN__':
    //gcc41-g/gcc/t.f90:8: internal compiler error: in gfc_conv_function_call,
    at fortran/trans-expr.c:1108
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <for instructions.
  • No.2 | | 128 bytes | |

    Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-04 06:59
    I think this code is valid. Changing to ice-on-valid-code.
  • No.3 | | 255 bytes | |

    Comment #3 from tobi at gcc dot gnu dot org 2006-10-06 20:36
    Slightly reduced testcase, gives the same ice:
    implicit character*32 (a-z)
    CHARACTER(len=255), DIMENSIN(1,2) :: a
    a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))
    END PRGRAM
  • No.4 | | 505 bytes | |

    Comment #4 from tobi at gcc dot gnu dot org 2006-10-06 20:37
    Another interesting variation:
    schluter@pcl247:~/src/pr/29267cat t.f90
    implicit character*32 (a-z)
    CHARACTER(len=255), DIMENSIN(1,2) :: a
    a = reshape((/ to_string(1.0) /), (/ 1, 2 /))
    END PRGRAM
    schluter@pcl247:~/src/pr/29267~/src/gcc/build/gcc/f951 t.f90
    MAIN__
    t.f90:1: fatal error: gfc_todo: Not Implemented: complex character array
    constructors
    compilation terminated.
    schluter@pcl247:~/src/pr/29267
  • No.5 | | 218 bytes | |

    Comment #5 from tobi at gcc dot gnu dot org 2006-10-06 21:01
    Actually this is invalid code. The string lengths in the constructor are
    different, even though they have to be the same. See 4.5 in the F95 standard.
  • No.6 | | 282 bytes | |

    --
    tobi at gcc dot gnu dot org changed:
    What |Removed |Added
    AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
    |dot org |
    Status|NEW |ASSIGNED
    Last reconfirmed|2006-10-04 06:59:59 |2006-10-06 21:42:33
    date| |
  • No.7 | | 565 bytes | |

    Comment #6 from franke dot daniel at gmail dot com 2006-10-07 07:09
    Tobi,
    Actually this is invalid code. The string lengths in the constructor are
    different, even though they have to be the same.
    please try the testcase in the orignal PR with idental string lengths. It will
    crash gfortran as well.

    TH,
    a(1,1) = "x"
    a(1,2) = to_string(1.0)
    should work even if
    CHARACTER(len=255), DIMENSIN(1,2) :: a
    and
    CHARACTER(len=32) FUNCTIN to_string(x),
    so, why is an equivalent assignment through the array constructor invalid?
  • No.8 | | 1097 bytes | |

    Comment #7 from tobi at gcc dot gnu dot org 2006-10-09 11:14
    (In reply to comment #6)
    please try the testcase in the orignal PR with idental string lengths. It will
    crash gfortran as well.

    Works for me. Please provide a testcase.
    schluter@pcl247:~/src/pr/29267cat t.f90
    ! implicit character*32 (b-z)
    CHARACTER(len=255), DIMENSIN(2) :: a
    a = reshape((/ "", to_string(1.0) /),
    shape(a))
    print *, a
    CNTAINS
    CHARACTER(32) FUNCTIN to_string(x)
    REAL, INTENT(in) :: x
    WRITE(to_string, FMT="(F6.3)") x
    END FUNCTIN
    END PRGRAM
    schluter@pcl247:~/src/pr/29267~/src/gcc/build/gcc/f951 t.f90
    MAIN__ to_string
    Execution times (seconds)
    parser : 0.01 (100%) usr 0.00 ( 0%) sys 0.01 (100%) wall
    132 kB (18%) ggc
    TTAL : 0.01 0.00 0.01
    740 kB
    Extra diagnostic checks enabled; compiler may run slowly.
    Configure with to disable checks.
    schluter@pcl247:~/src/pr/29267

    so, why is an equivalent assignment through the array constructor invalid?

    Because the standard says so, I already quoted the relevant part.
  • No.9 | | 932 bytes | |

    Comment #8 from franke dot daniel at gmail dot com 2006-10-13 15:54
    As requested in comment #7, a testcase for equal string lengths (identical to
    original PR but to_string() returns CHARACTER(len=255) instead of
    CHARACTER(len=32)):

    $cat cat pr29267.f90
    PRGRAM test_ice
    CHARACTER(len=255), DIMENSIN(1,2) :: a
    a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))

    CNTAINS
    CHARACTER(len=255) FUNCTIN to_string(x)
    REAL, INTENT(in) :: x
    WRITE(to_string, FMT="(F6.3)") x
    END FUNCTIN
    END PRGRAM

    $gfortran-4.2 -g -Wall pr29267.f90
    pr29267.f90: In function 'MAIN__':
    pr29267.f90:3: internal compiler error: in operand_subword_force, at
    emit-rtl.c:1353

    $gfortran-4.2 -v
    Using built-in specs.
    Target: i686-pc-linux-gnu
    Configured with: /gcc/configure $mylocalprefix

    ,fortran
    Thread model: posix
    gcc version 4.2.0 20061013 (experimental)
  • No.10 | | 808 bytes | |

    Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-13 19:19
    Subject: Re: ICE in operand_subword_force, at
    emit-rtl.c:1353

    franke dot daniel at gmail dot com <gcc-bugzilla (AT) gcc (DOT) gnu.orgwrote on
    Fri, 13 2006:

    As requested in comment #7, a testcase for equal string lengths (identical to
    original PR but to_string() returns CHARACTER(len=255) instead of
    CHARACTER(len=32)):

    , that's what you meant with equal lengths :-) This is indeed not
    required by the standard.

    And indeed, this triggers the same bug: the ICE has nothing to do with
    the assignment, it is the code dealing with the array constructor that
    is making us ICE.

    Thanks!

    This message was sent using IMP, the Internet Messaging Program.
  • No.11 | | 449 bytes | |

    Comment #10 from franke dot daniel at gmail dot com 2006-10-14 08:46
    Don't know whether it makes any difference - but if it is the array constructor
    that crashes because of unequal string lengths within its arguments, why is
    there no problem with this code?

    PRGRAM test_constructor
    CHARACTER(len=32), DIMENSIN(1,2) :: a
    a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
    END PRGRAM

    (Also compare with #3)
  • No.12 | | 1022 bytes | |

    Comment #11 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-16 10:52
    Subject: Re: ICE in operand_subword_force, at
    emit-rtl.c:1353

    franke dot daniel at gmail dot com <gcc-bugzilla (AT) gcc (DOT) gnu.orgwrote on
    Sat, 14 2006:
    Don't know whether it makes any difference - but if it is the array
    constructor
    that crashes because of unequal string lengths within its arguments, why is
    there no problem with this code?

    PRGRAM test_constructor
    CHARACTER(len=32), DIMENSIN(1,2) :: a
    a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
    END PRGRAM

    Because this doesn't trigger the buggy codepath :-) Sometime in the
    past someone went to some lengths to support this kind of invalid
    code. Had they read the standard closely, they could have saved
    themselves some work.

    (Also compare with #3)

    I don't see the relation.

    Cheers,
    - Tobi

    This message was sent using IMP, the Internet Messaging Program.

Re: New: ICE in operand_subword_force, at emit-rtl.c:1353


max 4000 letters.
Your nickname that display:
In order to stop the spam: 4 + 3 =
QUESTION ON "Development"

EMSDN.COM