On Feb 9, 2018, Alexandre Oliva <aol...@redhat.com> wrote: > On Feb 9, 2018, Jeff Law <l...@redhat.com> wrote: >> On 02/08/2018 08:53 PM, Alan Modra wrote: >>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: >>>> Here's what I checked in, right after the LVU patch. >>>> >>>> [IEPM] Introduce inline entry point markers >>> >>> One of these two patches breaks ppc64le bootstrap with the assembler >>> complaining "Error: view number mismatch" when compiling >>> libdecnumber. >>> >> I've just passed along a similar failure (.i, .s and command line >> options) to Alex for ppc64 (be) building glibc.
> Thanks. So, I'm told there are more such issues, that non-asm insn > length attrs can't be relied on at this time to be nonzero only when the > actual length is not zero. I wonder... In the previously-posted patch, we still regard call insns are advancing PC. I think that's a safe assumption, but... are there any other kinds of patterns we could recognize that would certainly generate an actual PC-changing insn? How about jump insns? How about insns that are SETs, or PARALLELs containing at least one SET? Does anyone see any risk in recognizing those when the length attr is, conservatively or not, deemed unreliable? Any other paterns we could recognize to that end? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
