zig cc: build error when targeting `wasm32-freestanding`

[LucasThompson]

Supplying -target wasm32-freestanding to either zig cc or zig c++ results in an error like the following:

error: option
      '-atomics,-bulk-memory,-exception-handling,-multivalue,-mutable-globals,-nontrapping-fptoint,-sign-ext,-simd128,-tail-call,-unimplemented-simd128'
      cannot be specified with '-target-feature'

clang doesn't seem to like the comma separated list. passing each value separately seems to fix the issue, i.e.

-target-feature -atomics -target-feature -bulk-memory -target-feature -exception-handling -target-feature -multivalue -target-feature -mutable-globals -target-feature -nontrapping-fptoint -target-feature -sign-ext -target-feature -simd128 -target-feature -tail-call -target-feature -unimplemented-simd128

vs the generated:

-target-feature -atomics,-bulk-memory,-exception-handling,-multivalue,-mutable-globals,-nontrapping-fptoint,-sign-ext,-simd128,-tail-call,-unimplemented-simd128

In the cc1 TableGen file target-feature is defined as Separate (An option which is followed by its value), which seems consistent with the error from the wasm example.

However, the comma separated list does appear to work for all other targets I have tried. So, I have no idea what is going on.

I am using the macOS binary from the website, corresponding to commit 8e9e126d41cbca619a2a4658fb38d10120388e8f

[andrewrk]

This seems like an issue with the wasm backend in llvm or clang. My suggestion is to:

• file an upstream bug report in the hopes that this target can be modified to match all the other targets
• don't wait for it to be fixed, add target_requires_separate_target_feature_flags to target.hpp/target.cpp and make it only true for wasm. Then update add_cc_args to pass the options separately when this is true.

This is a contributor friendly issue, if anyone wants to take a stab at it.

[georgeroman]

I would like to take this one if no one else is working on it.

[FireFox317]

@georgeroman Have you read the discussion in the IRC about this issue?

[LucasThompson]

does anybody know why it is expected for the comma separated list to work?

sure, it happens to work - but is that somehow relying on a private implementation detail?

from the TableGen file and tests from llvm, it looks designed to accept the values separately. (note, the linked test there isn't testing the flag, it just happens to invoke cc1 in the RUN line)

also compare the following flags as documented in clang -cc1 --help:

-target-feature <value> Target specific attributes
vs
-cl-ext=<value> OpenCL only. Enable or disable OpenCL extensions. The argument is a comma-separated sequence of one or more extension names, each prefixed by '+' or '-'.

passing them separately also works for all backends.

[andrewrk]

passing them separately also works for all backends.

OK I think this is a good reason to unconditionally pass them separately for all backends.

It's a bit annoying since now the command line will look like this for just 2 items:

-Xclang -target-feature -Xclang foo -Xclang -target-feature -Xclang bar

But so be it, we must communicate this information to clang.