Re: [PATCH, ARM] Unaligned accesses for builtin memcpy [2/2]
On Fri, Oct 14, 2011 at 6:53 AM, Julian Brown jul...@codesourcery.com wrote: On Wed, 28 Sep 2011 14:33:17 +0100 Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: On 6 May 2011 14:13, Julian Brown jul...@codesourcery.com wrote: Hi, This is the second of two patches to add unaligned-access support to the ARM backend. It builds on the first patch to provide support for unaligned accesses when expanding block moves (i.e. for builtin memcpy operations). It makes some effort to use load/store multiple instructions where appropriate (when accessing sufficiently-aligned source or destination addresses), and also makes some effort to generate fast code (for -O1/2/3) or small code (for -Os), though some of the heuristics may need tweaking still Sorry it's taken me a while to get around to this one. Do you know what difference this makes to performance on some standard benchmarks on let's say an A9 and an M4 as I see that this gets triggered only when we have less than 64 bytes to copy. ? No, sorry, I don't have any benchmark results available at present. I think we'd have to have terrifically bad luck for it to be a performance degradation, though... I've backported the unaligned struct and memcpy patches to our 4.6 based compilers and benchmarked them. The worst is a 0.84 % drop in performance, the best a 7.17 % improvement, and a geomean of 0.18 %. This was in a Cortex-A9 NEON -O3 configuration. The results are accurate to less than 0.1 %. I'll send you and Ramana the raw results privately. -- Michael
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 4 April 2012 04:17, Andrew Haley a...@redhat.com wrote: On 04/03/2012 05:09 PM, Richard Earnshaw wrote: On 03/04/12 12:01, Jakub Jelinek wrote: On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: If, so then there's only one way to sort out this mess. /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader The above scheme is a Debianism which no other distro is using. Jakub Not really, it's just a naming convention for where the config-specific dynamic loader lives. It doesn't affect where the remaining shared libraries live. The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros. -- Michael [1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
2012/4/4 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 3 de abril de 2012 20:48, Michael Hope michael.h...@linaro.org escreveu: snip Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding: Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build Gentoo: * I'm unsure (help?) * The Gentoo manual suggests ARMv7 softfp is the default I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be good to have to be able to run binaries for either without resorting to a chroot, and only testing purposes. Bumping major or calling it ld-linux-foo.so.3 is out of question? I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part. -- Michael
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 4 April 2012 10:56, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 3 Apr 2012, Michael Hope wrote:
+#define GLIBC_DYNAMIC_LINKER \
+ %{mhard-float: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{!mfloat-abi=hard:%{!mhard-float: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }}
(a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
be handled in specs.
Fixed.
(b) You need to handle compilers configured with --with-float=hard, so
make the specs depend on the default ABI the compiler was configured with.
GCC seems to take configure time options into account when evaluating
a spec file.
Tested by building a default, --with-float=hard, and
--with-float=softfp compiler then checking the loader path for all
combinations of {,-mglibc,-mbionic,-muclibc} x
{,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.
(c) Please include libc-ports on future submissions and provide both the
GCC patch and the glibc ports patch that have been tested to work together
to build and install the library in the given path; a patch to one
component like this cannot sensibly be considered in isolation. I imagine
you'll need appropriate ARM preconfigure support to detect what ABI the
compiler is using, much like the support for MIPS, so that the right
shlib-versions files are used.
Agreed.
I try to follow all ARM glibc discussions
on libc-ports closely, as the ARM glibc maintainer; was there a previous
discussion of the dynamic linker naming issue there that I missed?
Steve McIntyre is driving this inside Debian. I'll ping him on the
GLIBC support.
The tricky one is new GCC with old GLIBC. GCC may have to do a
configure time test and fall back to /lib/ld-linux.so.3 if the hard
float loader is missing.
(The only previous relevant discussion that I recall is one on
patc...@eglibc.org starting at
http://www.eglibc.org/archives/patches/msg01017.html, regarding how the
dynamic linker should check that a library has the right ABI, and there
was no real followup on that after I indicated what would seem to be the
appropriate implementation approaches and places for subsequent
discussion.)
The patch above changes the loader to catch a mixed installation and
reject mixing incompatible libraries. The static linker does this
currently but it's not essential.
I have no idea whether shlib-versions files naming a file in a
subdirectory will work - but if not, you'd need to send a patch to
libc-alpha to support dynamic linkers in subdirectories, with appropriate
justification for why you are doing something different from all other
architectures.
Understood. For now this is just a path. There's more infrastructure
work needed if the path includes a directory.
(d) Existing practice for Power Architecture and MIPS at least is that
hard-float and soft-float *don't* use different library directories /
dynamic linkers.
The goal is to have a standard loader path for all hard float distros
and, similar to how you can have a mixed 32/64 bit installation, allow
mixed softfp/hard float installations for distros that want it. This
is a new requirement and ARM is the first one exposed to it. I assume
Debian would push for similar changes on MIPS and PowerPC.
Do the MIPS or PowerPC loaders detect the ABI and change the library
path based on that? I couldn't tell from the code.
(e) Existing practice for cases that do use different dynamic linkers is
to use a separate library directory, not just dynamic linker name, as in
lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
make two sets of libraries work in parallel if you have separate library
directories like that.
Is this required, or should it be left to the distro to choose? Once
the loader is in control then it can account for any distro specific
features, which may be the standard /lib and /usr/lib for single ABI
distros like Fedora or /usr/lib/$tuple for multiarch distros like
Ubuntu and Debian.
So it would seem more appropriate to define a directory libhf for ARM
(meaning you need a binutils patch as well to
handle that directory, I think)
I'd like to leave that discussion for now. The Debian goal is to
support incompatible ABIs and, past that, incompatible architectures.
libhf is ambiguous as you could have a MIPS hard float library
installed on the same system as an ARM hard float library.
and these different Debian-style names
could be implemented separately in a multiarch patch if someone submits
one that properly accounts for my review comments on previous patch
versions (failure to produce such a fixed patch being why Debian multiarch
directory support has not got into GCC so far).
Agreed. Note that this loader path discussion is unrelated to
multiarch. It came from the same people so there's a family
resemblance.
(BTW Dann, apologies for stealing your patch)
-- Michael
2012-04-03 Michael Hope michael.h
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 4 April 2012 18:54, Jakub Jelinek ja...@redhat.com wrote: On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote: I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be good to have to be able to run binaries for either without resorting to a chroot, and only testing purposes. Bumping major or calling it ld-linux-foo.so.3 is out of question? I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part. If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think. and for those that choose the Debian layout instead, if it is added somehow configurable into upstream gcc/glibc of course handle it similarly there. Agreed. I just wonder why that hasn't been done 10 years ago and only needs doing now FPUs have only become common on ARM in the last few years. softfp was a good interim work around but performance is significantly better with hard float. (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp). Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only. -- Michael
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 4 April 2012 21:06, Joseph S. Myers jos...@codesourcery.com wrote: On Wed, 4 Apr 2012, Michael Hope wrote: The tricky one is new GCC with old GLIBC. GCC may have to do a configure time test and fall back to /lib/ld-linux.so.3 if the hard float loader is missing. I don't think that's appropriate for ABI issues. If a different dynamic linker name is specified, GCC should use it unconditionally (and require new enough glibc or a glibc installation that was appropriately rearranged). OK. I want GCC 4.7.1 to use the new path. Does this mean that released versions of GLIBC and GCC 4.7.1 will be incompatible, or does GLIBC pick the path up from GCC? I have no idea whether shlib-versions files naming a file in a subdirectory will work - but if not, you'd need to send a patch to libc-alpha to support dynamic linkers in subdirectories, with appropriate justification for why you are doing something different from all other architectures. Understood. For now this is just a path. There's more infrastructure work needed if the path includes a directory. Formally it's just a path - but an important feature of GNU/Linux and the GNU toolchain is consistency between different architectures and existing upstream practice is that the dynamic linker is always in the same directory as the other associated libraries and that this has the form /libsomething. In the absence of a compelling reason, which I have not seen stated, to do otherwise for a single case, I think that existing practice should be followed with the dynamic linker being in a directory such as /libhf. OK. This matches Jakub's email. The more infrastructure work needed makes clear that you need libc-alpha buy-in *before* putting any patches into GCC or ports. OK. I'm glad we had this discussion as it had to start somewhere. I'll do a follow up across gcc-patches, libc-alpha, and binutils. But maybe if you don't try to put the dynamic linker in a different directory from the other libraries, it's easier to support via existing mechanisms (setting slibdir differently if --enable-multiarch-directories or similar)? OK. /libhf may fit that better. Do the MIPS or PowerPC loaders detect the ABI and change the library path based on that? I couldn't tell from the code. No, they don't detect the ABI. Both ABIs (and, for Power, the e500v1 and e500v2 variants - compatible with soft-float at the function-calling level but with some glibc ABI differences with soft-float and with each other) use the same directories. Sorry, I'm confused. I had a poke about with MIPS and it uses different argument registers for soft and hard float. Soft float uses $4 and hard float $f0. Are there shims or similar installed by the loader? (e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to make two sets of libraries work in parallel if you have separate library directories like that. Is this required, or should it be left to the distro to choose? Once the loader is in control then it can account for any distro specific features, which may be the standard /lib and /usr/lib for single ABI distros like Fedora or /usr/lib/$tuple for multiarch distros like Ubuntu and Debian. I thought Fedora used the standard upstream /lib64 on x86_64 and so would naturally use a standard upstream /libhf where appropriate. Good. Dennis said the same. So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to handle that directory, I think) I'd like to leave that discussion for now. The Debian goal is to support incompatible ABIs and, past that, incompatible architectures. libhf is ambiguous as you could have a MIPS hard float library installed on the same system as an ARM hard float library. If you want both ARM and MIPS hard-float then I'd think you want both big-endian and little-endian ARM hard-float - but your patch defines the same dynamic linker name for both of those. Big endian is extremely uncommon on ARM and I'd rather define it when needed. For strictness sake I'll change the patch to use the new path for hard float little endian only. So: * Big endian: undefined, defaults to /lib/ld-linux.so.3 * Little endian, soft float: /lib/ld-linux.so.3 * Little endian, hard float: /libhf/ld-linux.so.3 Standard upstream practice supports having multiple variants that plausibly run on the same system at the same time, such as /lib and /lib64, and it seems reasonable to support hard and soft float variants that way via a directory such as /libhf. The Debian-style paths are not the default on any other architecture and I don't think it's appropriate to make them the default for this particular case only. OK. Debian multiarch covers libraries and headers but not executables
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 5 April 2012 12:07, Joseph S. Myers jos...@codesourcery.com wrote: On Thu, 5 Apr 2012, Michael Hope wrote: I don't think that's appropriate for ABI issues. If a different dynamic linker name is specified, GCC should use it unconditionally (and require new enough glibc or a glibc installation that was appropriately rearranged). OK. I want GCC 4.7.1 to use the new path. Does this mean that released versions of GLIBC and GCC 4.7.1 will be incompatible, or does GLIBC pick the path up from GCC? Released versions would be incompatible (you could make GCC check at configure time for too-old glibc if --with-float=hard); the path needs hardcoding in both places. Do the MIPS or PowerPC loaders detect the ABI and change the library path based on that? I couldn't tell from the code. No, they don't detect the ABI. Both ABIs (and, for Power, the e500v1 and e500v2 variants - compatible with soft-float at the function-calling level but with some glibc ABI differences with soft-float and with each other) use the same directories. Sorry, I'm confused. I had a poke about with MIPS and it uses different argument registers for soft and hard float. Soft float uses $4 and hard float $f0. Are there shims or similar installed by the loader? No. A system is either purely hard-float or purely soft-float, and the same paths are used for both so they can't coexist. (Mismatches at *static* link time are detected through object attributes.) Ah, the same as ARM then. The MIPS community would need something similar to this patch if they wanted to support soft and hard float side by side. Big endian is extremely uncommon on ARM and I'd rather define it when needed. For strictness sake I'll change the patch to use the new path for hard float little endian only. I don't think that's correct; the new path should be used independent of endian, just as the existing path is. OK. But any multiarch support patch should presumably define separate multiarch paths for each endianness. That's up to Debian. I've asked for documentation on the final tuples and what they mean as the one at: http://wiki.debian.org/Multiarch/Tuples is out of date. I prefer defining what is needed now and doing others as needed. -- Michael
Re: [branches/google/gcc-4_6] Backported r179661 and 179662 from mainline. (issue 5989043)
On 5 April 2012 15:56, asha...@chromium.org wrote: Reviewers: Diego Novillo, jingyu, davidxl, Message: Please take a look at this patch and tell me if it's OK for branches/google/gcc-4_6. Description: Backported the following patch from trunk: 2011-10-07 Andrew Stubbs a...@codesourcery.com gcc/ * config/arm/predicates.md (shift_amount_operand): Remove constant range check. (shift_operator): Check range of constants for all shift operators. gcc/testsuite/ * gcc.dg/pr50193-1.c: New file. * gcc.target/arm/shiftable.c: New file. Please review this at http://codereview.appspot.com/5989043/ Affected files: M . M gcc/ChangeLog M gcc/ChangeLog.google-4_6 M gcc/config/arm/predicates.md M gcc/testsuite/ChangeLog A + gcc/testsuite/gcc.dg/pr50193-1.c A + gcc/testsuite/gcc.target/arm/shiftable.c Andrew, could you check that the Google guys have the final version of your patch? Could you backport the fix to the 4.6 release branch if valid? Better than having the same patch in three places. -- Michael
Re: Phone call (was Re: Armhf dynamic linker path)
On 12 April 2012 10:38, Steve McIntyre steve.mcint...@linaro.org wrote: On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: And here's the details as promised. I've started a wiki page at https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 with a strawman agenda for now, and a Doodle poll at http://www.doodle.com/93bitkqeb7auyxn7 to see when the best time is for the call on Thursday/Friday. Please fill in the times that work for you ASAP and I'll announce the result during Wednesday. Ideally we'd like stakeholders from all the relevant distros and the upstream toolchain developers to be there, able to represent their groups and (importantly) able to make a decision here on what we should do. Apologies for the short notice, but we need a decision quickly. And the best time turns out to be Friday at 15:00 UTC (16:00 BST, 11:00 EDT etc.). Of the 10 people who responded in the poll, the only person who can't make that time is Michael in .nz. Sorry, Michael. All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: * is similar to /lib/ld-x86-64.so.2 * keeps the libraries and loader in the same directory * doesn't invent a new /libhf directory * is easier to implement in GLIBC * is architecture and ABI unique * requires less change for distros where the hard float libraries are already in /lib I'm happy to do the GLIBC and GCC implementation. -- Michael
Re: Phone call (was Re: Armhf dynamic linker path)
2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@linaro.org wrote: On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: And here's the details as promised. I've started a wiki page at https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 with a strawman agenda for now, and a Doodle poll at http://www.doodle.com/93bitkqeb7auyxn7 to see when the best time is for the call on Thursday/Friday. Please fill in the times that work for you ASAP and I'll announce the result during Wednesday. Ideally we'd like stakeholders from all the relevant distros and the upstream toolchain developers to be there, able to represent their groups and (importantly) able to make a decision here on what we should do. Apologies for the short notice, but we need a decision quickly. And the best time turns out to be Friday at 15:00 UTC (16:00 BST, 11:00 EDT etc.). Of the 10 people who responded in the poll, the only person who can't make that time is Michael in .nz. Sorry, Michael. All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: * is similar to /lib/ld-x86-64.so.2 * keeps the libraries and loader in the same directory * doesn't invent a new /libhf directory * is easier to implement in GLIBC * is architecture and ABI unique * requires less change for distros where the hard float libraries are already in /lib Sorry for more bikeshedding, but afaik rpm based distros are using the armv7hl identifier, so it could as well be /lib/ld-linux-armv7hl.so.3 This includes the ABI (h), adds the endianess (l), and implies a architecture level (v7). The name for the most common configurations should be as short as possible so I'd rather drop the 'l' and add a 'b' or 'eb' if anyone wants a big endian distro in the future. The architecture level is a problem as the loader should also be valid on ARMv5 and ARMv6 hard float builds. Skype should be able to make a hard float binary that runs on everything, including a potential ARMv6 hard float RaspberryPi build. Other variant could be /armv7hl-linux/lib/ld.so.3 This introduces both a new directory and a new style for naming :) -- Michael
Re: Phone call (was Re: Armhf dynamic linker path)
On 12 April 2012 12:38, Wookey woo...@wookware.org wrote: +++ Michael Hope [2012-04-12 12:16 +1200]: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: Sorry for more bikeshedding, /lib/ld-linux-armv7hl.so.3 I'd rather drop the 'l' We've already had the GNU triplet-name argument for this ABI. I don't think having it again in order to use something slightly different for the linker name is very helpful. Unless of course we find that was another chimera and in fact that's not really agreed either... Sorry, I should have said that in my reply. I agree, the GNU triplet should be used. I couldn't resist going into the past-covered reasons why. -- Michael
Re: Phone call (was Re: Armhf dynamic linker path)
2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 21:16, Michael Hope michael.h...@linaro.org escreveu: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@linaro.org wrote: On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: And here's the details as promised. I've started a wiki page at https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 with a strawman agenda for now, and a Doodle poll at http://www.doodle.com/93bitkqeb7auyxn7 to see when the best time is for the call on Thursday/Friday. Please fill in the times that work for you ASAP and I'll announce the result during Wednesday. Ideally we'd like stakeholders from all the relevant distros and the upstream toolchain developers to be there, able to represent their groups and (importantly) able to make a decision here on what we should do. Apologies for the short notice, but we need a decision quickly. And the best time turns out to be Friday at 15:00 UTC (16:00 BST, 11:00 EDT etc.). Of the 10 people who responded in the poll, the only person who can't make that time is Michael in .nz. Sorry, Michael. All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: * is similar to /lib/ld-x86-64.so.2 * keeps the libraries and loader in the same directory * doesn't invent a new /libhf directory * is easier to implement in GLIBC * is architecture and ABI unique * requires less change for distros where the hard float libraries are already in /lib Sorry for more bikeshedding, but afaik rpm based distros are using the armv7hl identifier, so it could as well be /lib/ld-linux-armv7hl.so.3 This includes the ABI (h), adds the endianess (l), and implies a architecture level (v7). The name for the most common configurations should be as short as possible so I'd rather drop the 'l' and add a 'b' or 'eb' if anyone wants a big endian distro in the future. The architecture level is a problem as the loader should also be valid on ARMv5 and ARMv6 hard float builds. Skype should be able to make a hard float binary that runs on everything, including a potential ARMv6 hard float RaspberryPi build. This means ld.so (and what else? a skype binary should not come fully statically linked) should be built with -march=armv5te? That is, common denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set? AFAIK, for user level, armv6 with vfp is effectively amv7 (sans armv7-r that has a div instruction in thumb mode). The architecture and feature set is a different topic and should be discussed by the distros but I'd rather finish the loader path one first. Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have all taken the opportunity to go to ARMv7 at the same time as switching to hard float. -- Michael
[PATCH v2] ARM: Use different linker path for hardfloat ABI
Change the dynamic linker path for ARM hard float executables.
Matches the path discussed and agreed on last week[1]. Carlos will
follow up with the matching patch to GLIBC[2]. I'm happy to if he's
busy.
OK for trunk?
-- Michael
[1] http://sourceware.org/ml/libc-ports/2012-04/msg00060.html
[2] http://sourceware.org/ml/libc-ports/2012-04/msg00064.html
2012-04-23 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..3ddf812 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{!mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 24 April 2012 03:35, Richard Earnshaw rearn...@arm.com wrote:
On 22/04/12 23:20, Michael Hope wrote:
Change the dynamic linker path for ARM hard float executables.
Matches the path discussed and agreed on last week[1]. Carlos will
follow up with the matching patch to GLIBC[2]. I'm happy to if he's
busy.
OK for trunk?
-- Michael
[1] http://sourceware.org/ml/libc-ports/2012-04/msg00060.html
[2] http://sourceware.org/ml/libc-ports/2012-04/msg00064.html
2012-04-23 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..3ddf812 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{!mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
I think this should handle having the hard-float variant as the default
more gracefully, so something like:
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
+ %{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
But I haven't tested any of that.
It tests just fine when setting the float ABI at configure time or
explicitly. Updated patch is below. I prefer the original, shorter
version but the new one is easier for someone else to understand.
OK for trunk?
-- Michael
2012-04-24 Michael Hope michael.h...@linaro.org
Richard Earnshaw rearn...@arm.com
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..2ace6f0 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,17 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
+%{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
Re: divide 64-bit by constant for 32-bit target machines
On 21 April 2012 00:57, Dinar Temirbulatov dtemirbula...@gmail.com wrote: Hi, Here is the patch that adds support for divide 64-bit by constant for 32-bit target machines, this patch was tested on arm-7a with no new regressions, also I am not sure on how to avoid for example i686 targets since div operation there is fast compared to over targets and it showed better performance with libc/sysdeps/wordsize-32/divdi3.c __udivdi3 vs my implementation on the compiler side, it is not clear for me by looking at the udiv_cost[speed][SImode] value. Hi Dinar. I'm afraid it gives the wrong results for some dividends: * 82625484914982912 / 2023346444509052928: gives 4096, should be zero * 18317463604061229328 / 2023346444509052928: gives 4109, should be 9 * 12097415865295708879 / 4545815675034402816: gives 130, should be 2 * 18195490362097456014 / 6999635335417036800: gives 10, should be 2 The expanded version is very large. Perhaps it should only turn on at -O2 and always turn off at -Os? The speed increase is quite impressive - I'm seeing between 2.7 and 20x faster on a Cortex-A9 for things like x / 3. -- Michael
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 27 April 2012 08:20, Carlos O'Donell car...@systemhalted.org wrote:
On Mon, Apr 23, 2012 at 5:36 PM, Michael Hope michael.h...@linaro.org wrote:
2012-04-24 Michael Hope michael.h...@linaro.org
Richard Earnshaw rearn...@arm.com
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..2ace6f0 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,17 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
+ %{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
This patch is broken. Please fix this.
You can't use a named enumeration in cpp equality.
The type ARM_FLOAT_ABI_HARD is a named enumeration and evaluates to 0
as an unknown identifier.
Therefore #if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
evaluates to #if 0 == 0 and is always true.
Watch out that #define ARM_FLOAT_ABI_HARD ARM_FLOAT_ABI_HARD for
such enums is not conforming C99/C11.
I suggest you define the types as macros and then set the named enum
to those values, then use the macros in the header equality checks.
e.g.
#define VAL1 0 then enum FOO { RVAL1 = VAL1, ... }
Look at arm.h for the enum definition.
I've looked further into this and I think the original pre-#if version
is correct.
The float ABI comes from these places:
* The -mfloat-abi= command line argument, else
* The --with-float= configure time argument, else
* TARGET_DEFAULT_FLOAT_ABI from linux-eabi.h
In the first case the ABI is explicit. In the second
OPTION_DEFAULT_SPECS turns the configure time argument into an explict
-mfloat-abi=.
The patch below covers all cases, keeps the logic in the spec file,
and adds a comment linking the two #defines.
Tested by building with no configure flags, --wtih-float=softfp,
--with-float=hard, and then running with all combinations of
{,-mfloat-abi=softfp,-mfloat-abi=hard} {,-mglibc,-muclibc,-mbionic}.
OK?
-- Michael
2012-04-27 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER): Pick the loader
using a spec rule.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 2ace6f0..e3cba57 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -60,19 +60,17 @@
#define SUBTARGET_EXTRA_LINK_SPEC -m TARGET_LINKER_EMULATION
/* Use ld-linux.so.3 so that it will be possible to run classic
- GNU/Linux binaries on an EABI system. */
+ GNU/Linux binaries on an EABI system.
+ Use ld-linux-armhf.so.3 so that it will be possible to install both
+ hard and soft float binaries on a system. */
#undef GLIBC_DYNAMIC_LINKER
#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
-#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
-#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
-#else
-#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
-#endif
+/* Update this rule if TARGET_DEFAULT_FLOAT_ABI changes from
+ ARM_FLOAT_ABI_SOFT. */
#define GLIBC_DYNAMIC_LINKER \
- %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
-%{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
-%{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT \
+ ; : GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 1 May 2012 03:24, Richard Earnshaw rearn...@arm.com wrote:
On 27/04/12 00:27, Michael Hope wrote:
On 27 April 2012 08:20, Carlos O'Donell car...@systemhalted.org wrote:
On Mon, Apr 23, 2012 at 5:36 PM, Michael Hope michael.h...@linaro.org
wrote:
2012-04-24 Michael Hope michael.h...@linaro.org
Richard Earnshaw rearn...@arm.com
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..2ace6f0 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,17 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+ %{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
+ %{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
This patch is broken. Please fix this.
You can't use a named enumeration in cpp equality.
The type ARM_FLOAT_ABI_HARD is a named enumeration and evaluates to 0
as an unknown identifier.
Therefore #if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
evaluates to #if 0 == 0 and is always true.
Watch out that #define ARM_FLOAT_ABI_HARD ARM_FLOAT_ABI_HARD for
such enums is not conforming C99/C11.
I suggest you define the types as macros and then set the named enum
to those values, then use the macros in the header equality checks.
e.g.
#define VAL1 0 then enum FOO { RVAL1 = VAL1, ... }
Look at arm.h for the enum definition.
I've looked further into this and I think the original pre-#if version
is correct.
The float ABI comes from these places:
* The -mfloat-abi= command line argument, else
* The --with-float= configure time argument, else
* TARGET_DEFAULT_FLOAT_ABI from linux-eabi.h
In the first case the ABI is explicit. In the second
OPTION_DEFAULT_SPECS turns the configure time argument into an explict
-mfloat-abi=.
The patch below covers all cases, keeps the logic in the spec file,
and adds a comment linking the two #defines.
Tested by building with no configure flags, --wtih-float=softfp,
--with-float=hard, and then running with all combinations of
{,-mfloat-abi=softfp,-mfloat-abi=hard} {,-mglibc,-muclibc,-mbionic}.
OK?
-- Michael
2012-04-27 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER): Pick the loader
using a spec rule.
Michael,
can you try this patch please. It should make it possible to then
create linux-eabihf.h containing just
#undef TARGET_DEFAULT_FLOAT_ABI
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
#undef GLIBC_DYNAMIC_LINKER_DEFAULT
#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
Which is not quite as simple as leaving out the second re-define, but
pretty close.
Hi Richard. Your patch tests just fine. I like it. You could change
the spec rule to the newer if-elseif-else form but that's a nit.
-- Michael
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 1 May 2012 10:01, Jeff Law l...@redhat.com wrote: On 04/30/2012 03:47 PM, Michael Hope wrote: 2012-04-27 Michael Hopemichael.h...@linaro.org * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER): Pick the loader using a spec rule. Michael, can you try this patch please. It should make it possible to then create linux-eabihf.h containing just #undef TARGET_DEFAULT_FLOAT_ABI #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD #undef GLIBC_DYNAMIC_LINKER_DEFAULT #define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT Which is not quite as simple as leaving out the second re-define, but pretty close. Hi Richard. Your patch tests just fine. I like it. You could change the spec rule to the newer if-elseif-else form but that's a nit. So who owns creating the appropriate glibc patch now that we've got a good gcc patch? Carlos is working on the GLIBC patch: http://sourceware.org/ml/libc-ports/2012-04/msg00171.html -- Michael
[PATCH, 4.6] Fix PR53170: missing target c++11 selector
The testsuite for PR52796 uses the 'target c++11' selector which doesn't exist
in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector target c++11 for dg-do 2 run { target c++11 }
'
errors which have appeared in recent 4.6 builds.
Tested on x86_64-linux-gnu with no regressions. Changes the ERROR to
UNSUPPORTED.
OK for 4.6?
-- Michael
2012-05-21 Michael Hope michael.h...@linaro.org
PR 53170
Backport from mainline
2011-11-08 Jason Merrill ja...@redhat.com
* lib/target-supports.exp (check_effective_target_c++11): New.
=== modified file 'gcc/testsuite/lib/target-supports.exp'
--- gcc/testsuite/lib/target-supports.exp 2012-02-22 17:38:22 +
+++ gcc/testsuite/lib/target-supports.exp 2012-05-18 01:57:51 +
@@ -3822,6 +3822,17 @@
return 0
}
+# Check which language standard is active by checking for the presence of
+# one of the C++11 -std flags. This assumes that the default for the
+# compiler is C++98, and that there will never be multiple -std= arguments
+# on the command line.
+proc check_effective_target_c++11 { } {
+if ![check_effective_target_c++] {
+ return 0
+}
+return [check-flags { { } { } { -std=c++0x -std=gnu++0x -std=c++11
-std=gnu++11 } }]
+}
+
# Return 1 if the language for the compiler under test is C++.
proc check_effective_target_c++ { } {
Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector
On 21/05/12 21:14, Paolo Carlini wrote:
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which doesn't exist
in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector target c++11 for dg-do 2 run { target c++11 }
'
errors which have appeared in recent 4.6 builds.
Tested on x86_64-linux-gnu with no regressions. Changes the ERROR to
UNSUPPORTED.
OK for 4.6?
To be honest, when I saw the issue I thought we wanted simply to not use the target
selector at all in the branch and simply add a // { dg-options -std=c++11 } I
thought somebody would commit the change as obvious ;)
Sure. The version below changes the selector for explicit flags that match
those passed by trunk.
OK for 4.6?
-- Michael (who's not keen enough to commit as obvious)
2012-05-23 Michael Hope michael.h...@linaro.org
PR PR52796
* g++.dg/cpp0x/variadic-value1.C: Change selector for explicit
options.
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
b/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
index 179919a..301bd54 100644
--- a/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
@@ -1,5 +1,5 @@
// PR c++/52796
-// { dg-do run { target c++11 } }
+// { dg-options -std=c++0x -pedantic-errors }
inline void *operator new(__SIZE_TYPE__ s, void *p) { return p; }
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 24 May 2012 02:16, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote: On Wed, 23 May 2012, Andreas Jaeger wrote: On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote: [...] This is a behaviour change. It would need RM approval for a release branch. R. There was agreement by all pushing for the change to use it. So, let's ask the release managers about their opinion, I'm ok with the change - but of course only to carry one less patch in our local tree. What do others think? It would definitely (anyway) need documenting in changes.html (for both 4.7.1 and 4.8). i've done this for Gentoo and 4.5.0+, so if all the distros are going to be doing this in 4.7.x anyways, makes sense to me to do it in the official branch. Agreed. Google have done it for their 4.6, Fedora have done it for 4.7 (?), and we've done it for Linaro GCC 4.6 and 4.7. My concern is that a point release of GCC would stop working against the latest release of GLIBC. I'm happy to prepare a backport to GCC 4.6, GCC 4.7, and GLIBC 2.15 so the next set of point releases will all work with each other. This would match what the distros are doing. -- Michael
Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector
On 24 May 2012 00:27, Paolo Carlini paolo.carl...@oracle.com wrote:
On 05/23/2012 05:39 AM, Michael Hope wrote:
On 21/05/12 21:14, Paolo Carlini wrote:
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which doesn't
exist in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector target c++11 for dg-do 2 run {
target c++11 } '
errors which have appeared in recent 4.6 builds.
Tested on x86_64-linux-gnu with no regressions. Changes the ERROR to
UNSUPPORTED.
OK for 4.6?
To be honest, when I saw the issue I thought we wanted simply to not use
the target selector at all in the branch and simply add a // { dg-options
-std=c++11 } I thought somebody would commit the change as obvious ;)
Sure. The version below changes the selector for explicit flags that
match those passed by trunk.
OK for 4.6?
-- Michael (who's not keen enough to commit as obvious)
I would say let's go ahead ;) But in the ChangeLog entry please use PR
c++/52796.
Done as per http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00810.html and
the typo fix in http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00813.html.
-- Michael
[PATCH, 4.7] Enable the libstdc++ prettyprinters test suite
The libstdc++ prettyprinters test suite isn't called out in Makefile.am. Backport Andreas's patch from mainline so that a sequential test run gives the same results as a parallel test. Tested with no regressions on x86_64-linux-gnu and arm-linux-gnueabi. The prettyprinter tests are enabled as expected. OK for 4.7? -- Michael 2012-07-25 Michael Hope michael.h...@linaro.org Backport from mainline r186389: 2012-04-12 Andreas Schwab sch...@linux-m68k.org * testsuite/Makefile.am (check_DEJAGNUnormal0): Run prettyprinters.exp. * testsuite/Makefile.in: Regenerated. diff --git a/libstdc++-v3/testsuite/Makefile.am b/libstdc++-v3/testsuite/Makefile.am index 7094ad5..0cf8de5 100644 --- a/libstdc++-v3/testsuite/Makefile.am +++ b/libstdc++-v3/testsuite/Makefile.am @@ -134,7 +134,7 @@ check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp normal0) \ if $(SHELL) -c $$runtest --version /dev/null 21; then \ $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) \ - $(RUNTESTFLAGS) abi.exp; \ + $(RUNTESTFLAGS) abi.exp prettyprinters.exp; \ else echo WARNING: could not find \`runtest' 12; :;\ fi; \ dirs=`cd $$srcdir; echo [013-9][0-9]_*/*`;; \ diff --git a/libstdc++-v3/testsuite/Makefile.in b/libstdc++-v3/testsuite/Makefile.in index e433bb9..bb077d1 100644 --- a/libstdc++-v3/testsuite/Makefile.in +++ b/libstdc++-v3/testsuite/Makefile.in @@ -572,7 +572,7 @@ check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp normal0) \ if $(SHELL) -c $$runtest --version /dev/null 21; then \ $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) \ - $(RUNTESTFLAGS) abi.exp; \ + $(RUNTESTFLAGS) abi.exp prettyprinters.exp; \ else echo WARNING: could not find \`runtest' 12; :;\ fi; \ dirs=`cd $$srcdir; echo [013-9][0-9]_*/*`;; \
Re: [PATCH, 4.7] Enable the libstdc++ prettyprinters test suite
cc'ed the libstdc++ list. Ping? -- Michael On 25/07/12 12:12, Michael Hope wrote: The libstdc++ prettyprinters test suite isn't called out in Makefile.am. Backport Andreas's patch from mainline so that a sequential test run gives the same results as a parallel test. Tested with no regressions on x86_64-linux-gnu and arm-linux-gnueabi. The prettyprinter tests are enabled as expected. OK for 4.7? -- Michael 2012-07-25 Michael Hope michael.h...@linaro.org Backport from mainline r186389: 2012-04-12 Andreas Schwab sch...@linux-m68k.org * testsuite/Makefile.am (check_DEJAGNUnormal0): Run prettyprinters.exp. * testsuite/Makefile.in: Regenerated. diff --git a/libstdc++-v3/testsuite/Makefile.am b/libstdc++-v3/testsuite/Makefile.am index 7094ad5..0cf8de5 100644 --- a/libstdc++-v3/testsuite/Makefile.am +++ b/libstdc++-v3/testsuite/Makefile.am @@ -134,7 +134,7 @@ check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp normal0) \ if $(SHELL) -c $$runtest --version /dev/null 21; then \ $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) \ -$(RUNTESTFLAGS) abi.exp; \ +$(RUNTESTFLAGS) abi.exp prettyprinters.exp; \ else echo WARNING: could not find \`runtest' 12; :;\ fi; \ dirs=`cd $$srcdir; echo [013-9][0-9]_*/*`;; \ diff --git a/libstdc++-v3/testsuite/Makefile.in b/libstdc++-v3/testsuite/Makefile.in index e433bb9..bb077d1 100644 --- a/libstdc++-v3/testsuite/Makefile.in +++ b/libstdc++-v3/testsuite/Makefile.in @@ -572,7 +572,7 @@ check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp normal0) \ if $(SHELL) -c $$runtest --version /dev/null 21; then \ $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) \ -$(RUNTESTFLAGS) abi.exp; \ +$(RUNTESTFLAGS) abi.exp prettyprinters.exp; \ else echo WARNING: could not find \`runtest' 12; :;\ fi; \ dirs=`cd $$srcdir; echo [013-9][0-9]_*/*`;; \
Re: [PATCH, ARM] Don't pull in unwinder for 64-bit division routines
On 17 August 2012 07:29, Julian Brown jul...@codesourcery.com wrote: On Thu, 16 Aug 2012 19:56:52 +0100 Ramana Radhakrishnan ramra...@arm.com wrote: On 07/24/12 13:27, Julian Brown wrote: On Fri, 20 Jul 2012 11:15:27 +0100 Julian Brown jul...@codesourcery.com wrote: Anyway: this revised version of the patch removes the strange libgcc Makefile-fragment changes, the equivalent of which have since been incorporated into mainline GCC now anyway, so the patch is somewhat more straightforward than it was previously. Joey Ye contacted me offlist and suggested that the t-divmod-ef fragment might be better integrated into t-bpabi instead. Doing that makes the patch somewhat smaller/cleaner. Minimally re-tested, looks OK. The original submission makes no mention of testing ? The ARM specific portions look OK to me modulo no regressions. Thanks -- I'm sure I did test the patch, but just omitted to mention that fact in the mail :-O. We've also been carrying a version of this patch in our local source base for many years now. Hi Julian. The test case fails on arm-linux-gnueabi: http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02100.html FAIL: gcc.target/arm/div64-unwinding.c execution test The test aborts as _Unwind_RaiseException is not null. _divdi3.o itself looks fine and no longer pulls in the unwinder so I assume something else in the environment is. I've put the binaries up at http://people.linaro.org/~michaelh/incoming/div64-unwinding.exe and http://people.linaro.org/~michaelh/incoming/_divdi3.o if that helps. -- Michael
Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses
On 8 June 2012 12:15, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: (CC to ARM maintainer approving the original patch.) I'm listing this under caveats rather than improvements and before the current top ARM-related caveat (as this one is more important :) because I don't see performance figures in the context of the original patch (r178852) backing up this as an improvement, and it caused sort-of a wild goose hunt for applications causing unaligned accesses, until it was found to be deliberately emitted by gcc-4.7 when configured for arm-unknown-linux-gnueabi and passing -marmv6. Hence caveat. Nomenclature taken from that patch; if prefer a different spelling of the ARM variants, please tell how. The some source codes was in the analyzed case a strcpy of a five-byte string (busybox/libbb/procps.c:365 'strcpy(filename_tail, stat);' of some unknown busybox-version). An OS configured with unaligned accesses turned off (IIUC the default for Linux/ARM), has the nice property that you easily spot a certain class of bad codes. Ok to commit? The wording is scarier than I'd like. Userspace and the Linux kernel post 3.1 are fine. Earlier kernels fail to start due to the kernel turning off the hardware support and an interaction of -fconserve-stack and -munaligned-access cause a char array to be unaligned on the stack. I don't agree that unaligned access is a sign of wrong code. It's very common when poking about in protocol buffers. Using the hardware support is better than the multi-byte read plus OR that GCC used to do. Where else have you seen this? Alternatively and IMHO preferably, there's reason enough to revert the (new) default, including the gcc-4.7 branch. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.113 diff -p -u -r1.113 changes.html --- changes.html 5 Jun 2012 11:03:53 - 1.113 +++ changes.html 8 Jun 2012 00:01:09 - @@ -43,6 +43,16 @@ /li + liOn ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, + ARMv7-R, or ARMv7-M How about ARMv6K and above? or ARMv6 and above, except for ARMv6-M the default of the new option + code-munaligned-accesses/code is on, which for some source + codes generates code that accesses memory on unaligned adresses. + This will require the OS of those systems to enable such accesses + (controlled by CP15 register c1, refer to ARM documentation). The CPU has an unaligned access trap which is off by default. The kernel has to turn the trap on to cause the fault. + Alternatively or for compatibility with OS versions that do not + enable unaligned accesses, all codes has to be compiled with + code-mno-unaligned-accesses/code./li + liSupport on ARM for the legacy floating-point accelerator (FPA) and the mixed-endian floating-point format that it used has been obsoleted. The ports that still use this format have been obsoleted as well. brgds, H-P
Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses
On 8 June 2012 15:20, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote:
From: Michael Hope michael.h...@linaro.org
Date: Fri, 8 Jun 2012 04:42:30 +0200
On 8 June 2012 12:15, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote:
The some source
codes was in the analyzed case a strcpy of a five-byte string
(busybox/libbb/procps.c:365 'strcpy(filename_tail, stat);' of
some unknown busybox-version).
An OS configured with unaligned accesses turned off (IIUC the
default for Linux/ARM), has the nice property that you easily
spot a certain class of bad codes.
Ok to commit?
The wording is scarier than I'd like. Userspace and the Linux kernel
post 3.1 are fine.
So the default for ALIGNMENT_TRAP changed in 3.1?
ALIGNMENT_TRAP is on by default but the early boot time trap is now
conditional on the architecture level:
__enable_mmu:
#if defined(CONFIG_ALIGNMENT_TRAP) __LINUX_ARM_ARCH__ 6
orr r0, r0, #CR_A
#else
bic r0, r0, #CR_A
#endif
Earlier kernels fail to start due to the kernel
turning off the hardware support and an interaction of
-fconserve-stack and -munaligned-access cause a char array to be
unaligned on the stack.
I don't agree that unaligned access is a sign of wrong code. It's
very common when poking about in protocol buffers. Using the hardware
support is better than the multi-byte read plus OR that GCC used to
do.
Totally disagree. Code that e.g. casts unaligned char * to int *
and dereferences that, is crappy and unportable and fails
without OS-configury choice on some platforms, and is also
avoidable. But hopefully that wasn't what you meant.
I mean direct access via helpers:
inline u16 get_u16(const char *p) {
#ifdef __ARM_FEATURE_UNALIGNED
return ntohs(*(const u16 *)p);
#else
...
}
...
u16 checksum = get_u16(buffer + CHECKSUM_OFFSET);
Where else have you seen this?
I don't get the else. I've seen the unaligned accesses from
userland code as quoted above. There were other (userland)
places in that build-tree that I'm not going to check, as this
was (again) GCC-generated code. There were no other misaligned
accesses on that system; not from the kernel, not from userspace.
You're suggesting we disable an optimisation. The combination of
older Linux ARM kernels and GCC 4.7 gives a faulty kernel. In all
other cases it should be an improvement. Have you seen other
combinations where there's a fault when this feature is turned on?
-- Michael
Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses
On 8 June 2012 16:53, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: From: Hans-Peter Nilsson h...@axis.com Date: Fri, 8 Jun 2012 06:29:04 +0200 From: Michael Hope michael.h...@linaro.org Date: Fri, 8 Jun 2012 05:50:52 +0200 The combination of older Linux ARM kernels and GCC 4.7 gives a faulty kernel. We're in agreement! Oh wait sorry, my bad, I misread. Instead of gives a faulty kernel, I'd say for ARMv6 and later (not -M), gives faulty user-space code. Maybe the kernel too, I can't say; there was IIRC no sign of it. Is there a bugzilla ticket logged for this? I'd like to try to reproduce it. It's interesting as we backported the patch into the Linaro GCC that was used to build Ubuntu Precise and didn't find any faults. -- Michael
Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses
On 13 June 2012 02:32, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote:
From: Hans-Peter Nilsson h...@axis.com
Date: Mon, 11 Jun 2012 00:59:57 +0200
From: Michael Hope michael.h...@linaro.org
Date: Mon, 11 Jun 2012 00:04:19 +0200
On 8 June 2012 16:53, Hans-Peter Nilsson hans-peter.nils...@axis.com
wrote:
From: Hans-Peter Nilsson h...@axis.com
Date: Fri, 8 Jun 2012 06:29:04 +0200
From: Michael Hope michael.h...@linaro.org
Date: Fri, 8 Jun 2012 05:50:52 +0200
The combination of
older Linux ARM kernels and GCC 4.7 gives a faulty kernel.
We're in agreement!
Oh wait sorry, my bad, I misread. Instead of gives a faulty
kernel, I'd say for ARMv6 and later (not -M), gives faulty
user-space code. Maybe the kernel too, I can't say; there was
IIRC no sign of it.
But (at least) after removing some local changed defaults,
there's at boot-time a lot of:
[ 0.95] Unhandled fault: alignment exception (0x801) at 0xc821ddee
That's a kernel address. What does /proc/kallsyms say is there?
For reference, the message comes from
arch/arm/mm/alignment.c:alignment_init() from the default trap
handler. The lines just before this disable the unaligned trap for
usermode:
if (cpu_is_v6_unaligned()) {
cr_alignment = ~CR_A;
cr_no_alignment = ~CR_A;
set_cr(cr_alignment);
ai_usermode = safe_usermode(ai_usermode, false);
}
Support was added by Russell King in 2008-12 and updated by Dave
Martin on 2011-07.
Out of interest, does your CPU report support for unaligned access via
CP15 CR1? It's bit 22 and shows during boot. My board shows:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=50c5387d
Is there a bugzilla ticket logged for this? I'd like to try to reproduce
it.
Here's a shorter case I'll attach to a PR for this unless it
gets resolved one way or another soonish. Remember, you'll have
to run this on a pre-3.2 kernel with CONFIG_ALIGNMENT_TRAP on
(the default) and you have to compile for ARM v6 or later (as in
-march=armv6). Using gcc-4.7.1-rc1 should do, most likely
earlier revisions too.
__attribute__ ((__noinline__, __noclone__))
void doit(char *x)
{
asm ();
__builtin_strcpy (x, stat);
}
int main(void)
{
char x[30];
doit(x + 1);
doit(x);
__builtin_exit (0);
}
This compiles into a five byte unaligned memcpy:
doit:
mov r2, r0
movwr3, #:lower16:.LC0
movtr3, #:upper16:.LC0
ldr r0, [r3, #0]@ unaligned
ldrbr3, [r3, #4]@ zero_extendqisi2
str r0, [r2, #0]@ unaligned
strbr3, [r2, #4]
bx lr
which is correct. The test case runs on my boards and kernels as
noted below. /proc/cpu/alignment doesn't change so the loads and
stores were handled by the hardware.
I added:
__attribute__ ((__noinline__, __noclone__))
long long doit2(char *x)
{
asm ();
return *(long long *)x;
}
which becomes:
doit2:
ldmia r0, {r0, r1}
bx lr
ldm must be aligned. The program runs to completion but this time the
kernel traps and handles the unaligned load:
cbuild@ursa1:~/bugs$ cat /proc/cpu/alignment before
cbuild@ursa1:~/bugs$ ./a.out
cbuild@ursa1:~/bugs$ cat /proc/cpu/alignment after
cbuild@ursa1:~/bugs$ diff -u before after
--- before 2012-06-12 22:29:20.428268001 +
+++ after 2012-06-12 22:29:26.107955560 +
@@ -1,8 +1,8 @@
-User: 3
+User: 4
System:7
Skipped: 0
Half: 0
Word: 0
DWord: 0
-Multi: 10
+Multi: 11
User faults: 2 (fixup)
It's interesting as we backported the patch into the Linaro GCC that
was used to build Ubuntu Precise and didn't find any faults.
I have no idea why you didn't run into this, unless it was one
of the obvious reasons: not building for ARM v6 or the kernel
was 3.2 or later, or configured with CONFIG_ALIGNMENT_TRAP off.
Or other local patches of yours.
Linaro's stock configuration is -march=armv7-a -mtune=cortex-a9
-mthumb. Ubuntu is the same. I can't reproduce the fault on a
PandaBoard with omapzoom 2.6.35, Ubuntu 3.2.14, Ubuntu Precise 4.6.3
GCC, or plain gcc-4.7.1-RC-20120606. The configurations for the
kernels are at:
*
http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/hardware/view/head:/ursa/r2/config
*
http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/hardware/view/head:/distro/precise/r1/config
and have CONFIG_ALIGNMENT_TRAP on.
-- Michael
Re: [PING ARM Patches] PR53447: optimizations of 64bit ALU operation with constant
On 18 June 2012 22:17, Carrot Wei car...@google.com wrote: Hi Could ARM maintainers review following patches? http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00497.html 64bit add/sub constants. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01834.html 64bit and with constants. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01974.html 64bit xor with constants. http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00287.html 64bit ior with constants. Hi Carrot. Out of interest, how do these interact with the 64 bit in NEON patches that Andrew has been doing? They seem to touch many of the same patterns and I'm concerned that they'd cause GCC to prefer core registers instead of NEON, especially as the constant values you can use in a vmov are limited. There's a (in progress) summary of the current state for the standard C operators here: https://wiki.linaro.org/MichaelHope/Sandbox/64BitOperations -- Michael
[PATCH, 4.6] Unsupported c++-11 selector in nullptr28.C
This patch fixes a selector fault in the new g++.dg/cpp0x/nullptr28.C test
by changing the c++-11 target selector to the equivalent options. The
test itself was backported from trunk in r188953 to fix PR52988.
Tested on x86_64-linux. The ERROR changes to a PASS.
OK for 4.6?
-- Michael
gcc/testsuite/
2012-07-03 Michael Hope michael.h...@linaro.org
PR c++/53814
* g++.dg/cpp0x/nullptr28.C: Change selector for explicit
options.
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
index 05fbe57..4cc790d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
@@ -1,4 +1,5 @@
-// { dg-do run { target c++11 } }
+// { dg-do run }
+// { dg-options -std=c++0x -pedantic-errors }
typedef decltype(nullptr) nullptr_t;
Re: [RFA/ARM 1/3] Add VFP support for VFMA and friends
On 5 July 2012 21:13, Matthew Gretton-Dann matthew.gretton-d...@arm.com wrote: On 26/06/12 14:44, Richard Earnshaw wrote: On 25/06/12 15:59, Matthew Gretton-Dann wrote: All, This patch adds support to the ARM backend for generating floating-point fused multiply-accumulate. OK? gcc/ChangeLog: 2012-06-25 Matthew Gretton-Dann matthew.gretton-d...@arm.com * config/arm/iterators.md (SDF): New mode iterator. (V_if_elem): Add support for SF and DF modes. (V_reg): Likewise. (F_w_constraint): New mode iterator attribute. (F_r_constraint): Likewise. (F_fma_type): Likewise. (F_target): Likewise. config/arm/vfp.md (fmamode4): New pattern. (*fmsubmode4): Likewise. (*fmnsubmode4): Likewise. (*fmnaddmode4): Likewise. F_target as an attribute name doesn't tell me anything useful. I suggest F_maybe_not_df. + TARGET_32BIT TARGET_HARD_FLOAT TARGET_FMA F_target This should be written as TARGET_32BIT TARGET_HARD_FLOAT TARGET_FMA F_maybe_not_df Then the attribute should expand (define_mode_attr F_maybe_not_df [(SF 1) (DF TARGET_VFP_DOUBLE)]) As I style nit, I would also suggest using the iterator name when it appears in the pattern name, even though it is redundant. This avoids potential ambiguities when there are multiple iterators operating on different expansions. That is, instead of: (define_insn fmamode4 use: (define_insn fmaSDF:mode4 OK with those changes. R. Now checked in with some changes (see attached patch for what was committed) - changes approved off list. Hi Matt. Your new patterns require TARGET_HARD_FLOAT but the testsuite doesn't giving failures when building for soft float[1] or softfp[2]. Which should it be? -- Michael [1] http://builds.linaro.org/toolchain/gcc-4.8~svn189401/logs/armv7l-natty-cbuild344-tcpanda06-armv5r2/gcc-testsuite.txt [2] http://builds.linaro.org/toolchain/gcc-4.8~svn189401/logs/armv7l-natty-cbuild344-tcpanda02-cortexa9r1/gcc-testsuite.txt
[PATCH, ARM] fix PR pch/45979 regression on ARM
Linux 2.6.35 and later on ARM randomise the address space, breaking precompiled header support in GCC. The fix is to use the support in GCC for mmap()ing into a fixed, likely to be free address. The ARM memory map is modeled on the i386 so I used the same definition. Tested on trunk with a Ubuntu 2.6.35 kernel. Bootstraps OK and clears all of the PCH testsuite failures. Note that this change is equivalent to Mikael Pettersson's patch at: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02252.html OK for trunk? -- Michael gcc/ 2011-05-02 Michael Hope michael.h...@linaro.org PR pch/45979 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __ARM_EABI__ hosts. diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c index 47ce3ea..8b41685 100644 --- a/gcc/config/host-linux.c +++ b/gcc/config/host-linux.c @@ -84,6 +84,8 @@ # define TRY_EMPTY_VM_SPACE0x6000 #elif defined(__mc68000__) # define TRY_EMPTY_VM_SPACE0x4000 +#elif defined(__ARM_EABI__) +# define TRY_EMPTY_VM_SPACE0x6000 #else # define TRY_EMPTY_VM_SPACE0 #endif
Re: [PATCH][ARM] -m{cpu,tune,arch}=native
On Sat, Aug 27, 2011 at 3:19 AM, Andrew Stubbs a...@codesourcery.com wrote: Hi all, This patch adds support for -mcpu=native, -mtune=native, and -march=native for ARM Linux hosts. So far, it only recognises Cortex-A8 and Cortex-A9, so I really need to find out what the magic part numbers are for other cpus before this patch is complete. I couldn't just find this information listed anywhere. I think there are a lot of clues in the kernel code, but it's hard to mine and it mostly only goes as far the architecture version, not the individual cpu. Could you send linaro-dev@ an email and ask them where this API is documented? Hmm. Should there be a -mfpu=native that picks between soft, VFP, and NEON based on the host? -- Michael
Re: [PATCH][ARM] -m{cpu,tune,arch}=native
On Tue, Aug 30, 2011 at 10:47 PM, Stubbs, Andrew andrew_stu...@mentor.com wrote: On 29/08/11 04:29, Michael Hope wrote: On Sat, Aug 27, 2011 at 3:19 AM, Andrew Stubbsa...@codesourcery.com wrote: Hi all, This patch adds support for -mcpu=native, -mtune=native, and -march=native for ARM Linux hosts. So far, it only recognises Cortex-A8 and Cortex-A9, so I really need to find out what the magic part numbers are for other cpus before this patch is complete. I couldn't just find this information listed anywhere. I think there are a lot of clues in the kernel code, but it's hard to mine and it mostly only goes as far the architecture version, not the individual cpu. Could you send linaro-dev@ an email and ask them where this API is documented? API? It reads /proc/cpuinfo, and that just spits out the magic numbers from the processor registers. Linaro-dev might know more magic numbers though. Yip, most (all?) of the files under /proc are an API between user space and the kernel and have the usual requirements of usability and compatibility. -- Michael
Re: [patch, arm] Fix PR target/50305 (arm_legitimize_reload_address problem)
On Sat, Sep 10, 2011 at 5:04 AM, Ulrich Weigand uweig...@de.ibm.com wrote: Hello, the problem in PR 50305 turned out to be caused by the ARM back-end LEGITIMIZE_RELOAD_ADDRESS implementation. Interesting the fault goes away with -mfpu=neon, perhaps due to the DI mode operations getting pushed out into NEON registers. You might want to be explicit about the FPU in dg-options. -- Michael
Re: [PATCH,ARM] Improve peepholes for LDM with commutative operators
On Thu, Mar 1, 2012 at 3:20 AM, Greta Yorsh greta.yo...@arm.com wrote: I'm attaching a new version of the patch. Fixed all comments and retested. No regression on qemu --with-cpu cortex-a9. I assume that on the Cortex-A9 this generates a LDM instead of an expensive LDRD. For reference, a tight load loop takes 2.5 s on the current version, 3.1 s with a LDRD, and 1.9 s with a LDM. -- Michael
[PATCH, ARM, 4.6] backport PR pch/45979
Hi there. This patch backports my PCH on ARM EABI fix[1] for pch/PR45979 to the 4.6 branch. This fixes PCH support on ARM and tidies up the random pch testsuite failures that are seen between runs. OK for 4.6? -- Michael [1] http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00017.html gcc/ 2012-03-16 Michael Hope michael.h...@linaro.org Backport from mainline 2011-05-05 Michael Hope michael.h...@linaro.org PR pch/45979 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __ARM_EABI__ hosts. diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c index 47ce3ea..ec61055 100644 --- a/gcc/config/host-linux.c +++ b/gcc/config/host-linux.c @@ -84,6 +84,8 @@ # define TRY_EMPTY_VM_SPACE0x6000 #elif defined(__mc68000__) # define TRY_EMPTY_VM_SPACE0x4000 +#elif defined(__ARM_EABI__) +# define TRY_EMPTY_VM_SPACE 0x6000 #else # define TRY_EMPTY_VM_SPACE0 #endif
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 3 April 2012 09:06, dann frazier dann.fraz...@canonical.com wrote:
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.
Hi Dann. The change should be in the EABI specific linux-eabi.h
instead of the shared/OABI linux-elf.h. It breaks support for uClibc
and Bionic by always using the GLIBC loader in hard float mode. The
final line in the spec is missing a '=hard' and always adds
/lib/ld-linux.so.3.
How about:
2012-04-03 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8498472 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,12 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
/lib/arm-linux-gnueabihf/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER \
+ %{mhard-float: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{!mfloat-abi=hard:%{!mhard-float: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }}
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
which works for the following test cases:
gcc -mhard-float foo.c = /lib/arm-linux-gnueabihf/ld-linux.so.3
gcc -mfloat-abi=hard foo.c = /lib/arm-linux-gnueabihf/ld-linux.so.3
gcc -msoft-float foo.c = /lib/ld-linux.so.3
gcc -mfloat-abi=softfp foo.c = /lib/ld-linux.so.3
gcc -mbionic = /system/bin/linker
gcc -mbionic -mhard-float = /system/bin/linker
gcc -muclibc = /lib/ld-uClibc.so.0
gcc -muclibc -mhard-float = /lib/ld-uClibc.so.0
-- Michael
Re: [RFC, ARM] Convert thumb1 prologue completely to rtl
On Sun, Jun 19, 2011 at 7:02 AM, Richard Henderson r...@twiddle.net wrote: I couldn't find anything terribly tricky about the conversion. The existing push_mult pattern would service thumb1 with just a tweak or two to the memory predicate and the length. The existing emit_multi_reg_push wasn't set up to handle a complete switch of registers for unwind info. I thought about trying to merge them, but thought chickened out. I havn't cleaned out the code that is now dead in thumb_pushpop. I'd been thinking about maybe converting epilogues completely to rtl as well, which would allow the function to be deleted completely, rather than incrementally. I'm unsure what testing should be applied. I'm currently doing arm-elf, which does at least have a thumb1 multilib, and uses newlib so I don't have to fiddle with setting up a full native cross environment. What else should be done? arm-eabi? Hi Richard. arm-linux-gnueabi bootstraps in Thumb1 mode. I haven't done many builds in that way, but here's the latest: http://builds.linaro.org/toolchain/gcc-4.6.0-RC-20110321/logs/armv7l-maverick-cbuild93-ursa1-armv5thumbr1/ -- Michael
Re: [testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux
On 10 October 2012 22:57, Richard Earnshaw rearn...@arm.com wrote:
On 10/10/12 03:11, Janis Johnson wrote:
On 10/09/2012 07:39 AM, Richard Earnshaw wrote:
On 27/09/12 01:02, Janis Johnson wrote:
Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
targets, as described in PR54732. This patch adds an XFAIL.
Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.
Janis
gcc-20120926-5
2012-09-26 Janis Johnson jani...@codesourcery.com
* gcc.target/arm/div64-unwinding.c: XFAIL for GNU/Linux.
Index: gcc.target/arm/div64-unwinding.c
===
--- gcc.target/arm/div64-unwinding.c(revision 191765)
+++ gcc.target/arm/div64-unwinding.c(working copy)
@@ -1,6 +1,7 @@
/* Performing a 64-bit division should not pull in the unwinder. */
-/* { dg-do run } */
+/* The test is expected to fail for GNU/Linux; see PR54723. */
+/* { dg-do run { xfail *-*-linux* } } */
/* { dg-options -O0 } */
#include stdlib.h
I don't like this. To me, XFAIL means there's a bug here, but we're
not too worried about it. The behaviour on linux targets is correct,
so this test should either PASS or be skipped.
Richard,
The impression I got from Julian is there's a bug here, but we're not
too worried about it. If you think it should be skipped instead then
I'll gladly change the test.
Janis
I don't believe there's a bug here. The ARM EABI defines __aeabi_idiv0 as
a hook that will be called if division by zero occurs. While the default
implementation simply raises SIGFPE on linux, it is perfectly possible to
provide your own definition of this hook and then throw() a C++ exception.
In order to do that you'd need unwind information in the divdi
implementation ([u]divsi tailcalls the hook).
Technically you could argue the same for bare metal, but in that case the
arguments against the code bloat outweigh this very small corner case and
users wanting this will have to rebuild their support code.
On linux, I think the presence of the unwind information is correct, since
the code bloat problem is very much a secondary concern.
So yes, please could you make the test be skipped on linux.
Julian's patch turns off the unwinding information for all ARM systems
including Linux. The test currently fails as something else (glibc?)
ends up pulling in the unwinder.
-- Michael
