Subject: bug#74216: closed (Re: [science team] flint build failure)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 12 Nov 2024 19:21:02 +0000

Your bug report

#74216: [science team] flint build failure

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
74216: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74216
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: [science team] flint build failure
From: Greg Hogan <[email-masked]>
To: Andreas Enge <[email-masked]>
Cc: [email-masked], Sharlatan Hellseher <[email-masked]>, [email-masked]
Date: Tue, 12 Nov 2024 14:19:10 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

On Tue, Nov 12, 2024 at 9:01 AM Andreas Enge <[email-masked]> wrote:
>
> Hello Greg,
>
> Am Tue, Nov 05, 2024 at 03:43:31PM -0500 schrieb Greg Hogan:
> > flint fails to build for me with the following error unless I include
> > as an input a newer gcc version.
>
> out of curiosity, what is your exact build architecture and processor
> line? The package builds without problems on my rather old laptop, and
> on the Guix build farms.

AWS r7a, AMD EPYC (4th Gen) 9R14

> I have asked someone who knows the flint code well, and they said it
> means that gcc has trouble realising how to expand the assembly code
> into load and stores and computation on machines with less than 8
> registers. Apparently it is a combination of compiler versions and
> processor specifics.
>
> Apart from that, I think we can apply your patch without worries, but
> I am just curious about what is happening.
>
> What is mildly worrying is that we already use the "--disable-assembly"
> configure flag; this could be a bug in the flint configuration.
>
> Andreas

Thanks for investigating this issue and pointing me in the right
direction. Turns out the flint package builds successfully when
upgrading GCC from 11.4 to 11.5. It looks like the processor was too
new.

When considering reproducible builds, this is a bug when building on
future, unknown hardware. For a time-bomb we can set back the clock,
and here we would need processor emulation?

Marking as done since the fix is to update a core package.

Greg

Subject: [science team] flint build failure
From: Greg Hogan <[email-masked]>
To: [email-masked]
Cc: Andreas Enge <[email-masked]>, Sharlatan Hellseher <[email-masked]>, [email-masked]
Date: Tue, 5 Nov 2024 15:43:31 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

flint fails to build for me with the following error unless I include
as an input a newer gcc version.

Greg

--8<---------------cut here---------------start------------->8---
  CC  fmpz_poly_q/add.c
In file included from src/fft_small/mpn_mul.c:17:
src/fft_small/mpn_mul.c: In function ‘_mpn_from_ffts_8’:
./src/crt_helpers.h:120:3: error: ‘asm’ operand has impossible constraints
  120 |   __asm__ ("addq %23,%q7\nadcq %21,%q6\nadcq %19,%q5\n\tadcq
%17,%q4\n\tadcq %15,%q3\n\tadcq %13,%q2\n\tadcq %11,%q1\n\tadcq
%9,%q0"    \
      |   ^~~~~~~
./src/crt_helpers.h:378:5: note: in expansion of macro
‘add_ssssssssaaaaaaaaaaaaaaaa’
  378 |     add_ssssssssaaaaaaaaaaaaaaaa(z[7],z[6],z[5],z[4],z[3],z[2],z[1],z[0],
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/crt_helpers.h:120:3: error: ‘asm’ operand has impossible constraints
  120 |   __asm__ ("addq %23,%q7\nadcq %21,%q6\nadcq %19,%q5\n\tadcq
%17,%q4\n\tadcq %15,%q3\n\tadcq %13,%q2\n\tadcq %11,%q1\n\tadcq
%9,%q0"    \
      |   ^~~~~~~
./src/crt_helpers.h:378:5: note: in expansion of macro
‘add_ssssssssaaaaaaaaaaaaaaaa’
  378 |     add_ssssssssaaaaaaaaaaaaaaaa(z[7],z[6],z[5],z[4],z[3],z[2],z[1],z[0],
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---