5

There are several questions about compiler options. Now I use the following:

-target i386-windows-gnu -mno-sse -c -O3
-target x86_64-windows-gnu -mcx16 -c -O3
-target i386-linux-gnu -mno-sse -c -O3
-target x86_64-linux-gnu -mcx16 -c -O3
-target i386-darwin-gnu -mno-sse -fomit-frame-pointer -c -O3
-target x86_64-macos-gnu -fomit-frame-pointer -c -O3
-target armv7-none-linux-androideabi -mfpu=neon -mfloat-abi=hard -mthumb -fPIC -c -O3
-target aarch64-linux-android -c -O3
-target armv7m-none-ios-gnueabi -mfpu=neon -mfloat-abi=hard -mthumb -c -O3
-target arm64-darwin-gnu -fno-stack-protector -c -O3

There are no complaints only on Linux/Android. For other platforms it gives a warning (https://godbolt.org/z/YhZ5uc):

clang-9: warning: argument unused during compilation: '--gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0' [-Wunused-command-line-argument]
Compiler returned: 0

ARM32 platforms do not support the preserve_most attribute (https://godbolt.org/z/SQRJB2):

<source>:2:21: warning: 'preserve_most' calling convention is not supported for this target [-Wignored-attributes]
void __attribute__((preserve_most)) proc_most(int* x);

But the biggest problem is that Mac/iOS does not support TLS variables (https://godbolt.org/z/6bqjby)!

__thread int x;

int test()
{
    return x;
}


<source>:2:1: error: thread-local storage is not supported for the current target
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Listener
  • 91
  • 7
  • [Duplicate](https://stackoverflow.com/questions/23791060/c-thread-local-storage-clang-503-0-40-mac-osx). – Hans Passant May 28 '20 at 18:28
  • This may help: https://github.com/tensorflow/tensorflow/issues/18356 – Display name May 28 '20 at 18:37
  • 1
    Thanks so much for your attention. But I already googled the answer to my question. And I got the impression that the problem was not solved. Could you take my link to the Godbolt (https://godbolt.org/z/6bqjby) and fix it so that TLS support is there? In addition, I also asked about warnings and the preserve_most attribute. Please pay attention to them too! – Listener May 28 '20 at 19:16
  • Are you writing new code? or are you porting old code that already uses TLS? I would avoid TLS in any new project: TLS is mainly useful for data that has `static` extent, and I try to avoid static data whenever possible. In new code, I would put any per-thread data into a `struct`, and I would give each thread a pointer to it's own private instance of the struct. – Solomon Slow May 29 '20 at 16:34
  • Hello. I am writing a low-level code (memory manager). I really need TLS. – Listener May 29 '20 at 17:21
  • Hello, having written low-level code for memory management extending from bare metal through caching kernel and base user space, I will stake the claim: using TLS is almost always a hack to correct a poor design or implementation. Clear thinking always rids the design of TLS. A great anti-pattern is in clang-blocks -- if the completion is ever executed after the thread that registered it has exitted the program panics. Yet the closure is in no way associated with the thread that registers it. – mevets Jun 02 '20 at 04:23
  • Also, maybe the issue is godbolt; on my macos (16.7.0) clang-900.0.39.2, your snippet compiles just fine; it even generates different code [ movq _x@TLVP(%rip), %rdi; callq *(%rdi))] vs [ movq _x@GOTPCREL(%rip), %rax] if I omit the __thread hackery. – mevets Jun 02 '20 at 04:33

0 Answers0