> From: Andreas Schwab <sch...@linux-m68k.org>
> Cc: Eli Zaretskii <e...@gnu.org>, gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 23:00:55 +0100
>
> On Jan 16 2018, DJ Delorie <d...@redhat.com> wrote:
>
> > And it's not the host's bit size that counts; there are usually ways to
> > get 64-bit file operations on 32-bit hosts.
>
> If ACX_LARGEFILE doesn't succeed in enabling those 64-bit file
> operations (thus making off_t a 64-bit type) then you are out of luck
> (or AC_SYS_LARGEFILE doesn't support your host yet).
Yes, AC_SYS_LARGEFILE doesn't support MinGW.
DJ, would the following semi-kludgey workaround be acceptable?
--- libiberty/simple-object-xcoff.c~0 2018-01-12 05:31:04.000000000 +0200
+++ libiberty/simple-object-xcoff.c 2018-01-17 12:21:08.496186000 +0200
@@ -596,13 +596,19 @@ simple_object_xcoff_find_sections (simpl
aux = (unsigned char *) auxent;
if (u64)
{
+ /* Use an intermediate 64-bit type to avoid
+ compilation warning about 32-bit shift below on
+ hosts with 32-bit off_t which aren't supported by
+ AC_SYS_LARGEFILE. */
+ ulong_type x_scnlen64;
+
if ((auxent->u.xcoff64.x_csect.x_smtyp & 0x7) != XTY_SD
|| auxent->u.xcoff64.x_csect.x_smclas != XMC_XO)
continue;
- x_scnlen = fetch_32 (aux + offsetof (union external_auxent,
-
u.xcoff64.x_csect.x_scnlen_hi));
- x_scnlen = x_scnlen << 32
+ x_scnlen64 = fetch_32 (aux + offsetof (union external_auxent,
+
u.xcoff64.x_csect.x_scnlen_hi));
+ x_scnlen = x_scnlen64 << 32
| fetch_32 (aux + offsetof (union external_auxent,
u.xcoff64.x_csect.x_scnlen_lo));
}
