From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 1298E385800A; Sun, 27 Nov 2022 02:32:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1298E385800A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669516325;
	bh=yR+CqaLdpCkVof7iPQCTZtziELPFJ7LlSWTWuNTYdU0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fsJM6KnVqQL9sbK+c9ronfiGGUXoki1Q6Xk2pHrQ4Gu4dpbej/oftBbtoaAomEcNY
	 sASlhL4Jts2qcmKBuFKApeTN05CxHCdo0ncxICRq1VU+MJlRYGb5jDHBntpj5ZwHaM
	 ibM8NSE4BBGxcnFk58LUfYLS3/oIQVWPp/xtIKl4=
From: "jdx at o2 dot pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/107801] Building cross compiler for H8 family fails
 in libstdc++ (c++17/memory_resource.cc)
Date: Sun, 27 Nov 2022 02:31:59 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 12.2.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jdx at o2 dot pl
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107801-4-ZJZNeYTVCO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107801-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107801-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #9 from Jan Dubiec <jdx at o2 dot pl> ---
I think I have found why the static assertion fails as mentioned in my prev=
ious
comment. Surprisingly, for H8/300H, H8/S and H8/SX in normal mode 32-bit
integers and floats are aligned on 4-byte boundaries.

Let's consider following structure:

struct foo
{
        uint32_t i;
        uint16_t j;
};

In advanced mode sizeof(struct foo) is 8. In normal mode, i.e. when the cod=
e is
compiled with -mn, the size is still 8 although one could expect it to be 6
(and that is why the assertion fails). In order to the size be 6 bytes,
-malign-300 must be used along with -mn.

So the natural solution seems to be adding -malign-300 to the compiler opti=
ons
when libstdc++ is built in normal mode.

BTW. I do not even get why 4-byte boundaries are used at all. According to
H8/300H and H8/S software manuals (I didn't check H8/SX) "The CPU can access
word data and longword data in memory, but word or longword data must begin=
 at
an even address." (longword is 32-bit word in Renesas' nomenclature). They =
do
not state that alignment must be 4 bytes for 32-bit integers and floats.=