From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6A56D3858C3A; Mon, 28 Nov 2022 12:10:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A56D3858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669637410; bh=aD0LUGcehwxqJR4dL7cGQt5+h9ntCJBcugQ6LJlbpdw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NytZTZSYlqLUwxTpw+3GxdmyEZKPU7YSURSnWGiHntKphKZ0NTMicm7pkP7K+/tP6 ozCRjNxbpIdkcnWQzdkN54fEHydR2Aldfddd8ublY2o9BNIM/iePDgTOCE0UsrTI1+ zNCAM+VPA9Mq62xI2ZKKYHmXF72u7W7sP7SsXds8= From: "redi at gcc dot 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: Mon, 28 Nov 2022 12:10:09 +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: redi at gcc dot gnu.org 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 #11 from Jonathan Wakely --- I don't think we want to build (parts of) the library with non-default opti= ons like that. It might affect the ABI of the library, and all users would have= to use the same options for their own code. I think we can just use bitset::size_type for the _M_bytes member. We don't need to use uint32_t there if size_t only has 16 bits. We can't allocate th= at much memory anyway. --- a/libstdc++-v3/src/c++17/memory_resource.cc +++ b/libstdc++-v3/src/c++17/memory_resource.cc @@ -505,7 +505,7 @@ namespace pmr } // Allocated size of chunk: - uint32_t _M_bytes =3D 0; + bitset::size_type _M_bytes =3D 0; // Start of allocated chunk: std::byte* _M_p =3D nullptr; @@ -579,7 +579,7 @@ namespace pmr // For 16-bit pointers it's five pointers (10 bytes). // TODO pad 64-bit to 4*sizeof(void*) to avoid splitting across cache li= nes? static_assert(sizeof(chunk) - =3D=3D sizeof(bitset::size_type) + sizeof(uint32_t) + 2 * sizeof(voi= d*)); + =3D=3D 2 * sizeof(bitset::size_type) + 2 * sizeof(void*)); // An oversized allocation that doesn't fit in a pool. struct big_block With that change, I get failures for fs_dir.cc instead: libtool: compile: /home/jwakely/src/gcc/build-h8/./gcc/xgcc -shared-libgcc -B/home/jwakely/src/gcc/build-h8/./gcc -nostdinc++ -L/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/src -L/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/src/.libs -L/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/libsupc++/.l= ibs -nostdinc -B/home/jwakely/src/gcc/build-h8/h8300-elf/normal/newlib/ -isystem /home/jwakely/src/gcc/build-h8/h8300-elf/normal/newlib/targ-include -isystem /home/jwakely/src/gcc/gcc/newlib/libc/include -B/home/jwakely/gcc/h8300-elf/h8300-elf/bin/ -B/home/jwakely/gcc/h8300-elf/h8300-elf/lib/ -isystem /home/jwakely/gcc/h8300-elf/h8300-elf/include -isystem /home/jwakely/gcc/h8300-elf/h8300-elf/sys-include -mn -I/home/jwakely/src/gcc/gcc/libstdc++-v3/../libgcc -I/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/include/h830= 0-elf -I/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/include -I/home/jwakely/src/gcc/gcc/libstdc++-v3/libsupc++ -std=3Dgnu++17 -nostdinc= ++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=3D2 -fdiagnostics-show-location=3Donce -ffunction-sections -fdata-sections -frandom-seed=3Dfs_dir.lo -fimplicit-templates -g -O2 -c /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc -o fs_dir.o In file included from /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc:37: /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h= : In static member function =E2=80=98static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)=E2=80=99: /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h= :210:36: warning: unused parameter =E2=80=98nofollow=E2=80=99 [-Wunused-parameter] 210 | openat(const _At_path& atp, bool nofollow) | ~~~~~^~~~~~~~ /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member funct= ion =E2=80=98bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_co= de&) const=E2=80=99: /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc:147:18: warning: unused parameter =E2=80=98is_directory=E2=80=99 [-Wunused-parameter] 147 | do_unlink(bool is_directory, error_code& ec) const noexcept | ~~~~~^~~~~~~~~~~~ /tmp/ccsGgjxM.s: Assembler messages: /tmp/ccsGgjxM.s:14980: Error: value of 000169ff too large for field of 2 by= tes at 00000010 /tmp/ccsGgjxM.s:14990: Error: value of 00025a7b too large for field of 2 by= tes at 0000002a /tmp/ccsGgjxM.s:15018: Error: value of 0002e814 too large for field of 2 by= tes at 00000065 /tmp/ccsGgjxM.s:15024: Error: value of 0002e805 too large for field of 2 by= tes at 00000073 /tmp/ccsGgjxM.s:15033: Error: value of 00030c1c too large for field of 2 by= tes at 00000083 (and hundreds more assembler errors like that)=