On Mon, Jun 6, 2016 at 1:12 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > > 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.
mesa-dev isn't a mailing list about C/C++ compilers. > > (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 http://www.google.sk/search?q=x86_64_entry_start+globl&sitesearch=lists.freedesktop.org My patch proposes the combination of ".globl" and "extern char". My quick search (which may be incomplete) didn't find any previous occurrences to this combination in mesa-dev. > and > compact/summarise things - fold bug reports as duplicates, reference > old patches/threads No. Why would I do that? > and even opt for the alternative fix ? Which alternate fix do you mean? You wrote "THE alternative fix" which implies that you mean a particular 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