[Mesa-dev] [PATCH] mapi: fix LTO compilation

[⚛]

On Mon, Jun 6, 2016 at 1:12 PM, Emil Velikov <emil.l.velikov at 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.0x9b at 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