https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Christophe Lyon from comment #11) > My setup uses armeb-none-linux-gnueabihf (as opposed to armeb-eabi as you > report). I have never tried armeb-eabi. > > I am also using qemu as simulator (in user mode, not in system mode). > > The failure in initialise_monitor_handles indicates a problem in the startup > code, while initializing the semi-hosting interface. > > Can you try qemu? Ughhh, off-list I've found that you build glibc/kernel and all that jazz. This is going to take forever if we (ahem I) rebuild the world in order to reproduce. In comment #6 you mention that the regression started between r197671 and r197815. Could you reduce the fortran testcase to the absolute minimum, and then we can take a look at the assembly before r197671 and after r197815? Perhaps start chopping off: i8 = (/(i,i=1,5)/) call isub8(i8(5:1:-1),5) ii8 = (/(5-i+1,i=1,5)/) if (any(ii8 /= i8)) call abort along with the isub8 subroutine, and continue chopping things similarly upward until you get to the abort that fails. Then see if you can chop non-dependent things from the top down until you get to the smallest block that has no problem before 197671 and a problem after 197815 (with -O3 -g -fno-vect-cost-model as suggested before). Once you have a reduced testcase, perhaps we could discern something from the assembly or gimple dumps. Again, please try to get the testcase as small as possible. That will exponentially improve the chances of things getting fixed :).
