linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Rong Chen <rong.a.chen@intel.com>,
	Patrick Menschel <menschel.p@posteo.de>
Cc: kernel test robot <lkp@intel.com>,
	kbuild-all@lists.01.org, linux-kernel@vger.kernel.org,
	linux-can <linux-can@vger.kernel.org>
Subject: Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(struct canfd_frame, len) || offsetof(struct can_frame, data) != offsetof(struc...
Date: Tue, 23 Mar 2021 12:36:55 +0100	[thread overview]
Message-ID: <a5599800-53f4-c53f-abcc-e166ea9028b9@rasmusvillemoes.dk> (raw)
In-Reply-To: <7ff6bfd3-6b4b-045a-abb7-485927909587@hartkopp.net>

On 23/03/2021 08.45, Oliver Hartkopp wrote:

> IMO we facing a compiler problem here - and we should be very happy that
> the BUILD_BUG_ON() triggered an issue after years of silence.
> 
> I do not have a good feeling about what kind of strange effects this
> compiler issue might have in other code of other projects.
> 
> So I would explicitly suggest NOT to change the af_can.c code to work
> around this compiler issue.
> 
> Let the gcc people fix their product and let them thank all of us for
> detecting it.

I'm sure you'd be eligible for a full refund in case this was a bug in
gcc. It is not. It's a pretty clear ABI requirement for (at least some
flavors of) ARM:

https://stackoverflow.com/questions/43786747/struct-layout-in-apcs-gnu-abi

and more directly from the horse's mouth:

https://developer.arm.com/documentation/dui0067/d/arm-compiler-reference/c-and-c---implementation-details/structures--unions--enumerations--and-bitfields

Field alignment

    Structures are arranged with the first-named component at the lowest
address. Fields are aligned as follows:

        A field with a char type is aligned to the next available byte.

        A field with a short type is aligned to the next even-addressed
byte.

        Bitfield alignment depends on how the bitfield is declared. See
Bitfields in packed structures for more information.

        All other types are aligned on word boundaries.

That anonymous union falls into the "All other types" bullet.

__packed is the documented and standard way to overrule the
compiler's/ABI's layout decisions.

Rasmus

  parent reply	other threads:[~2021-03-23 11:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 20:43 include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(struct canfd_frame, len) || offsetof(struct can_frame, data) != offsetof(struc kernel test robot
2021-03-21 14:19 ` Oliver Hartkopp
2021-03-22  8:52   ` [kbuild-all] " Rong Chen
2021-03-22 16:24     ` Oliver Hartkopp
2021-03-23  2:54       ` Rong Chen
2021-03-23  5:46         ` Vincent MAILHOL
2021-03-23  6:06           ` Rong Chen
2021-03-23  7:26             ` Patrick Menschel
2021-03-23  7:34         ` Marc Kleine-Budde
2021-03-23  7:45           ` Oliver Hartkopp
2021-03-23  8:32             ` Oliver Hartkopp
2021-03-23  8:54               ` Marc Kleine-Budde
2021-03-23  8:59                 ` Rong Chen
2021-03-23  9:35                   ` Rong Chen
2021-03-23 11:36             ` Rasmus Villemoes [this message]
2021-03-23 12:49               ` Oliver Hartkopp
2021-03-23 14:00                 ` Rasmus Villemoes
2021-03-23 18:59                   ` Oliver Hartkopp
2021-03-23 20:54                     ` Rasmus Villemoes
2021-03-24  9:09                       ` Oliver Hartkopp
2021-03-24  9:57                         ` Marc Kleine-Budde
2021-03-29  7:01                   ` Marc Kleine-Budde

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=a5599800-53f4-c53f-abcc-e166ea9028b9@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=menschel.p@posteo.de \
    --cc=mkl@pengutronix.de \
    --cc=rong.a.chen@intel.com \
    --cc=socketcan@hartkopp.net \
    /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 NNTP newsgroup(s).