Re: What is the purpose of these two fixincludes?

[Florian Weimer via Gcc]

* Richard Biener via Gcc:

> But are they still needed?  Often headers already contain
> alternatives for standard conforming compilers or GCC can now
> deal with the contents.

I suspect that io_quotes_def and io_quotes_use in particular often get
applied spuriously.

Thanks,
Florian

Re: How to target a processor with very primitive addressing modes?

[Florian Weimer via Gcc]

* Jeff Law via Gcc:

> If he's got a CC register exposed prior to LRA and LRA needs to insert
> any code, that inserted code may clobber the CC state.  This is
> discussed in the reload-to-LRA transition wiki page.

Do you mean the CC0 conversion page?

  

Thanks,
Florian

Re: configure adds -std=gnu++11 to CXX variable

[Florian Weimer via Gcc]

* Paul Eggert:

> On 2024-05-27 03:35, Florian Weimer wrote:
>> Does this turn on experimental language modes by default?  That's
>> probably not what we want.
>
> What do C++ developers want these days? Autoconf should have a
> reasonable default, and C++11 is surely not a good default anymore.

It's still a good default for GCC 5.

GCC developers will correct me, but I think the default C++ dialect is
updated to a newer version once the implementation is reasonably
complete and bugs have been ironed out.

This is different from the C front end, where it took close to 40 years
(from the introduction of void * into C) to activate type checking for
pointer types by default.

>> It would be better to have an option to raise the C++ mode to at least a
>> certain revision, and otherwise use the default.
>
> That option is already available. For example, a builder who doesn't
> want C++23 can use './configure ac_cv_prog_cxx_cxx23=no', and a
> developer can discourage C++23 by putting ':
> ${ac_cv_prog_cxx_cxx23=no}' early in configure.ac.

But that is not the same thing.  If a project uses C++14 constructs,
wouldn't it make sense to tell configure to try to get (likely
experimental) support for it if the compiler does not enable C++14 by
default?  And if the system is already at C++17, leave it at that?

Setting C++14 unconditionally could be incompatible with used system
libraries, which assume C++17 support because the distribution is aware
that the system compiler supports C++17.

Thanks,
Florian

Re: configure adds -std=gnu++11 to CXX variable

[Florian Weimer via Gcc]

* Paul Eggert:

> diff --git a/NEWS b/NEWS
> index 20dbc173..4ba8f3fe 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -16,6 +16,10 @@ GNU Autoconf NEWS - User visible changes.
>C11 and later.  Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__
>to use VLAs if available.
>  
> +*** AC_PROG_CXX now prefers C++23, C++20, C++17, C++14 if available.
> +  Older code may need to be updated, as some older features of C++ are
> +  removed in later standards.
> +

Does this turn on experimental language modes by default?  That's
probably not what we want.

It would be better to have an option to raise the C++ mode to at least a
certain revision, and otherwise use the default.  The default is more
likely to be supported by system libraries, and it's a bit less likely
that programmers use experimental, known-to-be-buggy features (language
and library) by accident.

Thanks,
Florian

Re: Updated Sourceware infrastructure plans

[Florian Weimer via Gcc]

* Jason Merrill:

> On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey  wrote:
>
>  > "Frank" == Frank Ch Eigler  writes:
>
>  >> [...]  I suggest that a basic principle for such a system is that it
>  >> should be *easy* to obtain and maintain a local copy of the history
>  >> of all pull requests.  That includes all versions of a pull request,
>  >> if it gets rebased, and all versions of comments, if the system
>  >> allows editing comments.  A system that uses git as the source of
>  >> truth for all the pull request data and has refs [...]
>
>  Frank> Do you know of a system with these characteristics?
>
>  Based on:
>
>  https://gerrit-review.googlesource.com/Documentation/dev-design.html#_notedb
>
>  ... it sounds like this is what gerrit does.
>
> Someone mentioned earlier that gerrit was previously tried
> unsuccessfully.  I think this is a common pattern in GCC at least:
> someone has an idea for a workflow improvement, and gets it working,
> but it isn't widely adopted.

We used it for glibc briefly.  It failed in part because we were too
kind and didn't give negative feedback in the tool itself (making it
less useful for contributors), and because it was deployed on the side
alongside the usual mailing list patch submission process.

It may be worth a try again, but this time with brutally honest feedback
(-2 and whatnot).  On the other hand, Gerrit appears to require Bazel to
build, and as far as I understand it, setting up and maintaining a Bazel
build environment that meets our requirements (basically: no mystery
binaries) is a very big task.

Thanks,
Florian

Re: [RFC] Linux system call builtins

[Florian Weimer via Gcc]

* Alexander Monakov:

> On Mon, 8 Apr 2024, Florian Weimer via Gcc wrote:
>
>> * Matheus Afonso Martins Moreira via Gcc:
>> 
>> >   + It's stable
>> >
>> > This is one of the things which makes Linux unique
>> > in the operating system landscape: applications
>> > can target the kernel directly. Unlike in virtually
>> > every other operating system out there, the Linux kernel
>> > to user space binary interface is documented[2] as stable.
>> > Breaking it is considered a regression in the kernel.
>> > Therefore it makes sense for a compiler to target it.
>> > The same is not true for any other operating system.
>> 
>> There is quite a bit of variance in how the kernel is entered.  On
>> x86-64, one once popular mechanism is longer present in widely-used
>> kernels.
>
> I assume you're implicitly referencing the vsyscall mechanism, but on
> amd64 it's not useful to *enter the kernel*, right? It was useful for
> obtaining the result of certain syscalls without actually entering
> the kernel, like with vdso.

The implementation performed a standard system call if a pure userspace
implementation wasn't possible.  It wasn't intended as a general-purpose
way to enter the kernel (although it could be used as such, hence the
desire to remove it in some cases).

Thanks,
Florian

Re: [RFC] Linux system call builtins

[Florian Weimer via Gcc]

* Matheus Afonso Martins Moreira via Gcc:

>   + It's stable
>
> This is one of the things which makes Linux unique
> in the operating system landscape: applications
> can target the kernel directly. Unlike in virtually
> every other operating system out there, the Linux kernel
> to user space binary interface is documented[2] as stable.
> Breaking it is considered a regression in the kernel.
> Therefore it makes sense for a compiler to target it.
> The same is not true for any other operating system.

There is quite a bit of variance in how the kernel is entered.  On
x86-64, one once popular mechanism is longer present in widely-used
kernels.  For POWER, the preferred way changed over time.  Likewise for
i386.

>   + It's a calling convention
>
> GCC already supports many calling conventions
> via function attributes. On x86 alone[3] there's
> cdecl, fastcall, thiscall, stdcall, ms_abi, sysv_abi,
> Win32 specific hot patching hooks. So I believe this
> would not at all be a strange addition to the compiler.

But using a builtin obfuscates that relationship.  There is no
__builtin_call_ms_abi, is there?

Thanks,
Florian

Re: Sourceware mitigating and preventing the next xz-backdoor

[Florian Weimer via Gcc]

* Guinevere Larsen via Overseers:

> Beyond that, we (GDB) are already experimenting with approved-by, and
> I think glibc was doing the same.

The glibc project uses Reviewed-by:, but it's completely unrelated to
this.  Everyone still pushes their own patches, and there are no
technical countermeasures in place to ensure that the pushed version is
the reviewed version.

Thanks,
Florian

Re: Builtin for consulting value analysis (better ffs() code gen)

[Florian Weimer via Gcc]

* Andrew Cooper via Gcc:

> Anyway - is there a way of doing this that I've managed to overlook?

Use __builtin_ffs?

I think there's some concern for GCC that some of the alternative x86-64
implementations do not follow the AMD and Intel behavior.

Thanks,
Florian

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

[Florian Weimer via Gcc]

* Andi Kleen via Gcc:

>> ***This is NodeNumber0
>> (0x7f12e13b0d00) NodeNumber0
>> tree_code: function_decl
>> tree_code_class: tcc_declaration
>
> My suggestion if you go this route would be to generate
> some standard format like YAML or JSON that other tools
> can easily parse.

And C++ code that emits equivalent GENERIC or GIMPLE, perhaps?

Thanks,
Florian

Re: Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer via Gcc]

* Martin Jambor:

> Given you probably have the most experience with it, can you please also
> suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
> would describe this change?  (I was thinking of proposing something
> myself, but I don't really know just how much verbose such an entry
> should be.)

Thank you for the reminder.  I veered somewhat on the verbose side and
submitted:

  [PATCH] Notes on the warnings-as-errors change in GCC 14
  


Florian

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

* Mathieu Desnoyers:

> On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote:
>> This commit
>> commit 8abddb187b33480d8827f44ec655f45734a1749d
>> Author: Andrew Burgess 
>> Date:   Sat Aug 5 14:31:06 2023 +0200
>>  libgcc: support heap-based trampolines
>>   Add support for heap-based trampolines on x86_64-linux,
>> aarch64-linux,
>>  and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
>>  __builtin_nested_func_ptr_deleted functions for these targets.
>>   Co-Authored-By: Maxim Blinov 
>>  Co-Authored-By: Iain Sandoe 
>>  Co-Authored-By: Francois-Xavier Coudert 
>> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is
>> currently
>> built, it ends up using a dynamic TLS variant on the Linux targets.
>> This means that there is no up-front TLS allocation with glibc (but
>> there would be one with musl).
>
> Trying to wrap my head around this:
>
> If I get this right, the previous behavior was that glibc did allocate
> global-dynamic variables from libraries which are preloaded and loaded
> on c startup as if they were initial-exec, but now that libgcc_s.so.1
> has a dynamic TLS variable, all those libraries loaded on c startup that
> have global-dynamic TLS do not get the initial allocation special
> treatment anymore. Is that more or less correct ?

Ahh.  I had forgotten about this aspect.  The allocation from the static
TLS area still happens as before.

> I've prepared a change for lttng-ust to move the lttng-ust libc wrapper
> "malloc nesting" guard variable from global-dynamic to initial-exec:
>
> https://review.lttng.org/c/lttng-ust/+/11677 Fix: libc wrapper: use 
> initial-exec for malloc_nesting TLS

I don't know if this is completely sufficient if there are other TLS
variables in the lttng stack.

> This should help for the infinite recursion issue, but if my understanding
> is correct about the impact of effectively changing the behavior used
> for global-dynamic variables in preloaded and on-startup-loaded libraries
> introduced by this libgcc change, I suspect we have other new issues here,
> such as problems with async-signal safety of other global-dynamic variables
> within LTTng-UST.

This didn't change, and the allocation is not done lazily (contrary to
what I might have written before).  But even on the __tls_get_addr fast
path, we check the TLS generation counter, and if that has changed, we
do extra bookkeeping work.  TLS usage in libgcc_s.so.1 means that in the
now-failing test, the generation counter changed.  Before bug 19924

  TLS performance degradation after dlopen 
  

was fixed, we did not do this bookkeeping work, which is why the problem
didn't occur.

General use of lttng should be fine, I think, only the malloc wrapper
has this problem.

> But moving all TLS variables used by lttng-ust from global-dynamic to
> initial-exec is tricky, because a prior attempt to do so introduced
> regressions in use-cases where lttng-ust was dlopen'd by Java or
> Python, AFAIU situations where the runtimes were already using most of
> the extra memory pool for dlopen'd libraries initial-exec variables,
> causing dlopen of lttng-ust to fail.

Oh, right, that makes it quite difficult.  Could you link a private copy
of the libraries into the wrapper that uses initial-exec TLS?

Thanks,
Florian

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

* Iain Sandoe:

>> On 15 Jan 2024, at 15:35, Florian Weimer  wrote:
>> 
>> * Carlos O'Donell:
>> 
>>> I agree. TLS should be seen more like .bss/.data rather than something
>>> that is allocated with malloc().
>> 
>> There wasn't consensus regarding this in 2014.  See below.
>> 
>>> If we leak memory via TLS that is a glibc bug that we can deal with,
>> 
>> This is something that libgcc_s.so.1 does in GCC 14 if the heap
>> trampolines are used.
>
> Is there a GCC BZ for this?
> (if there is something we should address in GCC, it would be better sooner)

Sorry, I wanted to write a reproducer first.  With it, I found two more
issue.

  Memory (resource) leak in -ftrampoline-impl=heap
  

  Incorrect symbol versions for __builtin_nested_func_ptr_created,
  __builtin_nested_func_ptr in libgcc_s.so.1
  

  __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be
  dynamically linked by default
  

Thanks,
Florian

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

* Carlos O'Donell:

> I agree. TLS should be seen more like .bss/.data rather than something
> that is allocated with malloc().

There wasn't consensus regarding this in 2014.  See below.

> If we leak memory via TLS that is a glibc bug that we can deal with,

This is something that libgcc_s.so.1 does in GCC 14 if the heap
trampolines are used.

> but making it easier to find glibc bugs is also a benefit to the
> community, but not as valuable a benefit as making TLS correctly
> async-signal safe.
>
> Likewise we need to discuss when the memory is allocated, regardless
> of which allocator is used, including allocation up-front at dlopen()
> time.
>> [1] https://sourceware.org/pipermail/libc-alpha/2014-January/047931.html

The change conflated multiple issues: sanitizer support,
async-signal-safe TLS access, and eager allocation of all TLS-related
memory, so that subsequent accesses cannot fail.  My impression was the
main point of contention was eager allocation because it was perceived
as a breaking semantic change.  Nowadays, as long as we are willing to
maintain both allocator variants, we could offer a choice between them
controlled by a tunable.  For sanitizer compatibility, we could perform
eager allocation using malloc.  It's probably a good idea to do it this
way anyway because a separate mmap-based allocator would increase TLB
pressure.

Thanks,
Florian

New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

This commit

commit 8abddb187b33480d8827f44ec655f45734a1749d
Author: Andrew Burgess 
Date:   Sat Aug 5 14:31:06 2023 +0200

libgcc: support heap-based trampolines

Add support for heap-based trampolines on x86_64-linux, aarch64-linux,
and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
__builtin_nested_func_ptr_deleted functions for these targets.

Co-Authored-By: Maxim Blinov 
Co-Authored-By: Iain Sandoe 
Co-Authored-By: Francois-Xavier Coudert 

added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
built, it ends up using a dynamic TLS variant on the Linux targets.
This means that there is no up-front TLS allocation with glibc (but
there would be one with musl).

There is still a compatibility impact because glibc assigns a TLS module
ID upfront.  This seems to be what causes the
ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
up with an infinite regress during process termination because
libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
happens, the bottom of the stack looks like this:

#4447 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
#4448 0x77fdb142 in free (ptr=)
at ../include/rtld-malloc.h:50
#4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
#4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0, 
gen=) at ../elf/dl-tls.c:916
#4451 0x77fddccc in __tls_get_addr ()
at ../sysdeps/x86_64/tls_get_addr.S:55
#4452 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
#4453 0x77fdb142 in free (ptr=)
at ../include/rtld-malloc.h:50
#4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
#4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0, 
gen=) at ../elf/dl-tls.c:916
#4456 0x77fddccc in __tls_get_addr ()
at ../sysdeps/x86_64/tls_get_addr.S:55
#4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
   from /lib64/liblttng-ust-common.so.1
