Why so much "inline" ? [SOLVED]

[MikeDB]

Neither foresaw weird compilers that would look for integer wrap around and then delete code containing bounds checks because the behavior was undefined in the standard.

Could you name such compilers ?

That is very worrying as in DSP a wrap-around can trigger an instability called limit-cycling which often never settles, so we have lots of checks on data at key points, though usually set to a whole bit away from overload - i.e we only use 31 bits out of 32 for example. I can't say I've ever noticed the bounds checking missing, but then again I don't recall ever looking to check it was there.

[Daniel Gessel]

I think aggressive optimization ultimately exposes that any undefined aspect of a language is a potential trap. As general practice is to encourage limiting the size of functions, creating boundaries the compiler cannot cross without interprocedural optimizations such as inlining, there are de-facto "soft" limits on how aggressive a compiler can get - limits lifted by inlining.

[ejolson]

Neither foresaw weird compilers that would look for integer wrap around and then delete code containing bounds checks because the behavior was undefined in the standard.

Could you name such compilers ?

That is very worrying as in DSP a wrap-around can trigger an instability called limit-cycling which often never settles, so we have lots of checks on data at key points, though usually set to a whole bit away from overload - i.e we only use 31 bits out of 32 for example. I can't say I've ever noticed the bounds checking missing, but then again I don't recall ever looking to check it was there.

My understanding is that optimizations based on undefined behavior of integer wrap around don’t happen with unsigned integers. Note, however, the possibility short unsigned 16-bit integers that get automatically promoted to signed integers.

There is probably not much audio processing using 16-bit unsigned integers, but it’s a possibility. In any case, the solution seems to be explicitly casting uint16_t to uint32_t before performing any arithmetic.

I think both clang and gcc are affected. Sorry that I don’t know more. If you find any bounds checks that were removed from your code, it would be interesting to hear about it.

[ejolson]

Neither foresaw weird compilers that would look for integer wrap around and then delete code containing bounds checks because the behavior was undefined in the standard.

Could you name such compilers ?

That is very worrying as in DSP a wrap-around can trigger an instability called limit-cycling which often never settles, so we have lots of checks on data at key points, though usually set to a whole bit away from overload - i.e we only use 31 bits out of 32 for example. I can't say I've ever noticed the bounds checking missing, but then again I don't recall ever looking to check it was there.

My understanding is that optimizations based on undefined behavior of integer wrap around don’t happen with unsigned integers. Note, however, the possibility short unsigned 16-bit integers that get automatically promoted to signed integers.

There is probably not much audio processing using 16-bit unsigned integers, but it’s a possibility. In any case, the solution seems to be explicitly casting uint16_t to uint32_t before performing any arithmetic.

I think both clang and gcc are affected. Sorry that I don’t know more. If you find any bounds checks that were removed from your code, it would be interesting to hear about it.

Here is a gcc example where automatic inlining may play a role:

Code: Select all

#include <stdio.h>
#include <stdint.h>

uint16_t clipit(uint16_t x,uint16_t y){
    if(x*y<0||x*y>=65535) return 65535;
    return x*y;
}

int main(){
    uint16_t x,y;
    for(;;){
        scanf("%hu %hu",&x,&y);
        printf("clipit(%u,%u)=%u\n",x,y,clipit(x,y));
    }
}

It runs as

Code: Select all

$ gcc -O3 -Wall main.c
$ ./a.out 
5 5
clipit(5,5)=25
50 50
clipit(50,50)=2500
500 500
clipit(500,500)=65535
5000 5000
clipit(5000,5000)=65535
50000 50000
clipit(50000,50000)=2500000000

Fido recommended ctrl-C after that last value.

[Daniel Gessel]

That's pretty ugly - I don't think I would have caught that. I try not to rely on automatic promotions, so I might have cast the uint16_ts to uint32_t, but not sure.

I wouldn't expect:

Code: Select all

  if(x*y<0||x*y>=65535) return 65535;

to be well defined, since 65535 is signed, but I might have written it as:

Code: Select all

  if(x*y>=65535U) return 65535U;

thinking I was doing a saturating unsigned 16 bit multiply... Eeek!

