bug#51104: comp-tests.elc messes up after reconfiguring for different machine

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> When trying out the emacs-28 branch on both 32- and 64-bit platforms,
>> I had test failures that I tracked down to this line:
>>
>> test/src/comp-tests.el:933:       (integer ,most-negative-fixnum
>> ,most-positive-fixnum))
>>
>> My problem was that I'd built test/src/comp-tests.elc on a 32-bit
>> platform (using "./configure CC='gcc -m32'" on an x86-64 machine) so
>> that .elc file had been built assuming 32-bit values for
>> most-negative-fixnum and most-positive fixnum. When I then re-ran
>> 'configure' for a 64-bit platform the .elc files were not
>> automatically rebuilt for it (they're supposed to be
>> machine-independent, right?) and so the optimizations were incorrect
>> for a 64-bit platform and the tests failed.
>>
>> What's a good way to fix this problem, while still testing everything
>> that comp-tests.el wants to test?
>
> This was a year ago, but the code in question seems unchanged now on
> "master":
>
>       ;; 14
>       ((defun comp-tests-ret-type-spec-f (x)
>          (comp-hint-fixnum x))
>        (integer ,most-negative-fixnum ,most-positive-fixnum))
>
> So I guess the problem is still present?  (I haven't tested myself.)
>
> Andrea, do you see any way to fix this test for this 32-bit/64-bit
> scenarion?

Hi Lars,

I think here IIUC we are using a .elc file (comp-tests.elc) compiled an
an arch X to test .eln files for architectures different than X.

`most-negative-fixnum' is replaced at byte-compilation time with a value
that is indeed arch dependent.  This is because we have some macrology
to defines those tests.

I believe in theory should be possible to move this computation in the
compile time to keep "comp-tests.elc" arch indepent if this is
requirement.

Best Regards

  Andrea