Re: [RFC] New pragma exec_charset

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Oct 20, 2017 at 09:48:38AM +0200, Richard Biener wrote:
> How does it work semantically to have different exec charsets?  That is,
> if "strings" flow from a region with one -fexec-charset setting to a region
> with another one is that undefined behavior?  Do we now require
> external function declarations to be in the proper region (declared under
> the appropriate exec charset flag)?  This would mean that passing
> the exec charset in effect as additional argument isn't a possibility.
> 
> Or do we have to treat -fexec-charset similar to -frounding-math, that is,
> we can't ever _interpret_ any string in the compiler?  [unless -fexec-charset
> is the same everywhere]
> 
> I think the -frounding-math route is probably the easiest (and wisest
> given the quite low test coverage we'll get) route.  Thus, add a -fmixed-charset
> flag and reject any exec-charset attribute/pragma if that flag is not set?
> With LTO we could always add this and/or merge -fexec-charset flags
> appropriately,
> injecting -fmixed-charset in case TUs use different settings.

It wouldn't have to be an option, simply mark in cfun all functions that
have more than one exec charset and give up on all optimizations/warnings
that require to read the characters and merge that unknown exec_charset
flag during inlining etc.  Though, that might still not be enough, e.g.
the whole function might have one exec charset, but a global const char []
variable might have another one and during optimization we might be looking
at that.  So perhaps it would need to be a per-TU flag merged during LTO.

	Jakub