Re: [PATCH v2 2/2] ci: compile "linux-gcc-default" job with -Og
- From
Justin Tobler <jltobler@gmail.com>
- Date
- Jun 6, 2024, 15:32 UTC
- Message-ID
- <crfguam2loy7nrwenirbt3rub3vj52nvhxuvr5foyx6sd2weez@vjnnzrmc6scc>
- In-Reply-To
- <bdf0e40a770c57b63e7519983d37b97a85ce07bf.1717662814.git.ps@pks.im>
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/
Show 16 quoted lines
> 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/
Show 17 quoted lines
> 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@pks.im> > --- > > 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