jdenny added inline comments.
================
Comment at: clang/lib/Sema/SemaOpenMP.cpp:1594
+ !Context.getTargetInfo().hasFloat128Type() &&
+ Context.getTargetInfo().getLongDoubleWidth() != 128) ||
(Ty->isIntegerType() && Context.getTypeSize(Ty) == 128 &&
----------------
ABataev wrote:
> jdenny wrote:
> > ABataev wrote:
> > > jdenny wrote:
> > > > ABataev wrote:
> > > > > Hmm, this look strange, at least. Seems to me, in this case the size
> > > > > of the long double is 128 bit (copied from the host), but device
> > > > > reports that it does not support 128 bit double. Seems to me, it is a
> > > > > problem with the device configuration. Why does the host translate
> > > > > long double to 128 bit fp, while the device translates it to 64 bit
> > > > > FP?
> > > > Sorry, I think I've misunderstood what's happening here, and my fix is
> > > > probably wrong.
> > > >
> > > > For x86_64, the example from my patch summary fails as described there.
> > > > Does that work for you?
> > > >
> > > > For powerpc64le, the reproducer I added to the test suite fails without
> > > > this patch. Shouldn't it succeed?
> > > Still, seems to me like the problem with the device config, not the
> > > original check.
> > > Still, seems to me like the problem with the device config, not the
> > > original check.
> >
> > I'm not sure where to begin looking for that. Can you point me in the
> > right direction? Thanks.
> You need to understand why host and device report different size of the type.
> Check how the device is configured in lib/Basic/Targets
Thanks for the pointer. I think I understand things a bit better now.
Without this patch's fix, the x86_64 example from this patch's summary fails
while this patch's new x86_64 test case passes. The difference is the
summary's example doesn't specify `-unknown-linux` after `x86_64`, and that's
what sets `hasFloat128Type()` to true.
`powerpc64le-unknown-linux-gnu` does not have `__float128`, it seems. That's
why this patch's new powerpc64le test case fails without this patch's fix.
It seems strange to me that the code we're commenting on originally looks for
the source type to be either `__float128` or 128-bit `long double`, and it then
requires the target to support `__float128`. It doesn't accept 128-bit `long
double` support as sufficient. My intention in this patch was to extend it to
accept either so that all the examples above compile. Is that too lenient? Am
I misinterpreting what's happening?
As for your comment about 64-bit floating point in the device translation, I
haven't seen that yet. Did I miss it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64289/new/
https://reviews.llvm.org/D64289
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
