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 XXX found but of incompatible kind with new pass YYY 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: basileatstarynkevitchdotnet 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 ja...@redhat.com 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 ja...@redhat.com 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 paul_kon...@dell.com 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 dongsheng.s...@gmail.com 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 a...@arndb.de 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 dnovi...@google.com 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 pins...@gmail.com 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 dnovi...@google.com wrote: On Wed, Feb 2, 2011 at 13:30, Andrew Pinski pins...@gmail.com 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 hjl.to...@gmail.com 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 dnovi...@google.com wrote: On Wed, Feb 2, 2011 at 13:48, H.J. Lu hjl.to...@gmail.com 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 a...@arndb.de 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 li...@arm.linux.org.uk 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 li...@arm.linux.org.uk 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 li...@arm.linux.org.uk 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 li...@arm.linux.org.uk 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 m...@mansr.com Date: Wed, 02 Feb 2011 23:08:01 + David Miller da...@davemloft.net writes: From: Russell King - ARM Linux li...@arm.linux.org.uk 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 da...@davemloft.net writes: From: Russell King - ARM Linux li...@arm.linux.org.uk 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 dnovi...@google.com 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 dodjiatseketeli... gave
me precious advices about it.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583 --- Comment #6 from Harald Klimach harald at klimachs dot de 2011-02-02 08:04:30 UTC --- (In reply to comment #5) Thanks a lot, at least for me this patch seems to solve the problem.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #15 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-02 08:48:27 UTC --- Author: jb Date: Wed Feb 2 08:48:24 2011 New Revision: 169517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169517 Log: PR 47571 Weakref trickery for clock_gettime() Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/time_1.h
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #6 from Martin Losch mlo...@uni-bremen.de 2011-02-02 09:00:10 UTC --- (In reply to comment #4) As far as I can see (from the header files that came with pre-compiled binaries) this was used: #define MPFR_VERSION_STRING 2.4.1 #define MPC_VERSION_STRING 0.8.1 #define __GNU_MP_VERSION 4 #define __GNU_MP_VERSION_MINOR 3 #define __GNU_MP_VERSION_PATCHLEVEL 1 I have used gdb for minimally, but what is its use here? I cannot create an executable if I do not reduce the optimization level. What do you suggest?
[Bug c++/47585] New: remaining dependent base lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47585
Summary: remaining dependent base lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: krec...@ginac.de
G++ accepts this invalid code:
template class T
struct base {
void f(void*);
};
template class T
struct derived : baseT {
derived() { f(this); } /* note: f(0) breaks g++, too */
};
struct instanced : derivedunsigned {
instanced() {}
};
See a recent discussion on news:comp.lang.c++.moderated about this:
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/ba5a7a368233a022
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #7 from Martin Losch mlo...@uni-bremen.de 2011-02-02 09:09:07 UTC --- (In reply to comment #5) I have had a look at the test code. Could you try (1) to comment the call to EXCH2_UV_AGRID_3D_RL, (2) the same for the (two?) COMMONs, and see if one of these changes makes the ICE disappear? I do not understand (1): commenting out the call to this routine elsewhere does not modify the compilation of the routine. If you meant commenting out the calls to EXCH2_RL1_CUBE, then this does not make the ICE go away. (2) I commented out all (five) COMMON blocks (but not the associated declarations of variables), and the ICE does not go away, either. What makes the problem go away is commenting out line 949.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2011.02.02 09:12:46
Ever Confirmed|0 |1
--- Comment #32 from Iain Sandoe iains at gcc dot gnu.org 2011-02-02 09:12:46
UTC ---
(In reply to comment #31)
I can confirm that adding -flat_namespace to the linkage of xplor using stock
gcc trunk is insufficient to eliminate the crashes in the FSF libgcc unwinder.
comment #30 and comment #31 are as one would expect.
adding -flat_namespace pushes the responsibility onto the build to ensure that
the libs are presented in the correct order for the design (when symbols appear
in more than one lib). That includes libs provided by GCC - although (maybe)
the User should not have to think about that. It also includes placement of
the libs in search paths at load/execute time (outside of our control).
One way of controlling the [link time] order (with the #24 patch in place) is
to add -flat_namespace to the exe too. Equally, one could ensure that the
build references /usr/lib/libgcc_s.10.5.dylib or libSystem before
/my/install/path/libgcc_s.1.dylib.
Ultimately, the 'fix' to this is to ensure that the lib we install to provide
the extensions does not export the other symbols (then we won't care about of
the order of libs or DYLD_LIBRARY_PATHs). However, this is not something for
stage 4, and I expect that there will be test-suite fall-out when we implement
it.
So either
1/revert 163267 as proposed,
Are we sure that it has no effect on any other (esp. Java) test-cases?
2/ Patch @ comment #24 is a work-around that only changes the order for flat
namespace.
If we do #2, then we should add Zforce_flat_namespace as Jack pointed out in
comment #27 like so:
%{Zflat_namespace|Zforce_flat_namespace:
3/ %L %G %L
If (1) doesn't work then neither will this.
So - the permutations need reg-strapping (on Darwin 10 at least) - I'll do a
sanity check on Darwin 9 - although it should be unaffected.
[Bug target/47551] ICE when reloading neon registers from out-of-range offsets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47551 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.02 09:16:47 CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/47553] ARM neon vld1q_lane_u8 co. don't accept lanes = 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg02284.htm ||l Last reconfirmed||2011.02.02 09:18:50 CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-02 09:35:31 UTC --- (In reply to comment #6) I have used gdb for minimally, but what is its use here? I cannot create an executable if I do not reduce the optimization level. What do you suggest? I suggest to run gdb on f951 to see the path leading to the error exch2_uv_agrid_3d_rl.f:293:0: internal compiler error: in build2_stat, at tree.c:3795 gfortran is located in /some_path/bin. You'll find f951 in /some_path/libexec/gcc/platform/version/ (gdb /opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/f951 for me). Set a breakpoint to fancy_abort, run the code and do a backtrace. (In reply to comment #7) What makes the problem go away is commenting out line 949. There is no line 949 in attachment 23201. The goal is to reduce the file to the minimal size reproducing the ICE. CALL and COMMON have triggered bugs in the past, hence my question (note that in the attachment 23201 there are only two COMMONs: /EEPARAMS_L/ and /EEPARAMS_I/).
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #9 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 09:50:23 UTC --- (In reply to comment #8) The potential fix seems to work fine on x86 as well. I'm going to build a arm-elf toolchain and see if anything else pops up during a cross build. If someone with real arm hardware could do a bootstrap with the potential fix applied, it'd be greatly appreciated. Thanks for nailing this one so quickly, Jeff. I will set off a native bootstrap and report back when done.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-02 09:59:29 UTC --- Author: rguenth Date: Wed Feb 2 09:59:23 2011 New Revision: 169518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169518 Log: 2011-02-02 Richard Guenther rguent...@suse.de PR tree-optimization/47566 * builtins.c (builtin_save_expr): No SAVE_EXPR for SSA_NAMEs. * gcc.dg/lto/20110201-1_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/20110201-1_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug target/47564] [4.6 Regression] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 10:00:11 UTC --- Created attachment 23211 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23211 gcc46-pr47564.patch Updated fix. For 4.7 I'd say we want to split this reinitialization up, into reinitializations that matter for tree optimizations (ideally those could be saved into (and restored from) some save area pointed to from TARGET_OPTION_NODE, e.g. init_set_costs can be saved into target_cfgloop structure), and initializations that only matter from expand_gimple_cfg entry till free_after_compilation (there we could remember the last TARGET_OPTION_NODE (or global) and if current TARGET_OPTION_NODE (or global) is different from it, call the init_* calls at the beginning of expand_gimple_cfg.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-02 10:00:49 UTC --- Fixed.
[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug debug/47508] [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47508 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 10:05:24 UTC --- And now a new version of that patch has been checked in. Can you verify if this bug still exists with current trunk (r169513 or newer)?
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Martin Losch mlo...@uni-bremen.de changed: What|Removed |Added Attachment #23201|0 |1 is obsolete|| --- Comment #9 from Martin Losch mlo...@uni-bremen.de 2011-02-02 10:08:39 UTC --- Created attachment 23212 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23212 simplified fortran code to reproduce problem commenting either lines 91 and 92 or 98 and 99 gets rid off the ICE
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #10 from Martin Losch mlo...@uni-bremen.de 2011-02-02 10:28:15 UTC --- (In reply to comment #8) (In reply to comment #6) I have used gdb for minimally, but what is its use here? I cannot create an executable if I do not reduce the optimization level. What do you suggest? I suggest to run gdb on f951 to see the path leading to the error exch2_uv_agrid_3d_rl.f:293:0: internal compiler error: in build2_stat, at tree.c:3795 gfortran is located in /some_path/bin. You'll find f951 in /some_path/libexec/gcc/platform/version/ (gdb /opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/f951 for me). Set a breakpoint to fancy_abort, run the code and do a backtrace. I am afraid that's beyond my capabilities. my gdb does not off a breakpoint fancy_abort and since I only download precompiled binaries the gbd does not even find the object files. Here's the beginning of the output: gdb /usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951 GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-apple-darwin...Reading symbols for shared libraries ... warning: Could not find object file /Users/gkhanna/build/x86_64-apple-darwin10.4.0/libgcc/_muldi3_s.o - no debug information available for ../../../gcc-4.6-20101106/libgcc/../gcc/libgcc2.c. [...] (In reply to comment #7) What makes the problem go away is commenting out line 949. There is no line 949 in attachment 23201 [details]. The goal is to reduce the file to the minimal size reproducing the ICE. CALL and COMMON have triggered bugs in the past, hence my question (note that in the attachment 23201 [details] there are only two COMMONs: /EEPARAMS_L/ and /EEPARAMS_I/). This is embarrissing. I apologize for attaching another wrong file (the correct file name would have been exch2_uv_agrid_3d_rl.f). I have now removed everything from this file that seems unnecessary to reproduce the ICE and have attached it as strippeddownfile.f (attachment 23212).
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-02 11:22:39 UTC --- This is embarrissing. I apologize for attaching another wrong file (the correct file name would have been exch2_uv_agrid_3d_rl.f). I have now removed everything from this file that seems unnecessary to reproduce the ICE and have attached it as strippeddownfile.f (attachment 23212 [details]). Now I can reproduce it with revisions 166102, 166367, 166401, 166533, and 167096, but not with revision 162456 nor revision 167584. So the bug seems to have been introduced between revisions 162456 and 166102 and fixed between revisions 167096 and 167584. You are unlucky to be right where the bug is;-(I'll look later to see if I can refine the windows and try to spot the right pr). Meanwhile you should notify Gaurav Khanna about the bug and ask him if he his planning a more recent build.
[Bug middle-end/47581] [4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 11:23:18 UTC --- Before Richard's commit apparently expand_one_var wasn't updating stack_alignment_needed, just stack_alignment_estimated, now it updates both. As PREFERRED_STACK_BOUNDARY is 128 (the default), ix86_minimum_alignment: if (TARGET_64BIT || align != 64 || ix86_preferred_stack_boundary = 64) return align; returns 64 instead of 32. So, to fix this, either the stack_alignment_needed updating in expand_one_var isn't strictly necessary and we could undo that part of the changes. Or return 32 as MINIMUM_ALIGNMENT for DImode long long even for ix86_preferred_stack_boundary = 64. Or we could perhaps the /* Align start of frame for local function. */ offset = (offset + stack_alignment_needed - 1) -stack_alignment_needed; in ix86_compute_frame_layout perform only if if (offset != frame-sse_reg_save_offset || size != 0 || !current_function_is_leaf || cfun-calls_alloca || ix86_current_function_calls_tls_descriptor) (i.e. if frame size is 0 and no outgoing calls, it doesn't make sense to align).
[Bug c++/47585] remaining dependent base lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47585 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02 11:50:00 UTC --- dup of PR 24163 ?
[Bug c++/47585] remaining dependent base lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47585 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02 11:57:52 UTC --- yes, I'm sure this is the same, as in the bug I reported, baseT::f is only found if the expression is dependent (so lookup is delayed to instantiation time) but that shouldn't affect it. 14.6.2/3 is clear that dependent bases are not examined for unqualified name lookup at definition or instantiation *** This bug has been marked as a duplicate of bug 24163 ***
[Bug c++/24163] dependent Base class scope examined during unqualified name lookup in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24163 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||kreckel at ginac dot de --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02 11:57:52 UTC --- *** Bug 47585 has been marked as a duplicate of this bug. ***
[Bug target/47584] [4.6 regression] internal compiler error: sigsegv in libcpp/line-map.c:285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47584 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i686-pc-mingw32 Component|driver |target Version|unknown |4.6.0 Target Milestone|--- |4.6.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-02 12:10:48 UTC --- I suspect PCH on mingw might simply not work reliably.
[Bug middle-end/47581] [4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-02 12:12:23 UTC --- (In reply to comment #3) Before Richard's commit apparently expand_one_var wasn't updating stack_alignment_needed, just stack_alignment_estimated, now it updates both. As PREFERRED_STACK_BOUNDARY is 128 (the default), ix86_minimum_alignment: if (TARGET_64BIT || align != 64 || ix86_preferred_stack_boundary = 64) return align; returns 64 instead of 32. So, to fix this, either the stack_alignment_needed updating in expand_one_var isn't strictly necessary and we could undo that part of the changes. Or return 32 as MINIMUM_ALIGNMENT for DImode long long even for ix86_preferred_stack_boundary = 64. Or we could perhaps the /* Align start of frame for local function. */ offset = (offset + stack_alignment_needed - 1) -stack_alignment_needed; in ix86_compute_frame_layout perform only if if (offset != frame-sse_reg_save_offset || size != 0 || !current_function_is_leaf || cfun-calls_alloca || ix86_current_function_calls_tls_descriptor) (i.e. if frame size is 0 and no outgoing calls, it doesn't make sense to align). I think we align the stack for reload (which might still happen without outgoing calls, simply with enough register pressure).
[Bug middle-end/47581] [4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02
12:25:01 UTC ---
But then wouldn't be size != 0?
At least when I try -O2 -m32:
int
foo (int x, int y)
{
long long a = (x + 0LL) * y;
long long b = (x - 63LL) * ((y | 12) + 67LL);
long long c = (x - 27LL) * ((y | 17) + 12);
long long d = (x - 79LL) * ((y | 12) + 18);
long long e = (x - 28LL) * ((y | 21) + 34LL);
long long f = (x - 77LL) * ((y | 18) + 39LL);
return (a 10) + (b 8) + (c 6) + (d 24) + (e 17) + (f 39);
}
size is 0 until IRA time (no stack slots needed) and thus with the patch it
keeps not aligning the offset and then when some pseudos are spilled the
function is called again, at that point already get_frame_size is non-zero and
it allocates bigger stack. reload iterates as long as
verify_initial_elimination_offsets fails or as long as frame size changes, and
if (insns_need_reload != 0 || something_needs_elimination
|| something_needs_operands_changed)
{
HOST_WIDE_INT old_frame_size = get_frame_size ();
reload_as_needed (global);
gcc_assert (old_frame_size == get_frame_size ());
gcc_assert (verify_initial_elim_offsets ());
}
should IMHO make sure the patch can work properly (because it only changes
frame offsets if get_frame_size () changed and these asserts assure they don't.
[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583 --- Comment #7 from jpr at csc dot fi 2011-02-02 12:48:37 UTC --- (In reply to comment #6) (In reply to comment #5) Thanks a lot, at least for me this patch seems to solve the problem. Well, that patch did break the direct_io_1.f90 test case however, as the ext.dt member setting overwrote the ext.iterator member (when there was implied do loop in the inquire(iolength=) statement). This might be better: Index: io.c === --- io.c(revision 169506) +++ io.c(working copy) @@ -3091,7 +3091,8 @@ cp = gfc_get_code (); cp-op = EXEC_TRANSFER; cp-expr1 = expr; - cp-ext.dt = current_dt; + if (k != M_INQUIRE) +cp-ext.dt = current_dt; *cpp = cp; return MATCH_YES;
[Bug debug/47501] [4.6 Regression] -fcompare-debug failure with -Os -fmodulo-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47501 --- Comment #5 from Zdenek Sojka zsojka at seznam dot cz 2011-02-02 13:00:06 UTC --- Thank you for quick fix. I tested that patch on top of r169501 (I tested it before with r169450, but deleted the results...) - bootstrap with yes,rtl,df checking went fine, check with RUNTESTFLAGS=--target_board=unix/-fschedule-insns2/-fsched2-use-superblocks/-fmodulo-sched/-fcompare-debug showed no ICEs, -fcompare-debug failures or exec failures caused by that patch. (languages=c,c++,lto,fortran)
[Bug fortran/47572] [OOP] Invalid: Allocatable polymorphic with init expression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572 --- Comment #2 from janus at gcc dot gnu.org 2011-02-02 13:11:54 UTC --- Author: janus Date: Wed Feb 2 13:11:50 2011 New Revision: 169520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169520 Log: 2011-02-02 Janus Weil ja...@gcc.gnu.org PR fortran/47572 * resolve.c (resolve_fl_variable): Handle polymorphic allocatables. 2011-02-02 Janus Weil ja...@gcc.gnu.org PR fortran/47572 * gfortran.dg/class_36.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_36.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47572] [OOP] Invalid: Allocatable polymorphic with init expression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from janus at gcc dot gnu.org 2011-02-02 13:12:56 UTC --- Fixed with r169520. Closing.
[Bug middle-end/47581] [4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 13:52:42 UTC --- Created attachment 23213 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23213 gcc46-pr47581.patch This patch indeed fixes the testcase and passed bootstrap/regtest on x86_64-linux and i686-linux.
[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #23185|0 |1 is obsolete|| --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 13:54:26 UTC --- Created attachment 23214 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23214 gcc46-pr45122.patch This patch passed bootstrap/regtest on x86_64-linux and i686-linux, no regressions this time.
[Bug fortran/47586] New: allocatable components: deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47586 Summary: allocatable components: deep copy missing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Follow-up to PR 47455 (comment #5): type :: tx integer, dimension(:), allocatable :: i end type tx type(tx) :: this type(tx), target :: that type(tx), pointer :: p allocate(that%i(2)) that%i = [0, 0] p = that ! this = that ! (1) direct assignment: works (deep copy) ! this = p ! (2) using a pointer works as well this = find_x(that) ! (3) pointer function: fails (deep copy missing) that%i = [1, 1] print *,this%i if(any (this%i /= [0, 0])) call abort() contains function find_x(that) type(tx), target :: that type(tx), pointer :: find_x find_x = that end function find_x end This code currently fails for the third case, while it works for the first two.
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 --- Comment #14 from janus at gcc dot gnu.org 2011-02-02 14:10:41 UTC --- (In reply to comment #13) Thus, left to do for this PR is comment 5: A deep copy is missing. This is now PR 47586. Closing this one.
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from janus at gcc dot gnu.org 2011-02-02 14:11:33 UTC --- (In reply to comment #14) Closing this one. For real!
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #7 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-02 14:17:23 UTC --- (In reply to comment #6) Fixed http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00776.html Please considered this... http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01206.html It must be **transaction_safe** not transaction_pure. Moreover I think we should also add ECF_MALLOC (malloc attribute) because otherwise the allocated memory will not be considered as local. Extract from trans-mem.c: thread_private_new_memory() if (stmt is_gimple_call (stmt) gimple_call_flags (stmt) ECF_MALLOC) /* Thread-local or transaction-local. */ ; else retval = mem_non_local; Thanks.
[Bug middle-end/47581] [4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-02-02 14:18:22 UTC --- (In reply to comment #6) Created attachment 23213 [details] gcc46-pr47581.patch This patch indeed fixes the testcase and passed bootstrap/regtest on x86_64-linux and i686-linux. Update both stack_alignment_needed and stack_alignment_estimated in expand_one_var may lead missed optimization like this. We should delay stack_alignment_needed as much as we can. Setting stack_alignment_estimated should be good enough before stack_realign_finalized is set. We should find out why expand_one_var needs to set stack_alignment_needed. I think this is a real bug.
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #10 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 14:49:02 UTC --- (In reply to comment #8) The potential fix seems to work fine on x86 as well. I'm going to build a arm-elf toolchain and see if anything else pops up during a cross build. If someone with real arm hardware could do a bootstrap with the potential fix applied, it'd be greatly appreciated. The native bootstrap was successful. I configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --enable-languages=c,c++,fortran
[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546 --- Comment #3 from janus at gcc dot gnu.org 2011-02-02 14:49:16 UTC --- (In reply to comment #1) If gfortran is 4.5, I get hydro_fluxes.f90:7.18: use hydro_speeds 1 Internal Error at (1): mio_component_ref(): Component not found I get the same error with gfortran 4.5, but 4.6 works nicely for me at r169520. Rich, which version are you using?
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #11 from Jeffrey A. Law law at redhat dot com 2011-02-02 14:51:19 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/11 07:49, ibolton at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #10 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 14:49:02 UTC --- (In reply to comment #8) The potential fix seems to work fine on x86 as well. I'm going to build a arm-elf toolchain and see if anything else pops up during a cross build. If someone with real arm hardware could do a bootstrap with the potential fix applied, it'd be greatly appreciated. The native bootstrap was successful. I configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --enable-languages=c,c++,fortran Thanks. After sleeping on it, I made one tweak to the patch to avoid potential problems with creating invalid reg+reg addresses. I'll post the final version of the fix shortly. Thanks for testing, jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNSW9YAAoJEBRtltQi2kC7S2QH/jWJFLO2hRYmkk2cTEjbO+Gj co6DifPykbJOgYn5L80LfLDF9eDvnv2OXBis0mBeMfntUjpbZbb7EKc8uC0jdGOX upbibjvlQxhYfBdakuQB+5IZFEQMsTK+CMRem0z3Dc5egritGe8Sw8tTDCB1txki FAdOfmQzzNq9yGNzy2PZjadfGqWLMznHCxoSkwmM+kMiMD4C4ijjnOZde6GvbcHU G4PKw3ZOUTu65E/HsJie9Pvvsdjm4i2ER8BP10zBH8m3+AwmqRDg8iQkv0SWR5JE vEV4vHLk+G65GHWaGPz9+rx5xYBCH/htH1kiZA/fDA9JPbjXzFu1/22+Rbge9zY= =a9ih -END PGP SIGNATURE-
[Bug middle-end/47581] [4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-02-02 14:57:22
UTC ---
For this tescase, gcc 4.4 generates the most efficient code
while 4.5/4.6 become worse and worse:
[hjl@gnu-6 gcc]$ cat x.i
unsigned mulh(unsigned a, unsigned b)
{
unsigned long long l __attribute__ ((aligned(32)))
=((unsigned long long)a * (unsigned long long)b) 32;
return l;
}
[hjl@gnu-6 gcc]$ /usr/gcc-4.4/bin/gcc -O2 -S -fomit-frame-pointer x.i -m32
[hjl@gnu-6 gcc]$ cat x.s
.filex.i
.text
.p2align 4,,15
.globl mulh
.typemulh, @function
mulh:
movl8(%esp), %eax
mull4(%esp)
movl%edx, %eax
ret
.sizemulh, .-mulh
.identGCC: (GNU) 4.4.4
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 gcc]$ /usr/gcc-4.5/bin/gcc -O2 -S -fomit-frame-pointer x.i -m32
[hjl@gnu-6 gcc]$ cat x.s
.filex.i
.text
.p2align 4,,15
.globl mulh
.typemulh, @function
mulh:
pushl%ebp
movl%esp, %ebp
movl12(%ebp), %eax
mull8(%ebp)
popl%ebp
movl%edx, %eax
ret
.sizemulh, .-mulh
.identGCC: (GNU) 4.5.1 20100507 (prerelease) [gcc-4_5-branch revision
159167]
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 gcc]$ ./xgcc -B./ -O2 -S -fomit-frame-pointer x.i -m32
[hjl@gnu-6 gcc]$ cat x.s
.filex.i
.text
.p2align 4,,15
.globlmulh
.typemulh, @function
mulh:
.LFB0:
.cfi_startproc
pushl%ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
andl$-32, %esp
movl12(%ebp), %eax
mull8(%ebp)
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
movl%edx, %eax
ret
.cfi_endproc
.LFE0:
.sizemulh, .-mulh
.identGCC: (GNU) 4.6.0 20110131 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 gcc]$
[Bug middle-end/47581] [4.5/4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2011-02-02 15:05:10
UTC ---
(In reply to comment #8)
For this tescase, gcc 4.4 generates the most efficient code
while 4.5/4.6 become worse and worse:
[hjl@gnu-6 gcc]$ cat x.i
unsigned mulh(unsigned a, unsigned b)
{
unsigned long long l __attribute__ ((aligned(32)))
=((unsigned long long)a * (unsigned long long)b) 32;
return l;
}
This is caused by revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #12 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 15:06:07 UTC --- The native bootstrap was successful. I configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --enable-languages=c,c++,fortran Thanks. After sleeping on it, I made one tweak to the patch to avoid potential problems with creating invalid reg+reg addresses. I'll post the final version of the fix shortly. I forgot to mention that I also used the bootstrapped compiler to confirm that the reduced test case now works. I will re-confirm when your final patch is posted. Thanks again.
[Bug bootstrap/47044] bootstrap comparison failure when -O2 defaults on -fgraphite-identity and --enable-build-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47044 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-02 15:08:33 UTC --- This issue appears to be resolved at r169520 with http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00070.html (omitting the TODO_update_address_taken part) and http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00095.html.
[Bug middle-end/47581] [4.5/4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 15:14:45 UTC --- As #c8 is caused by a different patch and is much lower priority (because only very few people use explicitly aligned long longs on i?86), please track it separately instead of overloading this bug.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 15:24:25 UTC --- One possibility would be to only fold __builtin_fma* into FMA_EXPR after IPA passes.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-02 15:30:51 UTC --- (In reply to comment #2) One possibility would be to only fold __builtin_fma* into FMA_EXPR after IPA passes. Expanding FMA_EXPR as __builtin_fma (thus, a libcall) as fallback sounds safe. We probably have similar issues for other builtins (consider the generic vector lowering code for example). Thus, in expr.c only dispatch to expand_ternary_op if there is an optab available, else emit a libcall. Folding back to __builtin_fma* sounds ugly.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02
15:39:00 UTC ---
FMA_EXPR is created though not only just for __builtin_fma{,l,f} in the code,
but also for x * y + z when contracting. Can expansion rely that this is
happening only after IPA passes? Otherwise we could be creating fma,f,l} calls
in freestanding environments, or try create it say for __float128 where there
is no such builtin, etc.
[Bug c++/47589] New: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589 Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: maxim.yegorush...@gmail.com g++ crashing consistently on the attached (preprocessed) source. $ /usr/bin/g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.5 20101112 (Red Hat 4.4.5-2) (GCC) $ /usr/bin/g++ -c -o /home/yegorm/depot1/cmm/prj_ledger_dev/build/Linux-x86_64-64.g++-debug/obj/infra/demux/unit_test.o -m64 -I/home/yegorm/depot1/cmm/prj_ledger_dev/include -I/home/yegorm/depot1/cmm/prj_ledger_dev/include/Linux-x86_64-64.g++ -I/opt/atm/gcc-4.1-64/include/tzcode2009i -I/apps/infra/3rd-party/gcc-4.4-64/libxml2-2.7.7/include/libxml2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99_MATH -D__STDC_FORMAT_MACROS -pipe -g -I/apps/infra/3rd-party/gcc-4.4-64/boost-1_42/include -I/apps/infra/3rd-party/gcc-4.4-64/qt-4.6.3/include -I/opt/atm/gcc-4.1-64/include/oapi-17.2 -I/apps/infra/3rd-party/gcc-4.4-64/hdf5-1.8.5/include -I/apps/infra/3rd-party/gcc-4.4-64/matio-1.3.4/include -I/apps/infra/3rd-party/gcc-4.4-64/gdbm-1.8.3/include -Wall -Wextra -Wno-parentheses -Wno-missing-field-initializers -Wno-unused-parameter -Winit-self -Wcast-align -Wmissing-include-dirs -Wpointer-arith -Wwrite-strings -Wno-non-virtual-dtor -Wno-multichar -Wno-ignored-qualifiers -march=native -fdiagnostics-show-option -fno-strict-aliasing -Werror=return-type -Werror=format-extra-args -fmessage-length=0 -falign-functions -MD -MP -MF /home/yegorm/depot1/cmm/prj_ledger_dev/build/Linux-x86_64-64.g++-debug/obj/infra/demux/unit_test.d /home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc In file included from /home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc:1: /home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/demux.h: In constructor 'atm::demux::TaggedFdEventTag, Derived::TaggedFd() [with EventTag = unnamed::FdTag, Derived = unnamed::DemuxTestClient]': /home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc:49: instantiated from here /home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/demux.h:325: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccfLB5zA.out file, please attach this to your bugreport.
[Bug c++/47589] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589 --- Comment #1 from Maxim Yegorushkin maxim.yegorushkin at gmail dot com 2011-02-02 15:43:45 UTC --- Created attachment 23215 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23215 Archived preprocessed source Could not attach the preprocessed source as plain text because of the attachment file size limit. Had to archive it.
[Bug bootstrap/47044] bootstrap comparison failure when -O2 defaults on -fgraphite-identity and --enable-build-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47044 --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:52:27 UTC --- Author: spop Date: Wed Feb 2 15:52:21 2011 New Revision: 169531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169531 Log: Fix PR40979 and PR47044: after LIM call copy_prop and DCE to clean up. 2011-02-02 Sebastian Pop sebastian@amd.com Richard Guenther rguent...@suse.de PR tree-optimization/40979 PR bootstrap/47044 * passes.c (init_optimization_passes): After LIM call copy_prop and DCE to clean up. * tree-ssa-loop.c (pass_graphite_transforms): Add TODO_dump_func. * gcc.dg/graphite/graphite.exp (DEFAULT_VECTCFLAGS): Add -ffast-math. * gcc.dg/graphite/pr35356-2.c: Adjust pattern. * gfortran.dg/graphite/graphite.exp: Run vect_files conditionally to check_vect_support_and_set_flags. * gfortran.dg/graphite/vect-pr40979.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/graphite.exp trunk/gcc/testsuite/gcc.dg/graphite/pr35356-2.c trunk/gcc/testsuite/gfortran.dg/graphite/graphite.exp trunk/gcc/tree-ssa-loop.c
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979 --- Comment #22 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:52:26 UTC --- Author: spop Date: Wed Feb 2 15:52:21 2011 New Revision: 169531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169531 Log: Fix PR40979 and PR47044: after LIM call copy_prop and DCE to clean up. 2011-02-02 Sebastian Pop sebastian@amd.com Richard Guenther rguent...@suse.de PR tree-optimization/40979 PR bootstrap/47044 * passes.c (init_optimization_passes): After LIM call copy_prop and DCE to clean up. * tree-ssa-loop.c (pass_graphite_transforms): Add TODO_dump_func. * gcc.dg/graphite/graphite.exp (DEFAULT_VECTCFLAGS): Add -ffast-math. * gcc.dg/graphite/pr35356-2.c: Adjust pattern. * gfortran.dg/graphite/graphite.exp: Run vect_files conditionally to check_vect_support_and_set_flags. * gfortran.dg/graphite/vect-pr40979.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/graphite.exp trunk/gcc/testsuite/gcc.dg/graphite/pr35356-2.c trunk/gcc/testsuite/gfortran.dg/graphite/graphite.exp trunk/gcc/tree-ssa-loop.c
[Bug tree-optimization/47555] [4.4 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #9 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:52:15 UTC --- Author: spop Date: Wed Feb 2 15:52:08 2011 New Revision: 169530 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169530 Log: Fix PR47576 and PR47555: add PARAM_SCEV_MAX_EXPR_COMPLEXITY. 2011-02-02 Sebastian Pop sebastian@amd.com PR tree-optimization/47576 PR tree-optimization/47555 * doc/invoke.texi (scev-max-expr-complexity): Documented. * params.def (PARAM_SCEV_MAX_EXPR_SIZE): Bump the value to 100. (PARAM_SCEV_MAX_EXPR_COMPLEXITY): Declared. * tree-scalar-evolution.c (follow_ssa_edge): Use PARAM_SCEV_MAX_EXPR_COMPLEXITY. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/tree-scalar-evolution.c
[Bug middle-end/47576] [4.6 Regression] FAIL: gfortran.dg/graphite/pr42732.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47576 --- Comment #4 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:52:15 UTC --- Author: spop Date: Wed Feb 2 15:52:08 2011 New Revision: 169530 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169530 Log: Fix PR47576 and PR47555: add PARAM_SCEV_MAX_EXPR_COMPLEXITY. 2011-02-02 Sebastian Pop sebastian@amd.com PR tree-optimization/47576 PR tree-optimization/47555 * doc/invoke.texi (scev-max-expr-complexity): Documented. * params.def (PARAM_SCEV_MAX_EXPR_SIZE): Bump the value to 100. (PARAM_SCEV_MAX_EXPR_COMPLEXITY): Declared. * tree-scalar-evolution.c (follow_ssa_edge): Use PARAM_SCEV_MAX_EXPR_COMPLEXITY. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/tree-scalar-evolution.c
[Bug bootstrap/47044] bootstrap comparison failure when -O2 defaults on -fgraphite-identity and --enable-build-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47044 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:54:17 UTC --- Fixed.
[Bug middle-end/47576] [4.6 Regression] FAIL: gfortran.dg/graphite/pr42732.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47576 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:56:23 UTC --- Fixed.
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 15:59:20 UTC --- Fixed.
[Bug tree-optimization/47555] [4.4 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #10 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 16:01:34 UTC --- What about backporting this patch to 4.4 and 4.5?
[Bug c++/47589] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02 16:05:34 UTC --- I think this is PR 45894
[Bug debug/47590] New: var tracking produces wrong debug in code where optimization is turned off using pragma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47590 Summary: var tracking produces wrong debug in code where optimization is turned off using pragma Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: harihar...@picochip.com Created attachment 23216 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23216 The source code In the attached testcase #pragma has been used to turn optimization off (The file is otherwise compiled at -Os). By turning off optimization, we expected to be able to get better debug experience. We noticed that the variable n in the function fn takes the following values, if you step through the function. 4 3 0 2 1 5 0 10 -1 which is obviously wrong. I reckon the problem lies in var-tracking. Our dwarf reader tells me that the value of n could be found in the following places. Name: n Location: [29, 48) : DW_OP_reg1 [48, 66) : DW_OP_reg4 [66, 102) : DW_OP_fbreg[-6] [102, 112) : DW_OP_reg4 I will attach the address encoded assembly so you can see that var-tracking gets it wrong. If i compile the whole file at -O0, the dwarf information the dwarf gets it right. Name: n Location: DW_OP_fbreg[-6] In this particular case, adding -fno-var-tracking has the same effect in correcting the debug information. I guess there are 2 things that could be done. 1. Find out the problem in var-tracking in this case and fix it. 2. Turn off var-tracking for functions where optimization is turned off using attributes/pragmas. Please let me know if you need any other information on this. I tried all my experiments with master (as of 2-feb-2011). The experiments were conducted on picochip (picochip-unknown-none target triplet). Thanks Hari
[Bug debug/47590] var tracking produces wrong debug in code where optimization is turned off using pragma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47590 --- Comment #1 from hariharans at picochip dot com 2011-02-02 16:07:27 UTC --- Created attachment 23218 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23218 The assembly output from -Os compilation
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #31 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 16:07:14 UTC --- Created attachment 23217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23217 gcc46-pr47274.patch I think it is fairly obvious where the bug is (though haven't tried to reproduce it). Passing address of a 32-bit enum variable and outputting from it the first byte obviously will DTRT only on little endian hosts.
[Bug c++/45894] [4.5 Regression] [C++0x] ICE: segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45894 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||maxim.yegorushkin at gmail ||dot com --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02 16:08:14 UTC --- *** Bug 47589 has been marked as a duplicate of this bug. ***
[Bug c++/47589] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02 16:08:14 UTC --- confirmed as a dup - 4.5.2 doesn't ICE on the testcase, but reverting the fix for PR 45894 causes it to ICE *** This bug has been marked as a duplicate of bug 45894 ***
[Bug debug/47590] var tracking produces wrong debug in code where optimization is turned off using pragma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47590 --- Comment #2 from hariharans at picochip dot com 2011-02-02 16:08:20 UTC --- Created attachment 23219 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23219 The assembly with instruction addresses
[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2011-02-02 16:23:27 UTC --- I won't fix graphite in 4.4, please use GCC 4.5.
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-02 16:25:42 UTC --- This pr looks like a duplicate of pr46664 fixed at revision 167173 (the test in attachment 23212 gives an ICE also at revision 167138).
[Bug c++/45894] [4.5 Regression] [C++0x] ICE: segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45894
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-02
16:27:46 UTC ---
Although this bug has 4.4.5 in the Known to work field, the bug in cp/tree.c
is present on the 4.4 branch, and the testcase in PR 47589 causes an ICE with
4.4.5, without -Wall or -std=c++0x
The fix for cp/tree.c looks safe to backport to 4.4 - any objections to doing
so?
--- gcc/cp/tree.c.jj2010-11-03 16:58:26.0 +0100
+++ gcc/cp/tree.c 2010-11-05 13:45:53.0 +0100
@@ -67,7 +67,8 @@ lvalue_kind (const_tree ref)
== REFERENCE_TYPE)
return lvalue_kind (TREE_OPERAND (ref, 0));
- if (TREE_CODE (TREE_TYPE (ref)) == REFERENCE_TYPE)
+ if (TREE_TYPE (ref)
+ TREE_CODE (TREE_TYPE (ref)) == REFERENCE_TYPE)
{
/* unnamed rvalue references are rvalues */
if (TYPE_REF_IS_RVALUE (TREE_TYPE (ref))
