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
infinite loop?
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 its last
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
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 problem is
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 ;)
I'd say
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 to
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 argument.
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
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 refs
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:
PR
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, we're very
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.
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
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 revealed the
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
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 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
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 an
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 since
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:
snip
I admit this is not a blocking bug, but it seems fairly (very) easy
to solve...
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 and
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
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
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
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:
PR
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
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?
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
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
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?
Why are
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 is not a
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?
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
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 would
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
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 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. Do you think
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 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've
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 building
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
41 matches
Mail list logo
