Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

[Gerald Pfeifer]

On Sat, 28 May 2016, Warner Losh wrote:
> armv6*-*-freebsd is only hard float ABI for FreeBSD 11.
:
> Are you saying that we need to get these changes to the ports in place
> to support hard float? 

For the record, this has now happened with the great help of
Andreas Tobler (both upstream and in our lang/gcc* ports).

If there is anything you see missing, please advise.

Gerald
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

[Mark Millard]

On 2016-May-28, at 9:50 PM, Warner Losh  wrote:

> On Wed, May 25, 2016 at 10:12 AM, Mark Millard  wrote:
>> I'm  not sure that Gerald or Brooks were CC'd on a report made to the arm 
>> list about armv6 builds of gcc and llvm being broken now because of hard 
>> float now being implicit:
>> (the first report listed below has more detail directly visible for gcc 
>> examples)
>> 
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html
>> and:
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html
>> 
>> The first (013931.html) shows that xgcc for configure:3686 for contest.c 
>> ends up with the likes of:
>> 
>> /usr/local/bin/ld: error: a.out uses VFP register arguments,
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not
>> /usr/local/bin/ld: failed to merge target specific data of file
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o
>> /usr/local/bin/ld: error: a.out uses VFP register arguments,
>> /tmp//cchNL2QG.o does not
>> /usr/local/bin/ld: failed to merge target specific data of file 
>> /tmp//cchNL2QG.o
>> /usr/local/bin/ld: error: a.out uses VFP register arguments,
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not
>> /usr/local/bin/ld: failed to merge target specific data of file
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o
>> collect2: error: ld returned 1 exit status
>> 
>> and points to gcc/config.gcc only having TARGET_FREEBSD_ARM_HARD_FLOAT=1 for 
>> arm*hf-*-freebsd* . But now armv6*-*-freebsd* is also hard float for 
>> 11.0-CURRENT.
> 
> armv6*-*-freebsd is only hard float ABI for FreeBSD 11.

My understanding is that the older rpi's are ARM1176JZF-S, "which IS armv6" to 
quote Ian Lepore. I've not used such under 10.x at all so I may be making some 
implicit bad assumptions below. Feel free to correct my stupidities. . .

Unless 10.x FreeBSD is also switching to hardfloat I do not expect that the 
above part of your note is fully descriptive for compiler ports. (Presumes 
continued targeting of 10.x armv6 for rpi.)

armv6*-*-freebsd10* (such as for a 10.x rpi) is softfloat and stays that way in 
10.x .

armv6*-*-freebsd11* (such as for a 11.x rpi or rpi2) is hardfloat now.

(I'm guessing those naming patterns.)

The compiler ports and their supporting runtime files deal with both targeting 
contexts for some amount of time (until 10.x can be dropped by ports). (Forms 
of on-the-fly code generation might also have such issues.)

>> Of course until everyone updates to modern enough armv6 context a mix of 
>> softfloat and hardfloat will be around.
> 
> Are you saying that we need to get these changes to the ports in place
> to support hard float? Are you saying we need to support a mix better
> (which is unlikely to happen, btw, without a passionate champion)? Is
> there some other point I'm missing?
> 
> Warner

A compiler toolchain in ports that targeted softfloat ABI before now needs to 
target the hardfloat ABI for 11.0 --and that apparently now uses "VFP register 
arguments".

gcc/crtbegin.o , gcc/crtend.o , and the like for hardfloat contexts need to 
handle at least "VFP register arguments" now but do not yet do so.

The old armv6*-*-freebsd* pattern used to identify a softfloat context and some 
text matching that pattern now identifies a hardfloat context ( 
armv6*-*-freebsd11* as far as I can tell). The toolchain example above is/was 
based on the pattern arm*hf-*-freebsd* to identify hardfloat vs. 
armv6*-*-freebsd* for softfloat (both 10.x and 11.0?). This is no longer 
sufficient.

Of course until someone rebuilds and installs replacing an older 11.0 build 
that had text matching the pattern armv6*-*-freebsd11*, the build it really is 
still softfloat so there is a transition-time issue because the text used does 
not uniquely identify the context: Once the ports they needed are ready folks 
then need to upgrade the 11.0 vintage to track. Before then the lack of ports 
might break their context if they update the 11.0 vintage. 

So I think the answer to the first question is: Yes there  are  changes that 
need to be made for the compiler ports to work for 11.0 and its hardfloat use. 
I'm guessing that building the ports for targeting 10.x is also to be possible 
for some time.

For the second question: hardfloat is not supported yet in ports. It needs to 
be for targeting armv6*-*-freebsd11* (11.0). Softfloat needs to be supported 
for targeting armv6*-*-freebsd10* (10.x). I do not see 11.0 supporting 
softfloat going forward. I do not see 10.x supporting hardfloat going forward. 
The relevant ports have 2 contexts to span unless 10.x ( armv6*-*-freebsd10* ) 
support is to be dropped now.

Am I clearer this time? (I leave the 3rd question to you: Did I make any new 
points here?)


===
Mark Millard
markmi at dsl-only.net

Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

[Warner Losh]

On Wed, May 25, 2016 at 10:12 AM, Mark Millard  wrote:
> I'm  not sure that Gerald or Brooks were CC'd on a report made to the arm 
> list about armv6 builds of gcc and llvm being broken now because of hard 
> float now being implicit:
> (the first report listed below has more detail directly visible for gcc 
> examples)
>
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html
> and:
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html
>
> The first (013931.html) shows that xgcc for configure:3686 for contest.c ends 
> up with the likes of:
>
> /usr/local/bin/ld: error: a.out uses VFP register arguments,
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not
> /usr/local/bin/ld: failed to merge target specific data of file
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o
> /usr/local/bin/ld: error: a.out uses VFP register arguments,
> /tmp//cchNL2QG.o does not
> /usr/local/bin/ld: failed to merge target specific data of file 
> /tmp//cchNL2QG.o
> /usr/local/bin/ld: error: a.out uses VFP register arguments,
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not
> /usr/local/bin/ld: failed to merge target specific data of file
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o
> collect2: error: ld returned 1 exit status
>
> and points to gcc/config.gcc only having TARGET_FREEBSD_ARM_HARD_FLOAT=1 for 
> arm*hf-*-freebsd* . But now armv6*-*-freebsd* is also hard float for 
> 11.0-CURRENT.

armv6*-*-freebsd is only hard float ABI for FreeBSD 11.

> Of course until everyone updates to modern enough armv6 context a mix of 
> softfloat and hardfloat will be around.

Are you saying that we need to get these changes to the ports in place
to support hard float? Are you saying we need to support a mix better
(which is unlikely to happen, btw, without a passionate champion)? Is
there some other point I'm missing?

Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"