GNU bug report logs - #54635
[PATCH 0/5] Add wfmash

Previous Next

Package: guix-patches;

Reported by: Arun Isaac <arunisaac <at> systemreboot.net>

Date: Wed, 30 Mar 2022 09:20:01 UTC

Severity: normal

Tags: patch

Done: Efraim Flashner <efraim <at> flashner.co.il>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 54635 <at> debbugs.gnu.org, Arun Isaac <arunisaac <at> systemreboot.net>
Subject: [bug#54635] [PATCH v2 5/5] gnu: Add wfmash.
Date: Thu, 31 Mar 2022 15:07:49 +0200
[Message part 1 (text/plain, inline)]
Efraim Flashner schreef op do 31-03-2022 om 15:18 [+0300]:
> > Arun Isaac schreef op do 31-03-2022 om 12:58 [+0530]:
> > > +                       (("-march=native") ""))
> > 
> > This is also wrong for x86 systems because it makes the build non-
> > reproducible.  Also, has upstream been informed about some of the
> > compiler flags being architecture-specific?
> 
> I'm pretty sure upstream is aware of it, and the -mcx16 flag. That
> whole phase doesn't need to be non-x86_64 only, upstream prefers it
> that way to get fater results

wfmash could be written to detect CPU features at runtime and there is
also --tune.  Also, upstream preferring march=native does not make the
build reproducible.

> but IMO it would be fine to move it into a snippet.

It does not have to be in a snippet, it just needs to be reproducible
(so no march=native, whether on x86 or not).

Upstream seems to be aware of the non-x86
(https://github.com/ekg/wfmash/issues/125) but they do not seem to be
aware of the problems with march=native.

Greetings,
Maxime
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 3 years and 99 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.