From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id CEb6KlBe+F91FgAA0tVLHw (envelope-from ) for ; Fri, 08 Jan 2021 13:29:52 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id sLKoJlBe+F/cAgAA1q6Kng (envelope-from ) for ; Fri, 08 Jan 2021 13:29:52 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 347539401C0 for ; Fri, 8 Jan 2021 13:29:52 +0000 (UTC) Received: from localhost ([::1]:37570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxrpu-0002uA-Un for larch@yhetil.org; Fri, 08 Jan 2021 08:29:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxrmK-00018y-Re for guix-devel@gnu.org; Fri, 08 Jan 2021 08:26:10 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:44518) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxrmH-00053Y-Oi; Fri, 08 Jan 2021 08:26:08 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 250143364C27; Fri, 8 Jan 2021 14:26:02 +0100 (CET) Date: Fri, 8 Jan 2021 14:25:57 +0100 From: Danny Milosavljevic To: grischka , Jan Nieuwenhuizen Subject: Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello' Message-ID: <20210108142557.4aee550b@scratchpost.org> In-Reply-To: <5FF806CD.1000405@gmx.de> References: <87im8cvdpa.fsf@gnu.org> <36b3777d90af6fa2e1c1778ba183111e@codethink.co.uk> <87lfd5rpr8.fsf@gnu.org> <20210107211058.40e0813a@scratchpost.org> <20210107212324.36bfd236@scratchpost.org> <20210107235208.04835b95@scratchpost.org> <5FF806CD.1000405@gmx.de> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/_xV=qnK2NV97xDMWHg3g4fV"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, tinycc-devel@nongnu.org, bootstrappable@freelists.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.45 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 347539401C0 X-Spam-Score: -2.45 X-Migadu-Scanner: scn0.migadu.com X-TUID: NEAP0r/+1C/L --Sig_/_xV=qnK2NV97xDMWHg3g4fV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi grischka, Hi Janneke, On Fri, 08 Jan 2021 08:16:29 +0100 grischka wrote: > But no such thing happens in this case. The 'ptr' in init_putv() > comes from >=20 > ptr =3D sec->data + c; >=20 > and it seems that if tcc is doing the right thing then 'c' cannot > be misaligned, and if malloc/realloc on that system is doing the > right thing, then sec->data cannot be misaligned either. So...? How does tcc allocate dynamic memory? I've tried to find out, but tcc_malloc is defined to be "use_tcc_malloc", which I don't find anywhere. Does it use libc malloc for that ? (With MEM_DEBUG defined, tcc_malloc_debug seems to use malloc. But what about without MEM_DEBUG defined ?) If so, is libc malloc supposed to ensure alignment of allocated memory? According to https://man7.org/linux/man-pages/man3/malloc.3.html yes. @Janneke: So our mes libc malloc should be aligning the stuff--but it's not doing it. So it's a bug in our libc. --Sig_/_xV=qnK2NV97xDMWHg3g4fV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/4XWUACgkQ5xo1VCww uqXHvAf/Rxb0Ahrgtd01NtXScWlhB4i6Vz+8CtAmuu0hKDf5LiayLyT68M6YaleR 9kCoOtv2UFIyL1+VgahtQdP68icxz/DVpV8LZOCZbhhzFM5RTCd2IH2aodUWIUz1 1QeFUG+nsOupKzc0qjZgM5oTpXdlzrRH52ijwU0JK1a0TYs3tqPvjyag0T8Xnh5F RgINoyT1FIvwobW4H6JlWzxm7nGst83k3e4n204kLxvWskTsLs9lIitEH2O0Ls18 TcwxKzMP3KBI61k/KSJ1SOAfxW5uG/MKxnrDaKqRmZ9WED6Qn/4ownbyJ3GAPIMa +yM9sKIu8AH/ikSoxt6dct8mxK2+wQ== =y0eY -----END PGP SIGNATURE----- --Sig_/_xV=qnK2NV97xDMWHg3g4fV--