Re: [PATCH v2 2/2] ci: compile "linux-gcc-default" job with -Og

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/06/06 11:31AM, Patrick Steinhardt wrote:
> We have recently noticed that our CI does not always notice variables
> that may be used uninitialized. While it is expected that compiler
> warnings aren't perfect, this one was a but puzzling because it was

s/but/bit/

> rather obvious that the variable can be uninitialized.
> 
> Many compiler warnings unfortunately depend on the optimization level
> used by the compiler. While `-O0` for example will disable a lot of
> warnings altogether because optimization passes go away, `-O2`, which is
> our default optimization level used in CI, may optimize specific code
> away or even double down on undefined behaviour. Interestingly, this
> specific instance that triggered the investigation does get noted by GCC
> when using `-Og`.
> 
> While we could adapt all jobs to compile with `-Og` now, that would
> potentially mask other warnings that only get diagnosed with `-O2`.
> Instead, adapt the "linux-gcc-default" job to compile with `-Og`. This
> job is chosen because it uses the "ubuntu:latest" image and should thus
> have a comparatively recent compiler toolchain, and because we have
> other jobs that use "ubuntu:latest" so that we do not loose coverage for

s/loose/lose/

> warnings diagnosed only on `-O2` level.
> 
> To make it easier to set up the optimization level in our CI, add
> support in our Makefile to specify the level via an environment
> variable.
> 
> Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
> ---
> 
> I was a little torn whether we really want to name the variable `O`
> here because it feels so easy to set it by accident. We could rename
> this to `OPTIMIZATION` or `OPTIMIZATION_LEVEL`, but that's quite a
> mouthful.
> 
> Alternatively, if we don't want to have this variable in the first
> place, then I'm also happy to adapt the script itself to pass the
> optimization level via an argument.

I think the variable itself is fine, but for a name I think that either 
`OPTIMIZATION` or `OPTIMIZATION_LEVEL` would be a better pick. We have 
some other lengthy environment varible names so I don't think its too 
bad.

Otherwise, this looks good to me :)

-Justin




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux