public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "alan.lawrence at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59843] ICE with return of generic vector on aarch64
Date: Wed, 09 Jul 2014 15:45:00 -0000	[thread overview]
Message-ID: <bug-59843-4-h4rYPxpM32@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-59843-4@http.gcc.gnu.org/bugzilla/>

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

Alan Lawrence <alan.lawrence at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.lawrence at arm dot com

--- Comment #8 from Alan Lawrence <alan.lawrence at arm dot com> ---
Passing a vector of one double as argument also ICE'd prior to this patch, so
no worries there. Likewise passing such a vector in as varargs.

Regarding struct layout:

*IIUC, gcc generally lays out structs in memory according to the sizes of the
data members, which hasn't changed.

*The AAPCS64 does not mention gcc vector extensions explicitly, only the
architectural concept of short vectors, but if we consider gcc vector
extensions as mapping to these short vectors (as they have done) - then there
is no dependency on gcc's concept of "mode".

*I've verified this with some by-hand testcases, using
typedef double gcc_vector_f64x1 __attribute__ ((__vector_size__ ((8))));
passing and returning by value
    *a small struct of a single gcc_vector_f64x1
    *a small struct of a char and a gcc_vector_f64x1
    *a struct of four gcc_vector_f64x1's (classed as a Homogenous Vector
Aggregate)
....all passed in registers, and
    *a large struct (of over 16 bytes, containing char, gcc_vector_f64x1, char,
gcc_vector_f64x2)
...written to memory and passing a pointer. Also explicitly passing pointers to
structs in memory. In all cases the layout (in registers/memory) is the same
regardless of whether we have V1DFmode or the gcc_vector_f64x1 is just assigned
BLKmode. (FWIW code generation is usually, tho not in all cases, better with
V1DFmode.)

Do you believe the ABI has changed, or are you merely concerned that it may
have? Whilst I can never claim my checks have been exhaustive, at this point I
don't see reason for concern.


  parent reply	other threads:[~2014-07-09 15:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16 14:54 [Bug target/59843] New: " jakub at gcc dot gnu.org
2014-01-16 16:38 ` [Bug target/59843] " pinskia at gcc dot gnu.org
2014-01-16 17:25 ` yufeng at gcc dot gnu.org
2014-03-20 14:46 ` yufeng at gcc dot gnu.org
2014-03-20 19:44 ` yufeng at gcc dot gnu.org
2014-07-02 13:41 ` ktkachov at gcc dot gnu.org
2014-07-08 10:33 ` alalaw01 at gcc dot gnu.org
2014-07-09 10:22 ` jakub at gcc dot gnu.org
2014-07-09 15:45 ` alan.lawrence at arm dot com [this message]
2014-07-09 15:54 ` jakub at gcc dot gnu.org
2014-07-09 16:16 ` alan.lawrence at arm dot com
2014-11-18 16:40 ` alan.lawrence at arm dot com
2014-11-18 16:43 ` jakub at gcc dot gnu.org
2014-11-19 10:12 ` alalaw01 at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-59843-4-h4rYPxpM32@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).