Dave,
You checked in r150960 here:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00642.html
This change affected ltmain.sh:
http://gcc.gnu.org/viewcvs/trunk/ltmain.sh?r1=150960r2=150959pathrev=150960
All of those changes to sed now make sed fail miserably on any mingw
host during the build:
NightStrike wrote:
Dave,
You checked in r150960 here:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00642.html
This change affected ltmain.sh:
http://gcc.gnu.org/viewcvs/trunk/ltmain.sh?r1=150960r2=150959pathrev=150960
All of those changes to sed now make sed fail miserably on any mingw
Argh. Very sorry for the breakage, I'll get straight onto it. What
versions of the mingw+msys tools are you using? Can you please send me a copy
of the generated libtool script, and the output you get when re-running the
failing libtool command manually after adding the --debug (non-modal)
Paolo Bonzini wrote:
Argh. Very sorry for the breakage, I'll get straight onto it. What
versions of the mingw+msys tools are you using? Can you please send
me a copy
of the generated libtool script, and the output you get when
re-running the
failing libtool command manually after
On 08/26/2009 12:38 PM, Dave Korn wrote:
Oops. Looks like there are different versions of SED that have different
requirements, because on cygwin SED 4.1.5, you*have* to quote the comma in
the curly-braces {min,max} repetitions specifier or it is interpreted as a
separator.
Right. I also
On 08/26/2009 12:48 PM, Dave Korn wrote:
Dave Korn wrote:
Also please single-quote the commands.
Ok, why?
BTW should I do that for all four of the patterns? And what about $dirname
and $basename, and the couple of dozen other locations in ltmain.sh that use
quoted sed scripts? (You
Paolo Bonzini wrote:
On 08/26/2009 12:48 PM, Dave Korn wrote:
Dave Korn wrote:
Also please single-quote the commands.
Ok, why?
BTW should I do that for all four of the patterns? And what about
$dirname
and $basename, and the couple of dozen other locations in ltmain.sh
that use
FWIW, I'm still looking at this on and off. I beleive the pure function
was a red herring, as this example also does the wrong thing:
extern int z;
int foo(int *y)
{
z = 1;
*y = 0;
return z; // returns 1, even though y could point to z :(
}
Not much joy tracking it down as
On Wed, Aug 26, 2009 at 12:50 PM, Ned Gillthomas.g...@csr.com wrote:
FWIW, I'm still looking at this on and off. I beleive the pure function was
a red herring, as this example also does the wrong thing:
extern int z;
int foo(int *y)
{
z = 1;
*y = 0;
return z; // returns 1,
I've never seen the answer to the following question: Why do some
versions of gcc that I build not have string substitutions in error
messages?
I get things like this:
[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 -
fschedule-insns -Wno-unused -O1 -fno-math-errno
Bradley Lucier luc...@math.purdue.edu writes:
I've never seen the answer to the following question: Why do some
versions of gcc that I build not have string substitutions in error
messages?
Perhaps you configured with --disable-intl?
So, is -fschedule-insns an option to be avoided?
On Wed, 2009-08-26 at 09:00 -0400, Bradley Lucier wrote:
I've never seen the answer to the following question: Why do some
versions of gcc that I build not have string substitutions in error
messages?
I get things like this:
[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc
The release of GNU MPFR 2.4.2 (andouillette sauce moutarde
patch level 2) is imminent. Please help to make this release
as good as possible by downloading and testing this release
candidate:
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.xz
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.bz2
On Wed, Aug 26, 2009 at 06:30:44AM -0700, Ian Lance Taylor wrote:
Bradley Lucier luc...@math.purdue.edu writes:
I've never seen the answer to the following question: Why do some
versions of gcc that I build not have string substitutions in error
messages?
Perhaps you configured with
On 2009-08-26 18:10:24 +0200, Vincent Lefevre wrote:
The release of GNU MPFR 2.4.2 (andouillette sauce moutarde
patch level 2) is imminent. Please help to make this release
as good as possible by downloading and testing this release
candidate:
[...]
Note: I've just got a report saying that
I've been making progress on the Ada side, the basic usage pattern for
gnat1 and gnatmake is working.
There are two problems right now:
1) Mixing of Ada.Text_IO and Text_IO as described at
http://gcc.gnu.org/ml/gcc-help/2009-08/msg00113.html
2) The 'X' lines in the ALI files are not what
* Dave Korn wrote on Wed, Aug 26, 2009 at 12:38:50PM CEST:
Paolo Bonzini wrote:
$ sed -e 's,/\(\./\)\{1\,\},/,g;s,/\.$,/,'
./foo/bar/./baz
./foo/bar/baz
$ sed -e 's,/\(\./\)\{1,\},/,g;s,/\.$,/,'
sed: -e expression #1, char 18: unknown option to `s'
$
Maybe the best thing
Ralf Wildenhues wrote:
* Dave Korn wrote on Wed, Aug 26, 2009 at 12:38:50PM CEST:
Ralf, have we discovered a new item for the autoconf man page portable
shell
chapter?
Not really:
Patterns should not include the separator (unless escaped), even
as part of a character class.
[ trimmed Cc:, added autoconf-patches; followups can remove gcc@ ]
[ http://thread.gmane.org/gmane.comp.gcc.devel/108348 ]
* Dave Korn wrote on Wed, Aug 26, 2009 at 08:16:11PM CEST:
Ralf Wildenhues wrote:
Patterns should not include the separator (unless escaped), even
as part of a
Patterns should not include the separator (unless escaped), even
as part of a character class. In conformance with Posix, the Cray
`sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.
[...]
Portable `sed' regular expressions should use `\' only to escape
characters in the
When I worked at AMD, I was starting to suspect that it may be more beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
have hard wired uses, which in the past always meant a lot of
Paolo Bonzini wrote:
Patterns should not include the separator (not even escaped, unless
you fancy having to use a semantically significant metacharacter for
your separator), even as part of a ...
No. The problem is exactly when you use a semantically significant
metacharacter
On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
When I worked at AMD, I was starting to suspect that it may be more
beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
I am seeing a performance regression on the port I maintain, and I would
appreciate some pointers.
When I compile the following code
void f(int *x, int *y){
*x = 7;
*y = 4;
}
with GCC 4.3.2, I get the desired sequence
To whom it may be concerned:
I have a quick question on the useage of your gnu free
fortran compiler. I have written fortran code for
microsoft fortran compiler version 5.1 and use an include
statement in my code. In this compiler, the include
statement starts with a $ letter. I think they
On Wed, Aug 26, 2009 at 10:47 PM, Peter Bergnerberg...@vnet.ibm.com wrote:
On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
I am seeing a performance regression on the port I maintain, and I would
appreciate some pointers.
When I compile the following code
void f(int *x, int
* Jason Merrill wrote on Wed, Aug 26, 2009 at 10:32:05PM CEST:
On 08/03/2009 04:09 PM, Pedro Lamarão wrote:
Current trunk (revision 150381) fails to bootstrap with the following
configuration:
.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
‘char* basename(const
On Wed, 2009-08-26 at 23:30 +0200, Richard Guenther wrote:
On Wed, Aug 26, 2009 at 10:47 PM, Peter Bergnerberg...@vnet.ibm.com wrote:
Looking at update_equiv_regs(), if I disable the replacement for regs
that are local to one basic block (patch below) like it existed before
John Wehle's
2009/8/26 Ralf Wildenhues ralf.wildenh...@gmx.de:
.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
‘char* basename(const char*)’
/usr/include/string.h:601: error: ambiguates old declaration ‘const
char* basename(const char*)’
The problem is that AC_CHECK_DECLS gets
Bradley Lucier luc...@math.purdue.edu writes:
Are 12 registers not enough, in principle, to do scheduling before
register allocation? I was getting a 15% speedup on some numerical
codes, as pre-scheduling spaced out the vector loads among the
floating-point computations.
If you are getting
gjalka...@pasty.net writes:
I have a quick question on the useage of your gnu free
fortran compiler. I have written fortran code for
microsoft fortran compiler version 5.1 and use an include
statement in my code. In this compiler, the include
statement starts with a $ letter. I think
On Aug 12, 2009, at 10:32, Joel Sherrill wrote:
Hi,
GNAT doesn't build for arm-rtems on 4.4.x or
SVN (PR40775). I went back to 4.3.x since I
remembered it building.
I have run the ACATS on an ep7312 target and
get a number of generic test failures that
don't look RTEMS specific. Has anyone
On Aug 21, 2009, at 18:40, Paul Smedley wrote:
Hi All,
I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
configure complains about not finding gnat. The problem is that the
only gnat compiled for OS/2 was
On Wed, 2009-08-26 at 17:12 -0700, Ian Lance Taylor wrote:
If you are getting that kind of speedup (which I personally did not
expect) then this is clearly worth pursuing. It should be possible to
make it work at least in 64-bit mode. I recommend that you file a bug
report or two for cases
Hi all,
Working with great Graphite developers, I have finished this summer's
GSoC project.
So I think it's time to summarize this summer's work and plan next.
For details about autopar in Graphite, you could refer to this page:
http://gcc.gnu.org/wiki/Graphite/Parallelization
and this page:
The mpfr 2.4.2-rc1 release builds fine on x86_64-apple-darwin10
and passes all of its testsuite. I do see a few warnings though...
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1
-DHAVE_STDARG=1
On 2009-08-26 22:54:05 -0400, Jack Howarth wrote:
The mpfr 2.4.2-rc1 release builds fine on x86_64-apple-darwin10
and passes all of its testsuite. I do see a few warnings though...
Thanks. The warnings should not be a problem, because the configure
script detected that the non-C90 features were
On 08/15/2009 10:12 AM, Jerry Quinn wrote:
Building with --enable-build-with-cxx fails to bootstrap as follows:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
C:\...gcc -v
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.32/configure msdosdjgpp
Thread model: single
gcc version 4.3.2 (GCC)
Build command line: gpp -oexcpt -DTESTBADE excpt.C
Execute command line: excpt
The following source code is a pared down version of a short
--- Comment #5 from ubizjak at gmail dot com 2009-08-26 06:27 ---
FYI, this testcase also fails on alpha:
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
(I was not able to debug it properly, will wait for your reduced testcase...)
--
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-26 06:41 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01405.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
--- Comment #2 from gerolf dot wendland at nsn dot com 2009-08-26 06:55
---
(In reply to comment #1)
That would require that the ABI specifies such a mangling. I'm not sure
anyone wants to go that route.
This is exactly what I had in mind. Slightly extended names for
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-26 08:45 ---
This looks like a target issue as that message is from rs6000.c.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2009-08-26 09:50 ---
Janus,
Thanks for reporting this. In fact, the bug is worse than you report; the
namespace of 'F1' is never freed!
ns-refs is set to one by gfc_get_namespace
it is incremented in decl.c(get_proc_name):800 for
--- Comment #47 from dominiq at lps dot ens dot fr 2009-08-26 10:32 ---
Created an attachment (id=18427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18427action=view)
Self contained reduced test for pr40440
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #48 from dominiq at lps dot ens dot fr 2009-08-26 10:34 ---
are there issues other than the ones reported in comment #44
I have opened pr41056 and pr41059 for other problems. There are ICEs for the
original test in pr40440 (with external iso_varying_string.mod, but not if
--- Comment #49 from dominiq at lps dot ens dot fr 2009-08-26 10:35 ---
Finally the last time -fwhole-file was the default, -fno-whole-file, it was
not working.
Please read: Finally the last time -fwhole-file was the default,
-fno-whole-file was not working.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-08-26 10:54 ---
The issue here is that during linking we do not optimize which triggers the
path in out-of-ssa coalescing that assumes no overlapping life-ranges are
present. Which is obviously not true if we optimized during lto
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-26 13:23 ---
Subject: Bug 41163
Author: rguenth
Date: Wed Aug 26 13:23:04 2009
New Revision: 151122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151122
Log:
2009-08-26 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-08-26 13:37
---
Confirmed.
Shorter testcase (crashes with -O -m32 on x86_64-unknown-linux-gnu):
==
int foo(volatile int i)
{
return (1LL 128 * i) i;
}
==
The
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-26 14:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Using -Os with gcc4.4 vs gcc4.3 we see a ~15% increase in code size. This is
due to the fact that load/store multiple instructions are not being used for
function prologue/epilogues. The other option would be to use out of line
save/restore calls in the prologue/epilogues (which are also not
--- Comment #1 from galak at kernel dot crashing dot org 2009-08-26 14:18
---
Created an attachment (id=18428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18428action=view)
size of all object files using gcc 4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41175
--- Comment #2 from galak at kernel dot crashing dot org 2009-08-26 14:18
---
Created an attachment (id=18429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18429action=view)
size of all object files using gcc 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41175
--- Comment #3 from galak at kernel dot crashing dot org 2009-08-26 14:20
---
I've attached comparisions of building the same u-boot source tree with gcc-4.3
from Fedora 10 on a PPC 64 host:
[ga...@blarg u-boot-85xx]$ gcc -v
Using built-in specs.
Target: ppc64-redhat-linux
Configured
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-26 14:28 ---
Typedefs are found using lookup_name.
There is not really a separate mapping; instead the
trees are held directly in the identifier node.
These are reset as typedefs (or whatever) go out of scope,
though.
--
--- Comment #11 from spop at gcc dot gnu dot org 2009-08-26 14:42 ---
This is a fix for this particular bug: I am considering this bug closed, and I
will close it when the patch will be in trunk.
This fix also decreases the compile time of graphite in general. I will send a
pointer
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 14:43 ---
IIUC, the top-level const qualifier on const typename FooD::double3 in the
primary template applies to the type, which is not known during phase 1
At instantiation time, double3 is known to be an array type, so decays
--- Comment #2 from bergner at gcc dot gnu dot org 2009-08-26 13:44 ---
The problem here, is that for some reason, IRA is spilling the two pseudos in
the test case, even though it seems it should be trivial. Looking deeper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #7 from galak at kernel dot crashing dot org 2009-08-26 13:54
---
I'm not what the means are bump the priority on this as a significant
regression in gcc4.4 as code that was building with gcc4.3 no longer builds
because the size of the generated binaries is significantly
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 14:51 ---
(In reply to comment #2)
IIUC, the top-level const qualifier on const typename FooD::double3 in the
primary template applies to the type, which is not known during phase 1
i.e. it's equivalent to typename
--- Comment #3 from bergner at gcc dot gnu dot org 2009-08-26 15:14 ---
Actually, they're already reordered by the time we call ira_color and the ira
dumps shows that:
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
--- Comment #4 from bergner at gcc dot gnu dot org 2009-08-26 15:22 ---
It's update_equiv_regs() that is causing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-26 15:31 ---
Reduced:
#include cassert
#include exception
struct GoodE {
GoodE()
{
try {
throw 1;
} catch (...) {
}
}
};
struct BadE {
BadE()
try {
throw 1;
--- Comment #8 from froydnj at gcc dot gnu dot org 2009-08-26 15:50 ---
Even if the problems in expand are fixed, reassoc is still going to cause
problems with the original testcase. From the dse1 dump:
D.2474_14 = (long long int) vLo_11;
D.2475_15 = (long long int) c1_6;
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 15:52 ---
It looks as though uncaught_exception() does not always become false when
entering the handler of a function-try-block, and this causes it to stay true.
Maybe the count of uncaught exceptions is not decremented in the
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 16:01 ---
(In reply to comment #2)
at the end of the handler, causing it to be one more than it should not be.
Oops, obviously I meant one more than it should be
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-26 16:17 ---
(In reply to comment #1)
Note that GoodE doesn't cause the problem. The difference is that BadE has a
function-try-block
And, of course, that the exception is rethrown by BadE at the end of the
handler. Changing
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2009-08-26
16:47 ---
The output from typing gfortran -v is listed below. It is a
cross-compilation, if that is significant.
Built by Equation Solution http://www.Equation.com.
Using built-in specs.
Target: i386-pc-mingw32
--- Comment #5 from redi at gcc dot gnu dot org 2009-08-26 16:50 ---
I think the problem is that the uncaught_exception() is true as soon as the
memory for the exception has been allocated, but if the exception's copy
constructor is elided then happens before entering the exception's
--- Comment #3 from ro at gcc dot gnu dot org 2009-08-26 17:44 ---
Josef, there are a couple of issues with complex support on Solaris 2/IRIX 6
where
you might be able to help.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-08-26
17:51 ---
Subject: Re: [4.5 regression] libgfortran fails to build on Solaris 10+:
'_Imaginary_I' undeclared
--- Comment #2 from dje at gcc dot gnu dot org 2009-08-25 21:32 ---
Just follow the style that
--- Comment #4 from peter_foelsche at agilent dot com 2009-08-26 18:06
---
Created an attachment (id=18430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18430action=view)
gpperror.cpp
shorter testcase
--
peter_foelsche at agilent dot com changed:
What|Removed
--- Comment #5 from peter_foelsche at agilent dot com 2009-08-26 18:13
---
seems to be fixed in gcc v4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-08-26 18:35 ---
Note that even for
(long long)i * (long long)j * (long long)i
we can only use one mulsidi3, so promoting parts of the multiplications to
additions should be still beneficial.
I suppose we should detect widening
--- Comment #6 from bangerth at gmail dot com 2009-08-26 18:49 ---
It's also fixed on mainline and it works on 4.2.1. I don't have a version of
4.3 lying around, but that would be the only open branch which appears to
still have the problem.
Would someone mind testing this on a current
--- Comment #10 from redi at gcc dot gnu dot org 2009-08-26 19:04 ---
Subject: Bug 41005
Author: redi
Date: Wed Aug 26 19:04:11 2009
New Revision: 151127
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151127
Log:
2009-08-26 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #4 from doriankrause at web dot de 2009-08-26 19:26 ---
Thanks Jonathan for your explanation. Now I can understand the reason behind
this... (though I'm not really happy with the fact that you need to understand
sort of internals to see why code doesn't compile).
Do I need
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-26 19:40 ---
fails with 4.3.4, I don't have a 4.3 branch to check the tip
pr.cc: In constructor VamsSystemFunction__GET_DEP__::VamsSystemFunction()
[with std::setSyAccess*, std::lessSyAccess*, std::allocatorSyAccess*
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-26 19:15 ---
Fixed for 4.4.2 and 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bangerth at gmail dot com 2009-08-26 19:43 ---
(In reply to comment #7)
pr.cc:38: error: invalid operands of types #8216;bool#8217; and
#8216;int#8217; to binary
#8216;operator==#8217;
This is doubly fascinating as there is no operator== in this line ;-)
W.
The following is the code of vectorized sin computation which uses
a lookup table.
#define NUM_SAMPLES_IN_CIRCLE2 150*1024
extern const int sign_;
extern const int notsign_;
extern __vector float ONE_DIV_PI2_;
extern __vector float numSamples;
extern __vector float sign;
extern __vector float
--- Comment #5 from ami_stuff at o2 dot pl 2009-08-26 20:25 ---
-m68060 -O3 ...:
GCC 4.1.2 - 385KB
GCC 4.2.5 - 386KB
GCC 4.3.2 - 777KB
GCC 4.4.1 - 1,18MB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-26 20:54 ---
Likely the same issue as PR40992.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hjl at gcc dot gnu dot org 2009-08-26 20:55 ---
Subject: Bug 41162
Author: hjl
Date: Wed Aug 26 20:55:42 2009
New Revision: 151130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151130
Log:
2009-08-26 H.J. Lu hongjiu...@intel.com
PR fortran/41162
--- Comment #9 from hjl dot tools at gmail dot com 2009-08-26 20:56 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENED
--- Comment #5 from bergner at gcc dot gnu dot org 2009-08-26 20:57 ---
From my bug analysis and request for comment on the mailinglist:
http://gcc.gnu.org/ml/gcc/2009-08/msg00485.html
This is caused by update_equiv_regs() which IRA inherited from local-alloc.c.
Although with gcc
--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-26 21:00 ---
I've maybe some insight why this is happening, compiling just the module. By
putting a breakpoint on gfc_set_backend_locus, the break is on
#0 gfc_set_backend_locus (loc=0x12f28b0) at
--- Comment #5 from rwild at gcc dot gnu dot org 2009-08-26 21:39 ---
patch at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01371.html
avoiding the regression but not fixing issues in remark #2
--
rwild at gcc dot gnu dot org changed:
What|Removed
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #12 from paolo dot carlini at oracle dot com 2009-08-26 22:55
---
Thanks Jon. I would say I'm guilty of this issue. To be fully honest, when Ed
proposed these bits of C++0x, I wasn't particularly excited: ok, can be
actually handy but really, we don't expect surprises
--- Comment #4 from sje at cup dot hp dot com 2009-08-26 22:58 ---
In addition to copying the t-* files over, you also need to modify config.gcc.
If you look at the 'alpha*-*-freebsd*' entry in that file you will see where
tmake_file is set to a list of files including t-crtfm. The
--- Comment #6 from hp at gcc dot gnu dot org 2009-08-26 23:09 ---
I see the patch for this PR has been reverted. Please also remove the
test-case, or xfail it until a fix is committed, as it's now technically a
regression (at least my autotester thinks so). Don't forget that you must
--- Comment #15 from sje at cup dot hp dot com 2009-08-26 23:10 ---
Test no longer fails due to checkin that fixes the scan for IA64.
See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01600.html
--
sje at cup dot hp dot com changed:
What|Removed
with this compiler:
[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline
--enable-languages=c,c++ --enable-stage1-languages=c,c++ --with-cpu=default64
Thread model:
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-27 00:14
---
Created an attachment (id=18431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18431action=view)
preprocessed source file
I'm not having much luck cutting this down more, sorry.
--
--- Comment #108 from lucier at math dot purdue dot edu 2009-08-27 01:18
---
direct.c contains a direct FFT; I've compiled the direct and inverse fft and I
ran it on arrays with 2^23 double-precision complex elements and
heine:~/programs/gcc/objdirs/bench-mainline-on-fft
--- Comment #109 from lucier at math dot purdue dot edu 2009-08-27 01:22
---
Created an attachment (id=18432)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18432action=view)
inner loop of direct.c with -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #110 from lucier at math dot purdue dot edu 2009-08-27 01:22
---
Created an attachment (id=18433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18433action=view)
inner loop of direct.c without -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #34 from carrot at google dot com 2009-08-27 01:40 ---
There is one optimization that we can do without affecting the ABI and linker
compatibility. The delete destructor(D0) always contains the content of
complete desturctor(D1) followed by a function call to delete. So
100 matches
Mail list logo
