[cfe-dev] Rendering of variable declarations specifying register allocation

[Matthew Fernandez]

OK, will do. While we're on the topic, Clang also seems to remove bracketing around parameters to 
inline asm:

  $ cat foo.c
  void foo() {
    int i = 0;
    asm ("mov %%eax, %%ebx"::"a"(i));
  }
  $ clang -c foo.c
  $ clang -cc1 -ast-print foo.c | tee bar.c
  void foo() {
      int i = 0;
      asm ("mov %%eax, %%ebx" :  : "a" i);
  }
  $ clang -c bar.c
  bar.c:3:38: error: expected '(' after 'asm operand'
      asm ("mov %%eax, %%ebx" :  : "a" i);
                                       ^
  1 error generated.

To me, this is indicative of a second bug. Should I file this one separately as well? My hesitancy 
is because I'm not sure how robust this functionality is intended to be. Should the output of 
-ast-print always be parseable as input to Clang? I would think yes.

On 01/10/14 09:33, Renato Golin wrote:
> Possibly. Opening a bug is definitely worth, though, at least to investigate.
>
> Cheers,
> Renato
>
> On 30 Sep 2014 22:48, "Matthew Fernandez" <matthew.fernandez at gmail.com
> <mailto:matthew.fernandez at gmail.com>> wrote:
>
>     Thanks, Renato. So this is definitely a bug? If so, I'll open a new one at
>     http://llvm.org/bugs/. Just wanted to make sure it wasn't intended behaviour.
>
>     On 01/10/14 06:51, Renato Golin wrote:
>
>         On 30 September 2014 02:57, Matthew Fernandez
>         <matthew.fernandez at gmail.com <mailto:matthew.fernandez at gmail.com>> wrote:
>
>             This seems to be independent of the target platform; at least I get similar
>             results for ARM and x86. What is the intended behaviour here?
>
>
>         Current tip does:
>
>         void foo() {
>               register int x asm("eax");
>         }
>
>         AND
>
>         void foo() {
>               register int x = 1 asm("eax");
>         }
>
>         The first looks correct, but the second looks weird. I don't know
>         what's the expected behaviour, or if this output can be regarded as
>         valid code (I'm guessing not), so in theory, it doesn't matter much.
>         But it does seem an easy fix for this particular case, I think.
>
>         cheers,
>         --renato
>