Attempting to resend my response differently since my last email seems
to have had problems with email permissions.
Apologies for the duplication.
On 12/2/24 16:48, Jason Merrill wrote:
External email: Use caution opening links or attachments
On 10/21/24 6:43 AM, Matthew Malcomson wrote:
Ping (re-sending ping because previous message body too large for list --
apologies for duplication to those on Cc).
Attaching update on testsuite to fix testism on Arm that Linaro CI
caught.
From: Matthew Malcomson <mmalcom...@nvidia.com>
This commit newly introduces the ability to use overloaded builtins in
C++ SFINAE context.
...
that I have updated to take the extra boolean flag. I have not adjusted
the functions implementing those target hooks (except to update the
declarations) so target specific builtins will still error in SFINAE
contexts.
Since you're adding the parameter, why not adjust them to check it?
Honestly it looked like much more work than the main patch (especially
around ensuring comprehensive testcases) and was mostly on code (and
functionality) that I've never seen before. I also didn't know of any
case where these target specific builtins would benefit from having
SFINAE, but I had a motivating case for adding SFINAE for atomics.
- With SFINAE GCC is happy with multiple definitions of a differently
typed template as long as they aren't instantiated, while clang is
not. This seems to be a general difference around clang and GCC and
not specific to builtins.
I.e. two template definitions with the same name where one
specialises on `myfunc (std::declval<T>())` and another on
`myfunc (std::declval<T>(), std::declval<T>())` will not give an
error in GCC unless one attempts to instantiate the template.
However it will give an error in clang on the template redefinition.
Can you give a testcase? I'm having trouble understanding what you mean.
With the following code clang errors about redefinition of `struct
is_available`, while GCC does not error unless the `static_assert` is
uncommented.
```
#include <type_traits>
int myfunc(int x, int y) { return x + y; }
int myfunc() { return 100; }
int myfunc(int x) { return x + 2; }
template <typename T, typename = void>
struct is_available : std::false_type {};
template <typename T>
struct is_available<T, std::void_t<decltype(myfunc (std::declval<T>())) >>
: std::true_type {};
template <typename T>
struct is_available<T, std::void_t<decltype(myfunc (std::declval<T>(),
std::declval<T>())) >>
: std::true_type {};
int f() {
// static_assert(is_available<int>::value == true);
return 0;
}
```
- I do not block the warning about using
__builtin_speculation_safe_value on a target that does not have any
active mitigation defined. I do this since when this happens we do
not return error_mark_node, which means that if a user attempted to
use SFINAE to check for this situation that would silently fail if the
warning were suppressed.
N.b. this is also a warning rather than an error.
Similarly I do not block the warning about an invalid memory model
argument in get_atomic_generic_size.
Hmm, I think we want a SFINAE failure in these cases rather than a
warning, like various extensions that we reject in SFINAE but accept
with a pedwarn in other contexts.
Giving a warning when considering a candidate that might not be chosen
for other reasons seems undesirable.
... Working on this now ... thanks!
If we're avoiding warnings does that imply I should change the boolean I
pass down to the c-common.cc functions to
`complain & (tf_error | tf_warning)` instead of `complain & tf_error`?
@@ -8356,41 +8473,41 @@ resolve_overloaded_builtin (location_t loc,
tree function,
{
case BUILT_IN_ATOMIC_EXCHANGE:
{
- if (resolve_overloaded_atomic_exchange (loc, function,
params,
- &new_return))
- return new_return;
- /* Change to the _N variant. */
- orig_code = BUILT_IN_ATOMIC_EXCHANGE_N;
- break;
+ if (resolve_overloaded_atomic_exchange (loc, function, params,
+ &new_return, complain))
+ return new_return;
+ /* Change to the _N variant. */
+ orig_code = BUILT_IN_ATOMIC_EXCHANGE_N;
+ break;
}
Try not to change the indentation of lines you aren't otherwise changing.
Ah, yes apologies about this. Will tidy up.
Jason
