Hi Jan, Fwiw I fully agree on your point on outstanding patches.
Now about this patch itself. On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com> wrote: > LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3 because > src/mapi uses unusual mixing of C code and assembly code. The issue > may be present in case of GCC 6.1 as well. > > This is a Mesa bug rather than a compiler bug This is a bold statement without any justification. I'm not saying that the code is correct - just that saying "it's wrong" without saying "why or how" serves little benefit. > (although in an ideal > world the compilation with -flto should fail if and only if normal > compilation fails). > > The error message: > > entry_x86-64_tls.h:61: undefined reference to `x86_64_entry_start' > > Without the patch: > - using "-flto -O2 -DDEBUG" fails with GCC 4.9 and 5.3 > - using "-flto -O3 -DDEBUG" succeeds with GCC 4.9 and 5.3 > - using "-flto -O2 -DNDEBUG" succeeds with GCC 4.9 and 5.3 > Thanks you for the test/analisys. So it seems like that infamous x86_64_entry_start comes again. There's been a few threads and bug reports on the topic. In some it was pointed out that clang was enforcing C11 rule/behaviour, even though -std=c99 was used at the command line. In others there was a suggestion on alternative solution. Can you please search through for the said symbol and compact/summarise things - fold bug reports as duplicates, reference old patches/threads and even opt for the alternative fix ? > The patch assumes that the assembler understands ".hidden" directive. > This is perfectly fine assumption, since we already rely on it in other parts of mesa. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev