On 10/16/16 18:56, Michael Butler wrote:
On 10/16/16 11:36, Joe Marcus Clarke wrote:
Seems like the easy fix would be to incorporate the fix for this bug,
and then disable SSE4.2 in a CFLAGS override. The better fix would be
to have clang do the same as GCC so that the test build would fail on
those platforms that don't support SSE4.2.
Personally, I feel that this whole approach is wrong. To have CONFIGURE
set a flag asking for instructions not supported by the host for the
whole project when only one module has a run-time check for them is
depending on undefined behavior. This is plainly poor engineering.
It so happens that GCC does the expected thing but there is no guarantee
that any other compiler can or should.
In CLANG's case, it found an opportunity to use an SSE-4.2 instruction
in compiling LEMON and assumed it could use it as CONFIGURE told it
explicitly that it could. "fixing" every compiler out there to be
GCC-compatible is not an acceptable or desirable work-around.
The option should only be set for the module prepared for and capable of
handling the absence of the extended instructions,
Sure. I think the better case is to do a runtime check of a binary
built with this instruction set versus just a compiler check. Seems
like the compiler check is what WS is settling on, though.
Will any stub executable built with these instructions fail, or is there
a specific call that needs to be made to test this? I imagine the latter.
Joe
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gn...@freebsd.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
