[Mesa-dev] [PATCH] mapi: fix LTO compilation
Emil Velikov
emil.l.velikov at gmail.com
Mon Jun 6 14:00:13 UTC 2016
On 6 June 2016 at 13:01, ⚛ <0xe2.0x9a.0x9b at gmail.com> wrote:
> 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.
>
Indeed it's not. Yet one could/should say what is wrong in brief and
highly optional link to relevant discussion and/or other thread for
further information.
>> > (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?
>
Because you're the one having the time and interest in having this
fixed ? Most of the time collaborative software development work like
this:
1 Person A is interested in getting feature/issue X resolved.
2 Person A provides enough, easily accessible information/summary for peers.
3 Peers cross reference and confirm his findings, agree on the
topic/issue proposed and things get accepted.
If you expect peers to do 2 and 3, then things are not going to happen
in the time frame you expected them to.
In general, I will ask you to be less abrupt to almost everything
people say. Please ? Regardless of how correct your point is, it won't
get across. I believe that Patrick (and myself) mentioned something
similar a while back.
>> 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 one that was proposed in the 'other threads', that I suggested
that you give a look and summarise ?
Thanks
Emil
More information about the mesa-dev
mailing list