Revert "modules: hal_rpi_pico: set -std=gnu11 in a toolchain independ…

[soburi]

This reverts commit 05401b3.

Introducing c-std setting with CMake way in the commit, but the actual command line is below.

arm-zephyr-eabi-gcc -DKERNEL ... -std=gnu11 ...  -std=c99 ...

The setting CONFIG_STD_C99 in Kconfig appends the -std=c99, and (At least in gcc,) options are processed last-come-first, so this setting was meaningless.

This will cause a build error,
https://github.com/zephyrproject-rtos/zephyr/actions/runs/15357763548/job/43220292776?pr=90893
so we will revert it.

[soburi]

@RobinKastberg

Here, we want to maintain C99 compliance for the Zephyr source,
but hal_rpi_pico assumes gcc11, so we use gcc11 only when compiling sources under the modules/hal_rpi_pico.
(If it is not a GCC extension, C24 that includes the 'typeof' operator specs is required)
The CMake method cannot be used, and since we want to enforce C99 compatibility for the Zephyr code, setting the Kconfig value is also undesirable.
It's a workaround of sorts, but a reasonable compromise for the current situation.

Would you consider fixing this as an individual case for IAR?

I have marked this PR as a DNM for now. Please let me know if there are no problems.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[RobinKastberg]

How unfortunate. However it's not like IAR is currently working on pico and it's currently not our priority to fix so feel free to revert this.

If you could make it a generator expression or check CMAKE_C_COMPILER_ID we wouldn't have to fix it again later however.

[soburi]

How unfortunate. However it's not like IAR is currently working on pico and it's currently not our priority to fix so feel free to revert this.

If you could make it a generator expression or check CMAKE_C_COMPILER_ID we wouldn't have to fix it again later however.

Thanks. Once, I'll proceed with the current policy.
I will consider how to respond separately.

[dancollins]

I will also get a chance to test this fix. I know setting GNU_COMPILER_EXTENIONS allows the tests to build, and the issue was caused by exactly what is mentioned at the top - both standards being applied during compilation.

Thoughts on adding a warning or error when building pico SDK without GCC? That way, when we're using other toolchains, CMake will let you know at build-time.

[RobinKastberg]

Thoughts on adding a warning or error when building pico SDK without GCC? That way, when we're using other toolchains, CMake will let you know at build-time.

Feel free, but I think it's kind of drastic. pico sdk has had support for other toolchains in the past, but seems to have rotten somewhat.
e.g. see https://github.com/zephyrproject-rtos/hal_rpi_pico/blob/7b57b24588797e6e7bf18b6bda168e6b96374264/src/rp2_common/pico_platform_compiler/include/pico/platform/compiler.h