================
@@ -14,13 +14,18 @@ void __builtin_va_copy(double d);
// expected-error@+2 {{cannot redeclare builtin function '__builtin_va_end'}}
// expected-note@+1 {{'__builtin_va_end' is a builtin with type}}
void __builtin_va_end(__builtin_va_list);
-// RUN: %clang_cc1 %s -fsyntax-only -verify
-// RUN: %clang_cc1 %s -fsyntax-only -verify -x c
void __va_start(__builtin_va_list*, ...);
+ void *__builtin_assume_aligned(const void *, size_t, ...);
#ifdef __cplusplus
-void *__builtin_assume_aligned(const void *, size_t, ...) noexcept;
-#else
-void *__builtin_assume_aligned(const void *, size_t, ...);
+constexpr void *__builtin_assume_aligned(const void *, size_t, ...);
+ void *__builtin_assume_aligned(const void *, size_t, ...) noexcept;
+constexpr void *__builtin_assume_aligned(const void *, size_t, ...) noexcept;
+ void *__builtin_assume_aligned(const void *, size_t, ...) throw();
+constexpr void *__builtin_assume_aligned(const void *, size_t, ...) throw();
+
----------------
AaronBallman wrote:
Does anyone know why we allow builtins to be redeclared at all? CC @zygoloid
@rjmccall
I wonder just how much code we would break by not aiming for backwards
compatibility here and requiring users to update their declarations on the
assumption that declaring these at all is undefined behavior (using a reserved
name) and so it's up to the user to match the compiler's behavior rather than
make the compiler handle this with weird non-conforming language extension
behavior.
I'm not looking to punish users in this case, but the workaround to keep things
backwards compatible is pretty magical and awkward.
https://github.com/llvm/llvm-project/pull/91894
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
