| 1 |
On 09/13/2018 12:03 PM, Fabian Groffen wrote: |
| 2 |
> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: |
| 3 |
>> |
| 4 |
>> |
| 5 |
>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@g.o> wrote: |
| 6 |
>>> |
| 7 |
>>>> On 2018-09-12 16:50, Rich Freeman wrote: |
| 8 |
>>>> There is also the case where we want these warnings to block |
| 9 |
>>>> installation, because the risk of there being a problem is too great. |
| 10 |
>>> |
| 11 |
>>> I really disagree with that. So many devs have already said multiple |
| 12 |
>>> times in this thread that "-Werror" is only turning existing warnings |
| 13 |
>>> into fatal errors but "-Werror" itself doesn't add any new checks and |
| 14 |
>>> more often requires "-O3" to be useful. |
| 15 |
>> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong. |
| 16 |
> |
| 17 |
> Huh? -O3 enables more checks, which can generate more warnings. -O3 |
| 18 |
> isn't "needed", but if upstream is so interested in clean and correct |
| 19 |
> code, they should've fixed all warnings in the first place and thus |
| 20 |
> enabled all of them. |
| 21 |
|
| 22 |
That wasn't how I read this: |
| 23 |
|
| 24 |
> Also, consider that for -Werror to be "better", you also need -O3 in |
| 25 |
order to activate the "proper" compiler checks like "variable set but |
| 26 |
never used" ones. |
| 27 |
|
| 28 |
But I'll accept that I misunderstood. |
| 29 |
|
| 30 |
> In fact, I expect every sane upstream to use "-O3 |
| 31 |
> -Wall -Werror" in one of their automated builds. Not that this catches |
| 32 |
> anything useful on x86{,_64} when there is for instance use of signed |
| 33 |
> and unsigned char types, so it isn't conclusive. |
| 34 |
> |
| 35 |
> The whole point in here is that -Werror doesn't add much if you care. |
| 36 |
> The whole point why it is not desired in Gentoo is that users don't |
| 37 |
> necessarily are developers, or even interested in fixing warnings -- |
| 38 |
> regardless whether they point to real problems or not. |
| 39 |
> |
| 40 |
> If there are real problems in a package (exposed by a compiler or not) |
| 41 |
> then this should ideally stand out during ~arch testing, or even before |
| 42 |
> when the Gentoo maintainer examines the build (might even use -Werror |
| 43 |
> for his own purposes). If such code ends up in stable arch we just made |
| 44 |
> a stabilisation mistake, or got royally messed up by upstream, depending |
| 45 |
> how you look at it. |
| 46 |
> |
| 47 |
> Fabian |
| 48 |
> |
Archives