On 6 June 2016 at 13:01, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > 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. > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev