Hi Matthias! On 2020-07-23T15:54:55+0200, Matthias Klose <d...@ubuntu.com> wrote: > Trying to build a nvptx offload compiler on aarch64-linux-gnu
I have not yet heard any reports of ARM-host GCC builds with offloading enabled: 32-bit ARM, or 64-bit aarch64. In general, we've designed/implemented code offloading support in GCC so that it's completely independent from (unaware of) the specific host CPU architecture. Just indeed, for obvious reasons, ABI compatibility across the offloading compliation boundary is the one (only) place where there may be some fine tuning required, in particular if the CPU-side ABI is mandating (..., and the respective GCC back end thus implementing) any "unusual" things. (But I don't know about ARM/aarch64 myself.) > the libgomp tests > error out with > > unrecognizable argument of option -foffload-abi > > Passing that option goes a step further Thanks for looking into this. > hitting PR target/96265. I don't have any input on the 'lto1' errors you're mentioning there -- these seem "strange". Are we sure it's not a host vs. offloading compiler (LTO) configuration problem? Not sure if these are relevant, but just for completeness: I do remember the years-old unresolved <https://gcc.gnu.org/PR65362> "OpenACC compilation on Tegra K1 (ARM)" problem report, and <https://gcc.gnu.org/bugzilla/PR65099> "nvptx offloading: hard-coded 64-bit assumptions", which mentions a few minor technical items that need to be resolved for enabling 32-bit nvptx offloading builds -- which isn't your problem for aarch64. I don't have suitable aarch64 hardware/builds available myself. > Define that > hook, as it was done for rs6000 in 2015. Ok for the trunk? Looks good to me, in principle. Reviewed-by: Thomas Schwinge <tho...@codesourcery.com> > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -22739,6 +22739,16 @@ aarch64_stack_protect_guard (void) > return NULL_TREE; > } > > +/* Implement the TARGET_OFFLOAD_OPTIONS hook. */ > +static char * > +aarch64_offload_options (void) > +{ > + if (TARGET_ILP32) > + return xstrdup ("-foffload-abi=ilp32"); > + else > + return xstrdup ("-foffload-abi=lp64"); > +} I've verified that 'TARGET_ILP32' is the correct conditional to use for 'gcc/config/aarch64/'. I did wonder if we have to keep the current ("unsupported") behavior for big-endian ('BYTES_BIG_ENDIAN'?), but as 'gcc/config/rs6000/rs6000.c:rs6000_offload_options' isn't doing that, we also don't here have to consider that case specially either. > + > /* Return the diagnostic message string if conversion from FROMTYPE to > TOTYPE is not allowed, NULL otherwise. */ > > @@ -23079,6 +23089,9 @@ aarch64_libgcc_floating_mode_supported_p > #undef TARGET_NARROW_VOLATILE_BITFIELD > #define TARGET_NARROW_VOLATILE_BITFIELD hook_bool_void_false > > +#undef TARGET_OFFLOAD_OPTIONS > +#define TARGET_OFFLOAD_OPTIONS aarch64_offload_options > + > #undef TARGET_OPTION_OVERRIDE > #define TARGET_OPTION_OVERRIDE aarch64_override_options According to 'gcc/target.def', 'offload_options' appears after 'override_options_after_change', so maybe both 'aarch64_offload_options' and '#define TARGET_OFFLOAD_OPTIONS' should appear after 'aarch64_override_options_after_change' and '#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' -- but it's not that all the other ones would be sorted properly... ;-) Grüße Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
