================
@@ -72,3 +72,31 @@ const char16_t *UnicodeUCNString16 =
u"\u00E2\u00AC\U000000DF";
const char32_t *UnicodeUCNString32 = U"\u00E2\u00AC\U000000DF";
//CHECK: [4 x i32] [i32 226, i32 172, i32 223, i32 0]
//CHECK-UTF8: [4 x i32] [i32 226, i32 172, i32 223, i32 0]
+
+
+struct string_view {
+ int S;
+ const char* D;
+ constexpr string_view() : S(0), D(0){}
+ constexpr string_view(const char* Str) : S(__builtin_strlen(Str)), D(Str)
{}
+ constexpr string_view(int Size, const char* Str) : S(Size), D(Str) {}
+ constexpr int size() const {
+ return S;
+ }
+ constexpr const char* data() const {
+ return D;
+ }
+};
+
+constexpr string_view getfoo() { return "\174foo"; }
+
+void function()
+{
+ asm("\174foo");
+ // CHECK: asm{{.*}}@foo
+ // CHECK-UTF8: asm{{.*}}@foo
+ asm((getfoo()));
+ // CHECK: asm{{.*}}|\86\96\96
+ // CHECK-UTF8: asm{{.*}}|foo
----------------
hubert-reinterpretcast wrote:
I find it paradoxical that, in this context, the "obvious" behaviour in a z/OS
environment is achieved only by targeting a non-EBCDIC runtime environment.
For example, the following compiles with `-Xclang -fexec-charset -Xclang UTF-8`
but not `-Xclang -fexec-charset -Xclang IBM-1047`:
```cpp
int main(void) {
asm((string_view("\tnop\n")));
}
```
I suspect we need a conversion of the evaluated "string" _from_ the literal
encoding.
@cor3ntin, I think we knew that `-fexec-charset` support implied such
conversions for at least programmatically-generated `static_assert` strings,
right?
https://github.com/llvm/llvm-project/pull/169803
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
