================
@@ -9102,6 +9102,15 @@ bool InitializationSequence::Diagnose(Sema &S,
case FK_ConversionFailed: {
QualType FromType = OnlyArg->getType();
+ // __amdgpu_feature_predicate_t can be explicitly cast to the logical op
+ // type, although this is almost always an error and we advise against it
----------------
AaronBallman wrote:
> I suspect that the sense that something is tied to optimiser behaviour is due
> to my reply above, which perhaps was insufficiently clear - apologies.
No worries, this is complex stuff! I appreciate your willingness to talk me
through it. :-)
> The __has_builtin counter-example actually does not work and cannot work,
> please see: https://gcc.godbolt.org/z/7G5Y1d85b.
I cannot imagine a situation in which this isn't indicative of a bug, but
perhaps this situation is the same one that necessitated [this
PR](https://github.com/llvm/llvm-project/pull/126324#issuecomment-2706655366)
which eventually concluded that we should change the behavior of
`__has_builtin` rather than introduce a new builtin.
> furthermore, the ...later... bit is pretty important: what happens on that
> path?
Anything in the world besides changing the value of `has_builtin` to something
other than what `__has_builtin` returned.
> if you do any of those, your distant has_builtin variable no longer reflects
> the predicate, which is the issue;
Why is that an issue? If the variable no longer reflects the predicate, that's
not on the compiler to figure out how to deal with, that's "play silly games,
win silly prizes".
Backing up a step.. my expectation is that this eventually lowers down to a
test and jump which jumps past the target code if the test fails. e.g.,
```
%0 = load i8, ptr %b, align 1
%loadedv = trunc i8 %0 to i1
br i1 %loadedv, label %if.then, label %if.end
if.then:
# the target-specific instructions live here
br label %if.end
if.end:
ret void
```
So we'd be generating instructions for the target which may be invalid if the
test lies. If something did change that value so it no longer represents the
predicate, I think that's UB (and we could help users catch that UB via a
sanitizer check if we wanted to, rather than try to make the backend have to
try to figure it out at compile time).
> if for a chain from point of cast to final point of use folding fails
> (because you passed your value to an
opaque function, modified it based on a run time value etc.), you get an error
and a diagnostic.
I was thinking you would not get a diagnostic; you'd get the behavior you asked
for, which may be utter nonsense.
Am I missing something still? If so, maybe it would be quicker for us to hop in
a telecon call? I'm going to be out of the office until Monday, but I'm happy
to meet with you if that's more productive.
https://github.com/llvm/llvm-project/pull/134016
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
