unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Efraim Flashner <efraim@flashner.co.il>
Cc: 51536@debbugs.gnu.org
Subject: bug#51536: openblas builds not reproducible on different x86_64 machines
Date: Sat, 06 Nov 2021 22:33:12 -0400	[thread overview]
Message-ID: <87fss83dav.fsf@gmail.com> (raw)
In-Reply-To: <YX+rP5R0uFQPj5ym@3900XT> (Efraim Flashner's message of "Mon, 1 Nov 2021 10:54:23 +0200")

Hi again,

Efraim Flashner <efraim@flashner.co.il> writes:

> On Sun, Oct 31, 2021 at 11:07:00PM -0400, Maxim Cournoyer wrote:
>> Hello Guix,

[...]

> I compared our build flags with Debian's¹ (which is also what I often do
> when working on other architectures) and it looks like they have
> DYNAMIC_OLDER=1 and TARGET=GENERIC. From looking through Makefile.system
> it looks like TARGET=GENERIC makes it more portable, and DYNAMIC_OLDER=1
> adds support for some of the older x86_64 sub-architectures.


> If it weren't for the 2k+ packages which depend on openblas I think it'd
> be obvious to add the extra flags now. I wonder if we could
> unconditionally set DYNAMIC_ARCH=1 TARGET=GENERIC and then override it
> on some architectures, rather than now where each architecture needs its
> own flags.
>
> I also wonder if it's worth it to add a minimal openblas-native for an
> easy transform option of --with-graft=openblas=openblas-native, where
> openblas-native just adds -march=native and turns off substitutability.
>
> ¹ https://sources.debian.org/src/openblas/0.3.18+ds-2/debian/rules/#L19

I've tried this:

--8<---------------cut here---------------start------------->8---

modified   gnu/packages/maths.scm
@@ -4444,13 +4444,13 @@ (define-public openblas
              ,@(let ((system (or (%current-target-system) (%current-system))))
                  (cond
                   ((or (string-prefix? "x86_64" system)
-                       (string-prefix? "i686" system))
-                   '("DYNAMIC_ARCH=1"))
-                  ;; On some of these architectures the CPU can't be detected.
-                  ((or (string-prefix? "powerpc64le" system)
+                       (string-prefix? "i686" system)
+                       (string-prefix? "powerpc64le" system)
                        (string-prefix? "aarch64" system))
-                   '("DYNAMIC_ARCH=1"
-                     "TARGET=GENERIC"))
+                   ;; Dynamic older enables a few extra CPU architectures that
+                   ;; were released before 2010.
+                   '("DYNAMIC_ARCH=1" "DYNAMIC_OLDER=1" "TARGET=GENERIC"))
+                  ;; On some of these architectures the CPU can't be detected.
                   ;; On MIPS we force the "SICORTEX" TARGET, as for the other
                   ;; two available MIPS targets special extended instructions
                   ;; for Loongson cores are used.
--8<---------------cut here---------------end--------------->8---

And it fixed the illegal instruction problem on my Core 2 Duo CPU
(tested by using an offloaded openblas build and building numpy locally
with it).

But it didn't resolve the reproducibily issue.  I'll create a ticket
upstream asking for guidance.

Thank you,

Maxim




  parent reply	other threads:[~2021-11-07  2:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01  3:07 bug#51536: openblas builds not reproducible on different x86_64 machines Maxim Cournoyer
2021-11-01  8:54 ` Efraim Flashner
2021-11-05 16:38   ` Maxim Cournoyer
2021-11-07  2:33   ` Maxim Cournoyer [this message]
2021-11-03 15:03 ` zimoun
2022-02-02 23:13 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fss83dav.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=51536@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).