https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
--- Comment #10 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> --- (In reply to Eric Botcazou from comment #9) > > Uggh - these ancient options in the backend. mapcs-frame is quite ancient > > and isn't really something that's tested very often, no wonder it's rotting. > > In this case we seem to have regressed something that worked earlier, > > Yes, indirect tailcalls used to be rejected by the back-end. Indeed. > > > I do wonder if the fix here is to just turn IP regnum into a fixed register > > in > > the presence of mapcs-frame. > > This would only turn the problem into an ICE here. Hmmmm not sure. > I think this needs to be > fixed in arm_function_ok_for_sibcall, either in a big-hammer-ish way > (disable again indirect tailcalls with -mapcs-frame) or in a more precise > way. Sure that would work too but it feels like a rather big hammer. In the absence of anything else, I'm happy to review a patch if someone could post this upstream and get it tested, I won't have time to work on this bug for the next week or 2. While we are here, what's the thought on deprecating mapcs-frame in the arm-wrs-vxworks community ? It is not really something that's part of the ABI (it predates EABI), doesn't work with Thumb2 and not tested regularly and we keep finding issues with this. Can arm-wrs-vxworks move to using the EHABI information and unwinding information from there to handle such backtraces - after all libunwind has the capability now for unwinding ARM EHABI tables if you needed a generic library to do this ? regards Ramana
