Re: [PATCH] Set discriminators for call stmts on the same line within the same basic block

Re: [PATCH] Set discriminators for call stmts on the same line within the same basic block

[David Edelsohn]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

This patch causes a bootstrap comparison failure on AIX.  It apparently
does not cause a failure on PPC64BE Linux with the same ABI, so I suspect
that the failure may be related to the way that function aliases are
implemented on AIX, which doesn't have ELF symbol alias semantics.

"This change will also simplify call site lookups since now location with
discriminator will uniquely identify the call site (no callee function name
is needed)."

I will open a PR with more information about the comparison difference now
that I have a work-around to bring AIX back to a bootstrappable state.  Any
thoughts about what could be going wrong?

Thanks, David

Re: [EXTERNAL] Re: [PATCH] Set discriminators for call stmts on the same line within the same basic block

[Eugene Rozenfeld]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

I sent a patch that fixes a bug introduced by this patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603203.html

What you are seeing could have been caused by the same bug since it involves an uninitialized variable.

Eugene


On Oct 10, 2022, at 5:54 PM, David Edelsohn <dje.gcc@gmail.com> wrote:


This patch causes a bootstrap comparison failure on AIX.  It apparently does not cause a failure on PPC64BE Linux with the same ABI, so I suspect that the failure may be related to the way that function aliases are implemented on AIX, which doesn't have ELF symbol alias semantics.

"This change will also simplify call site lookups since now location with discriminator will uniquely identify the call site (no callee function name is needed)."

I will open a PR with more information about the comparison difference now that I have a work-around to bring AIX back to a bootstrappable state.  Any thoughts about what could be going wrong?

Thanks, David