Skip to content

Workaround for GCC 11 uninit variable warnings#946

Merged
paulthomson merged 1 commit intogoogle:mainfrom
mvainola:gcc11
Apr 7, 2021
Merged

Workaround for GCC 11 uninit variable warnings#946
paulthomson merged 1 commit intogoogle:mainfrom
mvainola:gcc11

Conversation

@mvainola
Copy link
Contributor

Release builds of Amber (and the CTS) with GCC 11.0.1 produce some uninitialized variable warnings:

external/amber/src/src/float16_helper.cc: In function ‘float amber::float16::{anonymous}::HexFloat16ToFloat(const uint8_t*)’:
external/amber/src/src/float16_helper.cc:79:11: error: ‘hex’ is used uninitialized [-Werror=uninitialized]
   79 |   return *hex_float;
      |           ^~~~~~~~~
external/amber/src/src/float16_helper.cc:77:12: note: ‘hex’ declared here
   77 |   uint32_t hex = sign | exponent | mantissa;
      |            ^~~

I'm not sure if this is a bug in GCC. This commit works around the warnings by replacing reinterpret_cast with memcpy when type punning unsigned integers to floats. At least on GCC the generated code should be unchanged compared to the current approach:

There's also a new stringop-truncation warning in SPIRV-tools which affects building Amber but not the CTS.

Building Amber with GCC 11.0.1 produces some uninitialized variable
warnings. This commit works around them by replacing
reinterpret_cast with memcpy when type punning unsigned integers to
floats.
@paulthomson paulthomson merged commit aa69a0a into google:main Apr 7, 2021
@mvainola mvainola deleted the gcc11 branch April 7, 2021 10:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants