>-Ofast, -ffast-math and -funsafe-math-optimizations will no longer add startup code to alter the floating-point environment when producing a shared object with -shared.

Well, that's a relief. Definitely won't fix anything already built, but it's a nice step in the right direction. The idea of finding out that a shared library is breaking unrelated code is a scary proposition.

Wow! That’s my bug report from just over 10 years ago :)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

Bugs that take this long to fix are surreal. The bugs will outlast us.

This was an issue in the Python packaging ecosystem recently: https://moyix.blogspot.com/2022/09/someones-been-messing-wit...

Audio people will be happy

> -Wxor-used-as-pow

This seems to only trigger in limited circumstances, one of my favorite accidentally true expression is still warning-free:

    printf("%d\n", 2^5);  // Warning here.

    assert((3^2) + (4^2) == (5^2));  // No warnings.

https://gcc.godbolt.org/z/4GqdEMfPb

My understanding is it only triggers when the left side is 2 or 10.

That's quite specific

It's based on the errors the proposers actually found in the wild, which seem to mostly be people attempting to use constant powers of 2 or 10.

should also include e.

Excellent. Now I'm wondering if Fermat's Last Theorem has a bitwise analogue.

Bitwise multiplication is bitwise ‘and’, so exponentiation (repeated multiplication) is the identity, so aⁿ+bⁿ=cⁿ iff a+b=c. I have a truly remarkable proof of this, but my filesystem is full.

> Now I'm wondering if Fermat's Last Theorem has a bitwise analogue.

It hasn’t in this sense. The ^n operator flips the ‘one’ bits in n in its argument, so for any n, we have

  a = a^n^n

So, for all a and b,

  a^n + b^n = ((a^n + b^n)^n)^n

that makes

  c = (a^n + b^n)^n

a solution to

  a^n + b^n = c^n

and that means we can find a c for every n, a and b.

Neat proof!

Can anyone please share their experience with Openmp offload? In terms of performance improvement observed, how much effort you had to put in, comparison with any other gpgpu paradigm etc.

I'm just getting started with it. My _impression_ is that this isn't quite mature yet. On a toy example I was working on, I had trouble beating host only Openmp performance. Cuda thrust was about 5 times faster, while taking about 5x less effort. Just a data point.

" -fanalyzer is still only suitable for analyzing C code. In particular, using it on C++ is unlikely to give meaningful output. " Not this time, maybe next time ?

It's a pleasure to have it for C still

Yes, anything that helps improving the safety of C code is welcomed, it isn't going away anytime soon.

Somewhat-opinionated tl;dr:

* C23 features

* C++23 features

* OpenMP work, including v5 / 5.1

* Support for more AArch64, arm CPUs

* Support for more Intel CPUs and ISA extensions (man, there are so many of those...)

* More static analyzer checks

I'm still waiting for #embed