Alexander Kabaev wrote:
On Sun, 13 May 2007 10:53:44 +0200
Andreas Schwab <[EMAIL PROTECTED]> wrote:
Alexander Kabaev <[EMAIL PROTECTED]> writes:
The instruction below appears to be the problematic one, but I
cannot tell why:
[MMI] st8 [r16]=r17
This insn looks completely benign, I'd rathe
Mark Mitchell wrote:
I agree in principle -- much better the bugs we know than the ones we
don't. But, IIUC, the patch we'd be reverting is from March, 2006,
which means that there's potentially a lot more that depends on it. In
that sense, I don't even feel confident that reverting the change
Jason Merrill wrote:
> Mark Mitchell wrote:
>> I'm concerned about either of the other approaches, in that we don't
>> fully understand why they work, so we can't really be confident we're
>> not just pushing the bug around.
>
> Yes. But I would assert that pushing the bug back to where it was in
Mark Mitchell wrote:
I'm concerned about either of the other approaches, in that we don't
fully understand why they work, so we can't really be confident we're
not just pushing the bug around.
Yes. But I would assert that pushing the bug back to where it was in
previous releases is better bec
As per:
http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html
> Therefore, I'm going to get 4.2.0 out the door.
>
> Please consider the 4.2.0 branch completely frozen at this time.
>
> I will be working through the release checklist tonight.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
Jason Merrill wrote:
> Mark Mitchell wrote:
>> No, I don't think we know. There's speculation in the PR trail, but
>> that's it. I'd appreciate it if you were able to investigate further,
>> but I think I'd best just accept that this will not be fixed for 4.2.0.
>
> Or revert the patch that reve
Thanks to the efforts of Richard G. and others, we've managed to close
PR 31797, one of the two I highlighted in my previous status report on
Friday.
Meanwhile, PR 30252, which is the other issue I highlighted, looks more
difficult to solve. In particular, we don't yet understand the cause of
the
On 5/12/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
The two regressions which exist are:
FAIL: gcc.dg/vect/vect-102.c scan-tree-dump-times possible dependence
between data-refs 1
FAIL: gcc.dg/vect/vect-104.c scan-tree-dump-times possible dependence
between data-refs 1
I had forgot to ha
Mark Mitchell wrote:
No, I don't think we know. There's speculation in the PR trail, but
that's it. I'd appreciate it if you were able to investigate further,
but I think I'd best just accept that this will not be fixed for 4.2.0.
Or revert the patch that revealed the bug, or apply Richard Gu
Kenneth Hoste wrote:
> I admit this is not a blocking bug, but it seems fairly (very) easy to
> solve... I still have to figure out how the patch submission framework
> works (never contributed to an open-source project before), so I didn't
> get around to solve it myself.
>
> http://gcc.gnu.org/
Dear GCC folks,
I think I found a code generation bug in GCC 4.0.1.
I'm sending this mail to make sure this bug is known and
is or will be removed in newer versions.
On a quick glance I couldn't find it in the bug database,
so it may not be known.
***
I am developing a simulation program th
Dear GCC folks,
I think I found a code generation bug in GCC 4.0.1.
I'm sending this mail to make sure this bug is known and
is or will be removed in newer versions.
On a quick glance I couldn't find it in the bug database,
so it may not be known.
***
I am developing a simulation program th
On May 13, 2007, at 3:48 AM, Tom Womack wrote:
I have some code of the form
This really isn't enough, I put a bit of a testcase together, but
nothing that would give bad behavior at -O3 (there is no -O9).
Have more of a testcase? Something compilable?
-eric
I have updated the bounds checking patches for gcc 4.0.2 and 3.4.4 on
http://sourceforge.net/projects/boundschecking/
My patches are available from http://williambader.com/bounds/example.html
I have tested them under CentOS 4.4 Linux and Solaris/SPARC 10.
The patches add a -fbounds-checking flag
On 5/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
> > On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >> Every time I think we're almost there with this release, I seem to
> >> manage to get stuck. :-( However,
On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Every time I think we're almost there with this release, I seem to
>> manage to get stuck. :-( However, we're very close: the only PRs that
>> I'm waiting for are:
Jason Merrill wrote:
> Mark Mitchell wrote:
>> PR 30252: Wrong code generation, perhaps due to the C++ front end's
>> representation for base classes. Jason, are you actively investigating
>> this one?
>
> I haven't been; I've been working on the forced unwind stuff, and
> looking at the rvalue r
On Sun, 13 May 2007 10:53:44 +0200
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Alexander Kabaev <[EMAIL PROTECTED]> writes:
>
> > The instruction below appears to be the problematic one, but I
> > cannot tell why:
> >
> > [MMI] st8 [r16]=r17
>
> This insn looks completely benign, I'd rather it'
On 5/13/07, Jason Merrill <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> PR 30252: Wrong code generation, perhaps due to the C++ front end's
> representation for base classes. Jason, are you actively investigating
> this one?
I haven't been; I've been working on the forced unwind stuff, and
On Sun, 13 May 2007, Paul Jarc wrote:
> > Maybe there could be something like --with-libc=/some/path that
> > would automatically generate the correct Makefiles; that would be an
> > enhancement.
>
> Yes, although a more general enhancement would be to let the user add
> arbitrary flags to LDFLAG
I have some code of the form
const int primes[] = {7,11,13,17,19};
const int nprimes = sizeof(primes)/sizeof(int);
and later an inmost loop of the form
bool happy = true;
for (int i=0; i
On Fri, Jan 06, 2006 at 02:48:30PM -0800, Richard Henderson wrote:
>
> What they're looking for is, for functions that don't use
> the pic register, to not reserve the pic register so that
> it's available for computation. This is harder. In theory,
> ppc has some scheme for this, where they eli
Alexander Kabaev <[EMAIL PROTECTED]> writes:
> The instruction below appears to be the problematic one, but I cannot
> tell why:
>
> [MMI] st8 [r16]=r17
This insn looks completely benign, I'd rather it's the next insn that is
the problem:
chk.a.clr r14, .L1063
This is a speculation che
23 matches
Mail list logo