I hope I would have written:

Code: Select all

  if((uint32_t)x*(uint32_t)y>=65535U) return 65535U;

but I can't say - the cat's out of the bag!

[jahboater]

Its a shame the compiler complains about returning x*y as a uint16_t even though the code on the previous line explicitly proves its OK.

[lop]

These compilers will shortly have to remove their signed integer overflow optimizations

In my opinion that is very good news. The sooner the better as the use of cyber operations to damage power generators and shutdown public transportation has already been demonstrated.

I would argue those optimizations are kind of justified, if they don't happen with default (no -O specified) (somebody specify -O3 should know what he is doing)?

But I agree (defined) wrapping signed integers would be handy (who needs "-0" [negative zero] anyway)

[jahboater]

The clipit function

Code: Select all

uint16_t clipit( uint32_t x, uint32_t y ) {
    const uint32_t product = x * y;
    return (uint16_t)(product >> 16 ? 65535U : product);
}

This version uses no signed integers at all, let alone signed integer overflow.
(The arguments are zero extended during the call - done for free on the Pi).
The right shift is done with the barrel shifter for free and the ternary uses the CSEL instruction.
So it should be quite fast.

[jahboater]

I would argue those optimizations are kind of justified, if they don't happen with default (no -O specified) (somebody specify -O3 should know what he is doing)?

The code was just plain wrong so its fine to delete it. But when C23 is ratified, it will be right again

who needs "-0" [negative zero] anyway)

We have it in floating-point, and impressively -0.0 == 0.0 returns true

[ejolson]

I would argue those optimizations are kind of justified, if they don't happen with default (no -O specified) (somebody specify -O3 should know what he is doing)?

The code was just plain wrong so its fine to delete it. But when C23 is ratified, it will be right again

who needs "-0" [negative zero] anyway)

We have it in floating-point, and impressively -0.0 == 0.0 returns true

Is there any indication when C23 might be the default language level in gcc?

[jahboater]

Is there any indication when C23 might be the default language level in gcc?

That's a good question. Not GCC 13 by the looks of it.
Some C23 features were added in GCC 12.2, many more are coming in GCC 13:
https://gcc.gnu.org/gcc-13/changes.html
I guess when C23 is ratified, the GCC devs then have confidence that it is all finalized, it wont be too long.

[slimhazard]

Is there any indication when C23 might be the default language level in gcc?

If history is any guide, the default for gcc might become g23 -- the C23 standard, or close to it, with gcc-specific extensions.

For a very long time, the default was g99, which implemented their support of C99 with gcc extensions. The standard is very close to full support with -std=g99 and -std=c99, but not 100% -- somewhere on gcc.gnu.org there is documentation with the details. But the gcc extensions can be very significant.

I was never much bothered by the bits that deviate from the C standard -- few compilers fulfill absolutely every detail, usually it's very obscure stuff, and I'm fairly sure that I never encountered any of it as a real issue during years of coding.

But I was never a fan of including the gcc extensions by default, unless it was a project for which I was absolutely sure that no other compiler besides gcc would ever be used. There's no feedback indicating that you're using gcc-specific features (with -std=g99, GNU_SOURCE is implicitly defined by default), making it very easy to use something that wouldn't necessarily build with another compiler. So at some point I got into the habit of setting -std=c99 in every build configuration.

It's worth noting that this thread has drifted away from the subject of the Pico C SDK. There's an issue at the SDK repo for clang support, which is currently set for the 1.7.0 milestone. Until then, Pico SDK projects are in fact among those for which we're gcc all the way.

[Daniel Gessel]

It's worth noting that this thread has drifted away from the subject of the Pico C SDK. There's an issue at the SDK repo for clang support, which is currently set for the 1.7.0 milestone. Until then, Pico SDK projects are in fact among those for which we're gcc all the way.

Fair point.

I had a look at the SPI code and many functions just peek or poke a memory mapped I/O location - using macros might have been a better choice. The HW (at least for SPI read/write) is, in some ways, simpler to understand than the abstractions; modifying or rolling your own routines to suit is reasonable, if you don't get the code you want.

[jahboater]

