Created attachment 36734 [details] zend.i from reduced test case If you attempt to build PHP 7 with -flto, you encounter errors for the 2 register global variables it uses: zend_execute.i:81:32: error: global register variable follows a function definition register const zend_op *opline __asm__("r29"); ^ zend_execute.i:80:36: error: global register variable follows a function definition register zend_execute_data *execute_data __asm__("r28"); ^ I've reduced this with multidelta and the preprocessed files are attached. Reproduce with: gcc -flto -O3 main.i php_cli.i zend_execute.i zend.i Of course this test case won't link or do anything useful, but it hits the LTO issue before getting to the link phase. I did my testing with trunk 230270, but older gcc 4.8.x also has the same problem.
Created attachment 36735 [details] zend_execute.i
Created attachment 36736 [details] php_cli.i
Created attachment 36737 [details] main.i
First off it seems wrong PHP is using global registers. But anyways the problem looks related to partitioning.
The partitioning seems to be involved. If you add -flto-partition=max, you can get past the global register error. However 230270 that I've been using for testing then hits a recursive inlining error that looks a lot like 59626 when trying to compile all of PHP 7. However gcc 5.2 is able to compile the whole thing using -flto-partition=max. I think I need to update my trunk build and then see if the recursive inlining error persists.
The proper partitioning algorithm to use would be 1to1, not max (which is for debugging only). Note that global register vars shouldn't be used with LTO and if they are restricted to just a few compilation units the recommended fix is to build those CUs without -flto. For the particular emitted error the issue is that we fail to materialize global reg vars before other functions. But that's likely not the only issue you might hit with global reg vars. Honza, that's probably caused by "lazy" initializer stuff or so? That is shouldn't materialize_cgraph process those somehow before symtab->compile () gets run?
Testing with 270468, -flto-partition=max does work and the code runs. However -flto-partition=1to1 gets the register global error.
Confirmed.
not really target-dependant since I can reproduce on x86_64 with 5.3.0
I can also reproduce it on x86_64 with 6.3.0
I am also seeing this on current trunk, even with -fno-toplevel-reorder. Bit annoying as this also comes up when testing GCC itself, at least if -flto is part of the torture-options.
*** Bug 86442 has been marked as a duplicate of this bug. ***