This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: -Wall by default


On Thu, Apr 5, 2012 at 2:17 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
>>
>> On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
>>>
>>> Well a lot of users have been burned by using optimization
>>> options, either becausae of compiler bugs, or because of bugs
>>> in their own code triggered by optimization. So the requirement
>>> of not using any optimization options is not that uncommon.
>>
>>
>> But no-optimizations (-O0) should not necessarily be the default
>> for these reasons.
>
>
> I think it is a problem that even at -O1 the debugger is
> seriously limited, especially for an inexperienced user.
>
> What is missing to me is a reasonable cleanup of the code that
> would remove some of the junk at -O0 but not impact debugging.
> In fact a reasonable criterion would be all the optimization
> that is cheap to do and does not affect debugging.
>
> Then I would make THAT the default (or simply redefine -O0
> to be this level, I see no real advantage in -O0 as it is now)

Fact is that -O1 pretty much enables random stuff without any
specific priorities (apart from making compile-time not too big).
It is definitely not "optimize but keep the program debuggable":

--
@opindex O1
Optimize.  Optimizing compilation takes somewhat more time, and a lot
more memory for a large function.

With @option{-O}, the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal of
compilation time.
--

It's on my large TODO list, somewhere at the bottom, to propose
to make -O1 stop after early optimizations and drop right to
expansion from there.  That would turn optimization expectations
upside-down of course, but early optimizations should be mostly
reducing code size (and thus increase compile speed) with
no fancy optimization that inhibit debugging (SRA, IPA-SRA,
switch conversion and function splitting are an exception,
but all but SRA are not enabled at -O1).  So we'd move to
compile-time and debuggability for -O1 (I'd expect compile time
that should be better or at least not a lot slower than -O0).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]