--- Comment #9 from brooks at gcc dot gnu dot org 2007-05-28 20:57 ---
Fixed, as per above commits.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from brooks at gcc dot gnu dot org 2007-05-28 20:54 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:54:49 2007
New Revision: 125142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125142
Log:
PR fortran/31972
* transfer_hollerith_1.f90: New test.
Added:
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-28 20:53 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:53:09 2007
New Revision: 125141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125141
Log:
PR 31972/fortran
* target-memory.c (gfc_target_expr_size): Add
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-17 22:45 ---
Yeah, this is to be expected, I think. Holleriths store the memory
representation but not the "semantic" representation of their value, and
transfer tries to fold things and gets confused.
There's probably an easy f
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-17 20:15 ---
Dominique, target-memory.c (frame #1 in the backtrace) was newly introduced at
20070516.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-17 18:18 ---
Works for me on OSX 10.3.9 gfortran 4.3.0 20070511:
PROGRAM lsstr
INTEGER, DIMENSION(1) :: i
i = (/ TRANSFER(4HSOLR, 0) /)
print *, i
END PROGRAM lsstr
outputs 1397705810 (83797682 hexa) with gfortran, xlf, and g95,
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-17 17:59 ---
Add Brooks to CC, again.
Brooks, could you have a look at this one?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-17 17:33 ---
Confirmed. Adding Brooks Moses to CC as he recently worked on this.
(gdb) bt
#0 gfc_internal_error (
format=0x86ca3bc "Invalid expression in gfc_target_expr_size.")
at ../../../gcc/gcc/fortran/error.c:820
#
