This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[RFA:] (Update:) fortran f/target.c cross tweak to not fail forbig-endian hosts.
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: <gcc-patches at gcc dot gnu dot org>
- Cc: Alan Modra <amodra at bigpond dot net dot au>
- Date: Mon, 26 Aug 2002 21:32:07 -0400 (EDT)
- Subject: [RFA:] (Update:) fortran f/target.c cross tweak to not fail forbig-endian hosts.
This is an update of
<URL:http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01492.html>.
Compared to that version, I have removed the check for
HOST_FLOAT_WORDS_BIG_ENDIAN against FLOAT_WORDS_BIG_ENDIAN since
that caused spurious failures testing arm-elf+arm-sim (which
defaults to little-endian except notably the well-known(?)
FLOAT_WORDS_BIG_ENDIAN weirdness. There's also a wording and
formatting tweak to the comment hunk. This is tested on
i686-pc-linux-gnu cross to: mmix-knuth-mmixware arm-unknown-elf
cris-axis-elf mn10300-unknown-elf v850-unknown-elf. Those are
little-endian configs except mmix-knuth-mmixare. No point
testing a hosted bootstrap since the code is all inside #ifdef
CROSS_COMPILE. I don't have a big-endian host handy to test
with, but considering that this version will "sorry" in fewer
cases than the version that worked for Alan Modra's NATIVE_CROSS
big-endian ppc-x-ppc64 case (IIRC), I don't worry.
BTW, there's currently (LAST_UPDATED Sat Aug 24 12:04:38 GMT
2002) a bug in sorry() causing messages come out as:
x/alpha1.f:7: sorry, unimplemented: sorry, not implemented: data initializer on host with different endianness
I haven't investigated that.
Ok to commit?
On 3.2 too (regression: problem with fortran on
big-endian-x-big-endian crosses; see URL above)?
* target.c (ffetarget_memcpy_): Don't test nonexistent
HOST_BYTES_BIG_ENDIAN, HOST_BITS_BIG_ENDIAN. Check
HOST_WORDS_BIG_ENDIAN against both WORDS_BIG_ENDIAN and
BYTES_BIG_ENDIAN.
Index: target.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/f/target.c,v
retrieving revision 1.19
diff -p -c -r1.19 target.c
*** target.c 17 Jun 2002 21:21:01 -0000 1.19
--- target.c 26 Aug 2002 12:06:43 -0000
*************** void *
*** 2521,2526 ****
--- 2521,2529 ----
ffetarget_memcpy_ (void *dst, void *src, size_t len)
{
#ifdef CROSS_COMPILE
+ /* HOST_WORDS_BIG_ENDIAN corresponds to both WORDS_BIG_ENDIAN and
+ BYTES_BIG_ENDIAN (i.e. there are no HOST_ macros to represent a
+ difference in the two latter). */
int host_words_big_endian =
#ifndef HOST_WORDS_BIG_ENDIAN
0
*************** ffetarget_memcpy_ (void *dst, void *src,
*** 2529,2550 ****
#endif
;
- int host_bytes_big_endian =
- #ifndef HOST_BYTES_BIG_ENDIAN
- 0
- #else
- HOST_BYTES_BIG_ENDIAN
- #endif
- ;
-
- int host_bits_big_endian =
- #ifndef HOST_BITS_BIG_ENDIAN
- 0
- #else
- HOST_BITS_BIG_ENDIAN
- #endif
- ;
-
/* This is just hands thrown up in the air over bits coming through this
function representing a number being memcpy:d as-is from host to
target. We can't generally adjust endianness here since we don't
--- 2532,2537 ----
*************** ffetarget_memcpy_ (void *dst, void *src,
*** 2555,2562 ****
for instance in g77.f-torture/execute/980628-[4-6].f and alpha2.f.
Still, we compile *some* code. FIXME: Rewrite handling of numbers. */
if (!WORDS_BIG_ENDIAN != !host_words_big_endian
! || !BYTES_BIG_ENDIAN != !host_bytes_big_endian
! || !BITS_BIG_ENDIAN != !host_bits_big_endian)
sorry ("data initializer on host with different endianness");
#endif /* CROSS_COMPILE */
--- 2542,2548 ----
for instance in g77.f-torture/execute/980628-[4-6].f and alpha2.f.
Still, we compile *some* code. FIXME: Rewrite handling of numbers. */
if (!WORDS_BIG_ENDIAN != !host_words_big_endian
! || !BYTES_BIG_ENDIAN != !host_words_big_endian)
sorry ("data initializer on host with different endianness");
#endif /* CROSS_COMPILE */
brgds, H-P