2019-06-03 23:57:25 +08:00
|
|
|
// RUN: %clang_cc1 %s -triple i386-pc-linux-gnu -verify -fsyntax-only
|
|
|
|
// RUN: %clang_cc1 %s -triple x86_64-pc-linux-gnu -verify -fsyntax-only
|
|
|
|
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
struct S {
|
|
|
|
~S();
|
2019-06-03 23:57:25 +08:00
|
|
|
int f(int);
|
|
|
|
private:
|
|
|
|
int k;
|
|
|
|
};
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
void test1(int n) {
|
2019-06-03 23:57:25 +08:00
|
|
|
// expected-error@+1 {{cannot jump from this goto statement to its label}}
|
|
|
|
goto DirectJump;
|
|
|
|
// expected-note@+1 {{jump bypasses variable with a non-trivial destructor}}
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
S s1;
|
2019-06-03 23:57:25 +08:00
|
|
|
|
|
|
|
DirectJump:
|
|
|
|
// expected-error@+1 {{cannot jump from this asm goto statement to one of its possible targets}}
|
|
|
|
asm goto("jmp %l0;" ::::Later);
|
|
|
|
// expected-note@+1 {{jump bypasses variable with a non-trivial destructor}}
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
S s2;
|
2019-06-03 23:57:25 +08:00
|
|
|
// expected-note@+1 {{possible target of asm goto statement}}
|
|
|
|
Later:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
struct T { ~T(); };
|
|
|
|
void test2(int a) {
|
2019-06-03 23:57:25 +08:00
|
|
|
if (a) {
|
|
|
|
FOO:
|
|
|
|
// expected-note@+2 {{jump exits scope of variable with non-trivial destructor}}
|
|
|
|
// expected-note@+1 {{jump exits scope of variable with non-trivial destructor}}
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
T t;
|
2019-06-03 23:57:25 +08:00
|
|
|
void *p = &&BAR;
|
|
|
|
// expected-error@+1 {{cannot jump from this asm goto statement to one of its possible targets}}
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
asm goto("jmp %l0;" ::::BAR);
|
2019-06-03 23:57:25 +08:00
|
|
|
// expected-error@+1 {{cannot jump from this indirect goto statement to one of its possible targets}}
|
|
|
|
goto *p;
|
|
|
|
p = &&FOO;
|
|
|
|
goto *p;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// expected-note@+2 {{possible target of asm goto statement}}
|
|
|
|
// expected-note@+1 {{possible target of indirect goto statement}}
|
|
|
|
BAR:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
int test3(int n)
|
2019-06-03 23:57:25 +08:00
|
|
|
{
|
|
|
|
// expected-error@+2 {{cannot jump from this asm goto statement to one of its possible targets}}
|
|
|
|
// expected-error@+1 {{cannot jump from this asm goto statement to one of its possible targets}}
|
|
|
|
asm volatile goto("testl %0, %0; jne %l1;" :: "r"(n)::label_true, loop);
|
|
|
|
// expected-note@+2 {{jump bypasses initialization of variable length array}}
|
|
|
|
// expected-note@+1 {{possible target of asm goto statement}}
|
|
|
|
return ({int a[n];label_true: 2;});
|
|
|
|
// expected-note@+1 {{jump bypasses initialization of variable length array}}
|
|
|
|
int b[n];
|
|
|
|
// expected-note@+1 {{possible target of asm goto statement}}
|
|
|
|
loop:
|
|
|
|
return 0;
|
|
|
|
}
|