[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[mdaniels at qnx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

mdaniels at qnx dot com  changed:

   What|Removed |Added

 CC||mdaniels at qnx dot com

--- Comment #15 from mdaniels at qnx dot com  ---
Created attachment 40828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40828=edit
An additional testcase for 5.4.0

I have seen a similar problem on 5.4. I applied this fix, just without the
aarch64_can_use_per_function_literal_pools_p() check, and it seems to do the
trick.

Attached is a test case that can reproduce with 5.4, but it not very good as it
is fragile to optimization changes. For example, git bisect landed me on
42b45e8 as a fix and not this change.

$ aarch64-unknown-linux-gnueabi-g++ -g -O2 -fPIE -fstack-protector-strong -c -o
/tmp/test.o /tmp/test.ii
/tmp/ccWVZeQe.s: Assembler messages:
/tmp/ccWVZeQe.s: Error: unaligned opcodes detected in executable segment

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

James Greenhalgh  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from James Greenhalgh  ---
> I do think a new bug should be opened.

OK. PR78561 .

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #13 from Andrew Pinski  ---
(In reply to James Greenhalgh from comment #12)
> I can still trigger this with a testcase using 16-bit floating-point types,
> and the tiny memory model:
> 
>   int
>   main (__fp16 x)
>   {
> __fp16 a = 6.5504e4;
> return (x <= a);
>   }
> 
> gcc foo.c -O3 -mcmodel=tiny -g
> 
> /tmp/ccwJITmo.s: Assembler messages:
> /tmp/ccwJITmo.s: Error: unaligned opcodes detected in executable segment
> 
> In this test case, a call to force_const_mem in ira adds a new 32-bit
> constant in the constant pool, but ultimately doesn't use it. That means
> that when we sweep patterns looking for which constant pool entries to emit,
> we don't mark the unused pattern created by ira, and it doesn't get emitted.
> But, that leaves us with inconsistent information between the offset we
> think we've got, and what we've actually emitted.
> 
> Presumably IRA isn't the only pass at fault here. Anything which eliminates
> a reference to a constant pool entry can cause the constant pool offset
> information to become stale.
> 
> Maybe force_const_mem shouldn't be updating the offset information at all,
> and we should only update that as we make the sweep looking for live pool
> entries? I guess the trouble there is that we don't record the mode of the
> mem in the constant_descriptor_rtx - but if we were to do that it looks like
> we might be able to defer calculating offset until when we actually emit the
> pool. rs6000 might need some changes, but a better interface for their uses
> of get_pool_size looks like it would be "pool_empty_p" anyway.
> 
> I'm not sure of this code though, so I don't know if that would make for a
> clean design.
> 
> If you think this needs to be a separate bug, feel free to reclose this and
> open a new one.

I do think a new bug should be opened.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

James Greenhalgh  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jgreenhalgh at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #12 from James Greenhalgh  ---
I can still trigger this with a testcase using 16-bit floating-point types, and
the tiny memory model:

  int
  main (__fp16 x)
  {
__fp16 a = 6.5504e4;
return (x <= a);
  }

gcc foo.c -O3 -mcmodel=tiny -g

/tmp/ccwJITmo.s: Assembler messages:
/tmp/ccwJITmo.s: Error: unaligned opcodes detected in executable segment

In this test case, a call to force_const_mem in ira adds a new 32-bit constant
in the constant pool, but ultimately doesn't use it. That means that when we
sweep patterns looking for which constant pool entries to emit, we don't mark
the unused pattern created by ira, and it doesn't get emitted. But, that leaves
us with inconsistent information between the offset we think we've got, and
what we've actually emitted.

Presumably IRA isn't the only pass at fault here. Anything which eliminates a
reference to a constant pool entry can cause the constant pool offset
information to become stale.

Maybe force_const_mem shouldn't be updating the offset information at all, and
we should only update that as we make the sweep looking for live pool entries?
I guess the trouble there is that we don't record the mode of the mem in the
constant_descriptor_rtx - but if we were to do that it looks like we might be
able to defer calculating offset until when we actually emit the pool. rs6000
might need some changes, but a better interface for their uses of get_pool_size
looks like it would be "pool_empty_p" anyway.

I'm not sure of this code though, so I don't know if that would make for a
clean design.

If you think this needs to be a separate bug, feel free to reclose this and
open a new one.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #11 from Jeffrey A. Law  ---
Fixed by rth's patch which I committed to the trunk.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 25 23:37:13 2016
New Revision: 234486

URL: https://gcc.gnu.org/viewcvs?rev=234486=gcc=rev
Log:
2016-03-25  Richard Henderson  

PR target/70120
* config/aarch64/aarch64.c (aarch64_asm_output_pool_epilogue): New.
* config/aarch64/aarch64-protos.h: Declare it.
* config/aarch64/aarch64.h (ASM_OUTPUT_POOL_EPILOGUE): New.

PR target/70120
* gcc.target/aarch64/pr70120-1.c: New.
* gcc.target/aarch64/pr70120-2.c: New.
* gcc.target/aarch64/pr70120-3.c: New.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr70120-1.c
trunk/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
trunk/gcc/testsuite/gcc.target/aarch64/pr70120-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/testsuite/ChangeLog

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #9 from Richard Henderson  ---
Ah right, -ffunction-sections.

That requires a more extensive, though less hackish, fix.
Will post a new patch later this afternoon.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #8 from Zdenek Sojka  ---
Created attachment 37987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37987=edit
further testcases

(In reply to Richard Henderson from comment #6)
> Created attachment 37975 [details]
> proposed patch
> 
> This is kind of a hack, but not too bad.
> 
> Zdenek, could you please test on that third testcase that
> you didn't post?  I expect it'll be fixed too, but...

Hello Richard,

Attached are testcases that were found overnight; the command line is always:
$ aarch64-unknown-linux-gnu-gcc @flags-min testcase-min0.i

Testcase 3 has a reasonable low number of arguments and short reproducer code.

The testcases are failing at r234227 + the patch applied (hopefully).

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #7 from Zdenek Sojka  ---
(In reply to Richard Henderson from comment #6)
> Created attachment 37975 [details]
> proposed patch
> 
> This is kind of a hack, but not too bad.
> 
> Zdenek, could you please test on that third testcase that
> you didn't post?  I expect it'll be fixed too, but...

I have most likely deleted it already, but testing r234223 + your patch applied
hasn't triggered that error yet; I will let you know if any problem was found
overnight.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #6 from Richard Henderson  ---
Created attachment 37975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37975=edit
proposed patch

This is kind of a hack, but not too bad.

Zdenek, could you please test on that third testcase that
you didn't post?  I expect it'll be fixed too, but...

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

--- Comment #5 from Richard Henderson  ---
The problem here is the literal pool isn't a multiple of the
instruction size, so the Letext label is "misaligned", which
affects the encoding of the dwarf2 info.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

Zdenek Sojka  changed:

   What|Removed |Added

Summary|[6 Regression][aarch64] |[6 Regression][aarch64] -g
   |-freorder-functions -g  |causes Assembler messages:
   |causes Assembler messages:  |Error: unaligned opcodes
   |Error: unaligned opcodes|detected in executable
   |detected in executable  |segment
   |segment |

--- Comment #4 from Zdenek Sojka  ---
I have another testcase that fails with -Og -fno-dce -fno-forward-propagate
-ffunction-sections -fno-tree-dce -g1 -mcmodel=tiny... so probably not caused
by just -freorder-functions.