Re: GCC 4.2.0 Status Report (2007-05-11)
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 output that stops in its internal > infinite loop? > 2. Or, is there an infinite outputting in the console? Did you read the referenced bug report? I suspect not. If not, please consider that you consume $100 for each email you post here and ask yourself, have I donated $100 worth of code to the project recently to pay for the cost of the email. If not, consider not posting the email or donating some more code to pay for it. Are you a president? Sure. You are mistaken, i have my freedom of expression. I am free like any person. Really? So, do you think you're free to talk about how to bake brownies on this list? Watch the google video linked to from slashdot a little while ago about code development in open source projects: http://developers.slashdot.org/article.pl?sid=07/03/12/1449201 and see what role you play, then see what role the people that tell you your posts are off-topic play and try and guess what role I play. Ask yourself, what direct benefit to the project does your contribution have? This list is for people that want to contribute code to gcc and for those that want to help and enable people that want to contribute code to gcc. My response to you I think is fairly off-topic for the list and is why I didn't include the whole list on that response, and I think your response above is off-topic as well. Let me repeat once more, please, stop posting off-topic posts to this list. This list is not open to off-topic posts. If you want to talk about the appropriateness of posting things to this list, you can talk about that on [EMAIL PROTECTED] if you'd like. Thank you for your consideration in this matter.
Re: GCC 4.2.0 Status Report (2007-05-11)
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? > 2. Or, is there an infinite outputting in the console? Did you read the referenced bug report? I suspect not. If not, please consider that you consume $100 for each email you post here and ask yourself, have I donated $100 worth of code to the project recently to pay for the cost of the email. If not, consider not posting the email or donating some more code to pay for it. Are you a president? You are mistaken, i have my freedom of expression. I am free like any person. I'm not a spammer. With the current tools (e.g. bugzilla, mail searcher, ..), if you can not localize the problem's origin then the problem will persist in the future. Is this due to bad A.I.? Poor agent of semantic network?
Re: GCC 4.2.0 Status Report (2007-05-11)
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 we better analyze what goes wrong (as the problem is possibly > latent on the mainline) and fix it properly. If we paper over it we will not > fix it at all. > I vote for reverting that change (r111639) on the branch before release. We would gain nothing by having bug 30252, however latent, uncovered in a released compiler. The patch only changes the heuristic where we create SFTs for. The bug is in handling aliasing with SFTs. So you'll fix this particluar case -- but I have no idea on what other testcases you re-expose the bug. So I'd rather stay with a few now known cases than shipping with other unknown ones (it maybe glibc which we miscompile after reverting the change). Richard.
Re: GCC 4.2.0 Status Report (2007-05-11)
"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 possibly > latent on the mainline) and fix it properly. If we paper over it we will not > fix it at all. > I vote for reverting that change (r111639) on the branch before release. We would gain nothing by having bug 30252, however latent, uncovered in a released compiler.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 sense, I don't even feel confident that reverting the change is a > conservative move, likely to lead to less optimal code, but not wrong > code. Are you? (That's a serious question; not a rhetorical one.) That's a fair question; I don't know anything about the patch or the bug it was intended to fix. Richard would know better. 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 possibly latent on the mainline) and fix it properly. If we paper over it we will not fix it at all. Richard.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 is a conservative move, likely to lead to less optimal code, but not wrong code. Are you? (That's a serious question; not a rhetorical one.) That's a fair question; I don't know anything about the patch or the bug it was intended to fix. Richard would know better. Jason
Re: GCC 4.2.0 Status Report (2007-05-11)
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 > previous releases is better because it's not a regression. 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 is a conservative move, likely to lead to less optimal code, but not wrong code. Are you? (That's a serious question; not a rhetorical one.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 because it's not a regression. Jason
Re: GCC 4.2.0 Status Report (2007-05-11)
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 bug, or apply Richard Guenther's > other patch to work around it? Sorry, your message *just* crossed: http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html in which I declared failure. :-) However, the release isn't really released until it's on the FTP sites, of course, so there's still time to talk me into a different course of action. 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. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 Guenther's other patch to work around it? Jason
Re: GCC 4.2.0 Status Report (2007-05-11)
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/bugzilla/show_bug.cgi?id=31586 > > Maybe someone could solve this, so it is solved in GCC 4.2 and others? Yes, this would be an easy bug to fix, and it would be good to do so, but I don't think this is likely before 4.2.0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 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 been commenting on this; are you working on the > >> fix? If so, do you have an ETA? > > > > It's not actually a PRE bug, andrew is right. > > None of the statements accessing volatile variables end up with > > has_volatile_ops set on them, which is what is really causing the > > problem. > > Thanks -- but that doesn't answer my questions. :-) Seriously, what I'm > trying to figure out is whether you (or someone) is working on fixing > this, so I can get a sense of the tradeoffs between releasing and > waiting for a fix. It means we have to figure out what is breaking it first :) I believe richard guenther has taken it over. Yes, it's fixed. Richard.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 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? > > It's not actually a PRE bug, andrew is right. > None of the statements accessing volatile variables end up with > has_volatile_ops set on them, which is what is really causing the > problem. Thanks -- but that doesn't answer my questions. :-) Seriously, what I'm trying to figure out is whether you (or someone) is working on fixing this, so I can get a sense of the tradeoffs between releasing and waiting for a fix. It means we have to figure out what is breaking it first :) I believe richard guenther has taken it over.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 patch. If you want I can work on this first, > but I doubt that the patch would be safe enough for the release branch. Yes, that's a good point. > Also, has someone actually verified that this is something that would be > fixed by the bases-as-fields work? 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. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 looking at the rvalue refs patch. If you want I can work on this first, but I doubt that the patch would be safe enough for the release branch. Also, has someone actually verified that this is something that would be fixed by the bases-as-fields work? Possibly not. See the audit trail of the PR. But, we can work around the problem by (bootstrapped and tested on x86_64-unknown-linux-gnu): Index: passes.c === --- passes.c(revision 124635) +++ passes.c(working copy) @@ -498,8 +498,8 @@ init_optimization_passes (void) /* Initial scalar cleanups. */ NEXT_PASS (pass_ccp); NEXT_PASS (pass_fre); - NEXT_PASS (pass_dce); NEXT_PASS (pass_forwprop); + NEXT_PASS (pass_dce); NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); though the base on which I would say this patch is safe is contradicted by the fact that it does fix (ok, work around) a regression ;) The underlying problem looks like an alias problem or a frontend problem leading to the alias problem, but I'm out of fu here and Sunday asks for some other things to do. Richard.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 LDFLAGS_FOR_TARGET. You can add --sysroot=, and the supported way to have libc in an unusual location is to build as a cross compiler and use --with-sysroot / --with-build-sysroot. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.2.0 Status Report (2007-05-11)
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. It may be that this insertion can be triggered in other ways that don't involve hand-editing, which would make it definitely a bug. So this is not known to be a bug, but also not known to not be a bug. > 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 LDFLAGS_FOR_TARGET. paul
Re: GCC 4.2.0 Status Report (2007-05-11)
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 2.95.3, so I'd think it > would be a bug, and a regression. But since this is such a rare > circumstance, I wouldn't expect it to be a release-blocker. I brought > it up only in the hope that it might be transparent to someone and > fixed before the release, but I certainly understand if it isn't. I disagree; you had a procedure to hand-edit the Makefile, and something changed so your procedure no longer works. But this was never a documented, supported way of doing things; nothing that involves hand-editing could be. Maybe there could be something like --with-libc=/some/path that would automatically generate the correct Makefiles; that would be an enhancement.
Re: GCC 4.2.0 Status Report (2007-05-11)
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? You know the regression is not on the 4.2 branch and only the trunk. I think Geoff applied the patch which caused the regression to your local 4.2 tree. So this is NOT a blocker for 4.2, only 4.3 when get around to fixing those regressions. Okay. Thanks, for checking on this! :-) -bw
Re: GCC 4.2.0 Status Report (2007-05-11)
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 this first, but I doubt that the patch would be safe enough for the release branch. Also, has someone actually verified that this is something that would be fixed by the bases-as-fields work? Jason
Re: GCC 4.2.0 Status Report (2007-05-11)
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 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? > > It's not actually a PRE bug, andrew is right. > None of the statements accessing volatile variables end up with > has_volatile_ops set on them, which is what is really causing the > problem. Thanks -- but that doesn't answer my questions. :-) Seriously, what I'm trying to figure out is whether you (or someone) is working on fixing this, so I can get a sense of the tradeoffs between releasing and waiting for a fix. I have two fixes and am currently testing one. Richard.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 committed it as a patch now: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00827.html Gerald
Re: GCC 4.2.0 Status Report (2007-05-11)
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 waiting for this one? RTEMS is not a primary or secondary platform. So there is no reason to wait with the release because of this PR, according to the release criteria (xf. http://gcc.gnu.org/gcc-4.2/criteria.html). I'm not particularly interested in it because of its RTEMS-ness. Rather, I'm interested in it because it's a new case of the compiler failing to correctly process valid code, not present in previous versions of GCC. The test case is not RTEMS-specific; it's a problem that looks like it could equally well apply to lots of other code out there making use of volatile storage. I thought Ralf had managed to reproduce the failure with the reduced test case on all targets he had tried. The code is in an RTEMS device driver but since it involves volatile, it is possible that this code occur in any OS or device driver. --joel
Re: GCC 4.2.0 Status Report (2007-05-11)
>> 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.gnu.org/ml/gcc-patches/2007-04/msg00476.html never got checked in to the 4.2 changes document. -benjamin
Re: GCC 4.2.0 Status Report (2007-05-11)
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 only the trunk. I think Geoff applied the patch which caused the regression to your local 4.2 tree. So this is NOT a blocker for 4.2, only 4.3 when get around to fixing those regressions. Thanks, Andrew Pinski
Re: GCC 4.2.0 Status Report (2007-05-11)
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 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/bugzilla/show_bug.cgi?id=31586 Maybe someone could solve this, so it is solved in GCC 4.2 and others? K. -- Computer Science is no more about computers than astronomy is about telescopes. (E. W. Dijkstra) Kenneth Hoste ELIS - Ghent University email: [EMAIL PROTECTED] blog: http://www.elis.ugent.be/~kehoste/blog website: http://www.elis.ugent.be/~kehoste
Re: GCC 4.2.0 Status Report (2007-05-11)
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 this is such a rare circumstance, I wouldn't expect it to be a release-blocker. I brought it up only in the hope that it might be transparent to someone and fixed before the release, but I certainly understand if it isn't. paul
Re: GCC 4.2.0 Status Report (2007-05-11)
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 enhancement request, to have a clean way of supporting glibc in an unusual place. You tried a hand-edit, and it didn't work as expected, and you filed a bug. Now you're bringing it up in a thread about release-blocking bugs?
Re: GCC 4.2.0 Status Report (2007-05-11)
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
Re: GCC 4.2.0 Status Report (2007-05-11)
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 RTEMS. >> Daniel, I see you've been commenting on this; are you working on the >> fix? If so, do you have an ETA? > > It's not actually a PRE bug, andrew is right. > None of the statements accessing volatile variables end up with > has_volatile_ops set on them, which is what is really causing the > problem. Thanks -- but that doesn't answer my questions. :-) Seriously, what I'm trying to figure out is whether you (or someone) is working on fixing this, so I can get a sense of the tradeoffs between releasing and waiting for a fix. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 been commenting on this; are you working on the fix? If so, do you have an ETA? It's not actually a PRE bug, andrew is right. None of the statements accessing volatile variables end up with has_volatile_ops set on them, which is what is really causing the problem.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 that the symbols aren't getting internal linkage (they're in an anonymous namespace, so should). It could impact performance on large systems quite a bit. Certainly during linking. 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. Also, this bug may be specific to typeinfo objects - other symbols seem to be ok. -Chris
Re: GCC 4.2.0 Status Report (2007-05-11)
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 it's
> >>worth
> >>adding to the list?
> >
> >Does it show up anywhere other than Darwin? On the basis of Darwin
> >alone, I would not further hold up the release. That is not to say
> >that
> >I would not consider a patch to fix it, of course.
> >
> 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
> (they're in an anonymous namespace, so should). It could impact
> performance on large systems quite a bit. Certainly during linking.
Shipping FSF releases already have that problem. Just try
---
namespace {
int foo = 0;
}
int bar = foo;
---
and look at the output with 4.1.2.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 (they're in > an anonymous namespace, so should). It could impact performance on large > systems quite a bit. Certainly during linking. 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? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 than Darwin? On the basis of Darwin alone, I would not further hold up the release. That is not to say that I would not consider a patch to fix it, of course. 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 (they're in an anonymous namespace, so should). It could impact performance on large systems quite a bit. Certainly during linking. -bw
Re: GCC 4.2.0 Status Report (2007-05-11)
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 not further hold up the release. That is not to say that I would not consider a patch to fix it, of course. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 base classes. Jason, are you actively investigating this one? 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? Please let me know the status of these soon. If we can't fix 'em, I'll just proceed with what we've got. Hi Mark, 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? -bw
Re: GCC 4.2.0 Status Report (2007-05-11)
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?
Re: GCC 4.2.0 Status Report (2007-05-11)
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 primary or secondary > platform. So there is no reason to wait with the release because of > this PR, according to the release criteria (xf. > http://gcc.gnu.org/gcc-4.2/criteria.html). I'm not particularly interested in it because of its RTEMS-ness. Rather, I'm interested in it because it's a new case of the compiler failing to correctly process valid code, not present in previous versions of GCC. The test case is not RTEMS-specific; it's a problem that looks like it could equally well apply to lots of other code out there making use of volatile storage. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
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 you waiting for this one? RTEMS is not a primary or secondary > platform. So there is no reason to wait with the release because of > this PR, according to the release criteria (xf. > http://gcc.gnu.org/gcc-4.2/criteria.html). As long as there are other blockers (e.g. 30252), I see no reason why RTEMS shouldn't have a chance to fix bootstrap. If there were no other blockers, then there would be an issue.
Re: GCC 4.2.0 Status Report (2007-05-11)
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 platform. So there is no reason to wait with the release because of this PR, according to the release criteria (xf. http://gcc.gnu.org/gcc-4.2/criteria.html). Gr. Steven
