AaronBallman wrote:
> > > As to why we want to upstream this, any users of the upstream compiler
> > > would need this change to work on z/OS.
> >
> >
> > Any user, really? As best I can tell, this is only for some very specific
> > situations, not for inline assembly in general? (I'm not familiar with the
> > code patterns you're having to deal with; if this is needed by ~100% of
> > folks, that's very different from if it's needed by ~1% of folks.)
>
> Full inline assembly support on z/OS depends on this change. We also plan to
> upstream [#pragma
> map](https://www.ibm.com/docs/en/open-xl-c-cpp-zos/2.2.0?topic=sp-pragma-map)
> after this, which is functionally equivalent to asm labels and is used
> extensively in the z/OS system headers. Both asm strings and #pragma map
> symbol names frequently contain EBCDIC escape sequences to handle variant
> characters across EBCDIC code pages, so both must follow the same string
> parsing and encoding rules.
Thank you for the context! If this is required for supporting system header
code, I think we'll probably have to hold our nose on it. However, one of the
test cases still worries me greatly:
```
constexpr string_view getfoo() { return "\174foo"; }
void function()
{
asm((getfoo()));
}
```
If I understand correctly, this is demonstrating the problem I raised before
where the literal encoding depends on context. e.g., the call to `getfoo()`
within `asm` will be using a different encoding than calling `getfoo()` in
another context, or am I wrong about that?
https://github.com/llvm/llvm-project/pull/169803
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
