Hi everyone,
I'm having some difficulty with fixing issue #33909, and I may have stumbled a more severe problem that might be causing some internal corruption.  I have raised a new issue about it, #33926.  Given the recent e-mail from Pierre, there might be something amiss going on inside the compiler that goes deeper than jump optimisations. A clue that leads me to believe there's internal corruption is that a produced .s file yields an alignment field of ".balign 119,0x90", which should never happen.  Furthermore, letting the debugger continue after it hits the compiler abort exception causes a SIGSEGV in a destructor. I apologise if it is indeed my optimisation that is causing these problems, but I'm at a bit of a loss as to where to go from here.

Gareth

It turns out that it's invalid memory.  Trying to call "ClassName" raises an access violation (other aligns work fine).  There's a dangling pointer somewhere.  I found one in the CMOV optimisation code, but that hasn't fixed the crash.

Gareth

On Fri 29/06/18 10:27 , Martok sent:

A clue that leads me to believe there's internal corruption is that a

produced

.s file yields an alignment field of ".balign 119,0x90", which should

never

happen.

Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a conditional on "tai_align_abstract(hp).aligntype=119" and check what the actual
type of hp is? It could be that at some point a node gets its typ changed in an
invalid way?
aligntype should be either one of 2^[0..5], never something else...

This is where AddressSanitizer support would be *nice*.

A clue that leads me to believe there's internal corruption is that a produced .s file yields an alignment field of ".balign 119,0x90", which should never happen.

Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a conditional on "tai_align_abstract(hp).aligntype=119" and check what the actual type of hp is? It could be that at some point a node gets its typ changed in an invalid way?
aligntype should be either one of 2^[0..5], never something else...

This is where AddressSanitizer support would be *nice*.

So I've made a breakthrough. The memory corruption is due to both parts of the CMOV optimization under OptPass2Jcc, not my Jcc addition (although it might have unintentionally accentuated it). The first part sets p to a dangling pointer, while the 2nd part is a little more complicated, but I'll try to spell everything out once I finish testing my new patch and see if I've eliminated all of my crashes

Gareth

On Fri 29/06/18 10:05 , "J. Gareth Moreton"
sent:
It turns out that it's invalid memory.  Trying to call "ClassName" raises an access violation (other aligns work fine).  There's a dangling pointer somewhere.  I found one in the CMOV optimisation code, but that hasn't fixed the crash.

Gareth

On Fri 29/06/18 10:27 , Martok sent:

A clue that leads me to believe there's internal corruption is that a

produced

.s file yields an alignment field of ".balign 119,0x90", which should

never

happen.

Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a conditional on "tai_align_abstract(hp).aligntype=119" and check what the actual
type of hp is? It could be that at some point a node gets its typ changed in an
invalid way?
aligntype should be either one of 2^[0..5], never something else...

This is where AddressSanitizer support would be *nice*.