Not only has C23 removed support for old integer representations, it has also added safe and correct support for overflow checking removing the need for the compiler extension or complicated a priori checks.
This code will move over to C23 when stdckdint.h appears:

Code: Select all

#if __has_include(<stdckdint.h>)
  // C23
#define add(a,b) ckd_add(&a,a,b)
#define sub(a,b) ckd_sub(&a,a,b)
#define mul(a,b) ckd_mul(&a,a,b)
#else
  // GCC extension
#define add(a,b) __builtin_add_overflow(a,b,&a)
#define sub(a,b) __builtin_sub_overflow(a,b,&a)
#define mul(a,b) __builtin_mul_overflow(a,b,&a)
#endif

These typically emit a "jump on overflow" instruction which is as fast as it gets.

I see there is another compiler extension that will no longer be needed:

Code: Select all

#if __has_include(<stdbit.h>)
#define clz(n) stdc_leading_zerosull(n)
#define ctz(n) stdc_trailing_zerosull(n)
#else
#define clz(n) __builtin_clzll(n)
#define ctz(n) __builtin_ctzll(n)
#endif

[jahboater]

ejolson,

Is there any indication when C23 might be the default language level in gcc?

There is a nice table here (in the Compiler support section):
https://en.cppreference.com/w/c/23
giving C23 features that are implemented in all the main compilers.
For most of the compilers, the compiler version is given for when the feature was introduced.
Links to the documentation for each feature are included too.

I find it amusing that the "paid for" compilers are way behind the free ones (GCC and clang).
You expect that for MSVC, but not for Apple Clang which some people here say is a very good compiler.

[MikeDB]

I find it amusing that the "paid for" compilers are way behind the free ones (GCC and clang).
You expect that for MSVC, but not for Apple Clang which some people here say is a very good compiler.

Paid for compilers need proper alpha and beta testing. The free ones can release anytime they wish to.

And Apple only release updates to everything at specific times of the year.

[jahboater]

Paid for compilers need proper alpha and beta testing.

Tier one compilers like GCC have a proper professional release program.
Its done on such a large scale that I suspect the exposure and testing is much greater than for something developed internally by one single company.

The free products don't have the cost/benefit tradeoff either, at least not in terms of shareholder value.

To be fair, I just saw the note at the top of the above table, that the status for Apple Clang and some other compilers is unknown.

So it may simply be that the paid for compilers don't disclose product details until release. Whereas the changes and release schedule for GCC are public.

[lop]

There is a nice table here (in the Compiler support section):
https://en.cppreference.com/w/c/23
giving C23 features that are implemented in all the main compilers.

some distributions are usually late in updating the packages (like Ubuntu, and sometimes Debian, too) - but it should take only a few month, before one could expect the main distribution to have updated the packages to the latest GCC?

[jamesh]

I find it amusing that the "paid for" compilers are way behind the free ones (GCC and clang).
You expect that for MSVC, but not for Apple Clang which some people here say is a very good compiler.

Paid for compilers need proper alpha and beta testing. The free ones can release anytime they wish to.

And Apple only release updates to everything at specific times of the year.

I suspect that the testing that GCC gets is considerably more extensive than these in house developed compilers. Some of that might be in the field of course, but the numbers of users is huge.

[jahboater]

some distributions are usually late in updating the packages (like Ubuntu, and sometimes Debian, too) - but it should take only a few month, before one could expect the main distribution to have updated the packages to the latest GCC?

The table shows the which compiler versions support which C23 features.
That's a separate thing from when a new compiler version is available to a distro's users via the package management.

I install GCC on all my computers within hours of a new release ( except for my 256MB Pi1 Rev 1 that takes days to build GCC )

[Daniel Gessel]

some distributions are usually late in updating the packages (like Ubuntu, and sometimes Debian, too) - but it should take only a few month, before one could expect the main distribution to have updated the packages to the latest GCC?

The table shows the which compiler versions support which C23 features.
That's a separate thing from when a new compiler version is available to a distro's users via the package management.

I install GCC on all my computers within hours of a new release ( except for my 256MB Pi1 Rev 1 that takes days to build GCC )

Based on my experience participating in standards development and committees (OpenCL, OpenGL and WebGL) for a couple of companies. All IMHO, totally.

