Re: Cortex-r52 FP double precision
Hi Thomas Don't you know by the way why ARMv8-R is not listed in t-rmprofile multilib ? Alex On Fri, Jan 26, 2018 at 9:25 PM, Thomas Preudhomme wrote: > That or just use -mfpu=auto (as in -mcpu=cortex-r52 -mfpu=auto > -mfloat-abi=(softfp|hard)). > > Best regards, > > Thomas > > > On 26/01/18 16:44, Alexander Fedotov wrote: >> >> Thank you Thomas >> >> So in order to set dp+Neon for armv8-r I should to use switch >> "neon-fp-armv8". Not an fpv5-d16. Right ? >> >> On Fri, Jan 26, 2018 at 12:52 PM, Thomas Preudhomme >> wrote: >>> >>> Hi Alexander, >>> >>> As mentioned in [1], Arm Cortex-R52 can have either single precision or >>> double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 >>> defaulting to the latter (double precision + Neon) and >>> -mcpu=cortex-r52+nofp.dp giving you the former (single precision). >>> >>> [1] https://developer.arm.com/products/processors/cortex-r/cortex-r52 >>> >>> Best regards, >>> >>> Thomas >>> >>> >>> On 25/01/18 21:22, Alexander Fedotov wrote: Hi, As I understand from this https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master branch doesn't have support of double-precision FPv5 floating-point instructions for ARMv8-R (Cortex-r52). If yes, are there any chances to see them in GCC 8 ? Alex >>> >> >> >> > -- Best regards, AF
Re: -static-pie and -static -pie
After looking at this for quite a while, I'm afraid I'm unsure how to proceed.
As of now, static and static-pie are mutually exclusive. So given the
GNU_USER_TARGET_STARTFILE_SPEC you pasted
earlier, "static" matches before "static-pie", causing the wrong start files.
It seems to me that the static-pie target complicates things more than
matching against static+pie individually.
If I convert -static + -pie to -static-pie, then "static" won't be
matched in specs, where maybe it otherwise should. Same for -pie.
Would you prefer to swallow -static and -pie and pass along only
-static-pie? Or forward them all along, and fix the specs which look
for static before static-pie ?
Regards,
Cory
On Tue, Jan 30, 2018 at 2:36 PM, H.J. Lu wrote:
> On Tue, Jan 30, 2018 at 11:18 AM, Cory Fields wrote:
>> On Tue, Jan 30, 2018 at 2:14 PM, H.J. Lu wrote:
>>> On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
> On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields
> wrote:
>> Hi list
>>
>> I'm playing with -static-pie and musl, which seems to be in good shape
>> for 8.0.0. Nice work :)
>>
>> However, the fact that "gcc -static -pie" and "gcc -static-pie"
>> produce different results is very unexpected. I understand the case
>> for the new link-type, but merging the options when possible would be
>> a huge benefit to existing buildsystems that already cope with both
>> individually.
>>
>> My use-case:
>> I'd like to build with --enable-default-pie, and by adding "-static"
>
> Why not adding "-static-pie" instead of "-static"?
>
>> to my builds, produce static-pie binaries. But at the moment, that
>> attempts to add an interp section.
>>
>> So my question is, if no conflicting options are found, why not hoist
>> "-static -pie" to "-static-pie" ?
>>
>> Regards,
>> Cory
>
>
>
> --
> H.J.
My build system, and plenty of others I'm sure, already handle -static
and -pie. Having that understood to mean "static-pie" would mean that
the combination would now just work.
Asking a different way, if I request -static and -pie, without -nopie,
quietly creating non-pie binary seems like a bug. Is there a reason
_not_ to interpret it as -static-pie in that case?
>>>
>>> GNU_USER_TARGET_STARTFILE_SPEC is defined as
>>>
>>> #define GNU_USER_TARGET_STARTFILE_SPEC \
>>> "%{shared:; \
>>> pg|p|profile:%{static-pie:grcrt1.o%s;:gcrt1.o%s}; \
>>> static:crt1.o%s; \
>>> static-pie:rcrt1.o%s; \
>>> " PIE_SPEC ":Scrt1.o%s; \
>>> :crt1.o%s} \
>>>crti.o%s \
>>>%{static:crtbeginT.o%s; \
>>> shared|static-pie|" PIE_SPEC ":crtbeginS.o%s; \
>>> :crtbegin.o%s} \
>>>%{fvtable-verify=none:%s; \
>>> fvtable-verify=preinit:vtv_start_preinit.o%s; \
>>> fvtable-verify=std:vtv_start.o%s} \
>>>" CRTOFFLOADBEGIN
>>>
>>> to pick a suitable crt1.o for static PIE when -static-pie is used.
>>>
>>> If gcc.c can convert ... -static ... -pie and ... -pie ... -static ... to
>>> -static-pic for GNU_USER_TARGET_STARTFILE_SPEC, it
>>> should work.
>>>
>>> --
>>> H.J.
>>
>> Great, that's how I've fixed it locally. Would you consider accepting
>> a patch for this?
>
> I'd like to see it in GCC 8. Please open a GCC bug and submit your
> patch against it.
>
> Thanks.
>
> --
> H.J.
Re: -static-pie and -static -pie
On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote: > After looking at this for quite a while, I'm afraid I'm unsure how to proceed. > > As of now, static and static-pie are mutually exclusive. So given the > GNU_USER_TARGET_STARTFILE_SPEC you pasted > earlier, "static" matches before "static-pie", causing the wrong start files. > > It seems to me that the static-pie target complicates things more than > matching against static+pie individually. > > If I convert -static + -pie to -static-pie, then "static" won't be > matched in specs, where maybe it otherwise should. Same for -pie. > > Would you prefer to swallow -static and -pie and pass along only > -static-pie? Or forward them all along, and fix the specs which look Yes. When you see both -static and -pie. regardless of their relative order on command-line, you 1. Remove -static and -pie. 2. Add -static-pie. > for static before static-pie ? > -- H.J.
Re: -static-pie and -static -pie
On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu wrote: > On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote: >> After looking at this for quite a while, I'm afraid I'm unsure how to >> proceed. >> >> As of now, static and static-pie are mutually exclusive. So given the >> GNU_USER_TARGET_STARTFILE_SPEC you pasted >> earlier, "static" matches before "static-pie", causing the wrong start files. >> >> It seems to me that the static-pie target complicates things more than >> matching against static+pie individually. >> >> If I convert -static + -pie to -static-pie, then "static" won't be >> matched in specs, where maybe it otherwise should. Same for -pie. >> >> Would you prefer to swallow -static and -pie and pass along only >> -static-pie? Or forward them all along, and fix the specs which look > > Yes. When you see both -static and -pie. regardless of their relative > order on command-line, you > > 1. Remove -static and -pie. > 2. Add -static-pie. > This assumes that -static -pie and -pie -static do not produce the working executable. If they do, you can't change them. -- H.J.
Re: Cortex-r52 FP double precision
Hi Alexander, An evaluation needs to be made of the benefit of a new multilib for Armv8-R (instead of reusing an existing multilib) compared to the extra maintenance and build time. Best regards, Thomas On 31/01/18 14:31, Alexander Fedotov wrote: Hi Thomas Don't you know by the way why ARMv8-R is not listed in t-rmprofile multilib ? Alex On Fri, Jan 26, 2018 at 9:25 PM, Thomas Preudhomme wrote: That or just use -mfpu=auto (as in -mcpu=cortex-r52 -mfpu=auto -mfloat-abi=(softfp|hard)). Best regards, Thomas On 26/01/18 16:44, Alexander Fedotov wrote: Thank you Thomas So in order to set dp+Neon for armv8-r I should to use switch "neon-fp-armv8". Not an fpv5-d16. Right ? On Fri, Jan 26, 2018 at 12:52 PM, Thomas Preudhomme wrote: Hi Alexander, As mentioned in [1], Arm Cortex-R52 can have either single precision or double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 defaulting to the latter (double precision + Neon) and -mcpu=cortex-r52+nofp.dp giving you the former (single precision). [1] https://developer.arm.com/products/processors/cortex-r/cortex-r52 Best regards, Thomas On 25/01/18 21:22, Alexander Fedotov wrote: Hi, As I understand from this https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master branch doesn't have support of double-precision FPv5 floating-point instructions for ARMv8-R (Cortex-r52). If yes, are there any chances to see them in GCC 8 ? Alex
gcc-6-20180131 is now available
Snapshot gcc-6-20180131 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180131/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 257272 You'll find: gcc-6-20180131.tar.xzComplete GCC SHA256=5c4ad7855a8de077fd7ebb949c8bbc6debfa886c1c5cee6c28fa61e8eb29c4f0 SHA1=43fb00233aec23ebb97553f07a059f23c04f53ed Diffs from 6-20180124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
