On 2020/11/01 17:58, Dima Pasechnik wrote:
> On Sun, Nov 01, 2020 at 03:03:02PM +0000, Stuart Henderson wrote:
> > It is just an assembler, a newer version of the one that's already used,
> > there's not really much that's likely to go wrong, it's more likely to fix
> > than introduce problems.
> >
> > If you have some cycles to spare, building gcc with Brad's diff and checking
> > that a selection of the existing ports (pcbasic, vmm-firmware, Fortran
> > things) still build with it would be useful.
>
> I don't understand why using gcc is preferred here to using clang.
> With clang and egfortran one does not need to worry about gas, as
> there is no inline assembly in Fortran code in OpenBLAS.
> Besides, it's all reasonably well-tested on a number of OS (Linux, macOS,
> FreeBSD) that it's perfectly OK to mix clang and gfortran for OpenBLAS
> (and its consumers such as numpy).
Changing the gcc port to use a more appropriate assembler is simple to
reason about, simple to test, and fixes another problem we already have
as well as works around this one. Of course it doesn't rule out *also*
changing ports using gfortran to use clang as the C compiler later.
Changing those to clang for C might be fine too, and I wouldn't object
to doing that if someone wants to untangle lang/8/gcc4.port.mk to
figure out how to implement it and test it (making sure that it breaks
things with neither base-clang arches nor base-gcc archs - important to
check both and that ports produced following that change still have the
correct LIB_DEPENDS/WANTLIB in both cases).
No comments:
Post a Comment