#4458 0x77f4c2e8 in ust_lock_nocheck () from /lib64/liblttng-ust.so.1
#4459 0x77f5175a in lttng_ust_cleanup () from /lib64/liblttng-ust.so.1
#4460 0x77fca0f2 in _dl_call_fini (
closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
#4461 0x77fce06e in _dl_fini () at dl-fini.c:114
#4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6

Cc:ing  for awareness.

The issue also requires a recent glibc with changes to DTV management:
commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
access after dlopen [BZ #19924]").  If I understand things correctly,
before this glibc change, we didn't deallocate the old DTV, so there was
no call to the free function.

On the glibc side, we should recommend that intercepting mallocs and its
dependencies use initial-exec TLS because that kind of TLS does not use
malloc.  If intercepting mallocs using dynamic TLS work at all, that's
totally by accident, and was in the past helped by glibc bug 19924.  (I
don't think there is anything special about libgcc_s.so.1 that triggers
the test failure above, it is just an object with dynamic TLS that is
implicitly loaded via dlopen at the right stage of the test.)  In this
particular case, we can also paper over the test failure in glibc by not
call free at all because the argument is a null pointer:

diff --git a/elf/dl-tls.c b/elf/dl-tls.c
index 7b3dd9ab60..14c71cbd06 100644
--- a/elf/dl-tls.c
+++ b/elf/dl-tls.c
@@ -819,7 +819,8 @@ _dl_update_slotinfo (unsigned long int req_modid, size_t 
new_gen)
 dtv entry free it.  Note: this is not AS-safe.  */
  /* XXX Ideally we will at some point create a memory
 pool.  */
- free (dtv[modid].pointer.to_free);
+ if (dtv[modid].pointer.to_free != NULL)
+   free (dtv[modid].pointer.to_free);
  dtv[modid].pointer.val = TLS_DTV_UNALLOCATED;
  dtv[modid].pointer.to_free = NULL;

As the comment hints, we shouldn't be using malloc for TLS memory at all
because it is not AS-safe, but that's a long-term change.  This change
seems rather specific to this particular test case failure because it
relies on libgcc_s.so.1 never using TLS before it gets unloaded.

Regarding the libgcc_s side, I'm not sure if the TLS usage there should
be considered a real problem, although I'm a bit nervous about it.
However, the current implementation caches one page of trampolines past
the outermost nested function pointer deallocation (otherwise creating
one function pointer per thread in a loop would be really expensive).
It looks to me that is never freed, so if the thread exits even with
proper unwinding (e.g., on glibc with code compiled with -fexceptions),
there is a memory leak.  Integration with glibc could avoid this issue,
and also help with the longjmp problem, and fix setcontext/swapcontext,
too.

Thanks,
Florian

Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

[Florian Weimer via Gcc]

* Andrew Pinski via Gcc:

> -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> not even supported with LTO. Does it make sense to deprecate the
> support for GCC 14 and remove it in GCC 15?

Is this the stuff around libitm and that adds _ITM_registerTMCloneTable
and _ITM_deregisterTMCloneTable symbol references to *all* binaries
(whether they use transactional memory or not)?

Thanks,
Florian

Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

[Florian Weimer via Gcc]

I feel like I have asked this before.  Currently, GCC uses calls to
__tls_get_addr to obtain the address of global-dynamic TLS variables.
On other architectures with support for GNU2 TLS descriptors, those are
used by default.

Should we flip the default to GNU2 descriptors?  Support has been
available in glibc for a long, long time.  Is there any other reason for
not doing this?  On the glibc side, the behavior regarding lazy
initialization and symbol binding does not change whether the old or new
interface is used.

Thanks,
Florian

-fcf-protection default on x86-64 (also for -fhardened)

[Florian Weimer via Gcc]

Currently, -fcf-protection defaults to both shadow stack and indirect
branch tracking (IBT) on x86_64-linux-gnu, and -fhardened follows that.
I think it should only enable shadow stack at this point.

I'm not sure if this is a good idea because there will likely be no
userspace support for IBT when GCC 14 releases, so these binaries will
not be tested.  They will carry markup that indicates compatibility with
IBT, though.  If there turns out to be a problem, we'd have to revision
the markup and disable IBT for all existing binaries (because we don't
know which ones have the toolchain fix applied).

I think we can keep the shadow stack markup because there will be ways
to test for compatibility fairly soon.  The risk is also fairly reduced
for shadow stack because there are no code generation changes in generic
code, while for IBT every function that has their address taken needs a
different prologue.

As far as I understand it, there won't be any i386 GNU/Linux support for
shadow stacks, so -fhardened shouldn't enable it on that target.
Furthermore, ENDBR32 is incompatible with the i386 baseline ISA because
it's a long NOP.

Thanks,
Florian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Florian Weimer via Gcc]

* LIU Hao via Gcc:

> 在 2023/12/8 21:59, Florian Weimer via Gcc 写道:
>>[PATCH] libgcov: Call __builtin_fork instead of fork
>>
>> <https://inbox.sourceware.org/gcc-patches/87edg4epw5@oldenburg.str.redhat.com/>
>
> May I ask why it's not something like this?
>
> Even though there may be people who define `fork()` in global scope, it will 
> be semantically 
> different from the POSIX fork.
>
> ```
> diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
> index b2ee9308641..10ce8edc4fb 100644
> --- a/libgcc/libgcov-interface.c
> +++ b/libgcc/libgcov-interface.c
> @@ -174,7 +174,7 @@ __gcov_dump (void)
>
>   #endif /* L_gcov_dump */
>
> -#ifdef L_gcov_fork
> +#if defined L_gcov_fork && !defined _WIN32
>   /* A wrapper for the fork function.  We reset counters in the child
>  so that they are not counted twice.  */
>
> ```

Other systems probably have the same issue.  We just don't have an
autobuilder, or we have one and I haven't seen its error.

Thanks,
Florian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Florian Weimer via Gcc]

* Mark Wielaard:

> BTW. The gcc-fedora-mingw buildbot has been broken because of this
> issue for the last week:
>
> https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw
> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit
> declaration of function 'fork' [-Wimplicit-function-declaration]
>   185 |   pid = fork ();
>   | ^~~~
> make[2]: *** [Makefile:935: _gcov_fork.o] Error 1

Yes, that's why I submitted a patch:

  [PATCH] libgcov: Call __builtin_fork instead of fork
  


Thanks,
Florian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Florian Weimer via Gcc]

* Richard Biener:

> On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc  wrote:
>>
>> I've received a report of a mingw build failure:
>>
>> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
>> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration 
>> of function 'fork' [-Wimplicit-function-declaration]
>>   185 |   pid = fork ();
>>   | ^~~~
>> make[2]: *** [Makefile:932: _gcov_fork.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>>
>> As far as I understand it, mingw doesn't have fork and doesn't declare
>> it in , so it's not clear to me how this has ever worked.  I
>> would expect a linker failure.  Maybe that doesn't happen because the
>> object containing a reference to fork is only ever pulled in if the
>> application calls the intercepted fork, which doesn't happen on mingw.
>>
>> What's the best way to fix this?  I expect it's going to impact other
>> targets (perhaps for different functions) because all of
>> libgcov-interface.c is built unconditionally.  I don't think we run
>> configure for the target, so we can't simply check for a definition of
>> the HAVE_FORK macro.
>
> This is wrapped inside
>
> #ifdef L_gcov_fork
> #endif
>
> grepping didn't find me what defines this, but it suggests the solution
> lies there ...

That's just the general libgcc/ coding style, which puts multiple
related functions into one C source file.  The file is compiled multiple
times with different -D options using Makefile rules like this one:

$(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c 
$(srcdir)/gcov.h $(srcdir)/libgcov.h
$(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c

It looks like this is done to emulate -Wl,--gc-sections without separate
source files.  Unfortunately, this is all built unconditionally.

Thanks,
Florian

libgcov, fork, and mingw (and other targets without the full POSIX set)

[Florian Weimer via Gcc]

I've received a report of a mingw build failure:

../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of 
function 'fork' [-Wimplicit-function-declaration]
  185 |   pid = fork ();
  | ^~~~
make[2]: *** [Makefile:932: _gcov_fork.o] Error 1
make[2]: *** Waiting for unfinished jobs

As far as I understand it, mingw doesn't have fork and doesn't declare
it in , so it's not clear to me how this has ever worked.  I
would expect a linker failure.  Maybe that doesn't happen because the
object containing a reference to fork is only ever pulled in if the
application calls the intercepted fork, which doesn't happen on mingw.

What's the best way to fix this?  I expect it's going to impact other
targets (perhaps for different functions) because all of
libgcov-interface.c is built unconditionally.  I don't think we run
configure for the target, so we can't simply check for a definition of
the HAVE_FORK macro.

Thanks,
Florian

Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer via Gcc]

The patch series is currently under review:

  [PATCH v3 00/11] : More warnings as errors by default
  


Jeff as a global reviewer has delegated review to Marek.

The current series is based on an earlier suggestion to do as much as
possible in one transition.  The full list of upgraded warnings is:

  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wint-conversion
  -Wreturn-mismatch (new, previously part of -Wreturn-types)
  -Wdeclaration-missing-parameter-type (new, previously unnamed)
  -Wincompatible-pointer-types

Fedora has a set of about 15,000 source packages which are built with a
GCC compiler in the buildroot.  Until recently, we only had experience
with dealing with -Wimplicit-function-declaration and -Wimplicit-int
issues.  We have implemented fixes or workaround in about 860 packages
for those two warnings.  Where possible, these fixes have been sent
upstream, but of course in many cases, upstream has been dormant for a
while or not around at all anymore.

We now have Fedora test builds with an instrumented GCC that covers all
the warnings listed above.  The data is skewed somewhat because we
underwent an unscheduled libxml2 API transition at the same time, and
also had a glibc crypt declaration regression initially.  I'm going with
the numbers I have today.  They include cleanups for about 50 packages
for various issues (most prominent ones being bash and xterm).

  autoconf
  all only
  implicit-function-declaration53   21
  implicit-int  20
  int-conversion   99   33
  return-mismatch  132
  declaration-missing-parameter-type00
  incompatible-pointer-types  374   50
  497   89

Numbers do not tally up because one package can have multiple issues.
The autoconf column counts packages where file-name based heuristics
suggest the critical errors are in autoconf-style feature probes, where
they are ignored and could silently alter the results.  My focus will be
on fixing those packages.

These numbers include a certain amount of false positives, especially
for implicit-function-declaration and incompatible-pointer-types, but
the GCC instrumentation has improved somewhat and now uses unrelated
errors (e.g., about unknown types, or incorrect number of function
errors) to suppress logging of the critical errors.

Looking at the numbers, everything seems quite doable except
incompatible-pointer-types.  (Keep in mind that these numbers are based
on over 15,000 packages.)  Instead of the incompatible-pointer-types
error, Clang only went with a subset (not yet implemented by GCC) called
incompatible-function-pointer-types, but I'm not sure if it would result
in a substantial amount of work reduction.  The status as a warning for
non-function pointers definitely hides real bugs (for example, an
out-of-bounds write in PyTables on 32-bit architectures).

I suggest we put in the incompatible-pointer-types upgrade for now
(pending review), and see how it goes in Fedora.  I plan to backport
these changes to GCC 13 as used in our current development version, so
that we can gain some feedback from package maintainers before we import
GCC 14 (which is expected to happen well before the GCC upstream
release).  If feedback is overly negative, I'm going to suggest that GCC
disables it again for the GCC 14 release, although that would run
counter to the request for one transition only.

Thoughts?

Excluded above are systemic issues related to Vala, which does not
produce valid C in many cases.  I will probably have to look into
teaching Vala to emit diagnostic pragmata in the generated C sources
because they are not expected to be valid C (although again, this really
seems to be hiding application bugs in some cases).

Thanks,
Florian

Emacs ChangeLog generation and commit messages

[Florian Weimer via Gcc]

Emacs has a very useful facility.  You press “C-x 4 a” in a place where
you make changes, and the editor automatically opens the right ChangeLog
file and adds a draft entry to it, like this:

2023-11-06  Florian Weimer  

* c-opts.cc (c_common_post_options): █

Is there something like this that works with commit messages and
produces output compatible with GCC's expectations?

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer via Gcc]

* David Brown:

>> C23 changes meaning of of extern foo(); to match the C++
>> interpretation of extern foo(void);.  I don't think we should warn
>> about that.  If we warn, it would be at the call site.
>
> I'm not sure I fully agree.  "extern foo();" became invalid when
> implicit int was removed in C99.  But "extern T foo();", where "T" is
> void or any type, has changed meaning between C17 (and before) and
> C23.

My concern is that the warning would not really be actionable.
Encouraging programmers to change foo() to foo(void) in declarations
seems merely busywork.  C++ doesn't need this, and future C won't need
it, either.

> IMHO I think calling "foo" with parameters should definitely be a
> warning, enabled by default, for at least -std=c99 onwards - it is
> almost certainly a mistake.  (Those few people that use it as a
> feature can ignore or disable the warning.)

It's possible to disable this warning in C23 by declaring foo as ”extern
T foo(...);”.  Not sure if this has ABI implications.

> I would also put warnings on the declaration itself at -Wall, or at
> least -Wextra (i.e., "-Wstrict-prototypes").  I think that things that
> change between standards, even subtly, should be highlighted.
> Remember, this concerns a syntax that was marked obsolescent some 35
> years ago, because the alternative (prototypes) was considered
> "superior to the old style on every count".

I still think the declaration is quite harmless if we warn at call
sites.

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer via Gcc]

* David Brown:

> On 11/10/2023 10:10, Florian Weimer wrote:
>> * David Brown:
>> 
>>> So IMHO (and as I am not a code contributor to GCC, my opinion really
>>> is humble) it is better to be stricter than permissive, even in old
>>> standards.  It is particularly important for "-std=c89", while
>>> "-std=gnu89" is naturally more permissive.  (I have seen more than
>>> enough terrible code in embedded programs - I don't want to make it
>>> easier for them to write even worse code!)
>> We can probably make (say) -std=gnu89 -fno-permissive work, in a way
>> that is a bit less picky than -std=gnu89 -pedantic-errors today.
>> 
>
> The gcc manual has "-permissive" under "C++ Dialect Options".  Are you
> planning to have it for C as well?

Yes, I've got local patches on top of Jason's permerror enhancement:

  [PATCH v2 RFA] diagnostic: add permerror variants with opt
  



> That sounds like a good idea (perhaps with some examples in the
> documentation?).  Ideally (and I realise I like stricter checking than
> many people) some long-obsolescent features like non-prototype
> function declarations could be marked as errors unless "-permissive"
> were used, even in C89 standards.

