From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112044 invoked by alias); 21 Aug 2019 14:32:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 112036 invoked by uid 89); 21 Aug 2019 14:32:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1326, HX-Spam-Relays-External:ESMTPA X-HELO: resqmta-po-01v.sys.comcast.net Received: from resqmta-po-01v.sys.comcast.net (HELO resqmta-po-01v.sys.comcast.net) (96.114.154.160) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Aug 2019 14:32:50 +0000 Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-01v.sys.comcast.net with ESMTP id 0RUTioD9npdw90RfMiruao; Wed, 21 Aug 2019 14:32:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1566397968; bh=Ifz4PiQ7NSlV036n1vUrCvD8PEkQJDRH+esrosDfkvk=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=mVayYDnrCULPqlUB8Ag8rMWdA9ziIkepxPO75q8AXuIONxn8rQbvCYoENMDgydOEJ AhM7XXq4jTR/fN55ndxqsyAu8VgQppZyggKM97QhphXPqMgV1hOR4TrlUagdt8XIXU gMSVR3ewoLCI4DPWXt2CQQujC3PzQNWIghqfiF74zFsfUUwciV7UXNjkIg1Hx/yTw1 lBEVNYYrydM14rknu9m6QOc2eQFLHq3cnHZL4cmeG5Ak98UZjjCsvbSZGOhugZHxYf Jagqt0GBR5LiA8l057jHqbVEGvWDYx39S6wZ0sqLGEeBrN4V1q1wHeAkmLOPgpnCl9 HJiaU8b1vl3EQ== Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-po-12v.sys.comcast.net with ESMTPA id 0RfEiJTHYQBoa0RfGiTWCF; Wed, 21 Aug 2019 14:32:48 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrudegfedgjeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheprfgruhhlucfmohhnihhnghcuoehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvtheqnecuffhomhgrihhnpehgnhhurdhorhhgnecukfhppeejfedriedtrddvvdefrddutddunecurfgrrhgrmhephhgvlhhopehpkhhonhhinhhgrdgrkhguvghsihhgnhdrtghomhdpihhnvghtpeejfedriedtrddvvdefrddutddupdhmrghilhhfrhhomhepphgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheprghmohhnrghkohhvsehishhprhgrshdrrhhupdhrtghpthhtohepmhgrrhhkuhhssehmuhgsfhdruggvpdhrtghpthhtohepghgttgesghgttgdrghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=-100;st=legit Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: asking for __attribute__((aligned()) clarification From: Paul Koning In-Reply-To: Date: Wed, 21 Aug 2019 14:32:00 -0000 Cc: =?utf-8?Q?Markus_Fr=C3=B6schle?= , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <0A5DAB14-F153-486B-BA04-6AD500C85E71@comcast.net> References: <1E465204-0887-49CB-8472-196EDE7AAE81@comcast.net> <055f71a6-7b20-eb80-6f0a-d7572c34fa47@arm.com> To: Alexander Monakov X-SW-Source: 2019-08/txt/msg00171.txt.bz2 > On Aug 21, 2019, at 10:28 AM, Alexander Monakov wrot= e: >=20 > On Tue, 20 Aug 2019, "Markus Fr=C3=B6schle" wrote: >=20 >> Thank you (and others) for your answers. Now I'm just as smart as before= , however. >>=20 >> Is it a supported, documented, 'long term' feature we can rely on or not? >>=20 >> If yes, I would expect it to be properly documented. If not, never mind. >=20 > I think it's properly documented in gcc-9: >=20 > https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes.html >=20 > (the "old" behavior where the compiler would neither honor reduced alignm= ent > nor issue a warning seems questionable, the new documentation promises a = more > sensible approach) I agree, but if the new approach generates a warning for code that was writ= ten to the old rules, that would be unfortunate. > In portable code one can also use memcpy to move unaligned data, the comp= iler > should translate it like an unaligned load/store when size is a suitable > constant: >=20 > int val; > memcpy(&val, ptr, sizeof val); >=20 > (or __builtin_memcpy when -ffreestanding is in effect) Yes. But last I tried, optimizing that for > 1 alignment is problematic be= cause that information often doesn't make it down to the target code even t= hough it is documented to do so. paul