<div dir="ltr"><div>Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> writes:</div><div>> Okay; it sounds like we need to make this a data-driven decision. The</div><div>> question is: of those codes using -O<n>, where n > 3, are they more</div>
<div>> likely to be numerics-dominated codes or more-likely to be</div><div>> control-flow-dominated codes. I remember someone posting a list here</div><div>> of # of packages (in some well-known distribution) vs. the default</div>
<div>> optimization flag, so this should be an answerable question.</div><div><br></div><div>I personally like having -Ox where x isn't something we explicitly</div><div>handle be an error. The problem with allowing "-O99" is that it</div>
<div>reinforces the "more is better" misconception. A lot of people don't</div><div>realize that "every optimization possible" doesn't make sense - some</div><div>optimizations conflict with another or have opposing goals.</div>
<div><br></div><div>Flags like "-O2", "-O3", and "-Os" have defined semantics, whereas</div><div>"-O99" is meaningless. The only reason, in my opinion, to accept this</div><div>would be GCC compatibility, in which case we should just do whatever</div>
<div>they do with it. That said, I'd still prefer this continue to be an</div><div>error.</div><div><br></div></div>