kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

My 2 cents:

In my experience, I sometimes use the optimizations levels as a "verification tool".
Ex: If I run it in debug (or without optimization) and it works and then I switch to optimizations and it doesn't produce the same results, then, there is a bug somewhere (as it was in boost)

I saw in some projects I worked before, they release versions of software/firmware in "debug mode" because it doesn't run in "release" mode :/ (and they dont know why!) .. and it was not fixed ..and started to get the things ugly... (because the sources have ghost bugs)

For the developers, the source should run in all optimizations levels (if the compiler is not bugged)
>From the user point of an enjoyable user experience, the release should have the best optimization that compiler can provide.

The only possible cons are:
- Slower builds
- Bigger .executables
but guess none is a really issue this days..

MRL
________________________________________
From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua.pt@xxxxxxxxxxxxxxxxxxx] on behalf of Wayne Stambaugh [stambaughw@xxxxxxxxx]
Sent: 14 December 2015 16:09
To: Mark Roszko
Cc: KiCad Developers; Kicad-developers
Subject: Re: [Kicad-developers] [PATCH 4/4] Drop gcc optimizer bug workaround

Optimization levels have typically been at the discretion of the builder
in other projects.  I never liked the idea of us forcing an optimization
level even though it resolved an issue related to the boost polygon
library.  You are correct.  There may be some optimization level bugs
but I haven't run into any up to this point.  I would rather the builder
override the system default optimization level if it is using and overly
aggressive level.  Now that we are providing nightly builds for most
platforms, the reason for controlling the build optimization level is
less critical.  When we were asking users to compile from source, it
made more sense.  We'll see, I may regret this decision.  If it becomes
a huge issue like it used to be, I can always change it back.

On 12/14/2015 10:57 AM, Mark Roszko wrote:
> Hence why I am asking, is it intended that we no longer enforce a
> single optimization mode at all? It seems like a can of worms because
> previously we could assume everyone is -O2. Now with people compiling
> at different levels, who knows level dependent bugs could crop up.
>
> On Mon, Dec 14, 2015 at 10:37 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>> This should depend on your platforms gcc default setting or spec file if
>> you use one.  I'm not sure how this done with clang.  On Debain testing,
>> -O2 is the default build optimization setting and -O3 on msys2/mingw32
>> and msys2/mingw64.
>>
>> On 12/14/2015 10:32 AM, Bernhard Stegmaier wrote:
>>> I also assumed something like that and therefore had a look yesterday.
>>> On OSX it seems to default to -O3, at least that's what I have seen with
>>> "make VERBOSE=1".
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 2015-12-14 16:01, Mark Roszko wrote:
>>>> Stupid question, doesn't this change remove -O2 entirely for all gcc
>>>> builds? Previously it defaulted to -O2 if the bug wasn't present. Now
>>>> it never optimizes as -O0 is the default.
>>>>
>>>> On Sat, Dec 12, 2015 at 2:59 PM, Wayne Stambaugh
>>>> <stambaughw@xxxxxxxxx> wrote:
>>>>> I committed your patch in the product branch r6370.  I tested it on
>>>>> msys1/mingw32, msys2/mingw32, msys2/mingw64, and Debian testing without
>>>>> issues.  You should also be able to be more aggressive with your
>>>>> optimization settings should you so desire.  Please keep in mind, if you
>>>>> do this and it breaks, you get keep both pieces.
>>>>>
>>>>> On 12/1/2015 2:14 AM, Simon Richter wrote:
>>>>>>
>>>>>> As boost::polygon is gone, we can drop the workaround for older gcc.
>>>>>> ---
>>>>>>  CMakeLists.txt | 15 ---------------
>>>>>>  1 file changed, 15 deletions(-)
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>
>
>

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp