From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id CEyaJQ+D+F/nHgAA0tVLHw (envelope-from ) for ; Fri, 08 Jan 2021 16:06:39 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GMtQIQ+D+F99RAAAbx9fmQ (envelope-from ) for ; Fri, 08 Jan 2021 16:06:39 +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 118C89401C0 for ; Fri, 8 Jan 2021 16:06:39 +0000 (UTC) Received: from localhost ([::1]:35738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxuHd-0000Sy-T6 for larch@yhetil.org; Fri, 08 Jan 2021 11:06:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxtVh-0004oQ-K2 for guix-devel@gnu.org; Fri, 08 Jan 2021 10:17:09 -0500 Received: from joooj.vinc17.net ([2001:4b99:1:3:216:3eff:fe20:ac98]:57298) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxtVf-0004N5-4T; Fri, 08 Jan 2021 10:17:04 -0500 Received: from smtp-zira.vinc17.net (128.119.75.86.rev.sfr.net [86.75.119.128]) by joooj.vinc17.net (Postfix) with ESMTPSA id E303939E; Fri, 8 Jan 2021 16:16:51 +0100 (CET) Received: by zira.vinc17.org (Postfix, from userid 1000) id C2192C2050D; Fri, 8 Jan 2021 16:16:51 +0100 (CET) Date: Fri, 8 Jan 2021 16:16:51 +0100 From: Vincent Lefevre To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] [bootstrappable] Re: Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello' Message-ID: Mail-Followup-To: tinycc-devel@nongnu.org, "bootstrappable@freelists.org" , grischka , Jan Nieuwenhuizen , "guix-devel@gnu.org" 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> <20210108142557.4aee550b@scratchpost.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.0.4+67 (a3db7ccb) vl-132933 (2021-01-03) Received-SPF: none client-ip=2001:4b99:1:3:216:3eff:fe20:ac98; envelope-from=vincent@vinc17.net; helo=joooj.vinc17.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 08 Jan 2021 10:57:16 -0500 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" , grischka , "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.35 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: 118C89401C0 X-Spam-Score: -2.35 X-Migadu-Scanner: scn1.migadu.com X-TUID: zF0HgeHMsS/r On 2021-01-08 13:36:26 +0000, Orians, Jeremiah (DTMB) wrote: > > 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. > > Looks like you'll have to waste 3.7bytes on average per malloc to > always pad to the 8byte boundary. Note that it's an 8-byte boundary for 32-bit systems, but a 16-byte boundary for 64-bit systems: https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html And about the average waste, this depends on other factors (the main one may be that the block size is often a multiple of some power of two). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)