Paul Eggert wrote:
> Thanks, I installed that into Gnulib and I expect it'll percolate into
> apps in due course.
I propagated it also to the two stable branches of Gnulib [1][2].
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2023-01/msg1.html
[2]
On 2023-01-19 20:20, Sam James wrote:
If it's not too much of a hassle, this works for me, because at least we
advertise the problem a bit, and we can tell distros
to set -D_... if they're stuck on older Clang for a bit.
Thanks, I installed that into Gnulib and I expect it'll percolate into
> On 20 Jan 2023, at 03:40, Paul Eggert wrote:
>
> On 1/19/23 13:30, Sam James wrote:
>> Right, I just meant that we don't tend to care about quieting warnings with
>> older compilers,
>> and it's not useful from a static analysis perspective here either given
>> that older Clangs can't be
On 1/19/23 13:30, Sam James wrote:
Right, I just meant that we don't tend to care about quieting warnings with
older compilers,
and it's not useful from a static analysis perspective here either given that
older Clangs can't be trusted.
It is of course useful as an attribute in general. I
> On 19 Jan 2023, at 21:20, Paul Eggert wrote:
>
> On 1/19/23 12:44, Sam James wrote:
>> _Noreturn is pretty much just an optimisation (and I'm not convinced that
>> it's _needed_ in a lot of cases, rather just a useful hint).
>
> _Noreturn is not just an optimization: it's also useful for
On 1/19/23 12:44, Sam James wrote:
_Noreturn is pretty much just an optimisation (and I'm not convinced
that it's _needed_ in a lot of cases, rather just a useful hint).
_Noreturn is not just an optimization: it's also useful for static
checking. For example:
int
f (int x)
{
if
> On 19 Jan 2023, at 04:17, Paul Eggert wrote:
>
> The problem we found in Gawk was that this sort of function call:
>
>(b ? f : g) (x)
>
> is mishandled by Clang < 16 when one function is _Noreturn and the other
> isn't, in that Clang mistakenly treats the call as if both functions are
The problem we found in Gawk was that this sort of function call:
(b ? f : g) (x)
is mishandled by Clang < 16 when one function is _Noreturn and the other
isn't, in that Clang mistakenly treats the call as if both functions are
_Noreturn.
I expect this sort of issue to be reasonably
Hi all,
Over on bug-gawk, we ended up finding that Clang was miscompiling certain
expressions involving _Noreturn. This is fixed in Clang's git repo but not
in any released version. It should be in 16.0.
Paul suggested [0] that gnulib ought to #define _Noreturn to blank
for known-broken Clang
