[cfe-dev] time of inline assembler evaluation in template specialization

[Sebastian Redl]

On 24.06.2011 10:09, Titus von Boxberg wrote:
> Am 23.06.2011 um 22:11 schrieb Douglas Gregor:
>>
>> Diagnosing ill-formed code within a template definition is a quality-of-implementation issue. Clang's philosophy is to diagnose everything that is allowed and reasonable. It's certainly reasonable to check the constraints, but our architecture makes it a bit hard to check the actual statement. That's a QoI issue that could conceivably be fixed in the future.
>>
>> Besides, in the example you give, we're not even talking about a template definition: this is actual code that presumably only works in GCC because one of the inline functions isn't ever emitted. I don't think it makes any sense whatsoever to accept this code.
>>
> Sorry to insist, and sorry if I was unclear.
> There is no "ill formed", "invalid" or whatsoever bad C++ code in my example.
There is ill-formed use of a GCC/Clang extension: you have a clobber 
list that contains registers not valid for the current platform. The 
fact that it happens to be in an inline function of a template 
specialization is irrelevant here.

> It's like in any template instantiation / specialization.
> It only works because the right (specialized) template code gets selected and emitted.
That's not how templates work.
> There is no standard for inline asm,
Yes, there is. It's just that this particular form is an extension of 
the standard form.
>   thus doing it like gcc (which is
> what http://clang.llvm.org/compatibility.html#inline-asm claims to be clang's intention)
> might be a good idea.
> gcc analyzes the syntactical correctness of the asm
> statement during template code parsing, and analyzes the content of
> the asm statement during template instantiation / code generation
More precisely, GCC only validates the asm constraints when actually 
generating code. It has nothing to do with templates. The only 
interesting thing happening here is that GCC doesn't emit the code for 
the inline function if it isn't used.
> (the statement itself is even passed through to gas, not being analyzed by gcc).
> With gcc you can write "r4", "blah" or "eax" in the register lists as long as e.g.
> the input / output lists are well formed (which can be analyzed at the "C++ code level").
> That the register lists take the form of string constants already points at
> the different levels of analysis. The register names are no special words
> at the "C++ code level" (sorry, have no better phrase)
> which is what I feel clang is erroneously trying to make sure.
Asm constraints are a compiler extension. Why shouldn't the compiler 
frontend validate them? Because they are in strings? Consider this:
extern "FooBar" void f();
Should the compiler not complain about this function unless it is used?

> All I want to say is:
> Doing it the gcc way is what I'd suggest for clang.
So you don't want to know about bad asm constraints if you just run an 
-fsyntax-only check over the file? Because that's what delaying the 
check to code generation means. Well, I want to get an error then. So I 
vote for not delaying the check.

>   And you already said that it's
> "a bit hard" to get clang consistent the other way round: to analyze
> the complete content of the asm statement during (template) parsing
> before code actually gets emitted.
Forget templates. They have nothing to do with this.
> The sense to accept this code is because one gains the option of
> using template specialization instead of having to rely on the preprocessor
> to select the right (assembly) code which is perfectly reasonable.
What makes the preprocessor a worse choice than templates here?
> Maybe it's helpful looking at clang's code?
> When time permits I'd try to figure out what would be needed
> to get clang gcc compatible.
You're welcome to try. But unless an -fsyntax-only run still detects 
genuinely invalid uses, I will oppose any patches.

Sebastian