For some of such declarations, this falls out of the implicit-int
removal.

C23 changes meaning of of extern foo(); to match the C++ interpretation
of extern foo(void);.  I don't think we should warn about that.  If we
warn, it would be at the call site.

> (As a side note, I wonder if "-fwrapv" and "-fno-strict-aliasing"
> should be listed under "C Dialect Options", as they give specific
> semantics to normally undefined behaviour.)

They are code generation options, too.

>> And of course there's still -Werror, that's not going to go away.  So if
>> you are using -Werror=implicit-function-declaration today (as you
>> probably should 8-), nothing changes for you in GCC 14.
>
> I have long lists of explicit warnings and flags in my makefiles, so I
> am not concerned for my own projects.  But I always worry about the
> less vigilant users - the ones who don't know the details of the
> language or the features of the compiler, and don't bother finding
> out.  I don't want default settings to be less strict for them, as it
> means higher risks of bugs escaping out to released code.

We have a tension regarding support for legacy software, and ongoing
development.  I think we should draw the line at C99.  That's the first
language standard that removes most of these obsolescent features, after
all.

Thanks,
Florian

Re: Function multiversioning ABI issues

[Florian Weimer via Gcc]

* Andrew Carlotti via Gcc:

> I've also seen the GCC documentation for the ifunc attribute [1].
> This states that "the indirect function needs to be defined in the
> same translation unit as the resolver function".  This is not how
> function multiversioning is currently implemented.  Instead, the
> resolver functions are added to the translation units of every caller.

I don't see how this can happen.  Do you have a declaration of the
resolver function in a shared header, by chance?

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer via Gcc]

* David Brown:

> So IMHO (and as I am not a code contributor to GCC, my opinion really
> is humble) it is better to be stricter than permissive, even in old
> standards.  It is particularly important for "-std=c89", while
> "-std=gnu89" is naturally more permissive.  (I have seen more than
> enough terrible code in embedded programs - I don't want to make it
> easier for them to write even worse code!)

We can probably make (say) -std=gnu89 -fno-permissive work, in a way
that is a bit less picky than -std=gnu89 -pedantic-errors today.

And of course there's still -Werror, that's not going to go away.  So if
you are using -Werror=implicit-function-declaration today (as you
probably should 8-), nothing changes for you in GCC 14.

> I suspect (again with numbers taken from thin air) that the proportion
> of C programmers or projects that actively choose C11 or C17 modes, as
> distinct from using the compiler defaults, will be less than 1%.  C99
> (or gnu99) is the most commonly chosen standard for small-systems
> embedded programming, combining C90 libraries, stacks, and RTOS's with
> user code in C99.  So again, my preference is towards stricter
> control, not more permissive tools.

I don't think the estimate is accurate.  Several upstream build systems
I've seen enable -std=gnu11 and similar options once they are supported.
Usually, it's an attempt to upgrade to newer language standards that
hasn't aged well, not a downgrade.  It's probably quite bit more than
1%.

Thanks,
Florian

Re: Documenting common C/C++ options

[Florian Weimer via Gcc]

* Jason Merrill:

>> But that wasn't really the direction of my question.  I was wondering
>> where we should document a future C version of -fpermissive.
>
> My permerror patch proposes moving it to the Warning Options node,
> right after -pedantic-errors.

Yes, that should work.  I'm basing my patches based on it.

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer via Gcc]

* Joseph Myers:

> On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote:
>
>> Are these code fragments valid C89 code?
>> 
>>   int i1 = 1;
>>   char *p1 = i;
>> 
>>   char c;
>>   char *p2 = 
>>   int i2 = p2;
>
> Implicit conversions between pointers and integers are not valid C89.
>
> ANSI C89, as adopted as FIPS PUB 160, is available from NIST: 
> https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf

Thank you, this is helpful information.

Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer via Gcc]

* Jakub Jelinek:

> On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
>> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc 
>> wrote:
>> 
>> > Are these code fragments valid C89 code?
>> >
>> >   int i1 = 1;
>> >   char *p1 = i;
>> >
>> >   char c;
>> >   char *p2 = 
>> >   int i2 = p2;
>> >
>> > Or can we generate errors for them even with -std=gnu89?
>> >
>> > (It will still be possible to override this with -fpermissive or
>> > -Wno-int-conversion.)
>> >
>> 
>> Given that C89 code is unlikely to be actively maintained, I think we
>> should be permissive by default in that mode.  People compiling with an old
>> -std flag are presumably doing it to keep old code compiling, and it seems
>> appropriate to respect that.
>
> Yeah, complete agreement here.

Okay.  It helps with the test suite conversation because -std=gnu89 -w
is available today, so I can post such patches separately.

>> I'm also (though less strongly) inclined to be permissive in C99 mode, and
>> only introduce the new strictness by default for C11/C17 modes.
>
> Especially when the default is -std=gnu17 that can be an option as well.
>
> There might be some code in the wild compiled with -std=gnu99 or -std=c99 just
> because it wanted to use C99 features back 15-20 years ago and hasn't been
> adjusted since then, but it might be better to adjust that if needed and keep
> using those flags only when they are needed because the code isn't C11/C17/C2X
> ready.

Linux currently uses -std=gnu99 deliberately in a few places, I believe.
It would be a shame if we defaulted to permissive mode over there.  I
would certainly prefer to restrict permissive mode to the C89/C90
language levels.  We can have this discussion once I post my patch
(which depends on Jason's permerror enhancement in several ways).

Thanks,
Florian

C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer via Gcc]

Are these code fragments valid C89 code?

  int i1 = 1;
  char *p1 = i;

  char c;
  char *p2 = 
  int i2 = p2;

Or can we generate errors for them even with -std=gnu89?

(It will still be possible to override this with -fpermissive or
-Wno-int-conversion.)

Thanks,
Florian

Re: Documenting common C/C++ options

[Florian Weimer via Gcc]

* Richard Earnshaw:

> On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote:
>> On 10/10/2023 10:47, Florian Weimer via Gcc wrote:
>>> Currently, -fsigned-char and -funsigned-char are only documented as C
>>> language options, although they work for C++ as well (and Objective-C
>>> and Objective-C++, I assume, but I have not tested this).  There does
>>> not seem to be a place for this kind of options in the manual.
>>>
>>> The options -fshort-enums and -fshort-wchar are documented under
>>> code-generation options, but this seems to be a bit of a stretch because
>>> (at least for -fshort-wchar), these too seem to be more about front-end
>>> behavior.
>>>
>>> What would be a good way to address this?
>>>
>>> Thanks,
>>> Florian
>>>
>> 
>> 
>> All of these are ABI; so where ever it goes, it should be documented
>> that changing them will potentially cause issues with any
>> pre-compiled object files having different settings.

> And you can add -f[un]signed-bitfield to that list as well.

There's already a section for those ABI options that are like
-fshort-enums:

@node Code Gen Options
@section Options for Code Generation Conventions

Maybe we should move them over there.

But that wasn't really the direction of my question.  I was wondering
where we should document a future C version of -fpermissive.

Thanks,
Florian

Documenting common C/C++ options

[Florian Weimer via Gcc]

Currently, -fsigned-char and -funsigned-char are only documented as C
language options, although they work for C++ as well (and Objective-C
and Objective-C++, I assume, but I have not tested this).  There does
not seem to be a place for this kind of options in the manual.

The options -fshort-enums and -fshort-wchar are documented under
code-generation options, but this seems to be a bit of a stretch because
(at least for -fshort-wchar), these too seem to be more about front-end
behavior.

What would be a good way to address this?

Thanks,
Florian

-Wint-conversion as errors seems doable for GCC 14

[Florian Weimer via Gcc]

I completed a Fedora rawhide rebuild with an instrumented GCC (~14,500
packages).  156 packages failed to build with a logged -Wint-conversion
error.  This number is much lower than what I expected, and I think we
should include -Wint-conversion in the GCC 14 changes.

My instrumentation isn't very good and has false positives due to
cascading errors, such as this example from Emacs:

conftest.c: In function 'main':
conftest.c:246:21: error: passing argument 1 of 'pthread_setname_np' makes 
integer from pointer without a cast
  246 | pthread_setname_np ("a");
  | ^~~
  | |
  | char *
In file included from conftest.c:242:
/usr/include/pthread.h:463:42: note: expected 'pthread_t' {aka 'long unsigned 
int'} but argument is of type 'char *'
  463 | extern int pthread_setname_np (pthread_t __target_thread, const char 
*__name)
  |~~^~~
conftest.c:246:1: error: too few arguments to function 'pthread_setname_np'
  246 | pthread_setname_np ("a");
  | ^~
/usr/include/pthread.h:463:12: note: declared here
  463 | extern int pthread_setname_np (pthread_t __target_thread, const char 
*__name)
  |^~

The error at column 21 is logged, even though it is harmless because the
compilation can never succeed because of the wrong argument count.

That's why I think the number of failing builds 156 is really quite low,
and we should be able to manage on the Fedora side.  I'll eventually do
another rebuild with better instrumentation (one that also handles
waivers for implicitly declared functions; currently we get errors from
those because their type is still treated as int internally; maybe I
should switch to error_mark_node for that).

Thanks,
Florian

Re: Question about merging if-else blocks

[Florian Weimer via Gcc]

* Richard Biener:

>> By disassembling the exe file generated by icc, I found that icc will
>> merge these two blocks with the example code below. So I think there
>> maybe some ways to make it.
>
> ... glibc for example allows user-provided printf format callbacks so
> printf might call back into the current TU and modify globals in such
> callback.  That's a GNU extension to printf that ICC likely doesn't
> support 
> (https://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html),
> so that we're currently not doing this is for correctness.
>
> I'm not sure if this extension is much used or if it is maybe
> deprecated.

There's also fopencookie, which is more widely available.  The GNU C
library supports assignment to stdout, so an fopencookie stream could be
the target of printf, also triggering callbacks.

But I'm not sure if callbacks updating global variables should prevent
GCC from treating printf et al. as leaf functions.

Thanks,
Florian

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

* Arsen Arsenović via Gcc:

> Sam James via Gcc  writes:
>
>> Florian Weimer via Gcc  writes:
>>
>>> My understanding of the consensus goes as follows:
>>>
>>> * We want to make some changes in this area for GCC 14.
>>> * We should do the same thing that Clang does: default to the relevant
>>>   -Werror= options.
>>> * Unlike regular warnings, these warnings-as-errors should also apply
>>>   to system headers.
>>> * At least implict-int and implicit-function-declaration should be
>>>   upgraded to errors in this way.
>>> * It's too early to make the () changes and bool-as-keyword from C2X
>>>   for GCC 14.
>>> * We should fix the missing scope of the int-conversion warnings
>>>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>>>
>>> Is this summary accurate?
>>>
>>
>> I wasn't there, but this reflects my understanding & what I would've
>> said if I could've attended.
>>
>>> I think the open issues are:
>>>
>>> * Do we want to implement something else beside implicit-int and
>>>   implicit-function-declaration?  (Candidates are int-conversion and
>>>   incompatible-pointer-types, and the void vs non-void part of
>>>   return-type, maybe others as previously discussed on the list.)
>>
>> Ideally, I'd like both int-conversion + incompatible-pointer-types in
>> this cycle, but if we have to defer one, I'd say to keep int-conversion.
>
> +1, this seems reasonable.  I'm not sure I can imagine any even
> half-legitimate use for falling off the end of functions and similar, so
> perhaps we should also take return-type?  Is that part of C23?

Falling of the end of the function is legitimate if a no-return function
is called and not annotated as such, among other things.  I don't think
we should warn or error for that by default.

The issue I'm concerned about is about “return;” in a function not
returning void, or “return expr;” in a function returning void.  This
looks like related to implict int return types for functions.  It's not
part of C99.  There is no separate -W switch to control this warning.
It is on by default (as required by C99), unlike other aspects of
-Wreturn-type.

Thanks,
Florian

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

* Jeff Law:

>> I think the open issues are:
>> * Do we want to implement something else beside implicit-int and
>>implicit-function-declaration?  (Candidates are int-conversion and
>>incompatible-pointer-types, and the void vs non-void part of
>>return-type, maybe others as previously discussed on the list.)
>> * How do we divide up the test suite cleanup work?

> Not to open a can of worms, but shouldn't these be evaluated along the
> same basic criteria?  ie, what's Clang doing here, are these
> warnings-as-errors and thus apply to system headers, etc.  ANd the
> biggie, do any of these issues tend to mask correctness errors in the
> wild at a level roughly similar to implicit
> int/implicit-function-declaration?

At present, it is not possible to evaluate them using the same basic
criteria because we don't have the answer to your last question.  I have
an instrumented compiler for -Wint-conversion, but have not had a chance
yet to run a distribution rebuild with it.

Thanks,
Florian

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

* Jakub Jelinek:

> On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
>> My understanding of the consensus goes as follows:
>> 
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>   -Werror= options.
>
> I think it doesn't have to be necessarily using defaulting to -Werror=,
> -Werror= involves diagnostic_classify_diagnostic etc.
> It could very well be also just testing if the corresponding warning
> option isn't explicitly (OPTION_SET_P) disabled and isn't explicitly
> -Wno-error=OPTION and c99 or later and conditionally based on that
> use error (which would print the [-W...] part though) or warning.
> The former would be in system headers too, the latter wouldn't.
> We need to decide what exact options we want to turn those errors (and/or
> warnings) off or on, -Wno-implicit-int, -w, -Wno-error,
> -Wno-error=implicit-int, ...

I didn't mean to be prescriptive about implementation details, sorry.

With Clang, -w and -Wno-error have no effect on those error-by-default
warnings, too.  And I don't think Clang supports suppressing warnings
from system headers.

Thanks,
Florian

Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

My understanding of the consensus goes as follows:

* We want to make some changes in this area for GCC 14.
* We should do the same thing that Clang does: default to the relevant
  -Werror= options.
* Unlike regular warnings, these warnings-as-errors should also apply
  to system headers.
* At least implict-int and implicit-function-declaration should be
  upgraded to errors in this way.
* It's too early to make the () changes and bool-as-keyword from C2X
  for GCC 14.
* We should fix the missing scope of the int-conversion warnings
  (PR109827).  Likweise for incompatible-pointer-types (PR109826).

Is this summary accurate?

I think the open issues are:

* Do we want to implement something else beside implicit-int and
  implicit-function-declaration?  (Candidates are int-conversion and
  incompatible-pointer-types, and the void vs non-void part of
  return-type, maybe others as previously discussed on the list.)
* How do we divide up the test suite cleanup work?

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer via Gcc]

* Alexander Monakov:

>> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine.
>> 
>> It still changes the result, doesn't it?
>
> I don't follow. I doesn't change the result for infinities (produces
> a NaN). It changes the result when x is so large that 'x + x' is
> not representable (exponent would overflow), but that's exactly what
> contraction is about?

Okay, you meant “changing the result” as in “changing the result in a
permitted way”.  Sorry, was confused.  So this is a bad example all
around.  Are there better ones (that don't involve FMA)?

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer via Gcc]

* Richard Biener:

>> How much numerical code is compatible with that?  For example, David
>> Goldberg's What Every Computer Scientist Should Know About
>> Floating-Point Arithmetic (revised) contains this sentence:
>>
>> | A language definition that does not require parentheses to be honored
>> | is useless for floating-point calculations.
>>
>> 
>
> I suppose that applies to re-association not honoring parens.  With C
> you either have no re-association (fine) or re-association but globally,
> at the expense of violating the standard.  FP contraction is _not_
> about honoring parens, the 'error' introduced by is subtle.

But for contracted expressions, + *is* associative.  Maybe this is not
the most relevant part of the article for contractions, though.

> Fortran for example allows re-association by default, but honors
> parens.  GCC can do this just fine.

I think it's still a divergence from the model promoted by the article.
For further problems see “Pitfalls in Computations on Extended-Based
Systems”; that covers the matter of excess precision (which, as far as I
understand, is very relevant to contractions).  It quotes this code
snippet:

| if (1.0 + x .eq. 1.0) then

The C11 standard does not define what “floating expressions” are (as far
as I can see), so it's a bit unclear whether the whole thing can be
contracted (assuming x is not a NaN).

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer via Gcc]

