Kenneth Hoste <[EMAIL PROTECTED]> writes: > A related question: how is decided which priority a bug gets?
In general the release manager, Mark Mitchell, sets the priorities of bugs in the bug database. He follows general guidelines where wrong-code is more important, primary platforms are more important, etc. That said, setting priorities has only a weak effect on which bugs actually get fixed. Which bugs are fixed is more related to which ones catch the interest of individual developers, and which ones are related to customers of people and organizations which provide paid support for gcc. > >> - the -fipa-X flags are not mentioned in the 4.1.2 documentation > > > > Looks like a bug. > > A documentation bug you mean? Yes. > >> - the documentation for fmove-loop-invariants and ftree-loop-optimize > >> mentions they are enabled at -O1 when they are not > > > > Actually I think they are enabled at -O1. This is done in a slightly > > tricky way: they default to being on, but they have no effect unless > > the other loop optimization passes are run. I think it would be > > appropriate to clean this up to make the code more obvious. > > Hmm, okay, thank you. Do you know of any other flags being activated > like this in a 'hidden' way? I don't know. One way to find some would be to look at common.opt for the variables which have Init(1), and consider whether they are really enabled at all times or whether they only take effect when other flags are turned on. A general case is that many passes are only run when optimization is turned on. There are also interactions which may be unexpected, such as the way that -frename-registers is turned on if -funroll-loops or -fpeel-loops is used. Look in process_options() in toplev.c for those sorts of interactions. > >> - When new optimization passes are completed, how is decided where > >> they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at- > >> a-time switch from -O2 to -O1 a while ago? And, as I noticed from the > >> 4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is > >> there some testing done, or is it just people saying "I think X > >> belongs there"? > > > > Where to put optimizations is a trade-off between the amount of time > > they take and the amount of good they do. The testing which is done > > is compilation time testing. > > Hmm, okay. I still feel this is a bit ad-hoc. What about flags that > don't get activated in any of the -On flags? Are these not stable > enough yet on important architectures, or are there other reasons? Flags which are not enabled at any optimization option are generally considered to not pay off in significant numbers of cases: they sometimes help and sometimes hurt. For example, -funroll-all-loops. Ideally, anybody who uses -funroll-all-loops would benchmark the code with and without the option when deciding whether to use it. We try to avoid flags which are unstable. There have been a few here and there over the years, but I'm not aware of any at present. That said obviously flags which are not turned on by default get less testing. But, yet, it is definitely ad-hoc. If somebody had a more organized proposal, it would be considered seriously. The current assumption is that we will converge on appropriate settings over time. Ian
