https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Xi Ruoyao from comment #26) > (In reply to Jakub Jelinek from comment #24) > > Maybe, but probably we need a whitelist or blacklist. > > Because e.g. powerpc64le-linux I guess wants libquadmath because it > > historically has been using it and long double depending on configuration > > sometimes is and sometimes is not IEEE quad. > > So maybe safer will be something along the lines of #c16, just with better > > wording of the comment (and for libquadmath too). > > Basically, we don't want to have libquadmath on targets which always have > > long double IEEE quad and where libquadmath wasn't used in the past. > > Or for now just #error if __loongarch__ at these two places? Yes. > I suppose in the future (at lease, GCC 16 stage 1) we might provide a > quadmath.h which just redirect sinq, cosq, etc to sinl, cosl, etc. and an > empty libquadmath.a on such targets to support those code assuming > libquadmath. No, first of all, for the I/O libquadmath has special APIs and more importantly, libquadmath always should be just a fallback when nothing else works, where if long double works, that should be used, if _Float128 with *f128 APIs works, that should be used and libquadmath only if neither of that. aarch64 works fine without libquadmath support and so should targets like loongarch IMHO.
