2017-03-31 05:48:55 +08:00
// RUN: %clang_cc1 -fsyntax-only -verify %s
// return values
void test_void_alloc_align ( void ) __attribute__ ( ( alloc_align ( 1 ) ) ) ; // expected-warning {{'alloc_align' attribute only applies to return values that are pointers}}
2021-10-07 02:20:44 +08:00
void * test_ptr_alloc_align ( unsigned long long a ) __attribute__ ( ( alloc_align ( 1 ) ) ) ; // no-warning
2017-03-31 05:48:55 +08:00
int j __attribute__ ( ( alloc_align ( 1 ) ) ) ; // expected-warning {{'alloc_align' attribute only applies to non-K&R-style functions}}
void * test_no_params_zero ( void ) __attribute__ ( ( alloc_align ( 0 ) ) ) ; // expected-error {{'alloc_align' attribute parameter 1 is out of bounds}}
void * test_no_params ( void ) __attribute__ ( ( alloc_align ( 1 ) ) ) ; // expected-error {{'alloc_align' attribute parameter 1 is out of bounds}}
void * test_incorrect_param_type ( float a ) __attribute__ ( ( alloc_align ( 1 ) ) ) ; // expected-error {{'alloc_align' attribute argument may only refer to a function parameter of integer type}}
// argument type
void * test_bad_param_type ( void ) __attribute ( ( alloc_align ( 1.1 ) ) ) ; // expected-error {{'alloc_align' attribute requires parameter 1 to be an integer constant}}
// argument count
2017-04-19 23:52:11 +08:00
void * test_no_fn_proto ( int x , int y ) __attribute__ ( ( alloc_align ) ) ; // expected-error {{'alloc_align' attribute takes one argument}}
void * test_no_fn_proto ( int x , int y ) __attribute__ ( ( alloc_align ( ) ) ) ; // expected-error {{'alloc_align' attribute takes one argument}}
void * test_no_fn_proto ( int x , int y ) __attribute__ ( ( alloc_align ( 32 , 45 , 37 ) ) ) ; // expected-error {{'alloc_align' attribute takes one argument}}
2017-03-31 05:48:55 +08:00
[Sema] Try 2: Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation
Summary:
`alloc_align` attribute takes parameter number, not the alignment itself,
so given **just** the attribute/function declaration we can't do any
sanity checking for said alignment.
However, at call site, given the actual `Expr` that is passed
into that parameter, we //might// be able to evaluate said `Expr`
as Integer Constant Expression, and perform the sanity checks.
But since there is no requirement for that argument to be an immediate,
we may fail, and that's okay.
However if we did evaluate, we should enforce the same constraints
as with `__builtin_assume_aligned()`/`__attribute__((assume_aligned(imm)))`:
said alignment is a power of two, and is not greater than our magic threshold
This was initially committed in c2a9061ac5166e48fe85ea2b6dbce9457c964958
but reverted in 00756b182398b92abe16559287467079087aa631 because of
suspicious bot failures.
Reviewers: erichkeane, aaron.ballman, hfinkel, rsmith, jdoerfert
Reviewed By: erichkeane
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72996
2020-01-24 03:49:50 +08:00
void * passthrought ( int a ) {
return test_ptr_alloc_align ( a ) ;
}
void * align16 ( ) {
return test_ptr_alloc_align ( 16 ) ;
}
void * align15 ( ) {
2020-02-20 21:39:26 +08:00
return test_ptr_alloc_align ( 15 ) ; // expected-warning {{requested alignment is not a power of 2}}
[Sema] Try 2: Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation
Summary:
`alloc_align` attribute takes parameter number, not the alignment itself,
so given **just** the attribute/function declaration we can't do any
sanity checking for said alignment.
However, at call site, given the actual `Expr` that is passed
into that parameter, we //might// be able to evaluate said `Expr`
as Integer Constant Expression, and perform the sanity checks.
But since there is no requirement for that argument to be an immediate,
we may fail, and that's okay.
However if we did evaluate, we should enforce the same constraints
as with `__builtin_assume_aligned()`/`__attribute__((assume_aligned(imm)))`:
said alignment is a power of two, and is not greater than our magic threshold
This was initially committed in c2a9061ac5166e48fe85ea2b6dbce9457c964958
but reverted in 00756b182398b92abe16559287467079087aa631 because of
suspicious bot failures.
Reviewers: erichkeane, aaron.ballman, hfinkel, rsmith, jdoerfert
Reviewed By: erichkeane
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72996
2020-01-24 03:49:50 +08:00
}
The maximal representable alignment in LLVM IR is 1GiB, not 512MiB
In LLVM IR, `AlignmentBitfieldElementT` is 5-bit wide
But that means that the maximal alignment exponent is `(1<<5)-2`,
which is `30`, not `29`. And indeed, alignment of `1073741824`
roundtrips IR serialization-deserialization.
While this doesn't seem all that important, this doubles
the maximal supported alignment from 512MiB to 1GiB,
and there's actually one noticeable use-case for that;
On X86, the huge pages can have sizes of 2MiB and 1GiB (!).
So while this doesn't add support for truly huge alignments,
which i think we can easily-ish do if wanted, i think this adds
zero-cost support for a not-trivially-dismissable case.
I don't believe we need any upgrade infrastructure,
and since we don't explicitly record the IR version,
we don't need to bump one either.
As @craig.topper speculates in D108661#2963519,
this might be an artificial limit imposed by the original implementation
of the `getAlignment()` functions.
Differential Revision: https://reviews.llvm.org/D108661
2021-08-26 16:51:28 +08:00
void * align1073741824 ( ) {
2021-10-07 02:20:44 +08:00
return test_ptr_alloc_align ( 8589934592 ) ; // expected-warning {{requested alignment must be 4294967296 bytes or smaller; maximum alignment assumed}}
[Sema] Try 2: Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation
Summary:
`alloc_align` attribute takes parameter number, not the alignment itself,
so given **just** the attribute/function declaration we can't do any
sanity checking for said alignment.
However, at call site, given the actual `Expr` that is passed
into that parameter, we //might// be able to evaluate said `Expr`
as Integer Constant Expression, and perform the sanity checks.
But since there is no requirement for that argument to be an immediate,
we may fail, and that's okay.
However if we did evaluate, we should enforce the same constraints
as with `__builtin_assume_aligned()`/`__attribute__((assume_aligned(imm)))`:
said alignment is a power of two, and is not greater than our magic threshold
This was initially committed in c2a9061ac5166e48fe85ea2b6dbce9457c964958
but reverted in 00756b182398b92abe16559287467079087aa631 because of
suspicious bot failures.
Reviewers: erichkeane, aaron.ballman, hfinkel, rsmith, jdoerfert
Reviewed By: erichkeane
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72996
2020-01-24 03:49:50 +08:00
}