> I tried to figure out why things had been done in this > slightly convoluted manner and failed. It seems to me that > this is easily represented with the individual instructions.
I wanted to avoid the back-and-forth game on the CFA offset and emit the same CFIs as in the normal case. Your solution is probably better in the end, but please add a comment in sparc_flat_expand_prologue explaining why we play this game to establish the frame. > A comment indicated that there had been problems with the > copy to %o7 being deleted. Elsewhere we have successfully > used a naked USE pattern to keep such things from being > deleted. Fine, thanks for cleaning up the whole thing. > Unfortunately, I can't seem to get -mflat to bootstrap on > gcc62 (as sparc-linux, not sparc64) either before or after > this patch, so I'm not sure what sort of pre-requisite I'm > missing in order to be able to test it... Just run the C testsuite, bi-arch preferably, with -mflat; it should be clean. It contains some unwinding tests. You can also run the C++ testsuite, but there are about 20 (known) failures without -mflat multilibs. I didn't try a bootstrap, but it probably doesn't work because the models are fully intermixable only if you insert flushw instructions at the boundaries. -- Eric Botcazou