* Alexander Monakov:

> On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
>
>> x - x is different because replacing it with 0 doesn't seem to be a
>> valid contraction because it's incorrect for NaNs.  x + x - x seems to
>> be different in this regard, but in our implementation, there might be a
>> quirk about sNaNs and qNaNs.
>
> Sorry, do you mean contracting 'x + x - x' to 'x'?

Yes.

> That is not allowed due to different result and lack of FP exception
> for infinities.

FP exceptions do not need to preserved in C11 (it's a recommended
practice in Annex F only, and the main text explicitly allows changes).
But you are right that inf - inf would result in a NaN, so that's a
different result that cannot be explained by infinite intermediate
precision.  Huh, so it's a bad example.  Sorry!

But the contraction would still be valid after an isfinite check
(something that ranger might catch these days), or with with
-ffinite-math-only in general.  Right?

> Contracting 'x + x - x' to fma(x, 2, -x) would be fine.

It still changes the result, doesn't it?

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer via Gcc]

* Richard Biener:

>> > > GCC contraction behavior is rather inconsistent.  It does not contract x
>> > > + x - x without -ffast-math, for example, although I believe it would be
>> > > permissible under the rules that enable FMA contraction.  This whole
>
> Is that really just x + x - x?  We currently gate simplifying x - x to zero
> on no-signed-zeros and round-to-nearest and have no special
> handling for x + x - x.

It's just an example I made up, and checked that GCC wouldn't optimize
it by default (without -ffast-math et al.).  I believe the rule that GCC
invokes to introduce FMA under -ffp-contract=standard (and
-ffp-contract=fast) would apply to these contractions as well.

Or put differently, -ffp-contract= seems to be exclusively about FMA,
while the option name and description is more generic.

x - x is different because replacing it with 0 doesn't seem to be a
valid contraction because it's incorrect for NaNs.  x + x - x seems to
be different in this regard, but in our implementation, there might be a
quirk about sNaNs and qNaNs.

>> The "correctness trumps performance" principle still applies, and
>> -ffp-contract=fast (the current default outside of -std=cNN) is
>> known to cause correctness issues and violates the C language standard.
>> And -ffast[-and-loose]-math for is not going away.
>
> I think that changing the default to =standard without -ffast-math is
> reasonable.  IIRC the standard allows such default if it's indicated,
> so it doesn't require =off anywhere.

How much numerical code is compatible with that?  For example, David
Goldberg's What Every Computer Scientist Should Know About
Floating-Point Arithmetic (revised) contains this sentence:

| A language definition that does not require parentheses to be honored
| is useless for floating-point calculations.



Few people have access to the IEEE 754 standard, and Goldberg's article
is therefore widely quoted as gospel.  If I understand this correctly,
according to Goldberg, contractions make C “useless”.  But I'm not a
floating point person, and I nowadays regret that I looked down upon the
numerical methods people at university.

Thanks,
Florian

Concerns regarding the -ffp-contract=fast default

[Florian Weimer via Gcc]

While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
several packages had test suite failures because x86-64 suddenly gained
FMA support.  I say “rediscovered” because these issues were already
visible on other architectures with FMA.

So far, our package/architecture maintainers had just disabled test
suites or had built the package with -fp-contract=off because the
failures did not reproduce on x86-64.  I'm not sure if this is the right
course of action.

GCC contraction behavior is rather inconsistent.  It does not contract x
+ x - x without -ffast-math, for example, although I believe it would be
permissible under the rules that enable FMA contraction.  This whole
thing looks suspiciously like a quick hack to get a performance
improvement from FMA instructions (sorry).

I know that GCC 14 has -fp-contract=standard.  Would it make sense to
switch the default to that?  If it fixes those package test suites, it
probably has an observable performance impact. 8-/

Thanks,
Florian

Re: [gcc r13-7720] x86: Update model values for Raptorlake.

[Florian Weimer via Gcc-patches]

* Lili Cui via Gcc-cvs:

> https://gcc.gnu.org/g:0fa76e35a5f9e141c08fdf151380f2f9689101c7
>
> commit r13-7720-g0fa76e35a5f9e141c08fdf151380f2f9689101c7
> Author: Cui, Lili 
> Date:   Mon Aug 14 02:06:00 2023 +
>
> x86: Update model values for Raptorlake.
> 
> Update model values for Raptorlake according to SDM.
> 
> gcc/ChangeLog
> 
> * common/config/i386/cpuinfo.h (get_intel_cpu): Add model value 
> 0xba
> to Raptorlake.
>
> Diff:
> ---
>  gcc/common/config/i386/cpuinfo.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gcc/common/config/i386/cpuinfo.h 
> b/gcc/common/config/i386/cpuinfo.h
> index 81f8b1766f8d..d6f2b7e3cfb3 100644
> --- a/gcc/common/config/i386/cpuinfo.h
> +++ b/gcc/common/config/i386/cpuinfo.h
> @@ -539,6 +539,8 @@ get_intel_cpu (struct __processor_model *cpu_model,
>  case 0xbf:
>/* Alder Lake.  */
>  case 0xb7:
> +case 0xba:
> +case 0xbf:
>/* Raptor Lake.  */
>  case 0xaa:
>  case 0xac:

This mismerge breaks the build (duplicate 0xbf case values).

Thanks,
Florian

Using __builtin_unwind_init in glibc

[Florian Weimer via Gcc]

I would like to use __builtin_unwind_init in glibc in a few places, to
preserve additional evidence for a debugger.  It's currently not a
documented built-in function.  Would that still be okay.

(Most architectures will have probably benefit from a custom
register-preserving assembler trampoline, but __builtin_unwind_init
would still be very useful for generic code.)

Thanks,
Florian

Re: Intel AVX10.1 Compiler Design and Support

[Florian Weimer via Gcc-patches]

* Hongtao Liu:

> On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich  wrote:
>> Aiui these ABI levels were intended to be incremental, i.e. higher versions
>> would include everything earlier ones cover. Without such a guarantee, how
>> would you propose compatibility checks to be implemented in a way

Correct, this was the intent.  But it's mostly to foster adoption and
make it easier for developers to pick the variants that they want to
target custom builds.  If it's an ascending chain, the trade-offs are
simpler.

> Are there many software implemenation based on this assumption?
> At least in GCC, it's not a big problem, we can adjust code for the
> new micro-architecture level.

The glibc framework can deal with alternate choices in principle,
although I'd prefer not to go there for the reasons indicated.

>> applicable both forwards and backwards? If a new level is wanted here, then
>> I guess it could only be something like v3.5.

> But if we use avx10.1 as v3.5, it's still not subset of
> x86-64-v4(avx10.1 contains avx512fp16,avx512bf16 .etc which are not in
> x86-64-v4), there will be still a diverge.
> Then 256-bit of x86-64-v4 as v3.5? that's too weired to me.

The question is whether you want to mandate the 16-bit floating point
extensions.  You might get better adoption if you stay compatible with
shipping CPUs.  Furthermore, the 256-bit tuning apparently benefits
current Intel CPUs, even though they can do 512-bit vectors.

(The thread subject is a bit misleading for this sub-topic, by the way.)

Thanks,
Florian

Re: Intel AVX10.1 Compiler Design and Support

[Florian Weimer via Gcc-patches]

* Richard Biener via Gcc-patches:

> I don’t think we can realistically change the ABI.  If we could
> passing them in two 256bit registers would be possible as well.
>
> Note I fully expect intel to turn around and implement 512 bits on a
> 256 but data path on the E cores in 5 years.  And it will take at
> least that time for AVX10 to take off (look at AVX512 for this and how
> they cautionously chose to include bf16 to cut off Zen4).  So IMHO we
> shouldn’t worry at all and just wait and see for AVX42 to arrive.

Yes, the direction is a bit unclear.  In retrospect, we could have
defined x86-64-v4 to use 256 bit vector width, so it could eventually be
compatible with AVX10; it's also what current Intel CPUs prefer (and
past, with the exception of the Xeon Phi line).  But in the meantime,
AMD has started to ship CPUs that seem to prefer 512 bit vectors,
despite having a double pumped implementation.  (Disclaimer: All CPU
preferences inferred from current compiler tuning defaults, not actual
experiments. 8-/)

To me, this looks like we may have defined x86-64-v4 prematurely, and
this suggests we should wait a bit to see where things are heading.

Thanks,
Florian

Re: Calling convention for Intel APX extension

[Florian Weimer via Gcc]

* Thomas Koenig via Gcc:

> Intel recommends to have the new registers as caller-saved for
> compatibility with current calling conventions.  If I understand this
> correctly, this is required for exception unwinding, but not if the
> function called is __attribute__((nothrow)).

Nothrow functions still can call longjmp, so that's probably not the
right discriminator.

For glibc on Linux, we have some extra space in jmpbuf in the signal
mask (we have 1024 bits, but the kernel can use just 64, some of those
have already been repurposed), but it's going to be tough for
cancellation support because of a historic microoptimization there.

Thanks,
Florian

[PATCH releases/gcc-13 1/2] libgcc: Fix eh_frame fast path in find_fde_tail

[Florian Weimer via Gcc-patches]

The eh_frame value is only used by linear_search_fdes, not the binary
search directly in find_fde_tail, so the bug is not immediately
apparent with most programs.

Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc:
Special-case BFD ld unwind table encodings in find_fde_tail").

libgcc/

PR libgcc/109712
* unwind-dw2-fde-dip.c (find_fde_tail): Correct fast path for
parsing eh_frame.

(cherry picked from commit 49310a993308492348119f4033e4db0bda4fe46a)
---
 libgcc/unwind-dw2-fde-dip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 6223f5f18a2..4e0b880513f 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -403,8 +403,8 @@ find_fde_tail (_Unwind_Ptr pc,
 BFD ld generates.  */
   signed value __attribute__ ((mode (SI)));
   memcpy (, p, sizeof (value));
+  eh_frame = p + value;
   p += sizeof (value);
-  dbase = value;   /* No adjustment because pcrel has base 0.  */
 }
   else
 p = read_encoded_value_with_base (hdr->eh_frame_ptr_enc,

base-commit: a1322d76ca1c3c914fb818d9ba3edc291ccfa25e
-- 
2.41.0

[PATCH releases/gcc-13 2/2] libgcc: Fix -Wint-conversion warning in find_fde_tail

[Florian Weimer via Gcc-patches]

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
in find_fde_tail").

libgcc/

PR libgcc/110179
* unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
implicit conversion of pointer value to integer.

(cherry picked from commit 104b09005229ef48a79a33511ea192bb3ec3c415)
---
 libgcc/unwind-dw2-fde-dip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 4e0b880513f..28ea0e64e0e 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -403,7 +403,7 @@ find_fde_tail (_Unwind_Ptr pc,
 BFD ld generates.  */
   signed value __attribute__ ((mode (SI)));
   memcpy (, p, sizeof (value));
-  eh_frame = p + value;
+  eh_frame = (_Unwind_Ptr) (p + value);
   p += sizeof (value);
 }
   else
-- 
2.41.0

Re: [PATCH] aarch64: Fix warnings during libgcc build

[Florian Weimer via Gcc-patches]

* Richard Earnshaw:

> On 11/07/2023 10:37, Florian Weimer via Gcc-patches wrote:
>> libgcc/
>>  * config/aarch64/aarch64-unwind.h
>> (aarch64_cie_signed_with_b_key):
>>  Add missing const qualifier.  Cast from const unsigned char *
>>  to const char *.  Use __builtin_strchr to avoid an implicit
>>  function declaration.
>>  * config/aarch64/linux-unwind.h (aarch64_fallback_frame_state):
>>  Add missing cast.
>> ---
>> diff --git a/libgcc/config/aarch64/linux-unwind.h 
>> b/libgcc/config/aarch64/linux-unwind.h
>> index 00eba866049..93da7a9537d 100644
>> --- a/libgcc/config/aarch64/linux-unwind.h
>> +++ b/libgcc/config/aarch64/linux-unwind.h
>> @@ -77,7 +77,7 @@ aarch64_fallback_frame_state (struct _Unwind_Context 
>> *context,
>>   }
>>   rt_ = context->cfa;
>> -  sc = _->uc.uc_mcontext;
>> +  sc = (struct sigcontext *) _->uc.uc_mcontext;
>> /* This define duplicates the definition in aarch64.md */
>>   #define SP_REGNUM 31
>> 
>
> This looks somewhat dubious.  I'm not particularly familiar with the
> kernel headers, but a quick look suggests an mcontext_t is nothing
> like a sigcontext_t.  So isn't the cast just papering over some more
> fundamental problem?

I agree it looks dubious.  Note that it's struct sigcontext, not
(not-struct) sigcontext_t.  I don't know why the uc_mcontext members
aren't accessed directly, so I can't really write a good comment about
it.

Obviously it works quite well as-is. 8-)  Similar code is present in
many, many Linux targets.

Thanks,
Florian

Re: m68k Coldfire and PC-relative addressing distances

[Florian Weimer via Gcc]

* Richard Biener:

> On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc  
> wrote:
>>
>> How does the Coldfire m68k subtarget and sure that displacements in PIC
>> code are within the addressable range?
>
> There is usually a branch shortening pass relying on correct
> instruction lengths.
>
> I suggest to file a bugreport with preprocessed sources as testcase.

Fair enough, I filed PR110627.

Thanks,
Florian

[PATCH] riscv: Fix -Wincompatible-pointer-types warning during libgcc build

[Florian Weimer via Gcc-patches]

libgcc/

