Created attachment 179950 [details]
WARN: Makefile: --build, --mandir, and --infodir are not needed in CONFIGURE_ARGS as they are already set in bsd.port.mk.
0 fatal errors and 1 warning found.
poudriere testport: (I also ran the `make test` under poudriere interative mode)
* pass on amd64, 11.0-RELEASE (with DEFAULT OPTIONS); make test pass
* pass on i386 , 11.0-RELEASE (with DEFAULT OPTIONS); make test pass
* pass on amd64, 10.3-RELEASE (with DEFAULT OPTIONS); make test pass
* pass on i386, 10.3-RELEASE (with DEFAULT OPTIONS); make test pass
A commit references this bug:
Date: Mon Feb 13 17:39:41 UTC 2017
New revision: 434009
Finally update to 6.1.2 release, it should work fine with currently supported FreeBSD releases.
Submitted by: Iblis Lin <firstname.lastname@example.org>
This breaks the build on head.
The error seems caused by a compiler bug:
Test compile: mpn_lshift_com optimization 2
configure:6805: cc -O2 -pedantic -fomit-frame-pointer -m64 conftest.c >&5
configure:6808: $? = 0
configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
Abort trap (core dumped)
eval: ./b.out: not found
eval: ./a.exe: not found
eval: ./a_out.exe: not found
eval: ./conftest: not found
configure:6816: $? = 127
failed program was:
/* The following is mis-compiled by Intel ia-64 icc version 1.8 under
"icc -O3", After several calls, the function writes partial garbage to
the result vector. Perhaps relates to the chk.a.nc insn. This code needs
to be run to show the problem, but that's fine, the offending cc is a
native-only compiler so we don't have to worry about cross compiling. */
6.1.2 can build on my 12.0-CURRENT #0 r313193...
This should be fixed by ports r434069
What was exactly the issue?
(In reply to Alex Dupre from comment #6)
When using malloc, there is no guarantee that uninitialized memory will be filled with zero.
With malloc debugging turned on (opt.junk), unitialized allocated is filled with 0xa5 and it breaks the mpn_lshift_com test (it checks if some longs are still 0).
You can reproduce the problem on 10.3 or 11.0 with either clang or gcc by setting environement MALLOC_CONF to junk:true
I see. The test case wasn't very well documented, but it seems to verify that untouched allocated bytes are still zero, so it's clearly a bug to use malloc in that case. Thanks for fixing it.
(In reply to Alex Dupre from comment #3)
This was fixed upstream in "Recognise AMD zen." by Torbjorn Granlund <email@example.com>: https://gmplib.org/repo/gmp/rev/2ce5c60f5372
The same file (acinclude.m4) also received several other fixes recently: https://gmplib.org/repo/gmp/log/tip/acinclude.m4
I reported the issue and a request for backporting upstream: https://gmplib.org/list-archives/gmp-bugs/2018-February/004331.html