Wrong output when code contains asm directives.

[cassioneri]

I was playing with an idea given in [1] which uses asm directives. In summary:

asm(
    ".ifnc %2,%%eax\n\t"
    "mull %2\n\t"
    ".else\n\t"
    "mull %3\n\t"
    ".endif"
...

Given the .ifnc/.else directives, the output should show either the 1st mull instruction or the 2nd one. It shows both. The complete example can be seen in [2]. Notice that when the code is compiled and disassembled (i.e., option 11010 is selected) the output is as expected. Therefore, it seems to be a bug in CE's parser.

I reckon this issue is a corner case but I hope this helps anyway.

[1] https://stackoverflow.com/questions/13617962/can-gcc-emit-different-instruction-mnemonics-when-choosing-between-multiple-alte
[2] https://godbolt.org/z/Zen61D

[apmorton]

This is an issue in the assembly output parser, but it may not be a trivial issue to fix.

If you turn off the assembly directive filtering (button labeled .text) you can see whats going on.
https://godbolt.org/z/vIphR2

Your .ifnc/etc directives are output as is by the compiler.
They aren't evaluated until the assembler itself runs, which is why you are seeing the expected results when using the 11010 button.

The .text button is doing exactly what it is designed to do: filter out all assembler directives. It just happens that you want to see some of them in this particular case.

I don't know how frequently .ifnc/.else/.endif come up, but maybe it would be useful to have an optional whitelist of directives to keep for each compiler.

[cassioneri]

Fair enough. As I said, I reckon this is really a corner case which probably don't affect the vast majority of users. I could suggest implementing a simple parser for .ifc/ifnc/.else/.endif directives but it's too much to ask for a very niche use case. The idea of a whilelist that preserves these directives seems to be a good compromise.

It's a shame that, as far as I'm aware, there's no "as preprocessor" that could be used by CE to process the directives.

Also, feel free to close the issue if you see the "fix" as not worth doing.

[mattgodbolt]

This is an interesting case! I think it'd be fun to support the conditionals as a special "don't filter them" case.

[mattgodbolt]

On second thought, given the backlog, I'm going to close this. I wouldn't be against it, but it's niche enough not to even be on the "maybe one day" pile; sorry!