Thanks Jakub.
> > +/* Parse a string literal or constant expression yielding a string.
> > + The constant expression uses extra parens to avoid ambiguity with "x"
> > (expr).
> > +
> > + asm-string-expr:
> > + string-literal
> > + ( constant-expr ) */
> > +
> > +static tree
> > +cp_parser_asm_string_expression (cp_parser *parser)
> > +{
> > + location_t sloc = cp_lexer_peek_token (parser->lexer)->location;
> > +
> > + if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_PAREN))
>
> Why should it be wrapped in ()s?
It's true it's only needed for the constraints, but not here.
> Too long line.
>
> > + string = TREE_OPERAND (string, 0);
> > + if (TREE_CODE (string) == VIEW_CONVERT_EXPR)
> > + string = TREE_OPERAND (string, 0);
> > + if (TREE_CODE (string) != STRING_CST && string != error_mark_node)
> > + {
> > + error_at (sloc, "Expected string valued constant expression for
> > %<asm%>, not type %qT",
> > + TREE_TYPE (string));
>
> Again, too long line, diagnostics should never start with a capital letter,
> but more importantly, this will handle only a small subset of what one can
> construct with constexpr functions, not everything they can return even if
> they return const char * is necessarily a STRING_LITERAL, could be an array
> of chars or something similar, especially if the intent is not just to
> return prepared whole string literals, but construct the template etc. from
> substrings.
>
> Given the https://wg21.link/P2741R3 C++26 addition, I wonder if it wouldn't
That's a good find.
> be much better to stay compatible with the static_assert extension there and
> use similar thing for inline asm.
> See https://gcc.gnu.org/r14-5771 and r14-5956 follow-up for the actual
> implementation.
Makes sense. I will adapt the code.
> One issue is the character set question. The strings in inline asm right
> now are untranslated, i.e. remain in SOURCE_CHARSET, usually UTF-8 (in
> theory there is also UTF-EBCDIC support, but nobody knows if it actually
> works), which is presumably what the assembler expects too.
> Most of the string literals and character literals constexpr deals with
> are in the execution character set though. For static_assert we just assume
> the user knows what he is doing when trying to emit non-ASCII characters in
> the message when using say -fexec-charset=EBCDICUS , but should that be the
> case for inline asm too? Or should we try to translate those strings back
> from execution character set to source character set? Or require that it
> actually constructs UTF-8 string literals and for the UTF-EBCDIC case
> translate from UTF-8 to UTF-EBCDIC? So the user constexpr functions then
> would return u8"insn"; or construct from u8'i' etc. character literals...
I think keeping it untranslated is fine for now. Any translation
if really needed would be a separate feature.
>
> In any case, as has been said earlier, this isn't stage4 material.
Yes that merge can be deferred of course.
-Andi
