[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-08-21 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

Richard Earnshaw  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.4

--- Comment #7 from Richard Earnshaw  ---
Also fixed on 4.7 and 4.8:

4.7: r201904
4.8: r201903


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-08-08 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

--- Comment #6 from Richard Earnshaw  ---
Fixed with

PR target/56979
* arm.c (aapcs_vfp_allocate): Decompose the argument if the
suggested mode for the assignment isn't compatible with the
registers required.


On Trunk: r201598.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-08-07 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
Testing a patch.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-08-06 Thread joseph at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

--- Comment #4 from joseph at codesourcery dot com  ---
On Sat, 3 Aug 2013, rearnsha at gcc dot gnu.org wrote:

> Although the compiler shouldn't ICE, it's arguable that passing over-aligned
> values by value to functions is not supportable (c11, for example, does not
> support over-aligning function arguments even though it does permit
> over-aligning some other objects) and that this case is really an ICE on
> invalid.

I see no such restriction in C11.  You can't use _Alignas directly on a 
parameter, but if you have somehow constructed an over-aligned type (and, 
as I noted on the WG14 reflector some time ago, and more recently in 
N1731, there is no syntax for doing so despite the discussion of such 
types in C11), being a struct or union with an alignment specifier used 
therein, nothing I see prohibits passing it to a function - it's simply 
implementation-defined whether that is a context in which such a type is 
supported.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-08-03 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

--- Comment #3 from Richard Earnshaw  ---
The problem here is that float2 has alignment 8, although this is not it's
natural alignment (which would be 4).

This argument is passed by value to the routine operator-(float, float2), and
the compiler treats float2 as an HFA containing 2 floats; these get allocated
to s1 and s2 under the AAPCS VFP rules.  On entry to the function, the compiler
then tries to store s1 and s2 as a pairwise (64-bit) type to the stack (since
the type is 64-bit aligned) -- the latter fails because for this to work the
64-bit type must start with an even numbered register.

The AAPCS does not describe what happens when arguments do not have their
natural alignment -- most cases will almost certainly not work as expected,
particularly if the alignment is greater than the natural stack alignment.

Although the compiler shouldn't ICE, it's arguable that passing over-aligned
values by value to functions is not supportable (c11, for example, does not
support over-aligning function arguments even though it does permit
over-aligning some other objects) and that this case is really an ICE on
invalid.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-04-16 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-16

 CC||ktkachov at gcc dot gnu.org

  Known to work||4.6.4

 Ever Confirmed|0   |1

  Known to fail||4.7.3, 4.8.0, 4.9.0



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-16 13:13:42 UTC ---

Reproduced on arm-none-eabi with trunk, 4.8, 4.7.

4.6 does not ICE.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-04-16 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979



--- Comment #1 from mgretton at gcc dot gnu.org 2013-04-16 12:45:38 UTC ---

Command line can be further reduced to



$ arm-none-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon

reduced-testcase.c