Thanks for the confirmation that the -g issue is orthogonal. I did start to try to address it but got pulled away by some other things for awhile. I'll see if I can take another stab at it.
In the meantime, could one of the global maintainers take a look at the patch? I don't want it to get too stale, and without these fixes I am unable to get -freorder-blocks-and-partition to work at all. Thanks! Teresa On Thu, Jan 31, 2013 at 6:18 AM, Christophe Lyon <christophe.l...@linaro.org> wrote: > Hello, > > Sorry for the long delay (ref http://patchwork.ozlabs.org/patch/199397/) > > > > On 6 December 2012 20:26, Teresa Johnson <tejohn...@google.com> wrote: >> >> >> >> On Wed, Nov 28, 2012 at 7:48 AM, Christophe Lyon >> <christophe.l...@linaro.org> wrote: >>> >>> I have updated my trunk checkout, and I can confirm that eval.c now >>> compiles with your patch (and the other 4 patches I added to PR55121). >> >> >> good >> >>> >>> >>> Now, when looking at the whole Spec2k results: >>> - vpr passes now (used to fail) >> >> >> good >> >>> >>> - gcc, parser, perlbmk bzip2 and twolf no longer build: they all fail >>> with the same error from gas: >>> can't resolve `.text.unlikely' {.text.unlikely section} - `.LBB171' >>> {.text section} >>> - gap still does not build (same error as above) >>> >>> I haven't looked in detail, so I may be missing an obvious patch here. >> >> >> Finally had a chance to get back to this. I was able to reproduce the >> failure using x86_64 linux with "-freorder-blocks-and-partition -g". >> However, I am also getting the same failure with a pristine copy of trunk. >> Can you confirm whether you were seeing any of these failures without my >> patches, because I believe they are probably a limitation with function >> splitting and debug info that is orthogonal to my patch. >> > Yes I confirm that I see these failures without your patch too; and > both -freorder-blocks-and-partition and -g are present in my > command-line. > And now gap's integer.c fails to compile with a similar error message too. > >>> >>> And I still observe runtime mis-behaviour on crafty, galgel, facerec and >>> fma3d. >> >> >> I'm not seeing this on x86_64, unfortunately, so it might require some >> follow-on work to triage and fix. >> >> I'll look into the gas failure, but if someone could review this patch in >> the meantime given that it does improve things considerably (at least >> without -g), that would be great. >> > Indeed. > >> Thanks, >> Teresa >> > > Thanks > Christophe -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413