Re: GCC 4.0.2 Released
Eric Botcazou wrote: >>I've decided not to do another release. I think it's too much effort >>for too little gain. The C++ and m68k patches are things that might >>just as easily not have been applied in the first place; we certainly >>wouldn't have considered either PR a showstopper. The Solaris problem >>is unfortunate, but I think not fatal. > > > Agreed. But I'm requesting a "caveat" note about the Solaris regression here: > http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2 > mentioning the workaround (g++ -pthreads) and the link: > http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html Roger that. I'll take care of it as soon as I can. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.2 Released
Mark Mitchell wrote: > 1. Move the ChangeLog entries on the 4.0 branch to accurately reflect > the released bits. > > 2. Modify Bugzilla to reset the target milestone for the three PRs in > question. > > 3. Modify gcc_release to prevent this situation in future. These steps have now been taken. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.2 Released
Eric Botcazou wrote: > Agreed. But I'm requesting a "caveat" note about the Solaris regression here: > http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2 > mentioning the workaround (g++ -pthreads) and the link: > http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html Done. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304 Index: gcc-4.0/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v retrieving revision 1.50 diff -c -5 -p -r1.50 changes.html *** gcc-4.0/changes.html29 Sep 2005 04:00:22 - 1.50 --- gcc-4.0/changes.html1 Oct 2005 08:58:24 - *** href="http://gcc.gnu.org/bugzilla/buglis *** 608,614 --- 608,624 of problem reports (PRs) from GCC's bug tracking system that are known to be fixed in the 4.0.2 release. This list might not be complete (that is, it is possible that some PRs that have been fixed are not listed here). + Unfortunately, due to a release engineering failure, this release + has a regression on Solaris that will affect some C++ programs. We + suggest that Solaris users apply a http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html";>patch + that corrects the problem. Users who do not wish to apply the patch + should explicitly link C++ programs with the -pthreads + option, even if they do not use threads. This problem has been + corrected in the current 4.0 branch sources and will not be present in + GCC 4.0.3. +
GCC 4.1 Status Report (2005-10-02)
The number of bugs targeted at GCC 4.1 has declined to 225 from 250 in my September 7th status report: http://gcc.gnu.org/ml/gcc/2005-09/msg00179.html The number of critical (wrong-code, ice-on-valid, rejects-valid) regressions has declined to 61 from 77. So, we're still fixing about one net regression per day, and about 2/3rd of the regressions we're fixing are critical. Of the 61 critical bugs, about half (31) are 4.1 regressions, i.e., do not occur with 4.0. 18 of the critical bugs are C++; the rest are primarily middle-end optimizer problems. Since we're checking in something like 5 patches a day to gcc/, and we're in bug-fix mode, we're either fixing a lot of bugs that aren't regressions, or we're introducing a lot of bugs when we check in patches, or people are finding new regressions at a rate that exceeds our ability to fix them. It's time for a quality push so that we can actually get to 4.1. Starting Friday, at midnight PDT, the mainline will go to the mode normally used for branches: fixes for regressions only, including code-generation regressions. We will stay in that mode until we hit our 100-regression target. Then, we'll re-open briefly to allow any queued-up critical non-regression bug-fixes. Then we'll branch. All of the usual suspects (Berlin, Bosscher, Henderson, Hubicka, Mitchell, Novillo, etc.) have bugs with our names on them. I think we can knock quite a few these down relatively easily. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Mainline now closed to all changes which do not fix regressions
As previously announced, here: http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html the mainline is now subject to the usual release-branch rules: only fixes for regressions. The goal is to quickly reduce the current 219 oustanding regressions against 4.1 to approximately 100 -- in part by me retargeting some of the bugs -- so that we can create the 4.1 release branch. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Mainline now closed to all changes which do not fix regressions
Steven Bosscher wrote: > On Monday 10 October 2005 19:35, Mark Mitchell wrote: > >>As previously announced, here: >> >>http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html >> >>the mainline is now subject to the usual release-branch rules: only >>fixes for regressions. > > > How does this affect gfortran, and what about already posted > but still unreviewed patches? I'm still willing to consider gfortran a special case. (After 4.1, that will probably no longer be true.) So, you can be more lenient with gfortran. Outstanding unreviewed patches may still be applied, after review. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Speed impact of virtual inheritance
Frans Englich wrote: > Hello all, > > In a large project I'm participating in, a design dilemma have arrived. > Adding > virtual inheritance would solve it beautifully on the source code level, but > a potential drawback is the speed penalty it brings. Measurement is always > the way of approaching performance questions, but since that sometimes can be > tricky, I thought of starting with getting a theoretical understanding of > virtual inheritance. In GCC, the performance cost is very slight. In constrast to older implementations (in GCC and other compilers), there is very little cost in terms of bytes per object for use virtual inheritance. (The only cost is that the most derived class must have a virtual table pointer; if the hierarchy has at least one virtual function, then there is no additional cost relative to that.) There is an increase in the size of the virtual table (of which there is one instance per class, not one instance per object) proportionate to the number of virtual base classes. The execution-time cost is two memory references required when casting to a virtual base class (as opposed to zero in the case of a cast to a non-vritual base class). Calling a virtual function will require a few additional instructions if virtual bases are involved; however, a function call is itself expensive, and virtual function calls typically cause i-cache misses, so the virtual-base part of the cost is quite small. There may be negative secondary optimization effects if the optimizers are no longer able to reason effectively about your code. My advice would be to use virtual bases in your class hierarchy where that seems attractive from a design point of view, but to avoid virtual function calls to small functions in performance critical loops, whether or not your hierarchy uses virtual bases. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Speed impact of virtual inheritance
Frans Englich wrote:
> Followup question: what is the increased cost of calling a non-virtual,
> inlined function('inline' keyword) on a virtual base?
None, if the function is inlined -- and whether it is inlined or not
should not be affected by whether or not it is in a virtual base.
> What makes me ask these questions, is that I have code which(according to my
> opinion) severely needs virtual inheritance(VI). The code VI would affect is
> not under my veto power, and the maintainers of that code have so far given
> as comment "VI is out of the question. Period," without giving a deeper
> motivation, except "performance."
There are a number of C++ features (templates are another) which, for
various reasons, including inferior initial implementations, have gotten
a bad reputation. Often, with current G++, using such features has
near-zero cost. However, sometimes people who had bad experiences, or
just incorrect perceptions, are very hard to persuade. I don't have a
secret formula for arguing against such objections; usually, I just try
to directly attack the problem by modifying the code in question, or
using similar test programs, to show that there is little or no cost.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: Speed impact of virtual inheritance
Frans Englich wrote:
> On Monday 10 October 2005 22:29, Mark Mitchell wrote:
>
>>Frans Englich wrote:
>>
>>>Followup question: what is the increased cost of calling a non-virtual,
>>>inlined function('inline' keyword) on a virtual base?
>>
>>None, if the function is inlined -- and whether it is inlined or not
>>should not be affected by whether or not it is in a virtual base.
>
>
> Ok, let me check my understanding of Joe's and your's reply, by an example:
>
> //--
> class Shared {
> public:
> //
> inline void ref() { m_ref++; }
> // ...
> protected:
> unsigned int m_ref;
> };
>
> class B : public virtual Shared {};
> class C : public virtual Shared {};
> class BC : public B, public C {};
> //--
>
> Running the expression "BCinstance->ref()" leads to the penalty that
> accessing
> the "m_ref" variable requires an indirection, if I've understood correctly.
Yes.
> What can safely be concluded from that? For example, could register
> allocation
> make it uncertain exactly how much the indirection costs?
Yes. (There are even scenarios where the indirection could actually
help, rather than hurt.) You'll just have to measure.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Support for init_priority in ARM EABI configurations
Paul, Richard -- The csl-arm-branch (and, probably, mainline) claim not to support the init_priority attribute for AAPCS targets. (I can't remember who did that; quite possibly me!) One of our customers has suggested that this is a mistake, and I tend to agree. I think the reason this isn't supported is that it's not portable, in the sense that EABI-compliant linkers need not support initialization priorities, and will probably (silently!) fail to run the prioritized code. However, on a fully-GNU system, it seems like a needless restriction. Therefore, I think we should allow the use of the attribute. Thoughts? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Regression status improving -- keep it up!
We're down from 219 4.1 regressions yesterday to 208 today. That's much better than the 1-per-day progress rate over the last few weeks! If we can sustain that rate, we'll be looking good pretty quickly. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: A couple more subversion notes
Diego Novillo wrote: > On Wednesday 19 October 2005 14:36, Daniel Berlin wrote: > > >>Well i guess i should aks the harsh question, which is, are these >>advantages enough for you guys, or should we just not move? >> > I vote 'move'. I've never used subversion -- this is the first time I know of that I've typed "svn". I hate upgrades. Their cost is always bigger than expected, even if you take that fact into account. (A variant of Hofstdater's law...) And, yet, I think we should move. We've discussed this extensively at CodeSourcery, and I think everyone is uniformly in favor. The superior branch facilities are a key benefit. You got us through the Bugzilla transition, and that's working well. Make it happen. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: A couple more subversion notes
Joseph S. Myers wrote: > I don't think keeping the CVS repository up to date after the move to > subversion is worthwhile I agree. I think that keeping CVS up-to-date is not a good use of resources; when we switch, we switch. If for some reason we have to switch back, we switch back. Let's not introduce last-minute feature creep. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: A couple more subversion notes
Joe Buck wrote: > Another possibility is to increase the frequency of snapshots after > the switch to subversion. They will have a lower cost, since it will > no longer be necessary to lock the database for an hour to attach the > snapshot tag. Or maybe no tag is necessary at all for snapshots, > if all we need to record is the global revision number. That would be my suggestion; just use revision number in lieu of the datestamp in the snapshot, and never mind the tag. The tag was just a way of imposing a global revision number on CVS. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Exception propagation problem on IA-64/Linux
Eric Botcazou wrote: >>The name here would seem to imply that we *are* mangling the type >>name: "typeinfo for foo()::S". Which begs the question of why you're >>seeing something different for ia64. > > > Both names are mangled identically (either on IA-32 or IA-64) because they > are > supposed to be local to the translation unit. Correct. This test case is valid, and the results observed are in incorrect; in other words, yes, there is a bug. In general, comparison of type_info objects is supposed to be done by checking for address equality of the type info strings. On systems without weak symbols, we use strcmp. (Look for __GXX_MERGED_TYPEINFO_NAMES in .) In the situation where we use strcmp, I would expect to see this bug. In the situation where we do not use strcmp, I would not expect to see that bug -- because I would expect that the type_info objects and the corresponding type_info strings are local symbols. If that is not the case, then that is the bug. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: resolving backslash newline whisky tango foxtrot: a proposal
Joe Buck wrote: > So the amended suggestion is to fix -Wcomment to shut up about continued > comments that don't matter, and also to add the new -f option to switch > the handling of spaces-at-the-end. I think your proposal, as amended, is the right approach. I generally don't much like new command-line options, but I agree that this is a situation in which both sides have valid points, there's legacy code around that depends on both behaviors, and having a switch makes sense. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.1 Status Report (2005-10-27)
We've made very good progress during the regression-only period on the mainline. From 219 regressions on the 10th, we're down to just 149 about two weeks later. Unfortunately, we made most of that progress in the first week to ten days; we've slowed down over the last week. There are still 44 regressions open that are on my critical list, i.e., that represent wrong-code, ice-on-valid, or rejects-valid regressions. I plan to make a pass over the 149 regressions over the weekend, postponing some. As I do that, I'm going to gather some better statistics about real priority -- how many are truly arcane, and how many look like real problems. The two key questions, of course are: 1. When will the mainline reopen for Stage 3 bug-fixes? 2. When will the mainline branch? I would still like to hit, or at least get closer to, the 100-regression target before we branch. I also recognize the need to move forward. I would hope that it's at most two weeks to drive down 49 regressions; that's just three a day. In any case, on November 11th, or when we hit 100 regressions, whichever comes first, we will reopen for bug fixes. Then, we will have one week for non-regression bug fixes. On November 18th, we'll branch. During the week for non-regression bug fixes, please remember that you're right up against the branch point, and that if you cause problems that cause me to delay the branch, people will be angry at both of us. :-) Also, please note that this means that it's time to get your 4.2 project proposals in, if you haven't already. As for 4.1, I'll be trying to make some suggestions about phasing those in during Stage 1 for 4.2. You'll be at the front of the queue if your patch has already been approved for 4.2 before we branch; please note that on your project pages. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Exception propagation problem on IA-64/Linux
Eric Botcazou wrote: > .hidden DW.ref._ZTIZ3foovE1S > .weak DW.ref._ZTIZ3foovE1S# > .section.gnu.linkonce.s.DW.ref._ZTIZ3foovE1S,"aws",@progbits > .align 8 > .type DW.ref._ZTIZ3foovE1S#, @object > .size DW.ref._ZTIZ3foovE1S#, 8 > DW.ref._ZTIZ3foovE1S: > data8 _ZTIZ3foovE1S# > > Found both in u.S and t.S and merged by the linker. Yes, that's wrong. I'd expect that to be a front-end bug, but if it doesn't happen on all platforms, then, maybe it's not? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Exception propagation problem on IA-64/Linux
Alexandre Oliva wrote: > If the strings turn out to be identical and the linker merges them, we > fail... The linker should not do that. These are not random string literals; these are the equivalent of the static char c[12] = "..." -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Exception propagation problem on IA-64/Linux
Eric Botcazou wrote: > Note that the type_info object itself (_ZTIZ3foovE1S) is local. What is not > local is the indirect reference to it through DW.ref._ZTIZ3foovE1S. So, > while the 2 DW.ref._ZTIZ3foovE1S symbols are advertised as being identical, > their contents would *not* be identical at link-time. I agree; that seems wrong to me. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Tag reorg
Daniel Berlin wrote: > Okay, well, consider this an official proposal to remove: > > 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk > into tree-ssa, *not* the other way around > 2. the ast-optimizer-branch merge tags > 3. structure-aliasing-branch merge tags. > 4. tree-cleanup-branch merge tags > 5. tree-profiling-branch merge tags > > (I'm much more concerned about cleaning up merge tags than branches, we > have 1588 things in the flat tags dir left :P) I'm not quite sure who can approve this, but I think probably I can. So, I'll approve it, conditional on no objections for 72 hours. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Tag reorg
Daniel Berlin wrote: > Diego already said it was okay, and since they were his tags, i did > it :) Well, then. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: New SVN repo is up
Joseph S. Myers wrote: > On Fri, 28 Oct 2005, Daniel Berlin wrote: > > >>contrib/ scripts have been updated in the new repository > > > I've merged the gcc_update change to 4.0 branch, 3.4 branch and > csl-arm-branch. In so doing, bug 20731 is fixed since the branch name is > no longer hardcoded. I have therefore also applied the following patch to > branching.html to remove mention of updating gcc_update. Swell! Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: New SVN repo is up
Daniel Berlin wrote: > [ Mark, my emails to gcc-announce are dropped on the floor, can you > forward this there? ] I've posted a slightly more user-centric announcement. I hope that's OK. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Use of Bugzilla fields
[Danny, see below for a request.] In my review of open PRs against the 4.1 branch, I'm going to adopt a new convention. Until now, when I've decided something is not important enough to require fixing for a particular release, I unset the target milestone. That's confusing because it might seem to mean that I'm saying the bug *can't* be fixed for a particular release, which isn't true. So, I'm going to adopt a new convention in these cases. In particular, I'm going to leave the target milestone alone, but set the priority field. P1 bugs will be bugs I think absolutely must be fixed before the next release; releasing with this bug would be diastrous. I'd like to use P2 to indicate that I've review the bug, and that it does not merit P1 status, but is important. So, Danny, is there any chance we could make it impossible for submitters to set this value and make P3 the default instead of P2? Severity is supposed to be "if this problem affects you, how bad is it?"; submitters can reasonably answer that. However, priority should be "in the grand scheme of things, how urgent is it that this shoudl be fixed?"; only we can decide that. P3 would then be the default, and would indicate that I've not yet reviewed the bug. P4 bugs will be ones I consider too unimportant to block the current release. P5 bugs will be ones I consider too unimportant to block *any* future release. I'm going to add links to the main web page to query for the regressions I think are important enough to block a release. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Use of Bugzilla fields
Joseph S. Myers wrote: > Does this mean regressions for languages and platforms other than those in > the release criteria should now have the milestone set, but be marked as > P4 or P5? Yes, as P5. But, I don't intend to try to go back and find those that are already unmarked, and "fix" the milestone. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Use of Bugzilla fields
Andrew Pinski wrote: >>[Danny, see below for a request.] >> >>In my review of open PRs against the 4.1 branch, I'm going to adopt a >>new convention. >> >>Until now, when I've decided something is not important enough to >>require fixing for a particular release, I unset the target milestone. >>That's confusing because it might seem to mean that I'm saying the bug >>*can't* be fixed for a particular release, which isn't true. > > > It might be better to add a flag for this istead of using the priority > field. I think it's an appropriate use of the priority field; the priority field is supposed to say how important the bug is, which is another way of saying how excited we should be about fixing it in an upcoming release. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Tag reorg
Mike Stump wrote: > On Oct 30, 2005, at 10:23 AM, Mark Mitchell wrote: > >> I'm not quite sure who can approve this, but I think probably I can. >> So, I'll approve it, conditional on no objections for 72 hours. > > > Would be nice to have a general well established policy that everyone > can follow, baring other reasons for not, and then branch owners can > render their verdicts. For the old apple merge tags, I'm inclined to > just rm them as well. My opinion is that tags on distributor branches should be under the control of distributors, just as distributors control the contents of the branch. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Use of Bugzilla fields
Ian Lance Taylor wrote: >>P5 bugs will be ones I consider too unimportant to block *any* future >>release. I'm going to add links to the main web page to query for the >>regressions I think are important enough to block a release. > > Could you or somebody please update the "Known regressions" bugzilla > search on the main gcc.gnu.org page to the search you are going to use > to count the number of regressions relevant for branching? That was supposed to be implied by the last sentence I wrote, which you quoted above. :-) I'll do it -- after I finish looking through the bugs, because I'm worried about confusing bugzilla's notion of my current query list. (Apparently, someone decided to go find all the bugs for which I'd previously removed the target milestone, and put the target milestones back. That's made it a little harder for me to plow through them all...) Sorry for the short-term confusion! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Regressions reviewed, main web page updated
I've made a pass through all of the open regressions for 4.1, assigning priorities as discussed previously. There are 112 regressions makred P3 or higher; the lower-priority PRs involving diagnostic nits, and such, have been downgraded to P4/P5. As per my last status report, if we can get to 100, we'll lift the regression-only rule on the mainline before the scheduled November 11th date. I've updated the main web page (patch attached) to have a "serious regressions" link, which is the P3-or-higher regressions for 4.1. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Analysis of optimization PRs
There are quite a few missed-optimization PRs on the serious-regression list: 25 to be exact. Clearly, performance is important; the justification for all of the tree-ssa infrastructure is better performance. The point is just to have more passes; it's to have better SPEC numbers, better CSiBe numbers, faster compilers, smaller kernels, etc. It's painful to give up hard-won gains. So, we need to take optimization regressions seriously. Now, that said, we all know that optimization is a game of heursitics, and that every release will regress on some test cases. We can add a new pass, which improves a set of benchmarks, but happens to pessimize some relatively rare case. Hey, it happens. But, we should investigate these PRs, and figure out what's going wrong, and why. If it's really the scenario above, then the audit trail should say something like: "The problem is that we're now splitting instructions earlier, which exposes more scheduling opprotunities, but combine is unable to combine four instructions, so we don't reassemble the original form. There's nothing practical that we can do about this without giving up the 3% SPEC improvement we got from the new splitters." The key elements are that you've (a) figured out what is different between this version and the one that worked better (the early splitting), (b) you've explained why this can't easily be fixed (combine's 3-insn limitation), and (c) you've justified not going backwards (the 3% SPEC improvement). Then, I can look at the PR, and just close it out. Or, you can. There's no need to feel embarassed that our compiler isn't able to solve NP-hard problems. But, without the anlaysis, we've got no way of knowing whether we've got a shot at fixing the regressions. "I want to say this is " or "This is just our register allocator being stupid" don't help. Do some real analysis; don't just guess. Show other people waht's wrong; if it's the register allocator being stupid, show the .lreg dump, and the .greg dump, and show how it dumped the register used in the inner loop, rather than the one in the outer loop. Imagine you had to write an essay that proved that you understood the problem. This isn't just for my sake when reviewing the PR list; it's for the sake of anyone who might want to fix the bug. Optimizer folks, please help with this -- your time might be as well spent analyzing some of these PRs as implementing additional stuff. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
-Wuninitialized issues
In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
All of these problems related to getting confused in the optimizers in
various ways; sometimes we think things are uninitialized when they
obviously aren't; other times we don't warn when we obviously should,
etc. The set of places we warn is moving around from 3.4 to 4.0 to 4.1,
which annoys people using -Werror, especially if we have new false
positives.
I'm not going to try to advance my own personal views on the best
solution; I've lost that argument enough times already. So, let's start
with the premise that we're doing this in the optimizers.
I still think we should take the goals of consistency across releases,
across architectures, and across optimization levels seriously. For
-Wuninitialized, we should err on the side of warning too often. If
possible, we should try to sketch the rules we're using so that users
understand them.
I think users who set this flag generally want warnings about variables
that look unitialized, but happen not be used, or happen to be
initialized only in tricky ways; they're often using these warnings to
make their code robust not just today, but in the face of future
modification. I'd expect that most users want a warning about:
int x;
if (f())
x = 3;
return x;
even if f() happens to always return true on this system. (I don't know
that we don't warn in this case; it's just meant as an example of a case
where doing too much optimization might cause us to miss a warning
people want.) Certainly, this code from PR 22456:
int i;
while (i) ++i;
should trigger a warning. The fact that i is then never used, and thus
the loop is removed, is a fine optimization, but that shouldn't affect
whether or not a warning is issued. Bugs like:
void f(int j) {
int i; // Should be initialized.
while (j) i += j--;
return j; // Should be i, not j.
}
are not that rare; the fact that this function can be optimized to
"return 0" should not preclude the warning!
Maybe it would help to move the checks closer to the front of the
optimizer chain. We'd have less accuracy, but, probably, more consistency.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: -Wuninitialized issues
Jeffrey A Law wrote: > On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote: > >>In reviewing the PR list, I saw several (maybe 5?) PRs about problems >>with -Wuninitialized. > Where I suspect we're falling down more often is not issuing warnings > because the uninitialized variable was optimized away or its uses were > turned into uses of other variables (possibly temporaries) due to copy > propagation. That may be an accurate assessment. >>modification. I'd expect that most users want a warning about: >> >> int x; >> if (f()) >>x = 3; >> return x; >> >>even if f() happens to always return true on this system. (I don't know >>that we don't warn in this case; it's just meant as an example of a case >>where doing too much optimization might cause us to miss a warning >>people want.) > > Certainly if we can't prove f always returns a nonzero value, then a > warning should be issued. If we do prove f always returns a nonzero > value, then I think it becomes unclear if we should generate a warning. I don't think it's unclear; I think it should be a warning. :-) The fact that f always returns a nonzero value may be a function of something about the current environment; I think people want this warning to tell them something about the code, semi-independent of the current environment. It may be that I've got different ideas about how this ought to work from some others in the community. Tools like valgrind/mudflap (and Purify, TestCenter, and CodeCenter before them...) exist to tell you about bugs that you definitely have. If there's a bug that doesn't happen to manifest in the test corpus you have, valgrind doesn't tell you. Often, that's exactly what you want -- don't tell me about the bugs I might have; tell me about the ones I do have on the inputs I care about. Tools like lint (including modern incarnations like the Stanford checker) exist to tell you about bugs you might have. For example: if this function returns an error code, then you'll exit this function without releasing the lock you grabbed here. Maybe that function never returns an error code, or you can magically reclaim the lock somewhere else; the purpose of the tool is to help you bulletproof against possible bugs. We have to figure out where this warning ought to lie on this continuum in order to figure how to implement it. I think most of our optimizer people think the right point on the continuum lies pretty close to the valgrind situation. In particular, the question they want to answer is "is there a code path through this function, when compiled on this architecture with these flags, etc., for which we might actually use an uninitialized value?" Using that question, if function f always returns non-zero, then we should not warn. Different levels of optimization give different levels of approximation to the abstractly right answer there; one would hope that as you crank up the optimization level, the answers get better, as you prove more things about the program. However, I think the right question is the more lint-like "Is there a code path through this function, when considered in isolation, and without being too clever, under which an uninitialized value is used?" Going back to the original example, if f always returns non-zero on all architectures, and always will, then why bother writing the conditional? The programmer who wrote that imagined that, at some point, f might return zero, and then the code would be buggy. I would consider that a "latent bug", and in my lint-like mindset, I want to fix it now. > The late pass could then also warn for those variables which were > marked by the first pass as maybe uninitialized, but which were > not marked by the second pass as maybe uninitialized -- these > are precisely those were optimizations either eliminated problem > paths through the CFG or DCE eliminated the uninitialized uses. Why doesn't that boil down to just warning about all the variables marked by the first pass, either right at the time of the first pass, or later during the second pass? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: -Wuninitialized issues
Jeffrey A Law wrote: > On Mon, 2005-10-31 at 17:11 -0800, Mark Mitchell wrote: > > >>>Certainly if we can't prove f always returns a nonzero value, then a >>>warning should be issued. If we do prove f always returns a nonzero >>>value, then I think it becomes unclear if we should generate a warning. >> >>I don't think it's unclear; I think it should be a warning. :-) The >>fact that f always returns a nonzero value may be a function of >>something about the current environment; I think people want this >>warning to tell them something about the code, semi-independent of the >>current environment. It may be that I've got different ideas about how >>this ought to work from some others in the community. > > We clearly disagree then. Though my 15+ years of working with GCC I've > seen far more complaints about false positives than missing instances > of this warning. OK, sure; we can agree to disagree. > I think the answer here is that there is no single answer that works > best for everyone. I hate to say that because I don't like the always > problematical "switch creep" in GCC, but I feel in this case giving the > user control over whether or not they want these additional warnings is > warranted. I think that's probably right. Ada already issues these kinds of warnings from the front-end, precisely to solve the kinds of user complaints I'm raising; if we're going to avoid doing that in other front-ends, we need to find some way to meet in the middle. A switch may be the least bad alternative, for all concerned. >>Why doesn't that boil down to just warning about all the variables >>marked by the first pass, either right at the time of the first pass, or >>later during the second pass? > > It boils down to being able to issue distinct warnings for the two > cases. There's a difference between noting that a variable might have > been used uninitialized and noting that a variable might have been > used uninitialized, but those problem uses were removed due to > optimizations or certain paths in the CFG were proven unexecutable. OK, now I get it. Yes, being able to distinguish these classes seems useful. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: -Wuninitialized issues
Ian Lance Taylor wrote: > Jeffrey A Law <[EMAIL PROTECTED]> writes: > > >>We clearly disagree then. Though my 15+ years of working with GCC I've >>seen far more complaints about false positives than missing instances >>of this warning. > > > I think that most of the false positives are of the form > > int x, f, y; > f = foo (); > if (f) > x = 1; > y = g (); > if (f) > y = x; > return y; > > Here presumably we can all agree that gcc ideally should not warn that > x may be used uninitialized. Indeed; I definitely agree that we shouldn't warn about this. The users have spoken definitively, if nothing else. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: -Wuninitialized issues
Diego Novillo wrote: > We won't get perfect answers, which is fine given the nature of the > problem. However, I would like, to get *consistent* answers. Yes, I agree that's very important. In fact, I'd like to generalize that to say that -- as much as possible -- the same code should generate the same warnings across architectures, optimization levels, and releases as well. If -O3 causes us to say "might have been uninitialized, but we removed it" while -O0 just says "uninitialized" that's probably OK. But, having warnings not appear at -O0, or go away completely with higher levels of optimization isn't good. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] c++ template instantiation generates zero-sized array (pr 19989)
Josh Conner wrote:
> I've been investigating PR 19989, where we are rejecting code when a
> template instantiation generates a zero-sized array, such as:
>
> template struct A
> {
> static const int i = 0;
> }
>
> template struct B
> {
> int x[A::i];
> };
>
> B<0> b;
>
> This is rejected on the grounds that not failing could generate an
> incorrect match in other instances
I understand what you're after: tolerate uses of the extension where
it's sufficiently harmless.
I don't think your proposed solution is correct, though, because we want
to maintain the invariant that all conforming programs compile and
behave as required by the standard in all compilation modes. In other
words, supplying -fpermissive and friends can make non-conforming
programs compile, when they otherwise wouldn't, but conforming programs
should behave identically in all modes.
I would imagine that if we encounter a zero-sized array when the
"complain" flag is tf_error, then we can just issue a conditional
pedwarn, with "if (pedantic) pedwarn (...)". But, if tf_error is not
set, we must reject the instantiation.
I know that sounds backwards. The point is that when tf_error is set,
we're committed to the instantiation. When tf_error is not set, SFINAE
applies. And, in a conforming program, we must reject the instantiation
in that case.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: [RFC] c++ template instantiation generates zero-sized array (pr 19989)
Josh Conner wrote: > I think this is consistent with my proposal -- the first example was > non-conforming, but accepted without -pedantic (as we do with other > zero-sized arrays). The second example was conforming and the only way > to alter its behavior was with the -fpermissive option. My point was that conforming programs should compile and behave identically in all modes; therefore -fpermissive must not alter the behavior. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: -Wuninitialized issues
Jeffrey A Law wrote:
> Again, the problem I have with the notion that we want to get
> consistent answers is that doing so, is going to give us a lot of
> false positives. That IMHO is a huge step backwards if that's how
> we make -Wuninitialized work.
You're right that it's the users that matter, and bug reports give us
some visibility into what annoyed people.
The false-positive case I remember seeing most often was the:
if (b) {
x = 1;
}
...
if (b) {
use(x);
}
I don't remember very many people complaining about other tricky cases;
I certainly don't remember anyone complaining about:
if (f())
x = 1;
use(x);
warning when f could be proven to return a non-zero value.
However, I'll freely admit this is just my notoriously fallible memory
at work here; I've not reviewed the PRs.
In any case, it does seem like you're moving in a direction that would
give us a mode where warnings would perhaps oscillate between your two
classes, but not come and go completely. I think that's pretty good.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: -Wuninitialized issues
Diego Novillo wrote: > Agreed 100%. My vote is to use your proposal for -Wuninitialized and have, > as you said, another flag that does the analysis immediately after going > into SSA, before any transformations are done. It certainly doesn't bother me to have -Wuninitialized continue to mean what it does, and have some other flag that means something else. Or, even -Wuninitialized=2, or something. I think it's fine to have modes here, and I agree that there are (clearly!) constituencies that want both the lint-like mode and the valgrind-like mode. Jeff, I'm sorry you're upset; I actually think we're closer to consensus than we've ever been before on this issue. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: -Wuninitialized issues
Jeffrey A Law wrote:
> For example, if the only use was inside an unreachable hunk of
> code, does that count as a use or not?
Yes, the EDG front-end does this:
[EMAIL PROTECTED]:~/tmp$ cat test.cpp
void f() {
int i;
if (0)
i = 3;
}
[EMAIL PROTECTED]:~/tmp$ eccp -A test.cpp
"test.cpp", line 2: warning: variable "i" was set but never used
int i;
^
(The "SGI Compiler" used to be EDG-based, on IRIX. I don't know whether
Kaveh's referring to that version or to the Open64 version, based on the
GCC front ends.)
(Wouldn't it be easy to emit a warning for this in GCC, in the same
optimization-based way we do uninitialized warnings? If there are no
paths from the block with the assignment to a use, then the store is
useless.)
I don't think EDG even builds a CFG. I think they just use some
relatively conservative algorithms to produce these sorts of warnings.
For this:
int i;
l:
j = i; // j is global
if (0)
i = 3;
goto l;
they don't warn on the unintialized use of "i"; they probably treat i as
maybe-initialized before reaching j.
So, just as you would expect, they are more consistent across the
various parameters we've discussed, but less accurate.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Patch reviews for 4.1
This rather horrid URL: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=patch&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= will get you the list of 4.1 PRs with the "patch" keyword set. Fixing these PRs may just require than an appropriate person review the patches. Per, there's one preprocessor patch below; would you please take a look? The rest are middle-end patches. Preprocessor 22042 Middle-End -- 23109 23948 24365 24483 24589 23155 24408 As per http://gcc.gnu.org/ml/gcc/2005-10/msg01083.html, if we can get the list of serious regressions under 100 -- and it's just 104 right now! -- I'll reopen the mainline for general bug fixes until November 18th, when we'll create the branch. (If you think there's some PR so serious that we shouldn't even create the branch until its fixed, let me know; I think that to qualify, a PR would have to have no fix other than major surgery on the compiler.) Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC mainline now open for bug fixes under normal Stage 3 rules
There are now 99 serious regressions against GCC 4.1. >From now until November 18th, the GCC mainline will be open for bug fixes under the usual Stage 3 rules, rather than the more restrictive rules we've been operating under recently. On November 18th, I plan to make the branch and open Stage 1 for GCC 4.2. Please exercise due care during this time. While we're allowing bug-fixes, the primary goal is still to prepare for the 4.1 release. So, if you're fixing bugs that aren't regressions, please be very careful not to be introducing new bugs in the process. I will consider asking for patches to be reverted if they prove disruptive. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Call for compiler help/advice: atomic builtins for v3
Paolo Carlini wrote: > Hi, > > we have this long standing issue which really we should solve, one way > or another: otherwise there are both correctness and performance issues > which we cannot fix, new features which we cannot implement. I have > plenty of examples, just ask, in case, if you want more details and > motivations. I think this is a somewhat difficult problem because of the tension between performance and functionality. In particular, as you say, the code sequence you want to use varies by CPU. I don't think I have good answers; this email is just me musing out loud. You probably don't want to inline the assembly code equivalent of: if (cpu == i386) ... else if (cpu == i486) ... else if (cpu == i586) ... ... On the other hand, if you inline, say, the i486 variant, and then run on a i686, you may not get very good performance. So, the important thing is to weigh the cost of a function call plus run-time conditionals (when using a libgcc routine that would contain support for all the CPUs) against the benefit of getting the fastest code sequences on the current processors. And in a workstation distribution you may be concerned about supporting multiple CPUs; if you're building for a specific hardware board, then you only care about the CPU actually on that board. What do you propose that the libgcc routine do for a CPU that cannot support the builtin at all? Just do a trivial implementation that is safe only for a single-CPU, single-threaded system? I think that to satisfy everyone, you may need a configure option to decide between inlining support for a particular processor (for maximum performance when you know the target performance) and making a library call (when you don't). -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Call for compiler help/advice: atomic builtins for v3
Paolo Carlini wrote: > Actually, the situation is not as bad, as far as I can see: the worst > case is i386 vs i486+, and Old-Sparc vs New-Sparc. More generally, a > targer either cannot implement the builtin at all (a trivial fall back > using locks or no MT support at all) or can in no more than 1 > non-trivial way. Are you saying that you don't expect there to ever be an architecture that might have three or more ways of doing locking? That seems rather optimistic to me. I think we ought to plan for needing as many versions as we have CPUs, roughly speaking. As for the specific IA32 case, I think you're suggesting that we ought to inline the sequence if (at least) -march=i486 is passed. If we currently use the same sequences for all i486 and higher processors, then that's a fine idea; there's not much point in making a library call to a function that will just do that one sequence, with the only benefit being that someone might later be able to replace that function if some as-of-yet uknown IA32 processor needs a different sequence. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Call for compiler help/advice: atomic builtins for v3
Paolo Carlini wrote: > Yes, in principle you are right, but in that case we can reorder the > ifs: first i686, last i386 ;) Seriously earlier today I was hoping we > can have something smarter than a series of conditionals at the level of > libgcc, I don't know it much. I was hoping we can manage to install a > version of it "knowing the target", so to speak. Yes, GLIBC does that kind of thing, and we could do. In the simplest form, we could have startup code that checks the CPU, and sets up a table of function pointers that application code could use. In principle, at least, this would be useful for other things, too; we might want different versions of integer division routines for ARM, or maybe, even, use real FP instructions in our software floating-point routines, if we happened to be on a hardware floating-point processor. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Call for compiler help/advice: atomic builtins for v3
Richard Henderson wrote: > I believe some poor design decisions were made for p4 here. But even > on a platform without such problems you can expect a factor of 30 > difference. So, that suggests that inlining these operations probably isn't very profitable. In that case, it seems like we could put these routines into libgcc, and just have libstdc++ call them. And, that if __exchange_and_add is showing up on the top of the profile, the fix probably isn't inlining -- it's to work out a way to make less use of atomic operations. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Call for compiler help/advice: atomic builtins for v3
Ulrich Drepper wrote: > Mark Mitchell wrote: > >>Yes, GLIBC does that kind of thing, and we could do. In the simplest >>form, we could have startup code that checks the CPU, and sets up a >>table of function pointers that application code could use. > > > That's not what glibc does and it is a horrible idea. The indirect > jumps are costly, very much so. The longer the pipeline the worse. I didn't mean to imply that GLIBC uses the simplistic solution I suggested, and, certainly, dynamic linking is going to be better on ssytems that support it. The simplistic solution was meant to be illustrative, and might be appropriate for use on systems without dynamic linking, like bare-metal embedded configurations, where, however, the exact CPU isn't know at link-time. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] What should be the semantics of a zero-bit bit-field with pragma pack?
Steven Bosscher wrote: > Of course, the semantics of "int : 0" are not defined by C99 for packed > structs. As far as I can tell, extend.texi doesn't discuss this case, > so we need to come up with something that makes sense. The semantics of zero-width bitfields (outside of packed structures) are part of the ABI for each system. They very somewhat from system-to-system, but, in general, they are interpreted as alignment directives. > We discussed this briefly on IRC. We have only two options AFAICT: > 1) ignore the ": 0" field completely. This is what we seem to do >since Jason's patch was commited. > 2) when we see :0 align to the next unit, which seems to be the >behavior of GCC pre-3.4. > > Jason suggested that it looks like they want it to mean "align the > next field despite pragma pack". So that is option (2), Yes, I think we should do option (2). There's otherwise no point at all in putting a zero-width bitfield into a packed structure; it seems better to assume the user had a purpose in having the zero-width bitfield. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: PR24138 and flexible arrays in C++
Aldy Hernandez wrote:
> Hi folks.
>
> The code below is ICE-ing in C++:
>
> typedef struct {
> unsigned char dir;
> int data[];
> } AiDefaultRailBlock;
> static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
>
> According to our docs, this is valid under flexible arrays:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Zero-Length.html#Zero-Length
>
> Mark has a note on the PR that says C++ does not support flexible arrays,
> but our documentation seems to imply we do.
What I actually said is that I'm not sure we ought to support this in
C++. I agree that there's nothing in the manual at the moment that
suggests that we don't support it. I don't really think anybody has
thought hard about this issue or consciously triedto implement it in G++.
Ideally, I think we would support it; I'm just not sure exactly what
restrictions, if any, should apply to the flexible array data member.
For example, perhaps the type of the elements should be one that does
not require construction. Perhaps that's OK; I'm just not sure.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: non-ambiguous typedefs
Gabriel Dos Reis wrote: > Plain compiler bug. I'm not aware of any existing report to that > effect, though GCC/g++ currently is completely confused when it sees > apparently ambiguous declarations, and would report non-existent > declaration. That needs fixing. I have a patch-in-progress for the fact that ambiguous declarations are reported as non-existant. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] PR C++/24138
Aldy Hernandez wrote: > (Frustratingly, max_index above yields false on integer_all_onesp(), but > we can tackle that once we can agree what to do here.) > > Is it ok to special case max_index being -1? Definitely. This problem appears in various places; we represent array bounds using a number of the same precision as the set of valid indices, so edge-case representations require a little special handling. (Of course, that whole function is busted if we get an array of a size that can't be represented in a HOST_WIDE_INT, but that's not your problem...) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Link-time optimzation
The GCC community has talked about link-time optimization for some time. In addition to results with other compilers, Geoff Keating's work on inter-module optimization has demonstrated the potential for improved code-generation from applying optimizations across translation units. Some of us (Dan Berlin, David Edelsohn, Steve Ellcey, Shin-Ming Liu, Tony Linthicum, Mike Meissner, Kenny Zadeck, and myself) have developed a high-level proposal for doing link-time optimization in GCC. At this point, this is just a design sketch. We look forward to jointly developing this with the GCC community when the design stabilizes. Our goal has been to develop a proposal that was sufficiently mature that it would serve as a plausible approach for consideration -- but we fully expect comments from the community to shape and change what we've written, perhaps in quite significant ways. Certainly, readers will find many details that are unresolved; we are not claiming that this is a final, formal specification. We would prefer not to have this thread devolve into a discussion about legal and "political" issues relating to reading and writing GCC's internal representation. I've said publicly for a couple of years that GCC would need to have this ability, and, more constructively, David Edelsohn has talked with the FSF (both RMS and Eben Moglen) about it. The FSF has indicated that GCC now can explore adding this feature, although there are still some legal details to resolve. Therefore, we have taken it as our mission to focus purely on technical considerations -- and that's what this discussion should be about. When we have a technical plan we like, then, before we implement it, we will get approval from the SC and the FSF -- but, first, lets develop the technical plan. The document is on the web here: http://gcc.gnu.org/projects/lto/lto.pdf The LaTeX sources are in htdocs/projects/lto/*.tex. Thoughts? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Link-time optimzation
Richard Henderson wrote: In general, I'm going to just collect comments in a folder for a while, and then try to reply once the dust has settled a bit. I'm interested in seeing where things go, and my primary interest is in getting *some* consensus, independent of a particular one. But, I'll try to answer this: > In Requirement 4, you say that the function F from input files a.o and > b.o should still be named F in the output file. Why is this requirement > more than simply having the debug information reflect that both names > were originally F? I see you go to some length in section 3 to ensure > actual symbol table duplicates, and I don't know why. Our understanding was that the debugger actually uses the symbol table, in addition to the debugging information, in some cases. (This must be true when not running with -g, but I thought it was true in other cases as well.) It might be true for other tools, too. It's true that, from a correctness or code-generation point of view, it shouldn't matter, so, for non-GNU assemblers, we could fall back to F.0/F.1, etc. > The rest of the requirements look good. I cannot immediately think of > anything you've forgotten. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Register Allocation
Andrew MacLeod wrote: > It must be the season for this sort of thing :-) I have not yet read the entire document, but I would very much like to applaud both the goal of improving register allocation, and the spirit in which you've approached it: in particular, posting a design and getting comments before starting implementation. I'm glad to see that strategy taking hold as a general approach for major development initiatives. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] PR/24900: computed but not used cast values
Richard Henderson wrote: > On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote: > >>Well, as I mentioned in the PR, macro writers can wrap the whole thing >>in a statement expression and avoid the warning. Can't we suggest this >>and keep (almost) everybody happy? > > I think so. FWIW, I agree with all of RTH's comments in this thread. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: pruning unused debugging types (enums/PR23336)
Richard Henderson wrote: > A solution that comes to mind is to have the front-end add dummy > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had > no DECL_NAME, it'd be easy for us to notice that we shouldn't > actually emit debug info for the TYPE_DECL itself, but that we > should consider its TREE_TYPE to be used. > > I'm open to better schemes. Perhaps a used-type hash table in > the struct function. I like the idea, but I think a hash table would be better. In fact, I think the best choice would be a hash table during compilation of the function, transformed into a vector after the closing brace of the function, so that we do not have the wasted memory associated with either dummy TYPE_DECLs or hash table entries. Also, we should do this only for the kinds of types we tend to lose (maybe casts and enums?), to keep the extra memory cost to a minimum. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.1/4.2 Status Report (2005-11-18)
The number of open serious regressions against 4.1 is a respectable 87, quite a few of which are P3s, waiting for me to categorize them. We still have some work to do before the release, but we will branch on 2005-11-18, as previously announced, at some point late Friday evening. Thank you for being patient through the long Stage 3. I am still reviewing the 4.2 projects, but I will post some ideas about staging those in before I create the branch tomorrow. There looks to be some exciting stuff in the pipeline! I would like to better understand the status of GOMP; is it going to be ready for 4.2 within a couple of months? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.1/4.2 Status Report (2005-11-18)
Diego Novillo wrote: > On Friday 18 November 2005 03:48, Mark Mitchell wrote: > > >>I would like to better understand the status of GOMP; is it going to be >>ready for 4.2 within a couple of months? >> > Most definitely. We have been essentially waiting for 4.1 to branch. > There are 5 modules to merge: library, C, C++, Fortran, middle-end. > The FEs can be merged in more or less independently from library and > middle-end. Great news. (The GOMP entry on the projects list was just a link to the project page; it didn't have this data.) It seems like it makes sense to do the library and middle-end first, and then the various front-ends in serial? Do you agree? I'd like to have a look at the C++ bits before they go in, but I'll not be looking to make life difficult. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.1/4.2 Status Report (2005-11-18)
Diego Novillo wrote: > Yes. The mental model is something like this: Makes sense. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: pruning unused debugging types (enums/PR23336)
Aldy Hernandez wrote: > Either way is fine by me. Just to make sure I understand things; > you want me to hack the front-end to fill the hash table every time > it parses a cast or enum type? Yes. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.1 branch created
I have created the GCC 4.1 branch, so any future commits for bug-fixes destined for 4.1 should go on the branch as well as on the mainline. I am still working through the remainder of the branch checklist. Please treat the mainline as if it were still in 4.1 Stage 3 until I have a chance to complete the checklist and send out information about 4.2 Stage 1; that will happen within the next thirty minutes. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.1 branch created
Mark Mitchell wrote: > I am still working through the remainder of the branch checklist. I believe that I have now completed the checklist, with the exception of: # Generate the next mainline snapshot manually, using the -p option of the gcc_release script. For that single run, adjust the script such that the announcement mail is sent to you personally so that you can adjust references to the previous snapshot in the README and index.html files of the new snapshot as well as the mail itself before relaying it. # Regenerate gcc.pot and cpplib.pot. Send them to the translation project. Joseph, would you be willing to help me with those two items? I don't know how do to the first, and you seem more facile than I with the .pot files. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.2
I've reviewed the GCC 4.2 projects on the Wiki. It certainly looks like some exciting stuff is in the pipeline. For 4.2, I'm not going to try to be too fine-grained about scheduling the individual projects; in 4.1, I don't think I added much value by doing that. Also, a lot of the project pages didn't have very precise data about availability. So, all I did here is separate them into Stage 1 and Stage 2 contributions. Even then, I don't want to forbid things listed under Stage 2 from going in under Stage 1, if the Stage 2 things are ready, but let's give priority to the Stage 1 things. I put things into Stage 1 that seemed either (a) most risky or (b) most ready. I'll readily concede that I may have miscategorized, and it's OK with me if people just treat the categorization as an informal guideline. Rather than try to make a fine-grained schedule, I'd like to ask that we just try to cooperate with each other to avoid destabilizing the mainline unduly, even through Stage 1. In particular: * Please announce major merges of new functionality 24 hours before the actual merge * Please allow 24 hours after a major merge before the next major merge * Please refrain from a major merge if we're currently experiencing serious stability problems that are being resolved from the previous merge. As of now, we're in GCC 4.2 Stage 1! == Stage 1 Projects * Decimal Floating Point * GOMP: library, middle-end, C * IPA cleanups * Load partial redundancy elimination * New tree reassociation pass * Remove old loop optimizer * Section Anchor Optimisations * Sign Extension Removal * Support for IA-64 speculation * Vectorization Enhancements, Part 1 Stage 2 Projects * Array references on pointers * GOMP: C++, Fortran * Induction variable optimizations cleanups * IPA on SSA Form * Omega data dependence test * Record GCC command line switches in object files * Replacements for CSE path following * Replace backend dataflow * Response files * Sub-Target specific math routines library * Vectorization Enhancements, Parts 2 and onwards. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.2
Gabor Loki wrote: > Mark Mitchell wrote: > >> I've reviewed the GCC 4.2 projects on the Wiki. >> >> It certainly looks like some exciting stuff is in the pipeline. > > > I hope it is not too late to merge the Code Factoring Optimizations branch > in GCC 4.2. It is not too late to merge it, provided that it gets a suitable review. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: trees
Gabriel Dos Reis wrote: > Hi, > > What kind of things did you want to put in doc/c-tree.texi under the > section "Trees" when you wrote > > @c- > @c Trees > @c- > > @node Macros and Functions > @subsection Trees > @cindex tree > > This section is not here yet. I have no idea If I wrote that (I'm not disbelieving, I just don't remember), it was many years ago. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] fixproto and canadian cross builds
Paul Brook wrote: > This suggests two options on what's supposed to happen: > (a) fix-header should actually be compiled for the "host" environment. If > host==build we run it, otherwise we just install it and let the user run it > on the build system. I think this is the right option, though, probably, we should be using a build->target fixproto, rather than doing nothing. (Just like we run the build->target compiler to build libgcc.) In any case, I'd imagine that whatever do for fixincludes also applies to these programs; it seems like it should be built and run in the same way. For Canadian crosses, we have: if test "x$TARGET_SYSTEM_ROOT" = x; then if test "x$STMP_FIXPROTO" != x; then STMP_FIXPROTO=stmp-install-fixproto fi fi I'm not sure what the TARGET_SYSTEM_ROOT check is doing there; I'd think that ought to be unconditional, given the current Makefile. > (c) fixproto is only for crufty old systems no-one really cares about. It > should be disabled by default, and documented to not work for canadian > crosses. Hmm. A lot of the *-elf targets have use_fixproto=yes in config.gcc, which somewhat surpises me; I'd have thought newlib didn't require that. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] fixproto and canadian cross builds
Ian Lance Taylor wrote: > So the question is why, before his change, those *-elf targets didn't > have an explicit fixproto=no, and I'm sure the answer is simply > laziness and/or lack of knowledge. fixproto is more or less a no-op > when run on modern header files, so it's not like anybody would notice > anything even in cases where it did run. That's comforting. I'd rather hoped that newlib wouldn't require fixing... So, Paul, perhaps the short answer is "turn it off for 68k and check that it doesn't seem too broken." -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis wrote: > Hi, > > In the C++ front end, default arguments are recorded in > FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are > the reasons for that? There used to be an extension that allowed default arguments on function pointer types. We agreed to kill it, although I don't know if it was actually removed. If that's been done, there's no longer any reason. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: overcoming info build failures
Ben Elliston wrote: > I tracked this build problem of mine down. I expect others will > experience it, too, hence this posting. If you're building from > clean, you won't have this problem. Sorry about that! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis wrote: > Assuming the extension was gone, do you see a reason we not move the > default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use > TREE_VEC instead of TREE_LIST to hold the parameter-type list? Both things sound OK to me. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC-3.4.5 Release Status
Gabriel Dos Reis wrote: > Mark, RTH, could you provide hints? I don't have any ideas, just from looking atthe problem. It could be a stack allocation problem, where we assign two things the same stack slot, and get confused. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Performance regression testing?
We're collectively putting a lot of energy into performance improvements in GCC. Sometimes, a performance gain from one patch gets undone by another patch -- which is itself often doing something else beneficial. People have mentioned to me that we require people to run regression tests for correctness, but that we don't really have anything equivalent for performance. Clearly, performance testing is harder than correctness testing; correctness is binary, while performance is a continuum. Machine load affects performance numbers. It's reasonable to strive for no correctness regressions, but introducing new optimizations is often (always?) going to cause some code to perform worse. If an optimization was unsafe, then correctness concerns may require that we generate inferior code. So, it's hard problem. The basic question I'm asking myself is: "Is there some pre check-in testing we could do that would help make sure we're not backsliding?" My goal is to make us aware of performance, without imposing anything too burdensome. As a strawman, perhaps we could add a small integer program (bzip?) and a small floating-point program to the testsuite, and have DejaGNU print out the number of iterations of each that run in 10 seconds. The results would show up on gcc-testresults automatically, and if we were really eager, we could post the results along with our testing. We wouldn't have to treat inferior numbers as regressions in the same way that we treat ordinary test failures, but maybe something like this would help us to keep our eye on the ball. Again, that's a strawman. I'm just looking for suggestions about what we might to do -- or even feedback that there's no need to do anything. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Performance regression testing?
Joe Buck wrote: > It would be possible to detect performance regression after fact, but > soon enough to look at reverting patches. For example, given multiple > machines doing SPEC benchmark runs every night, the alarm could be raised > if a significant performance regression is detected. Right; I think we do some of that at present. I was hoping that having it there when people did test runs would change the psychology; instead of having already checked in a patch, which we're then looking to revert, we'd be making ourselves aware of performance impact before check-in, even for patches that we don't expect to have performance impact. (For major new optimizations, we already expect people to do some benchmarking.) But, yes, this is a definite alternative: we could further automate the SPEC testers, or try to set up more of them. >>As a strawman, perhaps we could add a small integer program (bzip?) and >>a small floating-point program to the testsuite, and have DejaGNU print >>out the number of iterations of each that run in 10 seconds. > > Would that really catch much? I really don't know. That's why it's a strawman. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Torbjorn's ieeelib.c
Back in 1999, Torbjorn Granlund posted: http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html That message contains an IEEE floating-point emulation library, like fp-bit.c. Howeve, the performance is considerably better; Joseph measured against fp-bit.c with a modern compiler, and ieeelib.c is about 10-15% better than the current code on EEMBC on a PowerPC 440. So, we're considering doing what it takes to get ieeelib.c into GCC, or, perhaps, borrowing some of its ideas for fp-bit.c. In his original message, Torbjorn indicated that Swox AB (the company of which he is CEO) donated the code, and the old copyright file had an entry for Torbjorn, though not Swox AB. I've contacted Torbjorn, and he'd still like to see ieeelib.c in GCC. Is there any copyright issue that would prevent inclusion of this code? Assuming all the technical bits were in order, would we need to get the FSF involved in any way before including the code? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
Joe Buck wrote: > Well, the problem is that you're raising a legal technicality, and legal > technicalities are up to the FSF. Maybe they'll have no problem, > especially if Swox AB basically is Torbjorn. If there is a problem, and > Torbjorn is still CEO of Swox AB, it should be no problem (other than the > delay) to do new paperwork, and maybe RMS would be OK with it going in > now as long as we're sure that everything will be done by release time. > > But I do think we have to ask. Shucks. Should I ask [EMAIL PROTECTED] or RMS directly or ...? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
David Edelsohn wrote: > Swox AB does have a copyright assignment on file, so GCC is free > to use ieeelib.c. Great. Thanks for double-checking! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
Richard Henderson wrote: > I'd been hoping that someone would move libgcc to toplevel, and > perhaps rearrange fp emulation after that. I'd really like to see libgcc move too; is anyone actively working on that? (We're not...) So, I'm afraid we're going to end up going in the other order, unless someone steps up to do the libgcc move shortly. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
Anthony Green wrote: > I did some benchmarking a year or two ago with Torbjorn's library and > found good results as well. However, there was pushback on merging this > in from the GCC hackers I spoke with because they saw glibc's FP > emulation library as an even better solution, and implied there was some > effort underway to move glibc's code into libgcc (perhaps there were > licensing issues to resolve - I forget the details). RTH is listed as the author of a lot of those bits, so perhaps he knows more? The GLIBC bits claim to be LGPL'd, so that would indeed need a change to include them in libgcc. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: incomplete type return types
Gabriel Dos Reis wrote: > The resason here is that, after we complained that A is incomplete > (therefore cannot be used as return type in the function definition), > cp/decl.c:check_function_type() changes the return type to void, thus > giving misleading diagnostic later. That's the bug. It should change the return type to error_mark_node, and then the code that check returns should be silent in that case. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
Richard Henderson wrote: > The glibc bits handle ieee quad format, whereas I don't believe > that Torbajorn's does. I don't recall if Torbajorn's code allows > for emulation of all rounding modes or exception bits. I believe it does not. > But I suspect that Torbajorn's code compiles down smaller, which > is likely to be helpful to the folk that actually need it. I think both size and speed are important, but, yes, size is an issue. I would certainly expect that many embedded users would want to be able to disable rounding-mode and/or exception support to save code size, although there are probably also users that would make use of support for these features. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: pr14516 and GCC 3.4
Gunther Nikl wrote: > Hello! > > This PR is about missing USER_LABEL_PREFIX for static variables. The issue > was fixed for 4.0, but for 3.4 there won't be a fix as stated in the audit > trail by Mark Mitchell in comment #15. He probably based his decision on > comment #14, where Geoff Keating states that this bug does only affect > debugging programs that don't have full debugging info. That conclusion is > wrong, the bug has a much more severe impact! Yes, it's true that this is why I thought it was not important enough to fix in GCC 3.4.x. However, I am no longer managing releases from the 3.4.x branch, so it's up to Gaby to decide if he wants to reopen the issue. (I've cc'd Gaby on this message.) Geoff's patch in Comment #11 is clearly too big to backport to 3.4. Both Geoff and Ian are very knowledgeable, and I don't have personally have any opinion about whether or not the patch in comment #7 is correct or not, so I don't think I can say anything useful about whether or not that patch might be a good starting point. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
Aldy Hernandez wrote: > There was a thread discussing all this, when I was interested in doing > the work. I mailed rms directly, and he said it was ok to use the > glibc bits in gcc regardless of the LGPL/GPL disparity. Do you happen to have a pointer, or a copy of that message? If that route ends up making the most sense, then it would be nice to have our ducks in a row. As for the 16-bit issue, I don't think that's necessarily an all-or-nothing switch; the most likely route of progress would be to add ieeelib.c/glibc soft-fp and then gradually migrate targets that wanted to migrate. Joseph is comparing the two alternatives with fp-bit.c, and I'd expect he'll have an opinion about which is best. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
Aldy Hernandez wrote: > Argh... I've grepped all over my harddrive, but can't find it. But > I *am* sure I sent a mail to rms explaining the whole thing, and he > responded positively. Perhaps he can remember the conversation? Thanks for looking. I can ask him, if that route looks best. At this point, we have convincing ieeelib.c numbers, but I don't think we have GLIBC soft-fp data yet. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [C++] cp_token::type and cp_token::keyword
Gabriel Dos Reis wrote:
> In cp/parser.c:cp_parser_declaration(), we have the following code
>
> /* Try to figure out what kind of declaration is present. */
> token1 = *cp_lexer_peek_token (parser->lexer);
>
> if (token1.type != CPP_EOF)
> token2 = *cp_lexer_peek_nth_token (parser->lexer, 2);
> else
> token2.type = token2.keyword = RID_MAX;
>
> It looks to me like the last line is a typo for
>
> {
> token2.type = CPP_EOF;
> token2.keyword = RID_MAX;
> }
Yes. The obvious patch is pre-approved.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
LTO, LLVM, etc.
y a faster path to link-time optimization, since it already works, and that it doesn't in any way prevent us from adding the source-level integration later. The fact that the LTO proposal "hopes" to perform link-time optimization, whereas LLVM always works, is not an intrinsic aspect of the LTO proposal. In particular, the reason the LTO proposal permits the optimizer to bail out was to provide more type-based aliasing information at link-time by making it possible to distinguish more types. By using a structural type equivalence (and therefore weakening slightly the assumptions that could be made about aliasing), the LTO proposal could be made to always work as well. So, I don't think that's an intrinsic design issue. I have no idea whether the different in aliasing resolution would make any measurable difference on real code. In addition to already working, LLVM clearly has significant advantages as well, including better memory usage. Nothing based on trees is likely to eliminate the memory gap. Clearly, LLVM's IR is better documented (and simpler) that Tree. If we do switch to LLVM, it's not going to happen before at least 4.3, and, if I had to guess, not before 4.4. We learned with Tree-SSA that replacing our optimizers takes a while to shake out, and I'd imagine the same would happen with LLVM; even assuming the existing LLVM code is itself perfect, the LLVM->RTL widget, new LLVM code to support GCC extensions that aren't currently supported, and bugs exposed in the GCC backends by the use of different code paths will all take a while to get right. We'd also have to look at any performance regressions to work out whether those issues represent real problems, and how we should deal with them. So, since it's going to be a while before we can integrate LLVM, if we do decide that's best, I hope that we'll continue to improve Tree-SSA in the meanwhile. There are some nice projects in the works, and I'd like to encourage people to keep working on them. Moving algorithms from Tree-SSA to LLVM will no doubt be tractable, and we'll be able to benefit from new Tree-SSA optimizations, if/until LLVM is integrated. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LTO, LLVM, etc.
Ian Lance Taylor wrote: > In short, while this is an important issue, I don't see it as strongly > favoring either side. What it means, essentially, is that LTO is not > quite as much work as it might otherwise seem to be, because we are > going to do some of the work anyhow. So when considering how much > work has to be done for LTO compared to how much work has to be done > for LLVM, we should take that into account. > > This is more or less what you said, of course, but I think with a > different spin. I agree with what you've written, and you've captured my point (that this effectively reduces the cost of LTO, since it provides something else we want) nicely. Again, I don't think that's a definitive argument; it's just one item to factor in to the overall decision. THanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LTO, LLVM, etc.
Steven Bosscher wrote: > On Saturday 03 December 2005 20:43, Mark Mitchell wrote: > >>There is one advantage I see in the LTO design over LLVM's design. In >>particular, the LTO proposal envisions a file format that is roughly at >>the level of GIMPLE. Such a file format could easily be extended to be >>at the source-level version of Tree used in the front-ends, so that >>object files could contain two extra sections: one for LTO and one for >>source-level information. The latter section could be used for things >>like C++ "export" -- but, more importantly, for other tools that need >>source-level information, like IDEs, indexers, checkers, etc. > > > I actually see this as a disadvantage. > > IMVHO dumping for "export" and front-end tools and for the optimizers > should not be coupled like this. Iff we decide to dump trees, then I > would hope the dumper would dump GIMPLE only, not the full front end > and middle-end tree representation. You and I have disagreed about this before, and I think we will continue to do so. I don't see anything about Tree that I find inherently awful; in fact, it looks very much like what I see in other front ends. There are aspects I dislike (overuse of pointers, lack of type-safety, unncessary copies of types), but I couldn't possibly justify changing the C++ front-end, for example, to use something entirely other than Tree. That would be a big project, and I don't see much benefit; I think that the things I don't like can be fixed incrementally. (For example, it occurred to me a while back that by fixing the internal type-correctness of expressions, which we want to do anyhow, we could eliminate TREE_TYPE from expression nodes, which would save a pointer.) It's not that I would object to waking up one day to find out that the C++ front-end no longer used Tree, but it just doesn't seem very compelling to me. > Sharing a tree dumper between the front ends and the middle-end would > only make it more difficult again to move to sane data structures for > the middle end and to cleaner data structures for the front ends. The differences between GIMPLE and C++ Trees are small, structurally; there are just a lot of extra nodes in C++ that never reach GIMPLE. If we had a tree dumper for one, we'd get the other one almost for free. So, I don't think sharing the tree dumper stands in the way of anything; you can still switch either part of the compiler to use non-Tree whenever you like. You'll just need a new dumper, which you would have wanted anyhow. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LTO, LLVM, etc.
Chris Lattner wrote: > I totally agree with Steven on this one. It is *good* for the > representation hosting optimization to be different from the > representation you use to represent a program at source level. The two > have very different goals and uses, and trying to merge them into one > representation will give you a representation that isn't very good for > either use. I don't think that's entirely true. One of the nice things about WHIRL, at least in theory, is that the representation is gradually lowered throughout the compiler, but is never abruptly transitioned, as with GCC's Tree->RTL conversion. So, it's easier to reuse code, instead of having a Tree routine and an RTL routine that do "the same thing", as we do in several places in GCC. As a concrete example, having a control-flow graph in the front-end is very useful, for optimization purposes, diagnostic purposes, and for plugging in domain-specific optimizers and analyzers. It would be nice to have flow-graph code that could be easily used in both places, without having to make that code representation-independent, using adapters to abstract away the actual representation. That's not to say that I disagree with: > In particular, the optimization representation really does want > something in "three-address" form. The current tree-ssa implementation > emulates this (very inefficiently) using trees, but at a significant > performance and memory cost. The representation you want for > source-level information almost certainly *must* be a tree. Instead, it's a long-winded way of saying that I don't agree that there's any inherent benefit to using completely different representations, but that I do agree that one wants the right representation for the job, and that Tree-SSA is not the best representation for optimization. So, if Tree-SSA is not replaced, it will almost certainly need to evolve. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LTO, LLVM, etc.
ist for LTO. You're also correct that some of this work would also benefit GCC as a whole, in that the front-ends would use less memory too, and so you're also correct that there is value in doing at least some of the work independently of LTO -- although there might not be sufficient pressure to make that happen soon. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LTO, LLVM, etc.
Steven Bosscher wrote: > What makes EDG so great is that it represents C++ far closer to the > actual source code than G++ does. I know the EDG front-end very well; I first worked with it in 1994, and I have great respect for both the EDG code and the EDG people. I disagree with your use of "far closer" above; I'd say "a bit closer". Good examples of differences are that (before lowering) it has a separate operator for "virtual function call" (rather than using a virtual function table explicitly) and that pointers-to-member functions are opaque objects, not structures. These are significant differences, but they're not huge differences, or particularly hard to fix in G++. The key strengths of the EDG front-end are its correctness (second to none), cleanliness, excellent documentation, and excellent support. It does what it's supposed to do very well. > It would be good for G++ to have > a representation that is closer to the source code than what it has > now. Yes, closing the gap would be good! I'm a big proponent of introducing a lowering phase into G++. So, while I might disagree about the size of gap, I agree that we should eliminate it. :-) > I'd be surprised if there a compiler exists that runs optimizations > on EDG's C++ specific representation. I think all compilers that use > EDG translate EDG's representation to a more low-level representation. I've worked on several compilers that used the EDG front-end. In all cases, there was eventually translation to different representations, and I agree that you wouldn't want to do all your optimization on EDG IL. However, one compiler I worked on did do a fair amount of optimization on EDG IL, and the KAI "inliner" also did a lot of optimization (much more than just inlining) on EDG IL. Several of the formats to which I've seen EDG IL translated (WHIRL and a MetaWare internal format, for example) are at about the level of "lowered" EDG IL (which is basically C with exceptions), which is the form of EDG IL that people use when translating into their internal representation. In some cases, these formats are then again transformed into a lower-level, more RTL-ish format at some point during optimization. I'm not saying that having two different formats is necessarily a bad thing (we've already got Tree and RTL, so we're really talking about two levels or three), or that switching to LLVM is a bad idea, but I don't think there's any inherent reason that we must necessarily have multiple representations. My basic point is that I want to see the decision be made on the basis of the effort required to achieve our goals, not on our opinions about what we think might be the best design in the abstract. In other words, I don't think that the fact that GCC currently uses the same data structures for front-ends and optimizers is in and of itself a problem -- but I'm happy to switch to LLVM, if we think that it's easier to make LLVM do what we want than it is to make Tree-SSA do what we want. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LTO, LLVM, etc.
Mathieu Lacage wrote: > A path where different solutions for different problems are evolved > independently and then merged where it makes sense seems better to me > than a path where a single solution to two different problems is > attempted from the start. > > Which is thus why I think that "there are inherent reasons that you must > necessarily have multiple representations". There are a lot of places, in GCC and otherwise, where having a unified framework for things has been a clear advantage. So, I think your statement that "genericity is most often bad" is too strong; it's bad sometimes, and good other times. You're definitely right that false commonality can lead to bad results; but, on the other hand, a frequent complaint is that people have to write "the same code" twice because something that could have been shared was not. That's why I think we should be talking about the effort required to implement the approaches before us, and the payoffs from where those approaches lead us, rather than generalities about design. (And, if you really want a prize, you can put "risk-adjusted" in front of "effort" and "payoffs" above!) Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: C++ parser: Should we get rid of cp_parser_declarator_id?
Volker Reichelt wrote: > Shouldn't we fold cp_parser_declarator_id into the caller and call > cp_parser_id_expression directly? Originally, I was trying to have a function for each non-terminal. I'm not going to be dogmatic about that, but is there a good reason to remove the function? As Gaby says, perhaps we could mark the function inline, if you're worried about performance? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Nathan Sidwell as Morpho Technologies Co-Maintainer
The SC has approved Aldy's nomination of Nathan as a co-maintainer for the Morpho Technologies port. Nathan, please updated MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: g++.dg/ext/packed3.C
Nathan Sidwell wrote:
> Jan Beulich wrote:
>
>>
>> Why? It's broken. You just cannot embed something that requires
>> alignment into something that doesn't guarantee alignment, except that
>> for built-in types, the compiler can synthesize the necessary splitting,
>> but Foo's assignment operator, in your example, may be totally unaware
>> that it might get called with an unaligned object.
>
>
> People write such code and expect it to work.
The code in question is:
struct Foo { void operator=(Foo const &);};
struct Baz __attribute__((packed))
{
char c;
Foo m;
}
void Bar (Baz *ptr)
{
ptr->m = something;
}
I'm not sure it can be made to work, without making the base class
version of Foo::operator= expect unaligned input, which seems an
unreasonable pessimization. I would expect this code to be invalid, and
either issue a diagnostic, or at least be considered undefined behavior.
(In my idea world, ptr->m has type "packed Foo" in this case, and it's
not permissible to binding a "packed Foo" to a "Foo const&", so this
would be invalid, but I could live with undefined.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: g++.dg/ext/packed3.C
Nathan Sidwell wrote:
> Mark Mitchell wrote:
>
>> struct Foo { void operator=(Foo const &);};
>> struct Baz __attribute__((packed))
>> {
>>char c;
>>Foo m;
>> }
>>
>> void Bar (Baz *ptr)
>> {
>>ptr->m = something;
>> }
>>
>> I'm not sure it can be made to work, without making the base class
>> version of Foo::operator= expect unaligned input, which seems an
>> unreasonable pessimization. I would expect this code to be invalid, and
>> either issue a diagnostic, or at least be considered undefined behavior.
>
>
> It can be made to work by not packing Baz::m, and that is what g++ does
> (with a warning%).
Ah! That makes sense.
> % ah, I think that warning should only be given on non-default-packed
> arches. Is this your problem Jan?
I think the warning should be given only if the base class does not
itself have the minimum alignment for the artchitecture. (So that you
would get the warning on a system that was packed by default if you used
a base class which was explicitly aligned on a wider boundary.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
#pragma pack vs. zero-width bitfields
PR 22275 is about a change in the structure layout used by GCC when #pragma pack is mixed with zero-width bitfields. In particular, in GCC 3.3 and earlier, zero-width bitfields still forced the next element to be placed on an alignment boundary, just as they do in unpacked structures. In GCC 3.4 and later, zero-width bitfields no longer have this effect, when used within a structure. I believe the older behavior was better. The entire purpose for a zero-width bitfield is to make an alignment request. So, we should assume that if the user wrote that, even within the scope of #pragma pack, they had a reason for doing so. #pragma pack should pack the things that are not explicitly aligned, but it should no more pack the field following a zero-width bitfield than it should a field that has an explicit alignment attribute. As a result, I believe that we should change the behavior back in GCC 4.1. We should not change GCC 3.4.x or GCC 4.0.x because that would be an ABI change within a single release branch. I know this was discussed previously to some extent, but I'm not sure if we reached consensus. I'm going to interpret silence as assent if nobody objects within a few days. So, any disagreements? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.1 Status Report (2005-12-19)
It's now been a month since we created the 4.1 branch. We've still got 90 open PRs against 4.1, including about 20 P1s. So, we have our work cut out for us, if we're going to get to a release near the nominal scheduled date of January 19th. Let's knock 'em down. My intention is to create the first 4.1 release candidate when (a) we've eliminated the P1s, and (b) it's at least January 19th. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
Re: Will there be a GCC 4.0.3 ?
Frédéric L. W. Meunier wrote: > Sorry if this has already been answered, but I couldn't find any status > on the site and mailing-list and it's been almost 3 months since the > 4.0.2 release. Will there be a 4.0.3 or the next will be 4.1 ? There will be a GCC 4.0.3. I plan to begin work on that release shortly. The GCC 4.0.x branch is stable, so it's relatively easy to make a release. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
Re: RTL alias analysis
Steven Bosscher wrote: > Hi rth, > > The stack space sharing you added to cfgexpand.c breaks RTL alias > analysis. > > For example, the attached test case breaks for pentiumpro at -O2. > The problem apparently is that the second store to c is moved up > before before the load. My guess at a solution is that when A (with alias set S_a) and B (with alias set S_b) are given the same stack slot, we should create a new alias set S_c which is a subset of both S_a and S_b, and give the combined stack slot that aliase set. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
