On Thu, Sep 24, 2026 at 2:36 PM Tobias Burnus <[email protected]> wrote: > > That's with OpenMP offloading to either nvptx or amdgcn. > > Some benchmark code nicely compiled on the host - and then > the device lto1 compiler failed with: > > lto1: internal compiler error: tree check: > expected class ‘type’, have ‘exceptional’ (error_mark) > in lto_fixup_prevailing_type, at lto/lto-common.cc:1006 > > It turned out that the code in question used _Float16. > > For _Float128, no machine mode is found and a > nice error message is shown. But not so for _Float16. > > The reason, it turned out: "HF" is actually available as > machine mode – but the targetm.scalar_mode_supported_p > hook then simply reports it as unsupported, effectively > disabling it. > > (In the amdgcn's hook, HF is is commented out; in nvptx's, > it only available with -mexperimental [if additionally > -march=sm_53 or higher].) > > * * * > > When using the nvptx/amdgcn C compiler, _Float16 was rejected > during parsing; however, only with the attached patch there > now also a proper error message for offloaded code: > > lto1: fatal error: nvptx-none - 16-bit-precision floating-point numbers > unsupported (mode ‘HF’) > lto1: fatal error: amdgcn-amdhsa - 16-bit-precision floating-point numbers > unsupported (mode ‘HF’) > > OK for mainline?
Looks good, but how we get to pass == 3 is totally non-obvious ... why make it conditional on pass == 3 only? Thanks, Richard. > > Tobias
