Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Since neither objections or anything new has come up in all this time, about time we merged this. Thanks for the patch and sorry for taking so long. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-425895590___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Merged #425 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#event-1876603096___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
I should point out some deficiencies in using logic based on the {I,L,P,E} bits.
1) many operations to determine coloring of packages and transactions depend on
the ability of simply or'ing together file color flags contained within.
2) it's not just the insanity of static archives (and Itanium) containing both
elf32/elf64 a Objects that forced an arbitrary bit mask for file colors: e.g.
on OS X there are/were universal binaries (aka "fat binaries") that are
stitched/merged separate compilations intended for incompatible architectures.
3) while the ILP32 logic on arm is a reasonably sane designator that avoids
confusing/obscure arch naming, arm apparently has also added options for
floating point abi differences that may not fit into the scheme I outlined.
Meanwhile: if you are going to worry about arm arch names and compatibility
related to ILP32, you should also reserve some additional file color bits
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/425#issuecomment-382689633___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Correction: I meant Itanium IA64, not IA32, as the dinosaur platform that should burn in hell. But perhaps there's enough room in hell for ia32 to join its ia64 marketing named brethren as well ;-) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-382682503___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
The critical values for rpm installation are the file color bits, not the ever evolving arch names. The color values originally mapped onto the elf 32 and 64 bit designators because that is all that mattered at the time. The color value was designed as a bit mask to accomodate the insanity that a single *.a archive file might contain both 32 and 64 bit elf files. After looking up wtf!?! the "ILP32" stands for (a designator that indicates which of integer/long/pointer are 32 bits), a 4 bit mask composed of ILP and endianness might be a better choice than elf architectures for deciding elf file colors. Since C dictates that sizeof(long) == sizeof(pointer) afaik, only 3 bits are needed: let's call the set either PIE (or LIE ;-) with E for endianness. Ignoring the arcane issue of a single elf file being both 32 and 64 bit -- which was actually used on ia32 may that dinosaur platform burn in hell -- then there is an almost sensible mapping of a PIE designator onto the existing color values. Existing conventions for file colors are: 0 == uncolored, as in file doesn't have an ABI 1 == 32 bit 2 == 64 bit 4 == mips "other endian" (I.e. big endian) (and in PLD, used for x32) 8 == (unused) The one oddball is x32 (used in PLD iirc), where the 0x4 bit which would naturally represent E (as in "other" endianness, different from usual convention) is abused to indicate a 3rd relevant elf abi that might be encountered. Since ILP32 on arm64 is formally the same solution as X32 on x86_64 (please substitute the latest and greatest arch designators as appropriate), perhaps it's time to do the following for file colors: 1) always use 0x4 as E (I.e. "other endian", as in the non-typical ordering) 2) choose some simple algorithm based on P and I sizeof comparisons that assigns the values of the 0x1 and 0x2 bits compatible with existing practice. Ideally (in this proposal) x32 would map onto 0x3 rather than abusing 0x4. 3) reserve the 0x8 bit for an alternative abi designator, like a 128 bit architecture. Anyways, these are idle thoughts on choosing file colors for ILP32 on arm, which also comes in an "other endian" flavor, necessitating Yet Another Bit assignment if/when the existing ad hoc scheme for choosing file colors is extended Yet Again. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-382679371___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
I think this makes most sense (and is what I implemented in the original patch): armv8l == old ABI compatible with armv7l armv8hl == old hardfloat EABI compatible with armv7hl armv8hnl == armv8hl + neon, compatible with armv7hnl armv8hcnl == armv8hnl + crypto extensions ILP32, if properly implemented, probably needs a new name (if not a variant of aarch64, given it's closer to aarch64 than to armv7hnl? I'd be leaning towards aarch64_32 or something like that) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-382123819___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
@pmatilai someone brought to my attention today there is various confusion as to what 'armv8' actually means (for a package type). Does it mean traditional 32-bit ABI using instructions available on an 'ARMv8' processor? or does it mean using ILP32 ABI using all of the aarch64 instructions? In the former case, the ABI is compatible with armv7 and older.. in the later case, it's a new ABI. If you can make it clear ARMv8 is just the compatible with everything else version -- then it's just another marker... someone can add something new for ilp32 mode, if it is ever implemented. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-382121817___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
My largely uneducated take in this is... how about we just forget the exception clause about specialized environments and just define armv8 in rpm to mean standard armv8? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-381556571___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
If you wish to move to "human readable" names, then the specific functionalities tied to arch in rpmrc need to be separately configured. There's only a few critical values that rpmrc provides a default for * (per-arch) optflags (like in this issue) * (global) macrofiles search patterns and the rest of rpmrc is largely arch/os compatibility related to scoring, with some deeply obscure platform name/alias mappings buried in lib/rpmrc.c. >From experience in eliminating rpmrc configuration: I suspect that distro macro dialect deviations have progressed everywhere to the point that it is impossible to build without installing that distro's macro configuration which typically overrides %optflags (and usually provides C++ and other compiler flags). The arch scoring is/was the hardest to implement satisfactorily. And of course every distro I am aware of chose to repatch rpm to re-add the good old rpmrc "stuff". Old code never dies, oh well, I tried. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-379054402___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
@berolinux Just to be clear, I -have- a customer who has asked for armv8 WITHOUT NEON/VFP. This was obviously in the embedded space, but the same customer is saying that it's not for compatibility, but is actually a 32-bit 'armv8' processor. (No 64-bit support..) I have no idea if those claims are true or not, as I've not directly worked on that processor. Thus the mass confusion continues. But I agree with you, all aarch64 CPUs I have seen include all of the prescribed hardware as indicated by the spec. There may be some instruction scheduling differences, but so far the instruction set has been consistent and compatible. But with that said, I agree with what @n3npq mentioned above. Having these indicates as part of the package 'name' (other then for human readable purposes) really no longer makes sense. Between compatibility frameworks, emulators, etc... the system and users should be able to specify compatibility and priority and just 'go from there'. Same with package generation. It would make my life easier (using RPM in embedded systems) to get rid of this rpmrc notion for anything more then 'human readable'. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378942526___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
@mlschroe aarch64 and armv8 are the same CPU, but (obviously, given one is 32bit and one is 64bit) a different ABI -- no need to carry over the legacy float ABI. For neon, all aarch64 CPUs made so far have it, and it is part of the aarch64 core - however, ARM's docs say "Both floating-point and NEON are required in all standard ARMv8 implementations. However, implementations targeting specialized markets may support the following combinations: No NEON [...]" Neither gcc nor clang support aarch64 ABI without NEON for now, so targeting such a CPU is hypothetical anyway. So far, the only specialized implementations were 32-bit anyway, but we can't rule out a special purpose aarch64 CPU without neon coming out at some point. Given those (if they ever appear) will be rare and non-standard, if they're worth supporting at all they should probably get a modifier instead of discouraging people targeting aarch64 from using neon. For crypto, a modifier may well be useful, aarch64 CPUs exist both with and without the crypto extensions. Do we want to go there even though we don't have something comparable in the x86_64 world where it may make sense to have modifiers for SSE4, AVX, AVX2, SSE4a, SSE4.1, SSE4.2, .? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378906558___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Pardon the dumb question, but if armv8 is just the 32bit mode of aarch64 why doesn't aarch64 also need those float/neon/crypto modifiers? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378873147___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
@n3npq At least in the arm world it's somewhat less insane: uname -m shows what it should, armv7 vs armv8 vs aarch64 etc. is 100% consistent across all processors regardless of manufacturer and marketing names. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378774168___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
berolinux commented on this pull request. > @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a @kwizart yes, implicit still is -mfloat-abi=soft (both in clang and gcc) even though I haven't seen that used on any general purpose CPU in ages -- nobody wants to change what everyone has come to expect. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#discussion_r179052079___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
History repeats itself with ARM architectures ... At one point in time (see your favorite VCS for rpm -- git, cvs, whatever) rpmrc carried entries for i786/i886/I986. RPM development (IMHO) became impossible when RPM needed to detect a specific hardware (and buggy!) hardware flashing on PPC by trapping illegal instructions faults when compiling on a _COMPATIBLE_ cpu. Linux kernel dweebs deciding to return "i686" *always* through uname(2) forced lots of (imperfect IMHO) detection in user space. And then there were the Newer! Better! Bestest! marketing driven renaming of x86_64 -> amd64 -> whatever aliasing on Intel platforms. And then there is/was the insanity of whatever idiot (IMHO) decided to add ARM cpu attributes by appending to the 4tuple of CPU-VENDOR-OS-GNU for 32bit ARM cpus. And so now modifications to "arch compatibility" rpmrc variants for 64 bit ARM are being discussed ?!? Truly, "A VAX is a VAX is a ..." compatibility as implemented in RPM rpmrc files needs to DIE! DIE! DIE! DIE! DIE! IMHO. The arch naming is _ENTIRELY_ about marketing derived branding, not anything else. Start using arbitrary names like John/Paul/George/Ringo (or choose your own favorite rock stars) to identify cpu architectures in RPM: you are far more likely to devise something useful than trying to preserve last century's implementation of rpmrc. If you are not hearing what I am saying, then *PLEASE* show me an Intel i786 cpu: naming is all about marketing/branding, and "compatibility" is in the eye of the beholder. Peace ... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378488855___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
mhatle commented on this pull request. > @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a aarch32 is the new marketing name for what we used to call the 'arm instruction set'. armv8 is the most current incarnation of the 32-bit ARM instruction set. While the armv8 spec strongly suggests the inclusion of the VFP/Neon and other instructions. It is not strictly required. So yes, softfloat is still being used and is needed in some cases. There are multiple ARM licenses who claim to have armv8 compatible CPUs that do not have floating point units. (Note, all of the cases I know of these are 32-bit CPUs -- and all are geared toward embedded.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#discussion_r178826605___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
kwizart commented on this pull request. > @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a Do you implicitly really means -mfloat-abi=soft ? I anyone still care about this today ? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108945151___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
> armv8* is aarch64 machines in 32-bit mode. What is aarch32 then ? (open question). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378246983___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Conan-Kudo approved this pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108512134___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Conan-Kudo requested changes on this pull request. Small suggestions. > @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a +optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=vfpv4-d16 I'd suggest changing this to `-mfpu=vfpv4` > @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a +optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=vfpv4-d16 +optflags: armv8hnl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon There appears to be an armv8 variant of the neon fpu mode, so maybe we should use it? `-mfpu=neon-fp-armv8` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108512033___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Conan-Kudo approved this pull request. Looks good to me! Nice job! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108511918___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
According to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html, "Both floating-point and NEON are required in all standard ARMv8 implementations", but "implementations targeting specialized markets may support the following combinations: No NEON or floating-point." -- so armv8hl without n can make some sense for specialized CPU variants. Should probably strongly encourage armv8hnl w/ buildarchtranslate though, given mostly everyone will target standard armv8... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#issuecomment-30112___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Conan-Kudo commented on this pull request. > @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a +optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon Technically speaking, NEON is mandatory for the 64-bit ISA, but as far as I'm aware, that is not the case for the 32-bit ISA. AArch32 v8 still allows NEON to be omitted. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#discussion_r178450662___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
berolinux commented on this pull request. > @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a +optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon Same here, since NEON is mandatory for ARMv8 (that's why there is no -mfpu= switch in the aarch64-* compilers), armv8hl and armv8hnl are the same and -mfpu=neon will do the right thing. I don't see any use case for the combination of armv8-a and -mfpu=something other than neon, except in the softfloat case (armv8l) if you need to use a binary-only library that still doesn't support hardfloat (Android...) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#discussion_r178352048___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
berolinux commented on this pull request. > @@ -461,6 +472,8 @@ arch_compat: armv5tl: armv4tl arch_compat: armv4tl: armv4l arch_compat: armv4l: armv3l arch_compat: armv3l: noarch +arch_compat: armv8hnl: armv8hl +arch_compat: armv8hl: armv7hnl Since NEON is mandatory on aarch64, armv8hnl and armv8hl are the same thing, so it does describe a true superset to subset case. (To be even more correct, should probably add arch_compat: armv8hl: armv8hnl -- but I don't think circular loops there are a good idea.) It may be worth arguing armv8hnl shouldn't exist at all (because armv8hl is the same and therefore the extra n is superfluous) or armv8hl shouldn't exist at all (because armv8hnl is the same and having the n in there is consistent with what was done on armv7) -- I've put in both for now to be compatible with what either side would expect. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#discussion_r178351499___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Conan-Kudo requested changes on this pull request. > @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a +optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon `armv8hl` should not have neon. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108398815___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Conan-Kudo requested changes on this pull request. > @@ -461,6 +472,8 @@ arch_compat: armv5tl: armv4tl arch_compat: armv4tl: armv4l arch_compat: armv4l: armv3l arch_compat: armv3l: noarch +arch_compat: armv8hnl: armv8hl +arch_compat: armv8hl: armv7hnl This is not compatible. This does not describe a true superset to subset case. > @@ -593,6 +607,8 @@ buildarch_compat: armv4tl: armv4l buildarch_compat: armv4l: armv3l buildarch_compat: armv3l: noarch +buildarch_compat: armv8hnl: armv8hl +buildarch_compat: armv8hl: armv7hnl This is not compatible. This does not describe a true superset to subset case. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/425#pullrequestreview-108398489___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