Standards are embraced when they open doors for a company, eschewed when they open doors for competitors. Standards don't intrinsically matter to a commercial organization: tying developers to a platform is weighed against developer demands for standards (see DX, Metal, Objective-C, Swift). OpenGL was the holy grail, then an out of date legacy holding back innovation. Vulkan similarly came about from a sense of dominance in a market and as an attempt to leverage it.

Keeping up with standards? Change is risk, so it better make money.

[MikeDB]

I suspect that the testing that GCC gets is considerably more extensive than these in house developed compilers. Some of that might be in the field of course, but the numbers of users is huge.

I'm sure the number of people using Visual Studio compilers is equally large, and there is a rigorous Alpha/Beta user programme so the feedback is of high quality.

A lot of gcc users will just work around a bug and may not even know the method of feeding back problems. (I don't but I accept I hardly ever use it except for the RP2040 on a couple of projects.)

In theory Apple will be a lower number of users but nowadays many (most?) Macs are actually bought for development of iOS apps which is an essential OS for many products, so any release will get well tested pretty quickly. They also have more in-house development engineers than almost any other company on the planet so their alpha testing will probably be more than good enough.

A question I would pose to everybody - what C23 new feature do you actually intend to use ?

[jahboater]

A question I would pose to everybody - what C23 new feature do you actually intend to use ?

Already using a few:

#elifdef and #elifndef
static_assert with no message
__has_include and __has_c_attribute
being able to declare a variable after a case label
"maybe_unused" attribute

Looking forward to using:

Decimal floating point (for currency calculations)

safe checking for signed integer overflow

stdbit.h portable bit manipulation functions

"unsequenced" and "reproducable" function attributes

constexpr objects

specify a type and attributes for enumerations

possibly the bit precise integer types

unnamed parameters in function definitions

nullptr type

typeof_unqual

[Daniel Gessel]

Honestly (I accept annoyingly as well) I ask: will your use of feature X will make corporation Y more money?

This is a big part of the reason I appreciate GNU/Linux, and in turn, why I like RPi's support of the RPi OS. Stallman is a local (used to protest at one of my co-workers academic talks) and not everyone appreciates that he comes from the "The People's Republic of Cambridge", but GNU and the FSF started something that's pretty cool.

[ejolson]

I suspect that the testing that GCC gets is considerably more extensive than these in house developed compilers. Some of that might be in the field of course, but the numbers of users is huge.

I'm sure the number of people using Visual Studio compilers is equally large, and there is a rigorous Alpha/Beta user programme so the feedback is of high quality.

A lot of gcc users will just work around a bug and may not even know the method of feeding back problems. (I don't but I accept I hardly ever use it except for the RP2040 on a couple of projects.)

In theory Apple will be a lower number of users but nowadays many (most?) Macs are actually bought for development of iOS apps which is an essential OS for many products, so any release will get well tested pretty quickly. They also have more in-house development engineers than almost any other company on the planet so their alpha testing will probably be more than good enough.

A question I would pose to everybody - what C23 new feature do you actually intend to use ?

Compared to the Visual Studio C++ compiler, I suspect the number of users for Visual Studio C is quite small. For one thing Visual Studio C is not fully C99 compliant and leaves more out of C11. The feature page doesn't even address C17 or the upcoming C23 standards.

https://learn.microsoft.com/en-us/cpp/o ... w=msvc-170

When Microsoft integrated Clang with Visual Studio in 2019, I expected the proprietary compilers developed in house to be deprecated in a way similar to the Intel C/C++ compilers

https://community.intel.com/t5/Intel-on ... -p/1412267

see also

https://www.intel.com/content/www/us/en ... notes.html

and replaced by an LLVM based tool.

As far as I can tell, much of the increase in users of C is due to Arduino style micro controller programming. Does Microsoft Visual C appear in this context?

Though there may not be much C in the cloud compared to other languages, it is worth noting that Linux runs 90 percent of cloud workloads and Microsoft Visual C does not run on Linux.

On the other hand, the Microsoft C++ compiler is up to date and currently supports the C++20 standard with a number of C++23 features.