From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16821 invoked from network); 13 Sep 2020 17:43:00 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 13 Sep 2020 17:43:00 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 79B539CAFB; Mon, 14 Sep 2020 03:42:57 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0CE849CAE7; Mon, 14 Sep 2020 03:42:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="CfwtAxuc"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6DB699CAE7; Mon, 14 Sep 2020 03:42:22 +1000 (AEST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by minnie.tuhs.org (Postfix) with ESMTPS id CDDDE9CAE6 for ; Mon, 14 Sep 2020 03:42:21 +1000 (AEST) Received: by mail-vs1-f50.google.com with SMTP id c127so8314630vsc.1 for ; Sun, 13 Sep 2020 10:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JpqzPNSppYf32xY0LMaFvlBKdpLKvX9x4lVnPrZrz4I=; b=CfwtAxuceNU3lJ2v/KkaMc50BOCpxjXiBZxKOCDT247WHAW01NRA0Go8wKgoBf0dvz JosQ6P8f2202XrLaU2IRpy/GMXf4K3LILowWcaj+vGvyo4I5HJvln1lGzGPyOM6a/arZ k97YRJr1nVIWO1BuJJ4v7RIeAN21kd+lB6/hN17Eb3AR7jeoTXAz/+0uUMYNqFA2ON6x 5LGwvcKUMdK/5Vv0vmKP5hRE6XtCKK+dyu6MfZQNENYs72g+lieLaLCTD8vvXrPVzuaS JfVl0umUVUlle/NvFQ9P/qEhS9G0H4G73prgSxl90vgVZspFdHNwrqCrrsOxodEg3x5x CLOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JpqzPNSppYf32xY0LMaFvlBKdpLKvX9x4lVnPrZrz4I=; b=Goa9b20VN1Md01BAaP6hbZLv/ISHn17tAZqqeNPpmx47HeDBOcmuB98MsRngWoQ4Q2 ERIc926lmHU+qcZcaSRo1JlQ6ux1g3s+csPunwuTeSuo69rrPsYxOKirYSYkDVoo4o7x aLrqo204c+0UcTETVPlFyKSEjRdHXPouBFFSVZqCiuB7PNzHxDO40tiNIo8FKQJR/xYg qjnW/tKldAlOQlIXNtLqjoecXtL1lkkX5RUuMkrwRFqgbYghRNasN+RPrq2/nyrQA84t 9BW6YZhtBdoSyKXJLA3KyP8MjWhzCLgurQCnLVoCynSCJaMtyGqMFGZLP4xqCCaGqyxH P7pg== X-Gm-Message-State: AOAM531x9xuvUyfkgrdT1nXQlcv050b0dcDldJ1yKEAX0w66X0KKAqfW Z+DlJc/WNPUtZlKWSGeWWrYAMrkHkvhy5VJjx54= X-Google-Smtp-Source: ABdhPJzMHaVl3ibWwBzQNts8CufjbLsN7PLbgA6g/MyM6bAsIrx6MmPIXXxaIAtQVa/ZxQ06WElLkzJqyY/6O/ERpsg= X-Received: by 2002:a67:fb92:: with SMTP id n18mr5564103vsr.59.1600018940689; Sun, 13 Sep 2020 10:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6258:0:0:0:0:0 with HTTP; Sun, 13 Sep 2020 10:42:19 -0700 (PDT) In-Reply-To: <87k0x2ugb2.fsf@gmail.com> References: <87k0x2ugb2.fsf@gmail.com> From: Paul Winalski Date: Sun, 13 Sep 2020 13:42:19 -0400 Message-ID: To: Edouard Klein Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS List Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 9/10/20, Edouard Klein wrote: > Adding a bit of context, Software Heritage is used for example by GNU > Guix, which aims at making builds reproducible down to the exact bit. > To get complete build reproducibility, your compiler writers have to be careful. It's very easy to introduce random variability that doesn't affect the performance or semantics of the program. Register choice and instruction ordering, for example. Here's a real-world example of how such things can happen. Compilers have lots of data structures (temporary variables, for example) that require unique identifiers, but the value of the identifier is irrelevant--it simply has to be unique. It's tempting to use the memory address of the data structure as the unique ID--it saves both space and time. But suppose that your register allocator has to index those items in a hash table, and also at some point sequentially walks the hash table. The order of the sequential walk is now dependent on the memory addresses of the items in the table. In the case I observed, this resulted in different register choices if the program was recompiled. -Paul W.