I just researched the problem, and it comes down to function declarations using assembly. Maybe there some __attribute__ needs to be added and what not, but I kind of stuck ATM, because the assembly code is in a generated header `build/src/glapi/gen/glapi_mapi_tmp.h`.

I would appreciate if anybody acknowledged would tell what part of code is responsible for generating the header above.

I hope to take a closer look on the weekend.

That file is generated by src/mapi/mapi_abi.py
The exact command line used to generate src/glapi/gen/glapi_mapi_tmp.h is:
$ python3 src/mapi/mapi_abi.py --printer glapi src/mapi/glapi/gen/gl_and_es_API.xml > build/src/glapi/gen/glapi_mapi_tmp.h

I'm afraid I can't help with any assembly issue though.

As for LTO, it never worked for me :/
It's been on my "to look at eventually" list, but I haven't yet.

(In reply to Eric Engestrom from comment #2)
> That file is generated by src/mapi/mapi_abi.py
> The exact command line used to generate src/glapi/gen/glapi_mapi_tmp.h is:
> $ python3 src/mapi/mapi_abi.py --printer glapi
> src/mapi/glapi/gen/gl_and_es_API.xml > build/src/glapi/gen/glapi_mapi_tmp.h
> 
> I'm afraid I can't help with any assembly issue though.
> 
> As for LTO, it never worked for me :/
> It's been on my "to look at eventually" list, but I haven't yet.

Oh, thank you very much! For some reason I didn't get a notification about reply, it could've saved me some hours :(

------

To give some update, I reduced it to a minimal testcase, the problem turns out that gcc with flto removes functions implemented in asm. I reported a bug on that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89147 FWIW with clang it works correctly.

Please test the following patch, it should resolve the building problem.

What it does is disables flto for specific files with assembly defined functions. It's okay since from a cursory look there's not much code except the assembly stuff.

I should mention however, for some reason flto-optimized r600g works incorrectly for me. But this is irrelevant to the current problem, and in fact I've stopped using LTO build some months ago for that reason (yeah, LTO build with GCC worked for me too, I don't know why it broke recently). I wanted to bisect that back then, but screwed bisection up, and later I just didn't have motivation or time.

Created attachment 143280 [details] [review]
Fix LTO build with GCC

(In reply to Hi-Angel from comment #5)
> Created attachment 143280 [details] [review] [review]
> Fix LTO build with GCC

(In reply to Hi-Angel from comment #3)
> (In reply to Eric Engestrom from comment #2)
> > That file is generated by src/mapi/mapi_abi.py
> > The exact command line used to generate src/glapi/gen/glapi_mapi_tmp.h is:
> > $ python3 src/mapi/mapi_abi.py --printer glapi
> > src/mapi/glapi/gen/gl_and_es_API.xml > build/src/glapi/gen/glapi_mapi_tmp.h
> > 
> > I'm afraid I can't help with any assembly issue though.
> > 
> > As for LTO, it never worked for me :/
> > It's been on my "to look at eventually" list, but I haven't yet.
> 
> Oh, thank you very much! For some reason I didn't get a notification about
> reply, it could've saved me some hours :(
> 
> ------
> 
> To give some update, I reduced it to a minimal testcase, the problem turns
> out that gcc with flto removes functions implemented in asm. I reported a
> bug on that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89147 FWIW with
> clang it works correctly.

Thank you for taking the time to look into that. I will do a scratch build with the patch tomorrow and some testing! Awesome!

The build fail should be fixed with https://gitlab.freedesktop.org/mesa/mesa/commit/fccc9d3de6cfd1f4d7dbf49af1582b88d143c4cd

Feel free to reopen if it's not the case.