public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691 Date: Thu, 01 Dec 2011 10:26:00 -0000 [thread overview] Message-ID: <bug-50325-4-DGvq96NOSS@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-50325-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 10:25:33 UTC --- well.. sorry, that might be a bogus comment - it depends on whether the following can be interpreted to allow a different layout on the stack from 'normal' memory. Since the embedding alignment of bitfields doesn't seem to be specifically referenced in the struct. layout section (pp10 in the pdf) - other than saying that it's 'natural' if the first element and 4 bytes otherwise. but page14 in the pdf of the ABI doc has: 1. All nonvector parameters are aligned on 4-byte boundaries. 2. Vector parameters are aligned on 16-byte boundaries. 3. Noncomposite parameters (that is, parameters that are not arrays or data structures) smaller than 4 bytes occupy the high-order bytes of their 4-byte area. 4. Composite parameters (arrays, structures, and unions) 1 or 2 bytes in size occupy the low-order bytes of their 4-byte area. They are preceded by padding to 4 bytes. This rule is inconsistent with other 32-bit PowerPC binary inter faces. In AIX and Mac OS 9 (and earlier), padding bytes always follow the data structure even in the case of composite parameters smaller than 4 bytes. 5. Composite parameters 3 bytes or larger in size occupy the high-order bytes of their 4-byte area. They are followed by padding to make a multiple of 4 bytes, with the padding bytes being undefined. again no specific mention of bitfields ...
next prev parent reply other threads:[~2011-12-01 10:26 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-08 10:32 [Bug middle-end/50325] New: " krebbel at gcc dot gnu.org 2011-09-08 10:51 ` [Bug middle-end/50325] " dominiq at lps dot ens.fr 2011-09-08 12:10 ` [Bug middle-end/50325] [4.7 Regression] " rguenth at gcc dot gnu.org 2011-09-08 12:35 ` rguenth at gcc dot gnu.org 2011-09-14 7:38 ` krebbel at gcc dot gnu.org 2011-09-14 8:50 ` krebbel at gcc dot gnu.org 2011-09-14 13:33 ` dominiq at lps dot ens.fr 2011-09-14 18:04 ` dominiq at lps dot ens.fr 2011-09-14 18:29 ` dominiq at lps dot ens.fr 2011-09-16 14:46 ` dominiq at lps dot ens.fr 2011-10-10 12:36 ` rguenth at gcc dot gnu.org 2011-11-16 9:50 ` krebbel at gcc dot gnu.org 2011-11-16 10:22 ` krebbel at gcc dot gnu.org 2011-11-17 15:19 ` dje at gcc dot gnu.org 2011-11-17 15:21 ` dje at gcc dot gnu.org 2011-11-17 15:53 ` krebbel at gcc dot gnu.org 2011-11-17 16:38 ` dominiq at lps dot ens.fr 2011-11-19 16:08 ` iains at gcc dot gnu.org 2011-11-19 19:29 ` ebotcazou at gcc dot gnu.org 2011-11-20 12:32 ` rsandifo at gcc dot gnu.org 2011-11-21 0:55 ` oleg.endo@t-online.de 2011-11-21 8:42 ` iains at gcc dot gnu.org 2011-11-21 22:03 ` davem at gcc dot gnu.org 2011-11-22 9:49 ` krebbel at gcc dot gnu.org 2011-12-01 9:22 ` rguenther at suse dot de 2011-12-01 10:11 ` iains at gcc dot gnu.org 2011-12-01 10:26 ` iains at gcc dot gnu.org [this message] 2011-12-01 11:08 ` iains at gcc dot gnu.org 2011-12-01 11:26 ` rguenther at suse dot de 2012-01-08 13:00 ` dominiq at lps dot ens.fr 2012-01-08 17:26 ` ebotcazou at gcc dot gnu.org 2012-01-15 13:40 ` dominiq at lps dot ens.fr 2012-01-16 17:06 ` dje at gcc dot gnu.org 2012-01-16 21:32 ` rsandifo at gcc dot gnu.org 2012-01-16 22:05 ` ebotcazou at gcc dot gnu.org 2012-01-16 22:21 ` jakub at gcc dot gnu.org 2012-01-16 23:06 ` ebotcazou at gcc dot gnu.org 2012-01-17 11:36 ` jakub at gcc dot gnu.org 2012-01-17 12:09 ` rsandifo at gcc dot gnu.org 2012-01-17 22:10 ` rsandifo at gcc dot gnu.org 2012-01-17 23:46 ` rsandifo at gcc dot gnu.org 2012-01-23 10:12 ` amodra at gmail dot com 2020-03-13 9:10 ` marxin 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-50325-4-DGvq96NOSS@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: linkBe 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).