From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CDD98385455F; Tue, 22 Nov 2022 17:05:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDD98385455F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669136725; bh=yYCNHNwotCe5TkUsr0l1OF+mixXJNk049sarMgEtJzc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aGs9zrzTFY7Iprjd/oCjaY/dubeg2al24Y67VXPc/5owr/hNBre8eE8NsAvlD7okF 2Z18F3bChu94jZVmC4bFk3RNbQBsD2oCbP/NHNemlpn2rmeBZygNRfjGusH3hxj8zx /T5rTE7dEnCe4JuB3DCHfFGHuOii1LymFHn3BAeQ= From: "jdx at o2 dot pl" 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: Tue, 22 Nov 2022 17:05:25 +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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107801 --- Comment #5 from jdx at o2 dot pl --- (In reply to CVS Commits from comment #4) > The releases/gcc-12 branch has been updated by Jonathan Wakely > : >=20 > https://gcc.gnu.org/g:691012693aaa831e4cd1ab5180195792e32baceb >=20 > commit r12-8926-g691012693aaa831e4cd1ab5180195792e32baceb > Author: Jonathan Wakely > Date: Tue Nov 22 09:53:36 2022 +0000 >=20 > libstdc++: Fix pool resource build errors for H8 [PR107801] >=20=20=20=20=20 > The array of pool sizes was previously adjusted to work for msp430-elf > which has 16-bit int and either 16-bit size_t or 20-bit size_t. The > largest pool sizes were disabled unless size_t has more than 20 bits. >=20=20=20=20=20 > The H8 family has 16-bit int but 32-bit size_t, which means that the > largest sizes are enabled, but 1<<15 produces a negative number that > then cannot be narrowed to size_t. Jonathan, a bit of explanation regarding H8 family =E2=80=93 it has a few "subfamilie= s": 1. H8/300 and H8/300L (L from "low power" AFAIR) =E2=80=93 these are pure 1= 6-bit MCUs, it has 16-bit general purpose registers, sizeof(int) =3D sizeof(size_t) =3D= 2; AFAIK they are not manufactured anymore; I have never used any of them. 2. H8/300H, H8S and H8SX =E2=80=93 Renesas/Hitachi calls them 16-bit but I = call them quasi 32-bit MCUs because they have 32-bit GPRs and instructions, although = data bus width is 16 bit. Here things are more complicated =E2=80=93 sizeof(size= _t) =3D 4 but sizeof(int) may be 2 or 4 depending on -mint32 command line option. To get things even more complicated, these MCUs have also so called "normal mode" = (-mn option) =E2=80=93 it is compatibility mode with H8/300 and obviously in thi= s mode sizeof(int) =3D sizeof(size_t) =3D 2; __NORMAL_MODE__ macro is defined in t= his mode.=