fix backslashes in path used for asm_tests

[folkertdev]

fixes #622

The problem is with escaping the --compiletest-rustc-args argument. Use of \ and " or even ' does not work because of how this string is eventually used.

With this change I can actually run the asm tests

failures:
    [assembly] tests/assembly/asm/global_asm.rs
    [assembly] tests/assembly/asm/inline-asm-avx.rs

test result: FAILED. 0 passed; 2 failed; 50 ignored; 0 measured; 465 filtered out; finished in 57.76ms

Some tests failed in compiletest suite=assembly mode=assembly host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
help: ignored 1 up-to-date test; use `--force-rerun` to prevent this

If it's useful I can re-enable this test in run_all, but only 2 tests actually run (the rest is ignored) and those both fail right now.

[GuillaumeGomez]

That was a very stupid bug. Thanks for the fix!

[antoyo]

I remember that these tests were disabled because some of them required a feature unavailable in GCC, which is the ability to parse the asm and output a single asm syntax.

@GuillaumeGomez: Was there something else needed by these tests?

[GuillaumeGomez]

We cannot pick which asm syntax we want to use, hence why we can't run (most of) the asm tests.

[folkertdev]

yeah, the two errors that I see are firstly

libgccjit.so: error: unrecognized command-line option ‘--x86-asm-syntax=intel’

so for most x86 tests that's game over. And then the other one seems to have basically the same issue

/home/folkertdev/rust/rustc_codegen_gcc/build/rust/tests/assembly/asm/inline-asm-avx.rs:15:12: error: CHECK: expected string not found in input
 // CHECK: vbroadcastss (%{{[er][a-ds0-9][xpi0-9]?}}), {{%ymm[0-7]}}
           ^
/home/folkertdev/rust/rustc_codegen_gcc/build/rust/build/x86_64-unknown-linux-gnu/test/assembly/asm/inline-asm-avx/inline-asm-avx.s:12:9: note: scanning from here
convert:
        ^
/home/folkertdev/rust/rustc_codegen_gcc/build/rust/build/x86_64-unknown-linux-gnu/test/assembly/asm/inline-asm-avx/inline-asm-avx.s:15:2: note: possible intended match here
 vbroadcastss ymm0, [rsi]

I think this is just a difference between intel and at&t syntax (the argument order is swapped).

---

It seems kind of important to me that you test the assembly output of a new codegen backend though? So long term some solution is needed I'd think?

[GuillaumeGomez]

It's kinda planned but it'll have to wait for the GCC backend to be fully integrated into rustc pipeline, which isn't the case currently.

[antoyo]

I don't believe we'll ever be able to support this since AFAIK, GCC won't ever parse asm.

[GuillaumeGomez]

There is inline assembly iirc. Just no support for other syntaxes.

[folkertdev]

No parsing of asm as such is happening. The FileCheck tool just applies a bunch of rules/regexes to the assembly output text. But the rust tests implicitly assume an asm syntax. And if gcc does not use the same syntax, you get lots of unhelpful failures.

[antoyo]

No parsing of asm as such is happening. The FileCheck tool just applies a bunch of rules/regexes to the assembly output text. But the rust tests implicitly assume an asm syntax. And if gcc does not use the same syntax, you get lots of unhelpful failures.

I was talking about the flag --x86-asm-syntax=intel: it does change the output asm syntax: even when using inline asm for the other syntax, it will output the syntax selected by the flag.

[antoyo]

Is this PR ready to be merged?

[folkertdev]

eh, yes?

---

I was talking about the flag --x86-asm-syntax=intel

ah right. I think that one is rare though, and it would be easy to refactor the test suite to minimize its use

[antoyo]

Thanks for your contribution!

@folkertdev: are there tests failing that don't use this flag?

[folkertdev]

yes. Only two tests actually run, and they both fail

    [assembly] tests/assembly/asm/global_asm.rs
    [assembly] tests/assembly/asm/inline-asm-avx.rs

the top one runs into the flag not existing. the bottom one is runs into this check

// CHECK: vbroadcastss (%{{[er][a-ds0-9][xpi0-9]?}}), {{%ymm[0-7]}}

failing on this assembly emitted by GCC

vbroadcastss ymm0, [rsi]

So GCC emits the assembly verbatim using intel syntax, while the test is written to use AT&T syntax (e.g. vbroadcastss (%rsi), %ymm0). So, same flavor of issue, but it's not using the flag.

The rest of the tests is ignored

test [assembly] tests/assembly/asm/sparc-types.rs#sparcv8plus ... ignored, ignored when the sparc LLVM component is missing
test [assembly] tests/assembly/asm/wasm-types.rs ... ignored, ignored when the webassembly LLVM component is missing

[antoyo]

Interesting. The test inline-asm-avx.rs doesn't seem to specify that it should use the AT&T syntax. Not sure why it checks using this syntax.

[folkertdev]

AT&T is the default, so the test author just tests to use that. I also just noticed that this command runs the tests in "tests/assembly/asm", while there are way more tests in "tests/assembly", specifically ones that don't rely on inline assembly, but just check that constructs get lowered correctly.

[antoyo]

According to the doc:

On x86, the .intel_syntax noprefix mode of GAS is used by default.

[folkertdev]

That's confusing, but we can see that the default is AT&T in the test suite, right? you have to explicitly pick intel if you want it (roughly half of the x86 tests seem to do that).

[antoyo]

Perhaps the output by --emit=asm uses the AT&T syntax by default?
In the source code of cargo asm, they uses an additional argument for the Intel syntax: https://github.com/gnzlbg/cargo-asm/blob/577f890ebd4a09c8265710261e976fe7bfce8668/src/build.rs#L82

[folkertdev]

yes exactly.

[antoyo]

If I understand correctly, the normal compilation uses the Intel syntax, while --emit=asm uses AT&T.
That's confusing.

[folkertdev]

inline asm blocks also accept intel by default, and will give syntax errors when trying to use AT&T. Anyway, some way of specifying the format is needed that knows how the test is invoked (gcc or llvm) and then passes the right format specifier