Hello,
> By "this change" I mean just commenting out the check in
> doloop_condition_get. After applying the patch that introduced DOLOOP
> patterns for SPU (http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01470.html)
> we needed this hack in order to be able to use the doloop_condition_get to
> retu
> Same here (OpenSUSE 10.2, gcc 4.1.3), also for rev. 126127.
This was caused by accidental commit of mine (ie I've commited cse.c
with sharing changes). It is reverted now.
Honza
Snapshot gcc-4.3-20070629 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070629/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Friday 29 June 2007 17:31:17 pm Lawrence Crowl wrote:
> I've sent your question to the C++ committee, as I wasn't
> sure of the answer.
It's been pointed out to me, after I asked this, that the example code from
the second bullet under C++ for the gcc-4.2 changes document is almost
identical,
Same here (OpenSUSE 10.2, gcc 4.1.3), also for rev. 126127.
2007/6/29, Basile STARYNKEVITCH <[EMAIL PROTECTED]>:
Is it just me, or not?
On my system (Debian/Sid/AMD64 with gcc = 4.1.2 from Debian)
.
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/usr/src/Lang/gcc-tru
Seongbae Park (박성배, 朴成培) wrote:
> Here, because INCOMING_RETURN_ADDR_RTX is ultimately undef'ed,
> dataflow doesn't see any definition of the return address register,
> and happily treats b0 as not live throughout the function body.
> Then, global allocator, guided by this information, allocates
>
Is it just me, or not?
On my system (Debian/Sid/AMD64 with gcc = 4.1.2 from Debian)
.
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/usr/src/Lang/gcc-trunk/_Obj/build-x86_64-unknown-linux-gnu/fixincludes'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
On 6/29/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Thu, 28 Jun 2007, [EMAIL PROTECTED] wrote:
> Roman Zippel <[EMAIL PROTECTED]> wrote on 06/28/2007 07:54:43 PM:
>
> > Hi,
> > Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with
> > the other cases. While I tried to d
We have spent the last two weeks in lockdown, hopefully fixing
regressions.
At this point, there are 153 P3 and higher regressions open against GCC
4.3.0. In reviewing those, I was struck by how many are in fact new
regressions in 4.3 -- problems that did not occur in previous releases.
These in
Steve Kargl wrote:
> What's the status of the trunk freeze for going from stage
> 1 to stage 2? AFAICT, the number of regression on trunk
> has increased since you sent
>
> http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html
The important question is whether that change reflects more bugs being
int
> I'll try to make a simple example on which GCC produces bad code.
You can find an example below. GCC-4.1 generates bad code (GCC-4.2 is
fine). Neither version give a type-punning warning, though. I'm sorry
that I didn't check gcc-4.2 before I started this thread.
Geza
Here's the code, I c
After analyzing a build failure of wfmath with gcc-4.2, I condensed the issue
it was having to the following test case:
template class A { public: T x1; U x2; };
template class container_with_x1>
int f(const container_with_x1& y) {
return y.x1;
}
int g() {
A y;
return f(y);
}
This code c
Hello,
here are the numbers of regressions in 4.3 and the new regressions only
in 4.3:
Date All regressions new regressions
16.6.: 343 93
17.6.: 346 96
18.6.: 337 87
19.6.: 336 87
20.6.: 338 89
22.6.: 341 92
23.6.: 339 90
24.6.: 339 91
25.6.: 335 87
26.6.: 335 86
28.6.: 338 87
29.6.: 338 87
Hello,
> We did just this change
> (on top of SMS patches we intend to send in the next
> couple of weeks) and it did helped a lot - we succeeded on all unrolled
> loops that could not be SMSed before. Do you think it is safe to remove this
> check? There was no regressions found in our testing.
Hi,
On Thu, 28 Jun 2007, [EMAIL PROTECTED] wrote:
> Roman Zippel <[EMAIL PROTECTED]> wrote on 06/28/2007 07:54:43 PM:
>
> > Hi,
> > Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with
> > the other cases. While I tried to debug this I narrowed it down to the
> > changes in
>The following patch also solves the problem, but it makes me feel the
> need to state that I've *not* tried to make it look as bad as possible. :-(
I think that your solution is the minimally correct one, so no need for any
form of shyness. ;-)
> @@ -3297,23 +3299,6 @@ try_combine (rtx i3,
On Fri, Jun 29, 2007 at 11:43:49AM +1000, Hasjim Williams wrote:
> I guess I will need to define a new "maverick_cc_register". My question
> is can I reuse the same CC_REGNUM? Or do I also need another new
> CC_REGNUM_MAVERICK pseudo register?
See below.
> How do I get a new reg number alloca
On Fri, Jun 29, 2007 at 09:49:26AM +0200, Eric Botcazou wrote:
> > Index: gcc/combine.c
> > ===
> > --- gcc/combine.c (revision 125984)
> > +++ gcc/combine.c (working copy)
> > @@ -3298,7 +3298,7 @@ try_combine (rtx i3, rtx i2, rtx
> But try_combine() doesn't take that into account:
>
> /* If we had to change another insn, make sure it is valid also. */
> if (undobuf.other_insn)
> {
> rtx other_pat = PATTERN (undobuf.other_insn);
> ...
> other_code_number = recog_for_combine (&other_pat,
> undobuf.other_i
19 matches
Mail list logo
