On May 15, 2007, at 2:03 PM, J.C. Pizarro wrote:
2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>
> 1. Can you localize it
2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>
> 1. Can you localize its last output that stops in its internal
> infinit
On 5/14/07, Serge Belyshev <[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> It was a patch to enable more optimization. Reverting it should be as safe
> or unsafe as exchanging forwprop and dce passes. And I have no idea
> as how to quantify safeness of either ;)
>
>
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> It was a patch to enable more optimization. Reverting it should be as safe
> or unsafe as exchanging forwprop and dce passes. And I have no idea
> as how to quantify safeness of either ;)
>
> I'd say we better analyze what goes wrong (as the probl
On 5/14/07, Jason Merrill <[EMAIL PROTECTED]> wrote:
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
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
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
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/
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 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
Joe Buck <[EMAIL PROTECTED]> wrote:
> But this was never a documented, supported way of doing things;
> nothing that involves hand-editing could be.
Fair enough, as far as my particular case is concerned. But something
new in 4.2 is inserting "-Xcompiler" between "-Xlinker" and the
following argu
On Sat, May 12, 2007 at 02:42:22AM -0400, Paul Jarc wrote:
> Joe Buck <[EMAIL PROTECTED]> wrote:
> > I don't even think this qualifies as a bug. It's basically an
> > enhancement request, to have a clean way of supporting glibc in
> > an unusual place.
>
> It works in previous versions going back
On May 12, 2007, at 6:32 AM, Andrew Pinski wrote:
On 5/11/07, Bill Wendling <[EMAIL PROTECTED]> wrote:
This one was just filed against 4.2.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
It is causing LLVM (at least) to fail to build. Do you think it's
worth adding to the list?
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 refs patch. If you want I can work
On 5/12/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:
On Sat, 12 May 2007, Benjamin Kosnik wrote:
> Whoops. It looks like this:
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00449.html
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00476.html
>
> never got checked in to the 4.2 changes document.
Indeed. I took Jason's excellent description and com
Mark Mitchell wrote:
Steven Bosscher wrote:
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you've been commenting on this; are you working on the
fix? If so, do you have an ETA?
Why are you wai
>> Names in anonymous namespaces had external linkage for a long time in
>> G++. Did they have internal linkage in 4.1, or was that introduced
>> (in
>> theory) for 4.2?
>It was introduced in 4.2.
Whoops. It looks like this:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00449.html
http://gcc.g
On 5/11/07, Bill Wendling <[EMAIL PROTECTED]> wrote:
This one was just filed against 4.2.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
It is causing LLVM (at least) to fail to build. Do you think it's
worth adding to the list?
You know the regression is not on the 4.2 branch an
On 12 May 2007, at 00:02, Mark Mitchell 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:
I admit this is not a blocking bug, but it seems fairly (very) easy
to solve... I st
Joe Buck <[EMAIL PROTECTED]> wrote:
> I don't even think this qualifies as a bug. It's basically an
> enhancement request, to have a clean way of supporting glibc in
> an unusual place.
It works in previous versions going back to 2.95.3, so I'd think it
would be a bug, and a regression. But sinc
On Sat, May 12, 2007 at 12:32:25AM -0400, Paul Jarc wrote:
> Sorry to bring this up so late, but I just tried building the last
> 4.2.0 prerelease and hit what seems to be a build bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
I don't even think this qualifies as a bug. It's basically a
Sorry to bring this up so late, but I just tried building the last
4.2.0 prerelease and hit what seems to be a build bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
paul
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:
>>
>> PR 31797: An infinite loop in the compiler while
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:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you'v
On May 11, 2007, at 5:28 PM, Mark Mitchell wrote:
Bill Wendling wrote:
Andrew Pinski wasn't able to reproduce the link error on Linux,
and I've
only seen it on Darwin. However, as Chris Lattner pointed out, this
indicates a fairly serious problem (which shows up even on the Linux
build) in
On Fri, May 11, 2007 at 05:21:01PM -0700, Bill Wendling wrote:
> On May 11, 2007, at 5:15 PM, Mark Mitchell wrote:
> >Bill Wendling wrote:
> >>This one was just filed against 4.2.0:
> >>
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
> >>
> >>It is causing LLVM (at least) to fail to build
Bill Wendling wrote:
> Andrew Pinski wasn't able to reproduce the link error on Linux, and I've
> only seen it on Darwin. However, as Chris Lattner pointed out, this
> indicates a fairly serious problem (which shows up even on the Linux
> build) in that the symbols aren't getting internal linkage
On May 11, 2007, at 5:15 PM, Mark Mitchell wrote:
Bill Wendling wrote:
This one was just filed against 4.2.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
It is causing LLVM (at least) to fail to build. Do you think it's
worth
adding to the list?
Does it show up anywhere other tha
Bill Wendling wrote:
> This one was just filed against 4.2.0:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
>
> It is causing LLVM (at least) to fail to build. Do you think it's worth
> adding to the list?
Does it show up anywhere other than Darwin? On the basis of Darwin
alone, I
On May 11, 2007, at 3:02 PM, Mark Mitchell 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:
PR 30252: Wrong code generation, perhaps due to the C++ front end's
representation for
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
1. Can you localize its last output that stops in its internal infinite loop?
2. Or, is there an infinite outputting in the console?
Steven Bosscher wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>> Daniel, I see you've been commenting on this; are you working on the
>> fix? If so, do you have an ETA?
>
> Why are you waiting for this one? RTEMS
On Sat, May 12, 2007 at 12:05:49AM +0200, Steven Bosscher wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >PR 31797: An infinite loop in the compiler while building RTEMS.
> >Daniel, I see you've been commenting on this; are you working on the
> >fix? If so, do you have an ETA?
>
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you've been commenting on this; are you working on the
fix? If so, do you have an ETA?
Why are you waiting for this one? RTEMS is not a primary or secondary
platf
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:
PR 30252: Wrong code generation, perhaps due to the C++ front end's
representation for base classes. Jason, are you actively investigating
42 matches
Mail list logo