* config/riscv/linux-unwind.h (riscv_fallback_frame_state): Add
missing cast.

---
 libgcc/config/riscv/linux-unwind.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/riscv/linux-unwind.h 
b/libgcc/config/riscv/linux-unwind.h
index 931c2f2795d..e58d0f4113e 100644
--- a/libgcc/config/riscv/linux-unwind.h
+++ b/libgcc/config/riscv/linux-unwind.h
@@ -64,7 +64,7 @@ riscv_fallback_frame_state (struct _Unwind_Context *context,
 return _URC_END_OF_STACK;
 
   rt_ = context->cfa;
-  sc = _->uc.uc_mcontext;
+  sc = (struct sigcontext *) _->uc.uc_mcontext;
 
   new_cfa = (_Unwind_Ptr) sc;
   fs->regs.cfa_how = CFA_REG_OFFSET;

[PATCH] or1k: Fix -Wincompatible-pointer-types warning during libgcc build

[Florian Weimer via Gcc-patches]

libgcc/

* config/or1k/linux-unwind.h (or1k_fallback_frame_state): Add
missing cast.

---
 libgcc/config/or1k/linux-unwind.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/or1k/linux-unwind.h 
b/libgcc/config/or1k/linux-unwind.h
index aa873791daa..37b0c5aef37 100644
--- a/libgcc/config/or1k/linux-unwind.h
+++ b/libgcc/config/or1k/linux-unwind.h
@@ -51,7 +51,7 @@ or1k_fallback_frame_state (struct _Unwind_Context *context,
 return _URC_END_OF_STACK;
 
   rt = context->cfa;
-  sc = >uc.uc_mcontext;
+  sc = (struct sigcontext *) >uc.uc_mcontext;
 
   new_cfa = sc->regs.gpr[1];
   fs->regs.cfa_how = CFA_REG_OFFSET;

[PATCH] arc: Fix -Wincompatible-pointer-types warning during libgcc build

[Florian Weimer via Gcc-patches]

libgcc/

* config/arc/linux-unwind.h (arc_fallback_frame_state): Add
missing cast.

---
 libgcc/config/arc/linux-unwind.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/arc/linux-unwind.h b/libgcc/config/arc/linux-unwind.h
index 0292e22ed1b..dec9428a7e5 100644
--- a/libgcc/config/arc/linux-unwind.h
+++ b/libgcc/config/arc/linux-unwind.h
@@ -100,7 +100,7 @@ arc_fallback_frame_state (struct _Unwind_Context *context,
   if (pc[0] == MOV_R8_139)
 {
   rt_ = context->cfa;
-  sc = _->uc.uc_mcontext;
+  sc = (struct sigcontext *) _->uc.uc_mcontext;
 }
   else
 return _URC_END_OF_STACK;

[PATCH] csky: Fix -Wincompatible-pointer-types warning during libgcc build

[Florian Weimer via Gcc-patches]

libgcc/

* config/csky/linux-unwind.h (csky_fallback_frame_state): Add
missing cast.

---
 libgcc/config/csky/linux-unwind.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/csky/linux-unwind.h 
b/libgcc/config/csky/linux-unwind.h
index 66b2a44e047..1acef215974 100644
--- a/libgcc/config/csky/linux-unwind.h
+++ b/libgcc/config/csky/linux-unwind.h
@@ -75,7 +75,7 @@ csky_fallback_frame_state (struct _Unwind_Context *context,
siginfo_t info;
ucontext_t uc;
   } *_rt = context->cfa;
-  sc = &(_rt->uc.uc_mcontext);
+  sc = (struct sigcontext *) &(_rt->uc.uc_mcontext);
 }
   else
 return _URC_END_OF_STACK;

[PATCH] m68k: Avoid implicit function declaration in libgcc

[Florian Weimer via Gcc-patches]

libgcc/

* config/m68k/fpgnulib.c (__cmpdf2): Declare.

---
 libgcc/config/m68k/fpgnulib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgcc/config/m68k/fpgnulib.c b/libgcc/config/m68k/fpgnulib.c
index fe41edf26aa..d5c3411e947 100644
--- a/libgcc/config/m68k/fpgnulib.c
+++ b/libgcc/config/m68k/fpgnulib.c
@@ -395,6 +395,7 @@ double __extendsfdf2 (float);
 float __truncdfsf2 (double);
 long __fixdfsi (double);
 long __fixsfsi (float);
+int __cmpdf2 (double, double);
 
 int
 __unordxf2(long double a, long double b)

[PATCH] aarch64: Fix warnings during libgcc build

[Florian Weimer via Gcc-patches]

libgcc/

* config/aarch64/aarch64-unwind.h (aarch64_cie_signed_with_b_key):
Add missing const qualifier.  Cast from const unsigned char *
to const char *.  Use __builtin_strchr to avoid an implicit
function declaration.
* config/aarch64/linux-unwind.h (aarch64_fallback_frame_state):
Add missing cast.

---
 libgcc/config/aarch64/aarch64-unwind.h | 4 ++--
 libgcc/config/aarch64/linux-unwind.h   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgcc/config/aarch64/aarch64-unwind.h 
b/libgcc/config/aarch64/aarch64-unwind.h
index 3ad2f8239ed..30e428862c4 100644
--- a/libgcc/config/aarch64/aarch64-unwind.h
+++ b/libgcc/config/aarch64/aarch64-unwind.h
@@ -40,8 +40,8 @@ aarch64_cie_signed_with_b_key (struct _Unwind_Context 
*context)
   const struct dwarf_cie *cie = get_cie (fde);
   if (cie != NULL)
{
- char *aug_str = cie->augmentation;
- return strchr (aug_str, 'B') == NULL ? 0 : 1;
+ const char *aug_str = (const char *) cie->augmentation;
+ return __builtin_strchr (aug_str, 'B') == NULL ? 0 : 1;
}
 }
   return 0;
diff --git a/libgcc/config/aarch64/linux-unwind.h 
b/libgcc/config/aarch64/linux-unwind.h
index 00eba866049..93da7a9537d 100644
--- a/libgcc/config/aarch64/linux-unwind.h
+++ b/libgcc/config/aarch64/linux-unwind.h
@@ -77,7 +77,7 @@ aarch64_fallback_frame_state (struct _Unwind_Context *context,
 }
 
   rt_ = context->cfa;
-  sc = _->uc.uc_mcontext;
+  sc = (struct sigcontext *) _->uc.uc_mcontext;
 
 /* This define duplicates the definition in aarch64.md */
 #define SP_REGNUM 31

m68k Coldfire and PC-relative addressing distances

[Florian Weimer via Gcc]

How does the Coldfire m68k subtarget and sure that displacements in PIC
code are within the addressable range?

We have a source file in glibc that fails at assembly because it
contains a branch that is out of range with -fpic.  The GAS error is:

…/iso-2022-jp.s: Fatal error: Tried to convert PC relative branch to absolute 
jump

(Not sure if this is actually a branch, the diagnostic isn't really
helpful.)

The -fPIC option does not help, and -fpic -mpcrel ICEs at the end of
m68k.cc:sched_attr_op_type.  The op variable at this point is:

(mem/u:HI (const:SI (plus:SI (symbol_ref:SI ("__jisx0212_to_ucs_idx") [flags 
0x40] )
(const_int 2 [0x2]))) [2 MEM[(const struct jisx0212_idx 
*)&__jisx0212_to_ucs_idx].end

The iso-2022-jp.c source file has some large data tables, so it's
probably not surprising that -fpic doesn't work.

Thanks,
Florian

[PATCH] libgcc: Fix -Wint-conversion warning in find_fde_tail

[Florian Weimer via Gcc-patches]

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
in find_fde_tail").

libgcc/

PR libgcc/110179
* unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
implicit conversion of pointer value to integer.

---
 libgcc/unwind-dw2-fde-dip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 4e0b880513f..28ea0e64e0e 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -403,7 +403,7 @@ find_fde_tail (_Unwind_Ptr pc,
 BFD ld generates.  */
   signed value __attribute__ ((mode (SI)));
   memcpy (, p, sizeof (value));
-  eh_frame = p + value;
+  eh_frame = (_Unwind_Ptr) (p + value);
   p += sizeof (value);
 }
   else

base-commit: 1f9b18962f2d86abafbb452bf001b72edafb6eef

Re: [RFC] Add stdckdint.h header for C23

[Florian Weimer via Gcc-patches]

* Paul Eggert:

> I don't see how you could implement __has_include_next()
> for arbitrary non-GCC compilers, which is what we'd need for glibc
> users.

This is not a requirement for glibc in general.  For example, 
only works with compilers to which it has been ported.

Thanks,
Florian

[PATCH] libgcc: Fix eh_frame fast path in find_fde_tail

[Florian Weimer via Gcc-patches]

The eh_frame value is only used by linear_search_fdes, not the binary
search directly in find_fde_tail, so the bug is not immediately
apparent with most programs.

Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc:
Special-case BFD ld unwind table encodings in find_fde_tail").

[I'd appreciate suggestions how I could add a test for this.  BFD ld
does not seem to allow ommitting the binary search table.]

libgcc/

PR libgcc/109712
* unwind-dw2-fde-dip.c (find_fde_tail): Correct fast path for
parsing eh_frame.

---
 libgcc/unwind-dw2-fde-dip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 6223f5f18a2..4e0b880513f 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -403,8 +403,8 @@ find_fde_tail (_Unwind_Ptr pc,
 BFD ld generates.  */
   signed value __attribute__ ((mode (SI)));
   memcpy (, p, sizeof (value));
+  eh_frame = p + value;
   p += sizeof (value);
-  dbase = value;   /* No adjustment because pcrel has base 0.  */
 }
   else
 p = read_encoded_value_with_base (hdr->eh_frame_ptr_enc,

base-commit: b327cbe8f4eefc91ee2bea49a1da7128adf30281

Re: End of subscription

[Florian Weimer via Gcc]

* Iain Sandoe:

>> On 24 May 2023, at 14:09, Paul Koning via Gcc  wrote:
>> Curious, because Mac OS mail does show it as a mailing list message, 
>> offering up an "unsubscribe" button.  So it looks like an iOS mail bug.
>
> for me, in macOS mail “it depends” - sometimes the posts are marked as
> from a list (with the unsubscribe button present), sometimes they are
> not; I wonder if that depends on the CC’s etc.

Gmail throws away incoming messages if it deems them substantially
similar to a message it has already stored.  So if the direct message
arrives first, your mail client won't be able to access the List-Id:
header because Gmail discarded the message that had it.  (This
limitation is present in the Gmail web interface, too.)

Thanks,
Florian

Re: Differences between clang and gcc handling of int[static n] function arguments

[Florian Weimer via Gcc]

* Jonathan Wakely:

> On Wed, 24 May 2023 at 10:06, Florian Weimer wrote:
>>
>> * Jonathan Wakely via Gcc:
>>
>> >> It seems it might even be trivial enough for me to investigate and
>> >> tackle myself, in some spare time.
>> >>
>> >> I see very little code using either of these features, so it's
>> >> definitely not a high priority task regardless.
>> >>
>> >
>> > Glibc uses the nonnull attribute in many places. Libstdc++ uses it in a few
>> > places.
>>
>> Note that the glibc uses are frequently incompatible with libstdc++
>
> Do you mean incompatible with libstdc++ specifically, or incompatible
> with "common C++ idioms"?

The latter (common C++ idioms as encouraged by the standard library).

>> (std::vector in particular).  Unfortunately, there is no consensus to
>> fix this.  For example, one issue is that
>>
>>   memset(vec.data(), 0, sizeof(decltype(vec)::value_type) * vec.size())
>>
>> isn't necessarily defined even for vectors of POD type.
>
> It's not really idiomatic C++ code anyway. Why would you write that,
> instead of:
>
> vec.assign(vec.size(), {});
> or:
> std::fill_n(vec.begin(), vec.size(), range_value_t:{});
> ?
>
> (The latter optimizes to the ideal code, but I think I know how to
> make the former optimize to the same thing.)

Well, one might be tempted to write that explicit memset to eliminate
the conditional branch, except that it's technically required because
data() might return nullptr. 8-/

Thanks,
Florian

Re: Differences between clang and gcc handling of int[static n] function arguments

[Florian Weimer via Gcc]

* Jonathan Wakely via Gcc:

>> It seems it might even be trivial enough for me to investigate and
>> tackle myself, in some spare time.
>>
>> I see very little code using either of these features, so it's
>> definitely not a high priority task regardless.
>>
>
> Glibc uses the nonnull attribute in many places. Libstdc++ uses it in a few
> places.

Note that the glibc uses are frequently incompatible with libstdc++
(std::vector in particular).  Unfortunately, there is no consensus to
fix this.  For example, one issue is that

  memset(vec.data(), 0, sizeof(decltype(vec)::value_type) * vec.size())

isn't necessarily defined even for vectors of POD type.

Thanks,
Florian

Re: End of subscription

[Florian Weimer via Gcc]

* Jonathan Wakely via Gcc:

> Unfortunately even the Gmail web UI doesn't offer an unsubscribe
> option, despite knowing the mails come from a list and showing:
>
> mailing list: gcc@gcc.gnu.org Filter messages from this mailing list

It does for me, under the ⏷ menu at the end of the recipient list in the
message pane.  Be sure that you select a message copy that you actually
received through the mailing list.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Jason Merrill:

> As a compromise, it should be possible to error by default only in
> cases where the implicit int (including as a return value) is either
> the source or target of a non-value-preserving conversion, as those
> are very likely to be bugs.  That seems desirable for both camps.

Not sure, malloc returning 31-bit pointers goes a long way towards
maintaining int/pointer compatibility for 64-bit systems, too.  People
might actually have a working implicit-declared malloc on 64-bit today,
and still argue against the changes.

> A simpler change to catch this particular bug would be to make
> -Wint-conversion an error by default iff the sizes differ.

That doesn't address other bugs around implicitly-declared functions,
such as the bool/int ABI incompatibility, or the lack of type checking
for arguments.  I don't see those programmer mistakes because I think
it's easier to debug them on your own: swapped arguments are visible in
the source code, and GDB probably gives you enough data as well.  So I
suspect that people figure this out on their own.  They are still
wasting time on this, but probably somewhat less.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Jakub Jelinek:

> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
>> 
>> On Tue, 16 May 2023, Florian Weimer wrote:
>> 
>> > > (FWIW: no, this should not be an error, a warning is fine, and I 
>> > > actually 
>> > > think the current state of it not being in Wall is the right thing as 
>> > > well)
>> 
>> (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
>> 
>> > I don't understand why we do not warn by default and warn with -Wall.  I
>> > would expect this to be either a documented extension (no warning with
>> > -Wall), or a warning by default (because it's a conformance issue).  Is
>> > there any conformance issue that is treated in the same way?
>> 
>> Another one is -Wpointer-arith (pointer arithmetic on 'void *').
>
> That is a documented GNU extension, so we shouldn't increase severity of
> the diagnostics from the current state.

Right, it's also widely used, and harmless for void *.  For function
pointers, it's much more dubious, and not meaningful at all for some
targets.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Michael Matz:

> Hello,
>
> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> * Alexander Monakov:
>> 
>> > This is not valid (constraint violation):
>> >
>> >   unsigned x;
>> >
>> >   int *p = 
>> >
>> > In GCC this is diagnosed under -Wpointer-sign:
>> >
>> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
>> 
>> Thanks for the reference.  I filed:
>> 
>>   -Wpointer-sign must be enabled by default
>>   
>
> Can you please not extend the scope of your proposals in this thread but 
> create a new one?

I understood Joseph as asking for exploring a broadened scope, so I
looked into that.

> (FWIW: no, this should not be an error, a warning is fine, and I actually 
> think the current state of it not being in Wall is the right thing as 
> well)

I don't understand why we do not warn by default and warn with -Wall.  I
would expect this to be either a documented extension (no warning with
-Wall), or a warning by default (because it's a conformance issue).  Is
there any conformance issue that is treated in the same way?

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Eric Gallager via Gcc:

> I support this plan for using -Werror= and having it be split based on
> whether -std= is set to a strict ANSI option or a GNU option; is there
> a way to do that in the optfiles, or would it have to be handled at
> the specs level instead?

This isn't going to work well because -std=c17 (for example) disables
_DEFAULT_SOURCE for glibc, so lots of declarations go missing from the
glibc header files.  I don't see why these things should be tied
together because as I see it, this is not about standards conformance
(warnings make GCC conforming already), but programmer convenience.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Thomas Koenig via Gcc:

> So... using an error message as a crowbar to change people's behavior
> failed, at least partially.  And you only hear from the people who
> complain, not from those who are glad that they found errors that they
> would otherwise have missed.

Thank you for sharing the Fortran perspective.  I think the C changes
are a bit different.  Most of these fixes are of a localized nature, and
there is always an ugly escape hatch for missing function declarations
(write a prototype declaration right next to the call site).  Most
packages we fixed required a small number of changes, and where
maintainers reacted, they weren't opposed to making the changes (maybe
with one exception).  These changes do not create an ongoing maintenance
burden.

Admittedly, there are some packages where the sheer number of issues
makes patchings things up difficult, or the state (and presumed lack of
use) of a program may make creating patches look like a waste of time.
But in the Fedora corpus, these cases are quite rare.  Popular packages
for which we do not have a migration story yet are ksh, procmail, unzip,
zip.  For the latter three, part of the problem is that it's not clear
to what extent legacy systems (pre-C89, maybe even pre-K, without
 or ) still need to be supported.  These cases are
the exception, though.  In those cases, there could be a strong
incentive to make as few changes as possible (so telling the compiler to
keep accepting these obsolete constructs).

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Richard Biener:

> On Wed, May 10, 2023 at 10:05 AM Jonathan Wakely via Gcc
>  wrote:
>>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>>
>> >
>> > And then people will start complaining about GCC unnecessarily
>> > erroring out, which is a compiler bug, since there's no problem
>> > producing correct code in these cases.
>> >
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>>
>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> void foo(__UINTPTR_TYPE__);
> void bar() { foo("42"); }
>
> might be something we'd still like to diagnose but eventually not turn
> into an error?  Yes, it then depends on the target whether the code is
> accepted or not, but at least it would continue working where there's
> a "good" answer to your question.

The x86-64 defaults for GNU/Linux were originally set in such a way that
there is a good chance that pointers fit into an int, and broken code
like that happens to work (as long as it's in the main program).  Of
course I think we should nevertheless reject it by default.

Anyway, if int-conversion somehow proves more controversial, I believe
disabling implicit-int and implicit-function-declaration by default
would still be a huge step forward.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Eli Zaretskii via Gcc:

>> Date: Tue, 9 May 2023 21:07:07 +0200
>> From: Jakub Jelinek 
>> Cc: Jonathan Wakely , ar...@aarsen.me, gcc@gcc.gnu.org
>> 
>> On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
>> > People who ignore warnings will use options that disable these new
>> > errors, exactly as they disable warnings.  So we will end up not
>> 
>> Some subset of them will surely do that.  But I think most people will just
>> fix the code when they see hard errors, rather than trying to work around
>> them.
>
> The same logic should work for warnings.  That's why we have warnings,
> no?

People completely miss the warning and go to great lengths to show that
what they are dealing is a compiler bug.  (I tried to elaborate on that
in <87cz394b63@oldenburg.str.redhat.com>.)  If GCC errors out, that
simply does not happen because there is no object code to examine.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* David Edelsohn:

> Yes, GCC has two, distinct user groups / use cases, but GCC also has a
> very unique and crucial role, as the foundation for a large portion of
> the GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.

I tried to explain that in my introductory comments, but perhaps that
was a bit too abstract.

Here are some examples of the stuff I personally deal with in this space
on a semi-regular basis.

* alleged code generation bugs because the upper 32 bits of a pointer
  are set to zero or 0x, resulting in crashes.  This can happen
  if GCC synthesizes an implicit int declaration for a pointer-returning
  function.

* Alleged code generation bugs because a function returning bool does
  not set the entire register, as expected the caller.  This can happen
  if GCC makes up a function declaration returning int for a function
  that actually returns bool on x86-64.

* Making source-only API transitions away from a particular function is
  surprisingly hard if you still want to provide binary compatibility,
  and not put ugliness like

#define function_api_v1(arg0, arg1, arg2) \
  DO NOT CALL THIS, USE function_api_v2 instead

  into installed header files (or rely on GCC extensions such as the
  poison pragma).

* Incomplete ports of C extensions to newer Python and Ruby versions
  which still compile and link, but fail at some point during run time
  because they try to call functions that do not exist.  (BIND_NOW
  mitigates that to some extend, but that's mostly a downstream thing.)

These are just a subset of the issues that are escalated to me, and I
don't even work on the compiler for real.  I don't know how much of that
ends up with the real compiler developers, or in how many cases
programmers eventually debug the issue on their own, finally spot the
warning in the build log, and make the connection.

Nowadays I ask for full build logs before I look at anything else, and
given the way we build our applications, we usually have that, so that
is a convenient shortcut.  (For others, it will be buried in some IDE,
and all you can get from them are screenshots.)  But if application
developers poked at the problem with GDB to the point that they can
share disassembly they think that shows a compiler bug, they must have
spent quite some time on it.  If GCC had different defaults, they
wouldn't have to do that, increasing their productivity.

I hope this makes things clearer.  I do think the current GCC defaults
are needlessly frustrating, which is why I spent so much time on proving
(from my perspective) that it should be feasible to change them.

> GCC needs to be proactive, not reactive, without annoying and
> frustrating its user base.  Clang has been making some aggressive
> changes in warnings, but its constituency expects that.  Developers
> who want that experience already will use Clang, so why annoy
> developers who prefer the GCC experience and behavior?

I really would like to keep GCC as the system compiler, but avoid the
hidden costs of the current GCC defaults.

We can get fairly close by injecting appropriate -Werror= options during
the distribution build.  On the other hand, we are already up to about
fifteen recommended compiler flags.  We are looking at adding between
two and four additional -Werror= flags for this.  The optics aren't
great.  In our case, ISVs who do not do RPM builds would have to
replicate and maintain this flag list in their own build environments
because they wouldn't benefit from the distribution default flags.  I'm
worried all this looks rather unprofessional.

> The new warnings and errors help some developers and improve software
> security, but also drive some developers away, or at least cause them
> to reass their choice of toolchain.

That goes in the other direction as well, I think.  Developers are
pressured to use languages which are generally perceived to offer more
type safety.  Here we have a few cases where we could increase the type
safety of C, without having to switch to a completely different
language.

I don't think C is as static as used to be, by the way.  C2X (and glibc
before that, especially with _GNU_SOURCE) is adding lots of widely-used
identifiers to existing headers, so that will cause some breakage, too.
The C2X changes seem to conflict with keeping GCC as the 90s C compiler
(at least by default).

And g++ regularly fixes language and header conformance issues as bugs,
not treating them as perpetually supported extensions.  The resulting
churn does not seem to have hurt adoption of C++ or g++.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Sam James:

> Florian Weimer  writes:
>
>> * Richard Biener:
>>
>>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>>>> 
>>>> TL;DR: This message is about turning implicit-int,
>>>> implicit-function-declaration, and possibly int-conversion into errors
>>>> for GCC 14.
>>>
>>> I suppose the goal is to not need to rely on altering CFLAGS but
>>> change the default behavior with still being able to undo this using
>>> -Wno-error= or -Wno-?
>>
>> That's what Clang does (and the defaults chang along with -std=
>> settings). To me, -Werror by default for some warnings seems rather
>> hackish.  But that's just my personal preference, I do not have a strong
>> objection to doing it that way.
>
> Not that we have to follow Clang, but deviating by adding -fpermissive
> (which is a GCC-only flag) for C may not be desirable, and following
> Clang would let people use the same method for silencing known-bad
> codebases for now.

I think Clang already accepts -fpermissive, so it's not *too* bad?
(Presumably it just ignores it.)

>> One downside with -Wno- is that some developers jump on this rather
>> quickly instead of fixing the real problem.  So far, I've seen this in
>> both Chromium and the kernel, in fringe areas admittedly, but still.
>> The advantage is that there is a familiar workaround to get things
>> compiling quickly again, of course.
>
> I've not seen very much of this so far, FWIW. Only for the more annoying
> C23 warnings which have well-documented problems (and unrelated to this,
> so I won't go on about it anymore).

I think this could be a side effect of our different testing strategies.
The kernel -Wno-implicit-function-declaration change looks like it was
specifically added to build with Clang 15/16.

> But -fpermissive does have a nice property in that it's immediately
> obvious you're doing something *terrible* if you use it.

Right.

> In addition to this, this made me realise something similar to what
> Florian was saying wrt whitespace. Passing -Wno-error=... doesn't
> always work with some poorly-written build scripts because they split
> on '=' (this happens with some CMake when poorly written).

Hmm, maybe I've seen this as well but attributed it to whitespace.
The -std=gnu89 approach would run into problems with this, too.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Richard Biener:

>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>> 
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>
> I suppose the goal is to not need to rely on altering CFLAGS but
> change the default behavior with still being able to undo this using
> -Wno-error= or -Wno-?

That's what Clang does (and the defaults chang along with -std=
settings). To me, -Werror by default for some warnings seems rather
hackish.  But that's just my personal preference, I do not have a strong
objection to doing it that way.

One downside with -Wno- is that some developers jump on this rather
quickly instead of fixing the real problem.  So far, I've seen this in
both Chromium and the kernel, in fringe areas admittedly, but still.
The advantage is that there is a familiar workaround to get things
compiling quickly again, of course.

> I think instead of hard-coding a set of changes would it be possible
> to alter the default setting of diagnostic options during GCC
> configuration?  And maybe even note that when diagnosing?

I'd be worried about our package maintainers if we do something like
that.  We'd like them to report build failures upstream, and if it's
just one or two distributions doing that and not GCC upstream, well, I
guess we just got a preview of how some upstreams are going to react.
Package maintainers tend to be volunteer or junior engineering roles, I
think, so this doesn't seem fair to me.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Richard Biener:

> > Am 09.05.2023 um 18:13 schrieb David Edelsohn :
> >
> > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc  
> > wrote:
> >
> > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> > > 
> > > 
> > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
> > > > 
> > > > TL;DR: This message is about turning implicit-int,
> > > > implicit-function-declaration, and possibly int-conversion into errors
> > > > for GCC 14.
> > > 
> > > I suppose the goal is to not need to rely on altering CFLAGS but
> > > change the default behavior with still being able to undo this
> > > using -Wno-error= or -Wno-?
> >
> > Can't people just compile C89/K code with -std=c89/-std=gnu89 and not get
> > these errors that way?
> >
> > As Florian mentioned:
> >
> > "Presently, we
> > cannot use -std=gnu89 etc. to opt out because there are packages which
> > require both C89-only language features and C99-style inlining, which is
> > currently not a combination supported by GCC (but maybe that could be
> > changed). "
>
> But surely it would reduce the number of packages to fix?  So I
> support both having only C99 and up reject no longer valid code _and_
> having -fpermissive be forgiving (demoting errors to warnings).

It makes sense to disable the new erros in C89 mode.  It's what I did in
the instrumented compiler.  It also gives you yet another way to disable
the errors, using CC=c89, which works for some packages that do not
honor CFLAGS and do not support whitespace in CC.

The part David quoted above is about this:

$ gcc -fno-gnu89-inline -std=gnu89 t.c
cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode

And some packages need -fno-gnu89-inline, but also rely on implicit ints
and implicit function declarations heavily.  With a purely C89-based
opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
compile these self-contradictory programs.  Hence the idea of
-fpermissive, in addition to the -std=gnu89 escape hatch.

But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
remaining reason for -fpermissive would be a flag that is accepted by
both gcc and g++, in case a package build system passes CFLAGS to g++ as
well, which sometimes happens.  And -fno-gnu89-inline is currently not
accepted by g++.  But in the Fedora package set, this (some C++ and a
C89 requirement) must be exceedingly rare because it's a subset of the
already tiny set of -fno-gnu89-inline -std=gnu89 packages.

Thanks,
Florian

More C type errors by default for GCC 14

[Florian Weimer via Gcc]

TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.

A few of you might remember that I've been looking into turning some
type errors from warnings into errors by default.  Mainly I've been
looking at implicit function declarations because in too many cases, the
synthesized declaration does not match the prototype used at function
definition and can cause subtle ABI issues.

To recap, the main challenge is that GCC has to serve disparate groups
of users: some use GCC for writing programs themselves, but others just
need GCC to build sources that they have obtained from somewhere.  The
first group benefits from more type errors because they catch errors
earlier during development (experience shows that compiler warnings are
easy to miss in a long build log).  The second group might find these
errors challenging because the sources they have no longer build.

To see how large the impact is on that second group, we've mostly
removed implicit function declarations and implicit ints from Fedora:

  
  

Roughly 870 packages out of ~14,500 that have GCC present during the
build needed fixing (or flagging that they can't be built with the
additional errors), so 6%.  Most of the changes are mechanical in
nature, like adding additional headers to configure checks.  For about
~150 packages, automated patching could be used to rewrite problematic
built-in checks generated by long-obsolete autoconf versions.

Some of these changes prevent the compiler behavior for altering the
build results silently because the new errors changed the outcome of
autoconf checks.  (We had one of those in libstdc++, changing the ABI on
GNU/Linux because futex support oculd no longer be detected.)
Unfortunately, I did not record numbers about them, but think those were
quite rare; most autoconf problems were also accompanied with other
problems, or the incorrect results from autoconf led to build failures
later.  So it seems to me that the risk that the second group mentioned
above would silently get unexpected build results is fairly low.

Where possible, we tried to upstream patches, to simplify sharing across
distributions and to help those who compile upstream sources directly.
We also benefited from other distributions upstreaming changes along
similar lines (notably Gentoo for their Clang 16 project, but also from
Homebrew to a lesser extent).

An area we started exploring only recently for Fedora is implicit
conversions between integers and pointers (covered by -Wint-conversion).
These add another ~170 packages, but some of those are false positives
(due to our instrumented compiler approach) that do not change the build
outcome at all.  I'm still negotiating whether we have the capacity to
develop fixes for these packages proactively.

I brought up the matter with distributions, and the feedback was neutral
(not overly negative, as in “this would be the end of the world for
us”).

  
  
  


(I tried to contact Arch, but my message didn't make it past the
moderators, it seems.)

All in all, the whole situation is not great, but it still seems
manageable to me.

Anyway, thanks for reading this far.

I would like to suggest to turn implicit-int,
implicit-function-declaration, and possibly int-conversion from warnings
into errors for GCC 14.  This would give upstream projects roughly
another year to make new releases with compatibility fixes that have
been contributed so far.  I do not think waiting longer, until GCC 15,
would make a meaningful difference because any upstream project that
does not release within the next 12 months is not likely to release in
the next 24 months, either.

Regarding mechanics of the necessary opt out facility, Clang used
-Werror=… by default, but that seems a bit hackish to me.  Presently, we
cannot use -std=gnu89 etc. to opt out because there are packages which
require both C89-only language features and C99-style inlining, which is
currently not a combination supported by GCC (but maybe that could be
changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
separate, and a flag approach that works for C and C++ without
introducing any new warnings would be most convenient.  So maybe we
could use -fpermissive for C as well.

One fairly big GCC-internal task is to clear up the C test suite so that
it passes with the new compiler defaults.  I already have an offer of
help for that, so I think we can complete this work in a reasonable time
frame.

I have no data how big the compatibility impact of turning

Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Florian Weimer via Gcc-bugs]

* Puneet Kumar Yatnal via Gcc-bugs:

> What is next step here? How do I post this in Bugzilla and get
> support.

This issue has already been fixed with this commit:

commit 80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely 
Date:   Tue Nov 9 23:45:36 2021 +

libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

Since Glibc 2.34 all pthreads symbols are defined directly in libc not
libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
avoid unnecessary locking in single-threaded programs. This means there
is no reason to avoid linking to libpthread now, and so no reason to use
weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

libstdc++-v3/ChangeLog:

PR libstdc++/100748
PR libstdc++/103133
* config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
Define for glibc 2.34 and later.

It's been backported to GCC 10, but not GCC 9.  Backporting to 9
requires some messaging to get into 9 which lacks commit
b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined
__gthread_self weak symbol [PR 95989]").

Thanks,
Florian

Re: [libstdc++] use strtold for from_chars even without locale

[Florian Weimer via Gcc-patches]

* Jonathan Wakely via Libstdc:

> We could use strtod for a single-threaded target (i.e.
> !defined(_GLIBCXX_HAS_GTHREADS) by changing the global locale using
> setlocale, instead of changing the per-thread locale using uselocale.

This is not generally safe because the call to setlocale is still
observable to applications in principle because a previous pointer
returned from setlocale they have store could be invalidated.

Thanks,
Florian

Re: Probe emission in fstack-clash-protection

[Florian Weimer via Gcc]

* Varun Kumar E. via Gcc:

> Hello,
>
> https://godbolt.org/z/P3M8s8jqh
> The above case shows that gcc first decreases the stack pointer and then
> probes.
>
> As mentioned by Jeff Law (reference
> )
> under "More issues with -fstack-check". If an asynchronous signal is
> received between the decrement of stack pointer and probing of the pages.
> *"In that case, the stack pointer could be pointing beyond the guard into
> the heap. The signal arrives and the kernel transfers control to the
> registered signal handler. That signal handler is then running while its
> stack is pointing into the heap. Thus, the attacker has clashed the stack
> and heap, and there's a reasonable chance they can gain control over the
> program" *
>
> So, Shouldn't we first probe and if successful only then update the stack
> pointer? Or Maybe I have understood it incorrectly.

Let me rephrase a bit.  The caller has asserted that (%rsp) is valid
upon entry to the function because that's where the return address is
stored.  That means that (%rsp - 4096) is still in the guard page, so
the subsequent probe works.  But the kernel fault handler will not write
to that location because it has to protect the return address and the
red zone, so the first location used is (%rsp - 4096 - 8 - 128) or
thereabouts.

Jeff, this looks like a real bug to me.  It doesn't affect the main
thread on GNU/Linux because the kernel uses more than one page for the
guard area.  However, glibc uses exactly one page.  We could change that
to two pages on x86-64 at least without ill effects, I believe.  Or fix
GCC's probing to account for the red zone.

Thanks,
Florian

[PATCH] libstdc++: Mention recent libgcc_s symbol versions in manual

[Florian Weimer via Gcc-patches]

GCC_11.0 is an aarch64-specific outlier.

* doc/xml/manual/abi.xml (abi.versioning.history): Add
GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for
libgcc_s.

---
 libstdc++-v3/doc/xml/manual/abi.xml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libstdc++-v3/doc/xml/manual/abi.xml 
b/libstdc++-v3/doc/xml/manual/abi.xml
index 3a3cbd3346c..e0e241de3bd 100644
--- a/libstdc++-v3/doc/xml/manual/abi.xml
+++ b/libstdc++-v3/doc/xml/manual/abi.xml
@@ -203,6 +203,11 @@ compatible.
 GCC 4.6.0: GCC_4.6.0
 GCC 4.7.0: GCC_4.7.0
 GCC 4.8.0: GCC_4.8.0
+GCC 7.1.0: GCC_7.0.0
+GCC 9.1.0: GCC_9.0.0
+GCC 11.1.0: GCC_11.0
+GCC 12.1.0: GCC_12.0.0
+GCC 13.1.0: GCC_13.0.0
 
 
 

base-commit: 0c77a0909456034d34036aa22a8dfcf0258cfa2d

Re: GCC/Clang attributes guiding warnings about unused entities

[Florian Weimer via Gcc]

* Stephan Bergmann via Gcc:

> [cross-posting this to both the GCC and Clang communities]

I don't see your post here:

  


I don't think this is expected to work from a Discourse point of view.

> * __attribute__((unused)) behaves mostly the same as [[maybe_unused]].
>
> The one difference is that __attribute__((unused)) applied to a type
> does not warn about that type being unused, but rather warns about
> unreferenced variables of that type.  And it appears that both GCC and
> Clang implement [[maybe_unused]] with the same semantics as
> __attribute__((unused)), and cause [[maybe_unused]] applied to a type
> to warn about unreferenced variables of that type.  The mailing list
> thread starting at
> 
> "[[maybe_unused]] classes" discussed this, and argues that those
> special semantics of __attribute__((unused)) and [[maybe_unused]]
> applied to a type are not actually useful:  The GCC documentation
> cites as a use case "lock or thread classes, which are usually defined
> and then not referenced, but contain constructors and destructors that
> have nontrivial bookkeeping functions".  But the presence of those
> non-trivial con-/destructors will already prevent the compiler from
> emitting warnings about seemingly unused variables of such types.  So
> applying __attribute__((unused)) to such types looks like it does not
> bring any additional value.  Or what do other people think?

Not sure if I quite understand this.  If the attribute cannot be used to
mark (indirectly) variables of type (say) std::string as worthy of
warnings if they are unused, I think these special cases are not useful.

The assumption might be that compilers need to suppress warnings for
RAII guard variables, but GCC does not warn for them anyway.  This is
discussed occasionally, and the assumption is that such warnings would
not be useful.

> * __attribute__((warn_unused_result)) (which can only be applied to
>   functions) behaves the same as [[nodiscard]] applied to functions.

This is not entirely accurate because warn_unused_result is much harder
to suppress at the call site (at least in GCC).

> * __attribute__((warn_unused)) (which can be applied to class types)
>   is meant to allow warnings about unreferenced variables of the given
>   type, where the compiler could otherwise not infer that those
>   variables are truely unused (because the type has non-trivial
>   con-/destructors). (This attribute does not have a standard
>  counterpart.)
>
> Similarly to how [[nodiscard]] can be applied to individual
> constructors, it looks beneficial to me to allow
> __attribute__((warn_unused)) to be applied to individual constructors,
> too.  One example use case is a RAII class that has one constructor
> that does not acquire a resource (often the default constructor) and
> another constructor that does acquire a resource.  So the class itself
> cannot be marked __attribute__((warn_unused)).  But if the
> non-acquiring constructor could individually be marked
> __attribute__((warn_unused)), the compiler could warn about
> unreferenced variables that are initialized via that constructor.
>  "Allow
> `__attribute__((warn_unused))` on individual constructors" would
> implement that for Clang---but was met with some reservation for now,
> due to the already somewhat confusing landscape of standard and
> GCC/Clang-specific attributes guiding warnings about unused entities
> as outlined in this post.  What do other people think about it?  Would
> it be something that GCC would also want to implement?

How does this interact with deriving warn_unused for std::vector if T
is warn_unused?  That seems like a useful feature, and appears to
require that this is a type property, not a constructor property.

And maybe there is a trend to use constructor functions for these guard
variables and auto?  So

  auto g = make_guard(obj);

instead of:

  guard g(obj);

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Gcc-patches]

* Martin Liška:

> On 4/26/23 20:31, Florian Weimer wrote:
>> * Martin Liška:
>> 
>>> On 11/15/22 16:47, Martin Liška wrote:
 Hi.

 I've just pushed libsanitizer update that was tested on x86_64-linux and 
 ppc64le-linux systems.
 Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
 abidiff.
>>>
>>> Hello.
>>>
>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>> 
>> So … we have the issue that involves interceptors outside of libc.so.6,
>> namely crypt, crypt_r, and I posted an upstream patch for this:
>> 
>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>   
>> 
>> Can we just apply this downstream for now?  It blocks various folks from
>> using the sanitizers in their projects.
>
> Hello.
>
> Your upstream revision has been already accepted, so please apply it
> and I'm going to do one more merge from upstream in the following
> days. Does it work for you?

It's moving in a different direction now: 

But that's okay for me as well.

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Gcc]

* Martin Liška:

> On 4/26/23 20:31, Florian Weimer wrote:
>> * Martin Liška:
>> 
>>> On 11/15/22 16:47, Martin Liška wrote:
 Hi.

 I've just pushed libsanitizer update that was tested on x86_64-linux and 
 ppc64le-linux systems.
 Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
 abidiff.
>>>
>>> Hello.
>>>
>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>> 
>> So … we have the issue that involves interceptors outside of libc.so.6,
>> namely crypt, crypt_r, and I posted an upstream patch for this:
>> 
>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>   
>> 
>> Can we just apply this downstream for now?  It blocks various folks from
>> using the sanitizers in their projects.
>
> Hello.
>
> Your upstream revision has been already accepted, so please apply it
> and I'm going to do one more merge from upstream in the following
> days. Does it work for you?

It's moving in a different direction now: 

But that's okay for me as well.

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Gcc-patches]

* Martin Liška:

> On 11/15/22 16:47, Martin Liška wrote:
>> Hi.
>> 
>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>> ppc64le-linux systems.
>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>> abidiff.
>
> Hello.
>
> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.

So … we have the issue that involves interceptors outside of libc.so.6,
namely crypt, crypt_r, and I posted an upstream patch for this:

  sanitizers: Disable crypt, crypt_r interceptors for glibc
  

Can we just apply this downstream for now?  It blocks various folks from
using the sanitizers in their projects.

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Gcc]

* Martin Liška:

> On 11/15/22 16:47, Martin Liška wrote:
>> Hi.
>> 
>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>> ppc64le-linux systems.
>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>> abidiff.
>
> Hello.
>
> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.

So … we have the issue that involves interceptors outside of libc.so.6,
namely crypt, crypt_r, and I posted an upstream patch for this:

  sanitizers: Disable crypt, crypt_r interceptors for glibc
  

Can we just apply this downstream for now?  It blocks various folks from
using the sanitizers in their projects.

Thanks,
Florian

Re: Using __gnu_lto_slim to detect -fno-fat-lto-objects

[Florian Weimer via Gcc]

* Richard Biener:

> On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc  
> wrote:
>>
>> Can we use the COMMON symbol __gnu_lto_slim to detect
>> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
>> plugin)?
>
> Yes.

Great, thanks.

>> We currently build the distribution with -ffat-lto-objects, and I want
>> to switch away from that.  Packages will need to opt in to
>> -ffat-lto-objects if static objects they build escape the buildroot.
>> And to make sure that this opt-in happens, I want to fail the build if
>> there would be any -fno-fat-lto-objects objects leaking.
>
> For SUSE we're checking that no LTO bytecode leaks instead, thus we check
> for __gnu_lto_v? (I think).  The reason is that even for static libraries
> we do not want to ship LTO bytecode.

We build with -ffat-lto-objects, and this means we can create perfectly
fine object files by stripping the LTO data:

<https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-strip-lto>

This means that so far, we only had to fix LTO compilation problems in
the packages, but not teach individual packages about LTO and non-LTO
object files.  Of course it's wasteful because few packages actually
install the object files (without a final link into a program or shared
object), and that's what I want to fix.

Florian

Using __gnu_lto_slim to detect -fno-fat-lto-objects

[Florian Weimer via Gcc]

Can we use the COMMON symbol __gnu_lto_slim to detect
-fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
plugin)?

We currently build the distribution with -ffat-lto-objects, and I want
to switch away from that.  Packages will need to opt in to
-ffat-lto-objects if static objects they build escape the buildroot.
And to make sure that this opt-in happens, I want to fail the build if
there would be any -fno-fat-lto-objects objects leaking.

Thanks,
Florian

Re: libquadmath, glibc, and the Q format flag

[Florian Weimer via Gcc]

* Jakub Jelinek:

> On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
>> I recently discovered that libquadmath registers custom printf callbacks
>> on load.  As far as I can tell, this is done so that the Q format flag
>> can be used to print floating point numbers, using format strings such
>> as "%Qf".  To enable Q flag processing, libquadmath has to register
>> replacements for all floating point format specifiers (aAeEfFgG).
>> 
>> Unfortunately, this has the side effect that even with out the Q flag,
>> printing any floating point number enters a generic, slow path in glibc,
>> prior to the number formatting itself.  The effect is quite pronounced.
>> For example this admittedly silly benchmarking script
>> 
>> for i=1,500 do
>> print(i, i * math.pi)
>> end
>> 
>> runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
>> system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
>> seconds.
>> 
>> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
>> depends on libquadmath.
>
> Not anymore.
> If GCC is configured against new enough glibc (with _Float128 support)
> libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
> is added only --as-needed to ld command line, so if all the Fortran object
> files that need real(kind=16) (or quad complex) are built by such configured
> GCC, -lquadmath is not linked in (just needs to be present).

Hmm, I missed that recent change.

Would it make sense to drop the libgfortran RPM dependency on
libquadmath in Fedora rawhide?

> And, even for C, users can just use the standard glibc _Float128 support
> (if they don't mind strfromf128) if they target new enough glibc.
> So, libquadmath should be left over for non-glibc uses or uses with old
> glibc.
>
>> Would it make sense to transplant the implementation of the Q specifier
>> from libquadmath to glibc, and disable the registration code in
>> libquadmath if glibc is recent enough?  At least for the targets that
>> today have float128 support in glibc?
>
> Thus I'm not sure it is worth it.

Yeah, if most implicit libquadmath uses are history, then it's probably
not going to be needed (unless some standard suggests to use the Q
flag).

Thanks,
Florian

libquadmath, glibc, and the Q format flag

[Florian Weimer via Gcc]

I recently discovered that libquadmath registers custom printf callbacks
on load.  As far as I can tell, this is done so that the Q format flag
can be used to print floating point numbers, using format strings such
as "%Qf".  To enable Q flag processing, libquadmath has to register
replacements for all floating point format specifiers (aAeEfFgG).

Unfortunately, this has the side effect that even with out the Q flag,
printing any floating point number enters a generic, slow path in glibc,
prior to the number formatting itself.  The effect is quite pronounced.
For example this admittedly silly benchmarking script

for i=1,500 do
print(i, i * math.pi)
end

runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
seconds.

This impacts most (all?) Fortran code on GNU/Linux because libgfortran
depends on libquadmath.

Would it make sense to transplant the implementation of the Q specifier
from libquadmath to glibc, and disable the registration code in
libquadmath if glibc is recent enough?  At least for the targets that
today have float128 support in glibc?

Thanks,
Florian

Re: [PATCH] Various fixes for DWARF register size computation

[Florian Weimer via Gcc-patches]

* Jakub Jelinek:

> On Tue, Jan 03, 2023 at 12:15:23PM +0100, Florian Weimer wrote:
>> --- a/gcc/debug.h
>> +++ b/gcc/debug.h
>> @@ -245,7 +245,18 @@ extern const struct gcc_debug_hooks vmsdbg_debug_hooks;
>>  
>>  /* Dwarf2 frame information.  */
>>  
>> -extern int dwarf_reg_sizes_constant ();
>> +/* Query size information about DWARF registers.  */
>> +struct dwarf_single_register_size
>> +{
>> +  dwarf_single_register_size();
>
> Formatting, space before (
>
>> @@ -334,27 +333,39 @@ generate_dwarf_reg_sizes (poly_uint16 *sizes)
>>  targetm.init_dwarf_reg_sizes_extra (sizes);
>>  }
>>  
>> -/* Return 0 if the DWARF register sizes are not constant, otherwise
>> -   return the size constant.  */
>> -
>> -int
>> -dwarf_reg_sizes_constant ()
>> +dwarf_single_register_size::dwarf_single_register_size()
>
> Likewise.
>
>> +  for (int i = DWARF_FRAME_REGISTERS; i >= 0; --i)
>> +{
>> +  unsigned short value;
>> +  if (!sizes[i].is_constant () || value != 0)
>
> if (!known_eq (sizes[i], 0))
> ?

Right.

> Though, I still wonder, because all of this is a hack for a single target
> - x86_64-linux -m64 - I think no other target has similar constant
> sizes,

Really?  That's odd.

Is it because other architectures track callee-saved vector registers
through unwinding?

> whether
> it wouldn't be better to revert all this compiler side stuff and handle it
> purely on the libgcc side - allow target headers to specify a simple
> expression how to compute dwarf_reg_size + don't define dwarf_reg_size_table
> array in that case and instead in a testcase verify that
> __builtin_init_dwarf_reg_size_table initializes an array to the exact same
> values as the libgcc/config/**/*.h overridden dwarf_reg_size version.
> That way, for x86_64-linux we can use
> ((index) <= __LIBGCC_DWARF_FRAME_REGISTERS__ ? 8 : 0)
> but could provide something reasonable even for other targets if it improves
> the unwinder sufficiently.
> Say s390x-linux -m64 is
> ((index) <= 32 ? 8 : (index) == 33 ? 4 : 0)
> etc.

> Or, if you want to do it on the compiler side, instead of predefining
> __LIBGCC_DWARF_REG_SIZES_CONSTANT__ and __LIBGCC_DWARF_REG_MAXIMUM__
> register conditionally a new builtin, __builtin_dwarf_reg_size,
> which would be defined only if -fbuilding-libgcc and the compiler determines
> dwarf_reg_size is desirable to be computed inline without a table and
> would fold the builtin to say that
> index <= 16U ? 8 : 0 on x86_64 -m64,
> index <= 9U ? 4 : index - 11U <= 5U ? 12 : 0 on x86_64 -m32 etc.
> and if the expression is too large/complex, wouldn't predefine the builtin.

I think the pre-computation of the size array is useful even for targets
where the expression is not so simple, but the array elements are still
constants.  A builtin like __builtin_dwarf_reg_size could use a
reference to a constant static array, so that we can get rid of the
array initialization code in libgcc.  Before we can do that, we need to
figure out if the fully dynamic register sizes on AArch64 with SVE are
actually correct—and if we need to fix the non-SVE unwinder to work
properly for SVE programs.

So I don't want to revert the size array computation just yet.

> Or, is it actually the use of table that is bad on the unwinder side,
> or lack of a small upper bound for what you get from the table?
> In that case you could predefine upper bound on the sizes instead (if
> constant) and simply add if (size > __LIBGCC_DWARF_REG_SIZE_MAX__)
> __builtin_unreachable ()).

It also matters what kind of register sizes are used in practice.
Looking at the FDE for _Unwind_RaiseException on i686, we only save
4-byte registers there, I think.  Perhaps only non-GCC-generated code
may exercise the other register sizes?  That's different on AArch64,
where the vector registers are saved as well.

Should I repost this patch with the three nits fixed?  Or should I
revert two of the three patches I committed instead?

Thanks,
Florian

Default initialization of poly-ints

[Florian Weimer via Gcc]

It seems that the default constructor of the non-POD poly-ints does
nothing.  Is this intentional?  I expected zero initialization, to match
regular ints.

Thanks,
Florian

[PATCH] Various fixes for DWARF register size computation

[Florian Weimer via Gcc-patches]

The previous code had several issues.

1. XALLOCAVEC does not create any objects, so invocating
   the non-POD poly_uint16 assignment operator is undefined.
2. The default constructor of poly-ints does not create a
   zero poly-int object (unlike what happens with regular ints).
3. The register size array must have DWARF_FRAME_REGISTERS + 1
   elements.  The extra element can be DWARF_FRAME_RETURN_COLUMN
   or DWARF_ALT_FRAME_RETURN_COLUMN.

To fix problem 3, merely increasing the array size is sufficient,
but it inhibits the x86-64 register size optimization in libgcc
because it does not use the extra register, so it has size zero.
To re-enable the optimization, expose the maximum used register
to libgcc.  This is sufficient for the optimizers to figure out
that the memcpy call in uw_install_context_1 has a fixed size
argument on x86-64.

This restores bootstrap on aarch64-linux-gnu and powerpc64-linux-gnu.
Not sure about test suite results yet, I need to check the baseline.

gcc/

* debug.h (dwarf_reg_sizes_constant): Remove declaration.
(dwarf_single_register_size): New struct.
* dwarf2cfi.cc (generate_dwarf_reg_sizes): Initialize
extra register size.  Use in-place new for initialization.
Remove unnecessary memset.
(dwarf_reg_sizes_constant): Remove.
(dwarf_single_register_size::dwarf_single_register_size):
New constructor based on removed dwarf_reg_sizes_constant
function.  Allocate extra size element.
(expand_builtin_init_dwarf_reg_sizes): Allocate extra size
element.
* target.def (init_dwarf_reg_sizes_extra): Mention extra size
element.
* doc/tm.texi: Update.

gcc/c-family/

* c-cppbuiltin.cc (c_cpp_builtins): Switch to
dwarf_single_register_size for obtaining DWARF register sizes.
Define __LIBGCC_DWARF_REG_MAXIMUM__.

libgcc/

* unwind-dw2.c (dwarf_reg_size): Use
__LIBGCC_DWARF_REG_MAXIMUM__.

---
 gcc/c-family/c-cppbuiltin.cc | 12 
 gcc/debug.h  | 13 -
 gcc/doc/tm.texi  |  2 +-
 gcc/dwarf2cfi.cc | 45 +++-
 gcc/target.def   |  2 +-
 libgcc/unwind-dw2.c  |  7 +--
 6 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index ddfd63b8eb9..8098aca41e8 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1522,10 +1522,14 @@ c_cpp_builtins (cpp_reader *pfile)
   builtin_define_with_int_value ("__LIBGCC_DWARF_FRAME_REGISTERS__",
 DWARF_FRAME_REGISTERS);
   {
-   int value = dwarf_reg_sizes_constant ();
-   if (value > 0)
- builtin_define_with_int_value ("__LIBGCC_DWARF_REG_SIZES_CONSTANT__",
-value);
+   dwarf_single_register_size srs;
+   if (srs.common_size > 0)
+ {
+   builtin_define_with_int_value 
("__LIBGCC_DWARF_REG_SIZES_CONSTANT__",
+  srs.common_size);
+   builtin_define_with_int_value ("__LIBGCC_DWARF_REG_MAXIMUM__",
+  srs.maximum_register);
+ }
   }
   builtin_define_with_int_value ("__LIBGCC_DWARF_CIE_DATA_ALIGNMENT__",
 DWARF_CIE_DATA_ALIGNMENT);
diff --git a/gcc/debug.h b/gcc/debug.h
index 4fe9f3570ac..2e843da8b41 100644
--- a/gcc/debug.h
+++ b/gcc/debug.h
@@ -245,7 +245,18 @@ extern const struct gcc_debug_hooks vmsdbg_debug_hooks;
 
 /* Dwarf2 frame information.  */
 
-extern int dwarf_reg_sizes_constant ();
+/* Query size information about DWARF registers.  */
+struct dwarf_single_register_size
+{
+  dwarf_single_register_size();
+
+  /* The common register size, or 0 if the register size varies.  */
+  unsigned int common_size;
+
+  /* The maximum register number that is actually present.  Registers
+ above the maximum are size zero even if common_size is positive.  */
+  unsigned int maximum_register;
+};
 
 extern void dwarf2out_begin_prologue (unsigned int, unsigned int,
  const char *);
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index b6d7900f212..eb29cfb95aa 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -9847,7 +9847,7 @@ sizes of those pieces in the table used by the unwinder 
at runtime.
 It will be called by @code{generate_dwarf_reg_sizes} after
 filling in a single size corresponding to each hard register;
 @var{sizes} is the address of the table.  It will contain
-@code{DWARF_FRAME_REGISTERS} elements when this hook is called.
+@code{DWARF_FRAME_REGISTERS + 1} elements when this hook is called.
 @end deftypefn
 
 @deftypefn {Target Hook} bool TARGET_ASM_TTYPE (rtx @var{sym})
diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
index d5a27dc36c5..5bd12e070b3 100644
--- a/gcc/dwarf2cfi.cc
+++ 

Re: [PATCH 1/3] Compute a table of DWARF register sizes at compile

[Florian Weimer via Gcc-patches]

* Jeff Law:

> On 11/8/22 11:05, Florian Weimer via Gcc-patches wrote:
>> The sizes are compile-time constants.  Create a vector with them,
>> so that they can be inspected at compile time.
>>
>>  * gcc/dwarf2cfi.cc (init_return_column_size): Remove.
>>  (init_one_dwarf_reg_size): Adjust.
>>  (generate_dwarf_reg_sizes): New function.  Extracted
>>  from expand_builtin_init_dwarf_reg_sizes.
>>  (expand_builtin_init_dwarf_reg_sizes): Call
>>  generate_dwarf_reg_sizes.
>>  * gcc/target.def (init_dwarf_reg_sizes_extra): Adjust
>>  hook signature.
>>  * gcc/config/msp430/msp430.cc
>>  (msp430_init_dwarf_reg_sizes_extra): Adjust.
>>  * gcc/config/rs6000.cc (rs6000_init_dwarf_reg_sizes_extra):
>>  Likewise.
>>  * gcc/doc/tm.texi: Update.
>
> This series of 3 patches is fine.

Thanks, now pushed (after polishing the ChangeLog snippets).

Florian

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

[Florian Weimer via Gcc-patches]

* Marek Polacek via Gcc-patches:

> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 726392409b6..2de14466dd3 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -16510,6 +16510,14 @@ The option cannot be combined with 
> @option{-fsanitize=thread} or
>  @option{-fsanitize=hwaddress}.  Note that the only target
>  @option{-fsanitize=hwaddress} is currently supported on is AArch64.
>  
> +To get more accurate stack traces, it is possible to use options such as
> +@option{-O} (which, for instance, prevents most function inlining),
> +@option{-fno-optimize-sibling-calls} (which prevents optimizing sibling
> +and tail recursive calls), or @option{-fno-ipa-icf} (which disables Identical
> +Code Folding for functions and read-only variables).  Since multiple runs
> +of the program may yield backtraces with different addresses due to ASLR,
> +it may be desirable to turn off ASLR: @samp{setarch `uname -m` -R ./prog}.

What about -fasynchronous-unwind-tables?  It should help if ASAN ever
reports stray segmentation faults.  Whether it also helps in general
depends on whether ASAN maintains ABI around its instrumentation.

Thanks,
Florian

Re: Triggering -save-temps from the front-end code

[Florian Weimer via Gcc]

* Arsen Arsenović:

> Hi,
>
> Florian Weimer via Gcc  writes:
>
>> Unfortunately, some build systems immediately delete the input source
>> files.  Is there some easy way I can dump the pre-processed and
>> non-preprocessed sources to my log file?  I tried to understand how
>> -save-temps for crash recovery works, but it seems that this runs
>> outside of the frontend, in the driver.
>
> Would dumping unconditionally into some "side channel" -dumpdir be a
> sufficient workaround?

Of the file names overlap, and it seems in this case, the dump files are
just overwritten.  I don't see a way to make the file names unique.

I guess for the tough cases, I can just keep running the build under
strace.

Thanks,
Florian

Triggering -save-temps from the front-end code

[Florian Weimer via Gcc]

I've got some instrumentation for logging errors to a magic directory,
so that I can see if a build triggered them even when it did not
fail—and hid all compiler errors and warnings.

Unfortunately, some build systems immediately delete the input source
files.  Is there some easy way I can dump the pre-processed and
non-preprocessed sources to my log file?  I tried to understand how
-save-temps for crash recovery works, but it seems that this runs
outside of the frontend, in the driver.

Here's an example of the
challenges this would help to solve:

  Building in strict C99 mode
  

Thanks,
Florian