Re: Proper way to build GNAT cross compiler with gnattools
> Can you point me at least to the section which explains this? http://gcc.gnu.org/install/build.html -- Eric Botcazou
İstanbulun şirin ilçesi Şile
www.sileorganik.comİstanbulun şirin ilçesi Şile ve köylerinden evlerinize geliyor , unuttuğunuz o eski tatları sizlere hatırlatacağız , kapıda ödeme kolaylığıyla artık sizlere çok yakınız . Doğal köy yoğurdu ,köy yumurtası ,köy ekmeği ,köy peyniri www.sileorganik.com www.sileorganik.net
misleading message when failing to insert a pass...
Hello All
(I've found this issue with the GCC MELT branch rev 169469, but I strongly
believe it is not directly related to MELT and should happen with the trunk
also. You could run the testsuite/melt/topengpu-1.c test, a comment in that
file describes how to run the test)
First, a pass inserted by a plugin (or a MELT module) into the pass tree has
to be of the same type. So a GIMPLE_PASS can only be inserted before or
after another GIMPLE pass, a SIMPLE_IPA_PASS can only be be inserted near a
SIMPLE_IPA_PASS, and an IPA_PASS can only be inserted near an IPA_PASS.
In particular, I find a bit confusing that a SIMPLE_IPA_PASS provided by a
plugin cannot be inserted after an IPA_PASS.
When one try to insert a pass with a kind mismatch, the error message is
very confusing. For instance, I'm getting
cc1 : pass local-pure-const not found but is referenced by new pass
meltopengpu_detect
But the pass 'local-pure-const' does indeed exist. So at least, the error
message should be improved (but I imagine that it is too late to even bother
trying submit a patch to 4.6 trunk now, because we are probably in a stage
[3, 4, don't understand the numbering] which disallows that).
I believe that we should improve the error message. Maybe a message like
"pass found but of incompatible kind with new pass " could be
more understandable.
I also find confusing that the pass 'local-pure-const' is a GIMPLE_PASS in
file ipa-pure-const.c near line 1682 and the file is named ipa*.c (which
suggest an IPA_PASS or SIMPLE_IPA_PASS) but that pass is just a GIMPLE_PASS.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote: > On Tue, 1 Feb 2011, Dongsheng Song wrote: > >> The DATESTAMP change could also be in a post-commit hook (doing > >> nothing if the date didn't change, of course). No idea whether > >> this is technically possible of course. > > Yes, the post-commit hook can do this task. > > If we really want to do that, I can update the current post-commit > > hook script [1]. > > I'd love to see that and will be happy to work on this with you, > apply a patch, etc. > > Let's give others the chance to chime in, and if there are no > objections within the next two days, let's proceed. Fair? I'd say it should go into a pre-commit hook instead of post-commit, if possible. So that when one checks in some particular revision DATESTAMP already has the right timestamp. Jakub
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Wed, Feb 2, 2011 at 2:29 PM, Jakub Jelinek wrote: > On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote: >> On Tue, 1 Feb 2011, Dongsheng Song wrote: >> >> The DATESTAMP change could also be in a post-commit hook (doing >> >> nothing if the date didn't change, of course). No idea whether >> >> this is technically possible of course. >> > Yes, the post-commit hook can do this task. >> > If we really want to do that, I can update the current post-commit >> > hook script [1]. >> >> I'd love to see that and will be happy to work on this with you, >> apply a patch, etc. >> >> Let's give others the chance to chime in, and if there are no >> objections within the next two days, let's proceed. Fair? > > I'd say it should go into a pre-commit hook instead of > post-commit, if possible. So that when one checks in some particular > revision DATESTAMP already has the right timestamp. I wonder if it can go into the same commit even? Richard.
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Feb 2, 2011, at 8:32 AM, Richard Guenther wrote: > On Wed, Feb 2, 2011 at 2:29 PM, Jakub Jelinek wrote: >> On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote: >>> On Tue, 1 Feb 2011, Dongsheng Song wrote: > The DATESTAMP change could also be in a post-commit hook (doing > nothing if the date didn't change, of course). No idea whether > this is technically possible of course. Yes, the post-commit hook can do this task. If we really want to do that, I can update the current post-commit hook script [1]. >>> >>> I'd love to see that and will be happy to work on this with you, >>> apply a patch, etc. >>> >>> Let's give others the chance to chime in, and if there are no >>> objections within the next two days, let's proceed. Fair? >> >> I'd say it should go into a pre-commit hook instead of >> post-commit, if possible. So that when one checks in some particular >> revision DATESTAMP already has the right timestamp. > > I wonder if it can go into the same commit even? No. Subversion specifically documents the fact that a pre-commit hook can't change the transaction; it can only inspect it. paul
Re: LTO on newlib targets w/o Gold
On 02/01/2011 04:54 AM, Dave Korn wrote: On 01/02/2011 02:33, Joel Sherrill wrote: Should LTO work with a target not using gold? Yes, it should, but some work is needed at the binutils end. I am testing the attached two patches at the moment; the idea is to have fully-debugged support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes out. The patches have made those link errors go away. Unfortunately, something has happened to sparc in the past few days and the failures have shot up even with your patch in. I am posting about it in a separate email. Thanks. cheers, DaveK -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
sparc-rtems recent test regressions
Hi, In the past few days, something has regressed on the sparc. Revision 169143 only had 699 failures and ~100 of those were LTO related. David Korn's patch seems to have resolved those. Revision 169504 has 2231 failures. http://www.rtems.org/pipermail/rtems-tooltestresults/2011-January/000407.html === gcc Summary === # of expected passes67336 # of unexpected failures699 # of expected failures223 # of unresolved testcases128 # of unsupported tests1233 /users/joel/test-gcc/b-gcc1-sparc/gcc/xgcc version 4.6.0 20110123 (experimental) [trunk revision 169143] (GCC) http://www.rtems.org/pipermail/rtems-tooltestresults/2011-February/000440.html === gcc Summary === # of expected passes 64480 # of unexpected failures 2231 # of expected failures 226 # of unresolved testcases 50 # of unsupported tests 1247 /users/joel/test-gcc/b-gcc1-sparc/gcc/xgcc version 4.6.0 20110201 (experimental) [trunk revision 169504] (GCC) Any ideas? -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Wed, Feb 2, 2011 at 22:00, Paul Koning wrote:
> No. Subversion specifically documents the fact that a pre-commit hook can't
> change the transaction; it can only inspect it.
>
> paul
>
Yes, here is a pilot post commit hook for bumping DATESTAMP:
post-commit |2 ++
update_datestamp | 51 +++
2 files changed, 53 insertions(+)
Index: hooks/update_datestamp
===
--- hooks/update_datestamp (revision 0)
+++ hooks/update_datestamp (revision 0)
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+REPOS="$1"
+REV="$2"
+
+PATH=/usr/local/bin:/usr/pkg/bin:/usr/bin:/bin
+IGNORE_BRANCHES='gcc-(2_95|3_0|3_1|3_2|3_3|3_4|4_0|4_1|4_2)-branch'
+
+# Run this from /tmp
+/bin/rm -rf /tmp/$$
+/bin/mkdir /tmp/$$
+cd /tmp/$$
+
+# Compute the branches which we should check for update.
+BRANCHES=`svnlook -r ${REV} dirs-changed "${REPOS}" \
+| grep -E "^trunk/|^branches/gcc-[0-9]+_[0-9]+-branch/" \
+| grep -E -v ${IGNORE_BRANCHES} \
+| awk -F '/' '{if ($1 == "trunk") { print $1} else { print $2}}' \
+| sort -u`
+
+# Assume all will go well.
+RESULT=0
+for BRANCH in ${BRANCHES}; do
+
+ # Compute the svn root URL we should check for update.
+ if test "${BRANCH}" = "trunk"; then
+DATESTAMP_URL="file://${REPOS}/trunk/gcc"
+ else
+DATESTAMP_URL="file://${REPOS}/branches/${BRANCH}/gcc"
+ fi
+
+ CURR_DATE=`/bin/date -u +"%Y%m%d"`
+ PREV_DATE=`svn cat "${DATESTAMP_URL}/DATESTAMP"`
+ if test "${CURR_DATE}" = "${PREV_DATE}"; then
+continue
+ fi
+
+ svn -q co -N "${DATESTAMP_URL}/" gcc
+ echo -n ${CURR_DATE} > gcc/DATESTAMP
+ if ! svn commit -m "Daily bump." gcc/DATESTAMP; then
+# If we could not commit the files, indicate failure.
+RESULT=1
+ fi
+
+ # Remove the files.
+ rm -rf /tmp/$$/gcc
+done
+
+/bin/rm -rf /tmp/$$
+
+exit $RESULT
Property changes on: hooks/update_datestamp
___
Added: svn:executable
+ *
Index: hooks/post-commit
===
--- hooks/post-commit (revision 169520)
+++ hooks/post-commit (working copy)
@@ -17,3 +17,5 @@
--repository "${REPOS}" --revision "${REV}" --background
${REPOS}/hooks/synchooks.sh "${REPOS}" "${REV}"
+
+${REPOS}/hooks/update_version_svn ${REPOS} ${REV} &
--
Dongsheng Song
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
Dongsheng Song writes:
> + echo -n ${CURR_DATE} > gcc/DATESTAMP
What's the point of -n?
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
Re: sparc-rtems recent test regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/11 07:19, Joel Sherrill wrote: > Hi, > > In the past few days, something has regressed > on the sparc. Revision 169143 only had 699 failures > and ~100 of those were LTO related. David Korn's > patch seems to have resolved those. Revision 169504 > has 2231 failures. > > http://www.rtems.org/pipermail/rtems-tooltestresults/2011-January/000407.html > > > === gcc Summary === > > # of expected passes67336 > # of unexpected failures699 > # of expected failures223 > # of unresolved testcases128 > # of unsupported tests1233 > /users/joel/test-gcc/b-gcc1-sparc/gcc/xgcc version 4.6.0 20110123 > (experimental) [trunk revision 169143] (GCC) > > http://www.rtems.org/pipermail/rtems-tooltestresults/2011-February/000440.html > > > > === gcc Summary === > > # of expected passes 64480 > # of unexpected failures 2231 > # of expected failures 226 > # of unresolved testcases 50 > # of unsupported tests 1247 > /users/joel/test-gcc/b-gcc1-sparc/gcc/xgcc version 4.6.0 20110201 > (experimental) [trunk revision 169504] (GCC) > > Any ideas? Check 169231, it's exposed multiple latent bugs. I'm seriously considering pulling it. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNSW1kAAoJEBRtltQi2kC7LAkH/j+maTGTw8/xV1w8oJ1pb+C9 tzYsW0uAhLm3E6T2CjwPfdYEdcLdPRp0NL0VB2AVSqiKj0kcWG30x/GaHgDg2CSt xBpKPLVudml6Zf+2L4JuEkj3KlI/g1KMXudsfM9fR+SHlkWPsYyJz3cAYwdWesWg 0yzW3vqSUA+M1sL+TestGEjRW5+uGyjwhbg3iZ0QG+g6FXPXEXMp/gOGfkETFzFY VhvL4iQ2sbMYg5xn3wEAPs023hedpXWwg4udWtl5KrMgkgK9MLg13nPu9jXSmXrU zNaO4JzUquLW8sjiHu4llI9UTraKmWkoUd4fT5Ji/wC3XasHseUnqYSZ5vdMtlY= =qyya -END PGP SIGNATURE-
ARM unaligned MMIO access with attribute((packed))
As noticed by Peter Maydell, the EHCI device driver in Linux gets
miscompiled by some versions of arm-gcc (still need to find out which)
due to a combination of problems:
1. In include/linux/usb/ehci_def.h, struct ehci_caps is defined
with __attribute__((packed)), for no good reason. This is clearly
a bug and needs to get fixed, but other drivers have the same bug
and it used to work. The attribute forces byte access on all members
accessed through pointer dereference, which is not allowed on
MMIO accesses in general. The specific code triggering the problem
in Peter's case is in ehci-omap.c:
omap->ehci->regs = hcd->regs
+ HC_LENGTH(readl(&omap->ehci->caps->hc_capbase));
2. The ARM version of the readl() function is implemented as a macro
doing a direct pointer dereference with a typecast:
#define __raw_readl(a) (__chk_io_ptr(a), *(volatile unsigned int
__force *)(a))
#define readl_relaxed(c) ({ u32 __v = le32_to_cpu((__force __le32) \
__raw_readl(__mem_pci(c))); __v; })
#define readl(c)({ u32 __v = readl_relaxed(c); __iormb(); __v;
})
On other architectures, readl() is implemented using an inline assembly
specifically to prevent gcc from issuing anything but a single 32-bit
load instruction. readl() only makes sense on aligned memory, so in case
of a misaligned pointer argument, it should cause a trap anyway.
3. gcc does not seem to clearly define what happens during a cast between
aligned an packed pointers. In this case, the original pointer is packed
(byte aligned), while the access is done through a 32-bit aligned
volatile unsigned int pointer. In gcc-4.4, casting from "unsigned int
__attribute__((packed))" to "volatile unsigned int" resulted in a 32-bit
aligned access, while casting to "unsigned int" (without volatile) resulted
in four byte accesses. gcc-4.5 seems to have changed this to always do
a byte access in both cases, but still does not document the behavior.
(need to confirm this).
I would suggest fixing this by:
1. auditing all uses of __attribute__((packed)) in the Linux USB code
and other drivers, removing the ones that are potentially harmful.
2. Changing the ARM MMIO functions to use inline assembly instead of
direct pointer dereference.
3. Documenting the gcc behavior as undefined.
Other suggestions?
Arnd
Re: ARM unaligned MMIO access with attribute((packed))
On Wed, Feb 02, 2011 at 05:00:20PM +0100, Arnd Bergmann wrote: > I would suggest fixing this by: > > 1. auditing all uses of __attribute__((packed)) in the Linux USB code > and other drivers, removing the ones that are potentially harmful. > > 2. Changing the ARM MMIO functions to use inline assembly instead of > direct pointer dereference. > > 3. Documenting the gcc behavior as undefined. We used to use inline assembly at one point, but that got chucked out. The problem is that using asm() for this causes GCC to generate horrid code. 1. there's no way to tell GCC that the inline assembly is a load instruction and therefore it needs to schedule the following instructions appropriately. 2. GCC will needlessly reload pointers from structures and other such behaviour because it can't be told clearly what the inline assembly is doing, so the inline asm needs to have a "memory" clobber. 3. It seems to misses out using the pre-index addressing, prefering to create add/sub instructions prior to each inline assembly load/store. 4. There are no (documented) constraints in GCC to allow you to represent the offset format for the half-word instructions. Overall, it means greater register pressure, more instructions, larger functions, greater instruction cache pressure, etc.
Re: ARM unaligned MMIO access with attribute((packed))
On Wed, Feb 2, 2011 at 5:00 PM, Arnd Bergmann wrote:
> As noticed by Peter Maydell, the EHCI device driver in Linux gets
> miscompiled by some versions of arm-gcc (still need to find out which)
> due to a combination of problems:
>
> 1. In include/linux/usb/ehci_def.h, struct ehci_caps is defined
> with __attribute__((packed)), for no good reason. This is clearly
> a bug and needs to get fixed, but other drivers have the same bug
> and it used to work. The attribute forces byte access on all members
> accessed through pointer dereference, which is not allowed on
> MMIO accesses in general. The specific code triggering the problem
> in Peter's case is in ehci-omap.c:
> omap->ehci->regs = hcd->regs
> + HC_LENGTH(readl(&omap->ehci->caps->hc_capbase));
>
>
> 2. The ARM version of the readl() function is implemented as a macro
> doing a direct pointer dereference with a typecast:
>
> #define __raw_readl(a) (__chk_io_ptr(a), *(volatile unsigned int
> __force *)(a))
> #define readl_relaxed(c) ({ u32 __v = le32_to_cpu((__force __le32) \
> __raw_readl(__mem_pci(c))); __v; })
> #define readl(c) ({ u32 __v = readl_relaxed(c); __iormb();
> __v; })
>
> On other architectures, readl() is implemented using an inline assembly
> specifically to prevent gcc from issuing anything but a single 32-bit
> load instruction. readl() only makes sense on aligned memory, so in case
> of a misaligned pointer argument, it should cause a trap anyway.
>
> 3. gcc does not seem to clearly define what happens during a cast between
> aligned an packed pointers. In this case, the original pointer is packed
> (byte aligned), while the access is done through a 32-bit aligned
> volatile unsigned int pointer. In gcc-4.4, casting from "unsigned int
> __attribute__((packed))" to "volatile unsigned int" resulted in a 32-bit
> aligned access, while casting to "unsigned int" (without volatile) resulted
> in four byte accesses. gcc-4.5 seems to have changed this to always do
> a byte access in both cases, but still does not document the behavior.
> (need to confirm this).
>
> I would suggest fixing this by:
>
> 1. auditing all uses of __attribute__((packed)) in the Linux USB code
> and other drivers, removing the ones that are potentially harmful.
>
> 2. Changing the ARM MMIO functions to use inline assembly instead of
> direct pointer dereference.
>
> 3. Documenting the gcc behavior as undefined.
The pointer conversions already invoke undefined behavior as specified by the
C standard (6.3.2.3/7).
Richard.
Re: ARM unaligned MMIO access with attribute((packed))
On Wed, Feb 02, 2011 at 05:51:27PM +0100, Richard Guenther wrote:
> > I would suggest fixing this by:
> >
> > 1. auditing all uses of __attribute__((packed)) in the Linux USB code
> > and other drivers, removing the ones that are potentially harmful.
> >
> > 2. Changing the ARM MMIO functions to use inline assembly instead of
> > direct pointer dereference.
> >
> > 3. Documenting the gcc behavior as undefined.
>
> The pointer conversions already invoke undefined behavior as specified by the
> C standard (6.3.2.3/7).
Just to be clear: you are not saying that the ARM implementation is
undefined.
What you're saying is that converting from a pointer with less strict
alignment requirements to a pointer with more strict alignment
requirements is undefined.
IOW:
unsigned long *blah(unsigned char *c)
{
return (unsigned long *)c;
}
would be undefined, but:
unsigned char *blah(unsigned long *c)
{
return (unsigned char *)c;
}
would not be.
If you're saying something else, please explain with reference to the
point in the C standard you quote above.
Re: ARM unaligned MMIO access with attribute((packed))
On Wed, 2 Feb 2011, Richard Guenther wrote: > The pointer conversions already invoke undefined behavior as specified by the > C standard (6.3.2.3/7). I would say: the conversions are undefined if the pointer is insufficiently aligned for any of the pointer types involved (source, destination or intermediate), where the appropriate alignment for a packed type is 1. Thus, the conversion from packed to non-packed is OK iff the pointer target is sufficiently aligned for the non-packed type. In general from a sequence of casts the compiler is permitted to deduce that the pointer is sufficiently aligned for whatever type in the sequence has the greatest alignment requirement (the middle-end may not have that information at present, but the front end could insert some form of alignment assertion if useful for optimization). *But* that is what is permitted in standards terms; it is not necessarily safe in practice. In particular, on non-strict-alignment targets such as x86 people do in practice assume that unaligned accesses are OK at the C level, not just the assembly level (glibc does so, for example), so it might be a bad idea to assume alignment in a way that would cause that to break. -- Joseph S. Myers jos...@codesourcery.com
Re: ARM unaligned MMIO access with attribute((packed))
On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote: > We used to use inline assembly at one point, but that got chucked out. > The problem is that using asm() for this causes GCC to generate horrid > code. > > 1. there's no way to tell GCC that the inline assembly is a load >instruction and therefore it needs to schedule the following >instructions appropriately. > > 2. GCC will needlessly reload pointers from structures and other such >behaviour because it can't be told clearly what the inline assembly >is doing, so the inline asm needs to have a "memory" clobber. > > 3. It seems to misses out using the pre-index addressing, prefering to >create add/sub instructions prior to each inline assembly load/store. > > 4. There are no (documented) constraints in GCC to allow you to represent >the offset format for the half-word instructions. > > Overall, it means greater register pressure, more instructions, larger > functions, greater instruction cache pressure, etc. Another solution would be to declare the readl function extern and define it out of line, but I assume that this would be at least as bad as an inline assembly for all the points you brought up, right? Would it be possible to add the proper constraints for defining readl in an efficient way to a future version of gcc? That wouldn't help us in the near future, but we could at some points use those in a number of places. Arnd
[google] Merged google/integration from trunk at r169512
No new failures. Tested on x86_64. Diego.
Re: [google] Merged google/integration from trunk at r169512
On Wed, Feb 2, 2011 at 10:19 AM, Diego Novillo wrote: > > No new failures. Tested on x86_64. This caused a lot of svn revisions and addition to bug reports that was not really needed. -- Pinski
Re: [google] Merged google/integration from trunk at r169512
On Wed, Feb 2, 2011 at 13:30, Andrew Pinski wrote: > This caused a lot of svn revisions and addition to bug reports that > was not really needed. Gah, sorry about that. The multiple svn revisions were somewhat intentional, I was trying to keep the svn commit history, but I will stop doing that if it's an issue. I'll remove the PR references next time. Thanks for the heads up. Diego.
Re: [google] Merged google/integration from trunk at r169512
On Wed, Feb 2, 2011 at 10:47 AM, Diego Novillo wrote: > On Wed, Feb 2, 2011 at 13:30, Andrew Pinski wrote: > >> This caused a lot of svn revisions and addition to bug reports that >> was not really needed. > > Gah, sorry about that. The multiple svn revisions were somewhat > intentional, I was trying to keep the svn commit history, but I will > stop doing that if it's an issue. > > I'll remove the PR references next time. Thanks for the heads up. Git can solve this problem for you. -- H.J.
Re: [google] Merged google/integration from trunk at r169512
On Wed, Feb 2, 2011 at 13:48, H.J. Lu wrote: > Git can solve this problem for you. It was git the cause of the problem, actually. I committed with 'git svn dcommit' without squashing the commits into a single one. Diego.
Re: [google] Merged google/integration from trunk at r169512
On Wed, Feb 2, 2011 at 10:52 AM, Diego Novillo wrote: > On Wed, Feb 2, 2011 at 13:48, H.J. Lu wrote: > >> Git can solve this problem for you. > > It was git the cause of the problem, actually. I committed with 'git > svn dcommit' without squashing the commits into a single one. > I don't use svn to keep track merge history on svn x32 branch, which is just a place holder. The full history of x32 work is available on hjl/x32/trunk branch from http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary Check out from that git branch is identical to svn x32 branch. -- H.J.
Bugzilla spam caused by my merge
I would like to apologize for all the bugzilla spam I have caused with a recent merge I made. I was committing the merge with 'git svn', since I was interested in keeping the commit history. I did not realize that this would also commit the svn commit messages with the PR numbers, causing the massive bugzilla update. Sorry! I will be more careful in subsequent merges. Diego.
Re: ARM unaligned MMIO access with attribute((packed))
Arnd Bergmann writes: > On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote: >> We used to use inline assembly at one point, but that got chucked out. >> The problem is that using asm() for this causes GCC to generate horrid >> code. >> >> 1. there's no way to tell GCC that the inline assembly is a load >>instruction and therefore it needs to schedule the following >>instructions appropriately. >> >> 2. GCC will needlessly reload pointers from structures and other such >>behaviour because it can't be told clearly what the inline assembly >>is doing, so the inline asm needs to have a "memory" clobber. >> >> 3. It seems to misses out using the pre-index addressing, prefering to >>create add/sub instructions prior to each inline assembly load/store. >> >> 4. There are no (documented) constraints in GCC to allow you to represent >>the offset format for the half-word instructions. >> >> Overall, it means greater register pressure, more instructions, larger >> functions, greater instruction cache pressure, etc. > > Another solution would be to declare the readl function extern and define > it out of line, but I assume that this would be at least as bad as an > inline assembly for all the points you brought up, right? > > Would it be possible to add the proper constraints for defining readl > in an efficient way to a future version of gcc? That wouldn't help us > in the near future, but we could at some points use those in a number > of places. I think it would be quite difficult to implement item 1 above in a way that was actually usable. It would require some way to describe the scheduling requirements of an asm. But the details of scheduling are backend specific. Internally there are define_insn_reservation structures which have names, but the names are processor specific which is not what you want in source code (by processor specific I mean specific to particular CPUs within a family). There are define_cpu_unit structures which also have names, but are again processor specific. What you want here is some non-processor-specific way to describe the characteristics of an instruction. gcc does not have that today. Even if somebody implemented all that, most inline asms are not a single instructions and thus would find it difficult to take advantage of it. I don't see this as paying off in the long run. A more likely payoff would be to develop builtin functions for whatever functionality is required that can not expressed in source code. Item 2 above can be done. It is possible to describe precisely which areas of memory are clobbered. Item 3 above seems impossible to me. There is no way to combine compiler generated instructions with user written inline asm such that pre-index addressing can be used. Perhaps I misunderstand. Item 4 can be implemented; please consider opening a feature request in bugzilla. Ian
Re: ARM unaligned MMIO access with attribute((packed))
From: Russell King - ARM Linux Date: Wed, 2 Feb 2011 16:37:02 + > 1. there's no way to tell GCC that the inline assembly is a load >instruction and therefore it needs to schedule the following >instructions appropriately. Just add a dummy '"m" (pointer)' asm input argument to the inline asm statement. Just make sure "typeof(pointer)" has a size matching the size of the load your are performing. > 2. GCC will needlessly reload pointers from structures and other such >behaviour because it can't be told clearly what the inline assembly >is doing, so the inline asm needs to have a "memory" clobber. This behavior is correct, and in fact needed. Writing to chip registers can trigger changes to arbitrary main memory locations. > 3. It seems to misses out using the pre-index addressing, prefering to >create add/sub instructions prior to each inline assembly load/store. Yes, this is indeed a problem. But you really need that memory clobber there whether you like it or not, see above.
Re: ARM unaligned MMIO access with attribute((packed))
On Wed, Feb 02, 2011 at 01:38:31PM -0800, David Miller wrote: > From: Russell King - ARM Linux > Date: Wed, 2 Feb 2011 16:37:02 + > > > 1. there's no way to tell GCC that the inline assembly is a load > >instruction and therefore it needs to schedule the following > >instructions appropriately. > > Just add a dummy '"m" (pointer)' asm input argument to the inline asm > statement. Just make sure "typeof(pointer)" has a size matching the > size of the load your are performing. That involves this problematical cast from a packed struct pointer to an unsigned long pointer, which according to the C standard and GCC folk is undefined. > > 2. GCC will needlessly reload pointers from structures and other such > >behaviour because it can't be told clearly what the inline assembly > >is doing, so the inline asm needs to have a "memory" clobber. > > This behavior is correct, and in fact needed. Writing to chip registers > can trigger changes to arbitrary main memory locations. That is really not an argument which stands up to analysis. When does main memory locations change as a result of a write to a chip register? The answer is: when DMA is performed - which could be many microseconds or even milliseconds after you've written the register, which would be long after you've exited the function doing the writing. Not only that, but we have the DMA API to deal with the implications of that. On ARM, that's a function call, and GCC can't make any assumptions about memory contents across function calls where it doesn't know what the function does. Practice over the last 15 years on ARM has also shown that this is not necessary.
Re: ARM unaligned MMIO access with attribute((packed))
From: Russell King - ARM Linux Date: Wed, 2 Feb 2011 21:45:22 + > On Wed, Feb 02, 2011 at 01:38:31PM -0800, David Miller wrote: >> From: Russell King - ARM Linux >> Date: Wed, 2 Feb 2011 16:37:02 + >> >> > 1. there's no way to tell GCC that the inline assembly is a load >> >instruction and therefore it needs to schedule the following >> >instructions appropriately. >> >> Just add a dummy '"m" (pointer)' asm input argument to the inline asm >> statement. Just make sure "typeof(pointer)" has a size matching the >> size of the load your are performing. > > That involves this problematical cast from a packed struct pointer to > an unsigned long pointer, which according to the C standard and GCC > folk is undefined. It's alignment may be undefined, but it's size definitely is well defined and that's what matters here. > Practice over the last 15 years on ARM has also shown that this is not > necessary. Sorry oh big super man, little ole' me is only a kernel newbie.
Re: ARM unaligned MMIO access with attribute((packed))
From: Måns Rullgård Date: Wed, 02 Feb 2011 23:08:01 + > David Miller writes: > >> From: Russell King - ARM Linux >> Date: Wed, 2 Feb 2011 16:37:02 + >> >>> 1. there's no way to tell GCC that the inline assembly is a load >>>instruction and therefore it needs to schedule the following >>>instructions appropriately. >> >> Just add a dummy '"m" (pointer)' asm input argument to the inline asm >> statement. Just make sure "typeof(pointer)" has a size matching the >> size of the load your are performing. > > That should be "m"(*pointer). Right, thanks for the correction. >> But you really need that memory clobber there whether you like it or >> not, see above. > > I don't know of any device where the side-effects are not explicitly > indicated by other means in the code triggering them, so it probably > is safe without the clobber as Russel says. You're probably right.
Re: ARM unaligned MMIO access with attribute((packed))
David Miller writes: > From: Russell King - ARM Linux > Date: Wed, 2 Feb 2011 16:37:02 + > >> 1. there's no way to tell GCC that the inline assembly is a load >>instruction and therefore it needs to schedule the following >>instructions appropriately. > > Just add a dummy '"m" (pointer)' asm input argument to the inline asm > statement. Just make sure "typeof(pointer)" has a size matching the > size of the load your are performing. That should be "m"(*pointer). >> 2. GCC will needlessly reload pointers from structures and other such >>behaviour because it can't be told clearly what the inline assembly >>is doing, so the inline asm needs to have a "memory" clobber. > > This behavior is correct, and in fact needed. Writing to chip registers > can trigger changes to arbitrary main memory locations. > >> 3. It seems to misses out using the pre-index addressing, prefering to >>create add/sub instructions prior to each inline assembly load/store. > > Yes, this is indeed a problem. GCC has trouble doing anything more complicated than simple indexing. Load/store instructions with writeback seem not to be in its vocabulary at all. > But you really need that memory clobber there whether you like it or > not, see above. I don't know of any device where the side-effects are not explicitly indicated by other means in the code triggering them, so it probably is safe without the clobber as Russel says. -- Måns Rullgård m...@mansr.com
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Wed, 2 Feb 2011, Dongsheng Song wrote:
> Index: hooks/update_datestamp
> ===
> --- hooks/update_datestamp (revision 0)
> +++ hooks/update_datestamp (revision 0)
> @@ -0,0 +1,51 @@
> +#!/bin/sh
> +
> +REPOS="$1"
> +REV="$2"
> +
> +PATH=/usr/local/bin:/usr/pkg/bin:/usr/bin:/bin
/usr/local/bin on gcc.gnu.org is scary, and I think not needed;
/usr/pkg/bin does not actually exist.
> +IGNORE_BRANCHES='gcc-(2_95|3_0|3_1|3_2|3_3|3_4|4_0|4_1|4_2)-branch'
I believe we can omit this altogether. I see thhis script is a clone
of the one running once a day to bump on all branches, and there we
wanted to limit where that bumping happens. As long as a branch is
committed to, I don't see any problem with bumping the data stamp.
Anyone disagrees?
> +BRANCHES=`svnlook -r ${REV} dirs-changed "${REPOS}" \
Do we really need to worry about more than branch being hit in one
commit? I wasn't aware that SVN supports this, but I guess it's
defensive programming. :-)
> +| grep -E "^trunk/|^branches/gcc-[0-9]+_[0-9]+-branch/" \
Can you make this one a variable at the top, ${BRANCH_REGEXP} or
something like that?
> + if ! svn commit -m "Daily bump." gcc/DATESTAMP; then
> +# If we could not commit the files, indicate failure.
> +RESULT=1
> + fi
Can we also issue an error message here?
> Index: hooks/post-commit
> ===
> --- hooks/post-commit (revision 169520)
> +++ hooks/post-commit (working copy)
> @@ -17,3 +17,5 @@
> --repository "${REPOS}" --revision "${REV}" --background
>
> ${REPOS}/hooks/synchooks.sh "${REPOS}" "${REV}"
> +
> +${REPOS}/hooks/update_version_svn ${REPOS} ${REV} &
This should have been hooks/update_datestamp, no? We could, in fact,
use update_version_svn, too, that would be a bit of a performance issue,
though. :-)
Gerald
pb05 results at rr169776
Sebastian, Below are the results for the Polyhedron 2005 benchmarks on x86_64-apple-darwin10 using -O3 -ffast-math -funroll-loops under gcc trunk at r169776, with -fgraphite-identity and with -fgraphite-identity -ftree-loop-linear. I am surprised at the absence of any impact from -ftree-loop-linear in either run-time or executable size. The increase in compile time on some of the benchmarks suggested it was in effect. Is this a poor combination of optimizations for -ftree-loop-linear or is fortran less effective in using that optimization? Jack ps Hopefully when the remaining loop regressions in -fgraphite-identity are solved, the graphite results will improve a bit more. Using built-in specs. COLLECT_GCC=gcc-4 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.7.0 Configured with: ../gcc-4.6-20110202/configure --prefix=/sw --prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl Thread model: posix gcc version 4.6.0 20110203 (experimental) (GCC) command=gfortran -O3 -ffast-math -funroll-loops Run-time stock -fgraphite-identity -fgraphite-identity -ftree-loop-linear ac8.80 8.80 8.80 aermod 17.3217.43 17.43 air 5.48 5.43 5.44 capacita 32.4532.52 32.53 channel 1.84 1.84 1.84 doduc28.3026.28 26.28 fatigue 8.13 8.09 8.09 gas_dyn 4.30 4.32 4.31 induct 13.0712.51 12.51 linpk15.4715.41 15.41 mdbx 11.2111.21 11.21 nf 29.9130.20 30.01 protein 32.8632.21 32.20 rnflow 23.9424.18 24.17 test_fpu 8.02 8.05 8.04 tfft 1.87 1.87 1.87 Compile-time stock -fgraphite-identity -fgraphite-identity -ftree-loop-linear ac2.12 2.12 2.12 aermod 57.45 59.22 59.30 air 3.84 4.37 4.93 capacita 2.82 2.94 3.07 channel 1.00 1.20 1.33 doduc 8.57 8.92 8.95 fatigue 3.19 3.17 3.17 gas_dyn 5.38 5.57 5.57 induct6.59 6.77 8.81 linpk 1.08 1.33 1.31 mdbx 2.83 2.92 2.92 nf3.09 3.08 3.10 protein 8.51 8.70 8.67 rnflow9.94 10.09 10.09 test_fpu 7.22 7.24 7.28 tfft 0.81 0.88 0.83 Executable size stock -fgraphite-identity -fgraphite-identity -ftree-loop-linear ac 50976 50976 50976 aermod 1264832 1268928 1268928 air 73984 82184 82184 capacita 77976 77976 77976 channel 34792 34792 34792 doduc 193096193096193096 fatigue 86032 86032 86032 gas_dyn 119704115608115608 induct 174848174848174848 linpk38648 38648 38648 mdbx 82072 82072 82072 nf 75912 71816 71816 protein 131992131992131992 rnflow 181080181080181080 test_fpu155048150952150952 tfft 30760 30760 30760
Re: Bugzilla spam caused by my merge
On Wed, 2 Feb 2011 14:09:21 -0500
Diego Novillo wrote:
> I would like to apologize for all the bugzilla spam I have caused with
> a recent merge I made. I was committing the merge with 'git svn',
> since I was interested in keeping the commit history. I did not
> realize that this would also commit the svn commit messages with the
> PR numbers, causing the massive bugzilla update.
I am switching to daily use git for the MELT branch. What is the
command to avoid making the same mistake? Any general clues on using
git for GCC work is welcome. I did read
http://gcc.gnu.org/wiki/GitMirror and Dodji dodjiseketeli... gave
me precious advices about it.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
