[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Florian Weimer  ---
(In reply to Andrew Pinski from comment #6)
> What was done for libstdc++ was only specific to libstdc++ even though it
> uses the same headers, it was not changed for the generic libgcc code which
> is used in other places including but not limited to the unwinder, and
> libobjc. now the question comes to do we want to bring in pthread_ functions
> always with the unwinder? I don't know ...

For glibc, most of these functions are included in minimal static executables
anyway. At least today, the difference is not going to be large, if it exists
at all. In the future, minimal static executables may have a smaller footprint,
but even then, these functions are pretty small. The concern is probably more
in the opposite direction, that pthread_once pulls in the unwinder …

[Bug libfortran/114646] libgfortran doesn't work with static libpthread

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #4 from Florian Weimer  ---
Sorry, threading and -static is expected to work with glibc 2.34 and later.
There are no alternative function implementations when linking with and without
libpthread anymore. Instead we always link with the full implementation, and
some critical ones have fast paths for truly single-threaded operation.

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Florian Weimer  ---
This looks like a glibc bug to me.

[Bug sanitizer/113728] libasan uses incorrect prctl prototype

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Florian Weimer  ---
Then let's close it. We'll get the fix from LLVM if it ever gets implemented.

[Bug sanitizer/113728] libasan uses incorrect prctl prototype

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
This has been worked around in glibc. Should we close this issue?

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from Florian Weimer  ---
(In reply to H.J. Lu from comment #19)
> (In reply to Florian Weimer from comment #9)
> > (In reply to H.J. Lu from comment #7)
> > > > The __tls_get_addr call with the default approach potentially needs to 
> > > > solve
> > > > the same problem, doesn't it?
> > > 
> > > Isn't __tls_get_addr called via the PLT entry?
> > 
> > I'm not sure if that matters? Even if the lazy binding trampoline is active,
> > it won't protect the actual call.
> 
> Non-GNU2 TLS has
> 
> 4000  00010007 R_X86_64_JUMP_SLOT 
> __tls_get_addr + 1010
> 
> which calls _dl_runtime_resolve with lazy binding. _dl_runtime_resolve
> preserves all caller-saved registers.

The dynamic linker preserves register contents during lazy binding and restores
them before calling __tls_get_addr, so it doesn't help with __tls_get_addr
register usage itself. And lazy binding happens only once per process and
object, while we need to protect the first call on every thread.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Florian Weimer  ---
(In reply to Richard Biener from comment #16)
> I do wonder why __tls_get_addr would have to call the overloaded malloc, can
> we just not force-bind it to the glibc local malloc (and make sure that's
> compiled with -mgeneral-regs-only)?

Using the glibc malloc just for some small TLS allocation is rather wasteful
because of its (mostly) per-thread data structures. Allocating from the main
arena potentially clashes with brk usage from the replacement malloc.

We'd need an alternative memory allocator (in addition to replacement string
functions), but that is known to break Thread Sanitizer and Leak Sanitizer.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Florian Weimer  ---
(In reply to Richard Biener from comment #10)
> I think a glibc fix would be very much preferred.

It's a bit of a maintenance nightmare because we have to update the code
slightly each time new registers are added, and there isn't a good way for
applications to detect whether they run on a compatible glibc.

> Is -mtls-dialect=gnu2
> supposed to work on a per-TU base or are all parts of an executable + loaded
> shlibs required to have the same setting?

It's possible to link various TLS variants together, and they should
interoperate.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Florian Weimer  ---
(In reply to H.J. Lu from comment #7)
> > The __tls_get_addr call with the default approach potentially needs to solve
> > the same problem, doesn't it?
> 
> Isn't __tls_get_addr called via the PLT entry?

I'm not sure if that matters? Even if the lazy binding trampoline is active, it
won't protect the actual call.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Florian Weimer  ---
> (In reply to H.J. Lu from comment #4)
> > (In reply to H.J. Lu from comment #3)
> > > Created attachment 57385 [details]
> > > A patch
> > > 
> > > Try this.
> > 
> > This doesn't work properly.  To work around in ld.so, _dl_tlsdesc_dynamic
> > needs to save and restore ALL registers, which can be expensive.

Why doesn't this work properly? Is it possible to make it work with a different
approach?

The __tls_get_addr call with the default approach potentially needs to solve
the same problem, doesn't it?

(In reply to Jakub Jelinek from comment #5)
> Or it could be compiled with options to make sure it doesn't use vector
> registers etc., and only save/restore if it needs to call into some code
> where libc can't afford that (say allocate memory).

We currently call into malloc, which could be a replacement malloc. If GCC
cannot be fixed, full context switch or elimination of the slow path are our
best options for a glibc-side fix.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Florian Weimer  ---
Brought to the x86-64 ABI list:

GCC and the GNU2 TLS descriptor call ABI

[Bug target/113874] New: GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113874
   Summary: GNU2 TLS descriptor calls do not follow psABI on
x86_64-linux-gnu
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu

Consider this test case:

struct tls {
  long a, b, c, d;
};

extern __thread struct tls tls_var __attribute__ ((visibility ("hidden")));

void
apply_tls (struct tls *p)
{
  tls_var = *p;
}

With “-O2 -fpic -mtls-dialect=gnu2“, it gets compiled to:

apply_tls:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movdqu  (%rdi), %xmm0
leaqtls_var@TLSDESC(%rip), %rax
call*tls_var@TLSCALL(%rax)
addq%fs:0, %rax
movups  %xmm0, (%rax)
movdqu  16(%rdi), %xmm1
movups  %xmm1, 16(%rax)
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

Note how %xmm0 is loaded before the descriptor call. The glibc implementation
assumes psABI, so %xmm0 is potentially clobbered by the call.

Discovered as a crash in the polymake testsuite
(/fan/objects/Geometry/PolyhedralFan/properties/Combinatorics/DUAL_GRAPH) if
its dependency nauty is compiled with -mtls-dialect=gnu2.

(i686-linux-gnu has the same issue with -msse2.)

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Florian Weimer  ---
I we knew that the last successfully executed instruction was an indirect call
or branch (assumed to be tail call), we could use the return address at the top
of the stack, for architectures where call instructions push the return address
onto the stack. This is probably what GDB is doing.

The issue is of course that if the fault was caused by something else, we
should instead the program counter in the signal frame to continue unwinding.
Maybe we could special-case this for PC == 0, which is obviously invalid.

[Bug libgcc/113803] New: libgcc unwinder stops at calls to null function pointer on some targets

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113803
   Summary: libgcc unwinder stops at calls to null function
pointer on some targets
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Originally reported as a glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31349

If a null pointer is called, the backtrace stops at the signal frame on most
GNU/Linux architectures (tried aarch64, s390x, x86-64), presumably due to the
null address in the signal context. On powerpc64le, backtracing continues as
expected. This does not seem to be related to use of the sigreturn trampoline
from the vDSO.

[Bug sanitizer/113728] New: libasan uses incorrect prctl prototype

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113728
   Summary: libasan uses incorrect prctl prototype
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux-gnu

The prctl function in glibc is variadic, but the internal prototype used by
libasan has a fixed argument list.

This causes crashes on powerpc64le-linux-gnu with current glibc because the
glibc implementation is variadic as well, it uses . Older glibc uses
an assembler implementation which does not bother with variadic arguments. For
variadic function calls, it's the caller's responsibility to set up the
parameter save area, but that does not happen if function prototype is
incorrect and non-variadic.

I'll try to get this worked around in glibc, but I couldn't get my ABI
regression fix applied the first time I posted it. The libasan library isn't
the first application impacted by the prctl ABI change.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Florian Weimer  ---
Which version of the manual page are you looking at?

https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html seems pretty
clear about the scope-based nature (search for discussion of
break/return/goto).

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Florian Weimer  ---
Sorry, pthread_cleanup_push is purely scope-based, like the existing handler.
It cannot be used to push a handler to some unscoped cleanup function list that
persists even after the current function returns. It's also implemented as a
macro, so it's not possible to emit it from builtin expansion.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Florian Weimer  ---
(In reply to Iain Sandoe from comment #3)
> for platforms using pthreads as the underlying resource, then perhaps we can
> do this without thread_atexit (which I do not see in many places) by using
> pthread_cleanup_push ()

The current implementation already uses the same underlying mechanism as
pthread_cleanup_push if building with -fexceptions. It does not solve the leak
because the outermost handler deliberately does not perform a full deallocation
of the thread state.

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #9 from Florian Weimer  ---
Could we change the C++ standard not to declare std::remove in ?

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #11)
> Or put it in libgcc_eh.a and libgcc_s.so.1?

Yes, that's what I came up with as well (conceptually, not a patch, and I only
have a background in ELF), but Iain already dismissed it in comment 3.

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Florian Weimer  ---
In the current implementation, as far as I understand it, avoiding multiple
objects is just an optimization, not a correctness issue. STB_GNU_UNIQUE is for
correctness (although I don't think we'd implement it this way today).

The deallocation API does not explicitly reference the closure, which is why
stackful coroutines/fibers will have to switch the allocator state as part of
the context switch. Once we start doing this, it simplifies matters greatly if
there is just one such state to switch, and not an arbitrary count.

[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
Weak symbols have no meaning for ELF DSOs, so this wouldn't work for libgcc_s
on ELF targets. Instead we automatically link against dynamic libgcc_s if
certain symbols not in libgcc.a are referenced. Sources built with
-ftrampoline-impl=heap -fexceptions can already trigger such a dependency for
_Unwind_Resume because it's used in the cleanup handler, for example.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
(In reply to Iain Sandoe from comment #1)
> (In reply to Florian Weimer from comment #0)
> 
> > The fix is to register a TLS destructor to
> > deallocate that page, too. On glibc, that also fixes another memory leak for
> > -fno-exceptions compilations (the default for C) if pthread_exit is called
> > with an active trampoline.
> 
> Does this mean you have a proposed patch already? (before I start
> investigation)

No, this was a reference to __cxa_thread_atexit, which is unfortunately in
libstdc++ (but is a thin shim around __cxa_thread_atexit_impl for current
glibc). The pthread_key_create fallback probably needs to be duplicated into
libgcc_s.

[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Florian Weimer  ---
I should say I have only tested this on x86-64, but it is likely that this
impacts other supported ABIs as well.

[Bug libgcc/113403] New: __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113403
   Summary: __builtin_nested_func_ptr_created,
__builtin_nested_func_ptr should be dynamically linked
by default
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

There are hidden definitions of __builtin_nested_func_ptr_created,
__builtin_nested_func_ptr in libgcc.a. As a result of the default link order,
the exported global definitions of these functions in libgcc_s.so.1 are never
used.

This is unfortunate because it means that every DSO that creates a trampoline
gets its own trampoline cache (one TLS variable and two data pages for
trampolines), increasing the overhead of this feature significantly.

[Bug libgcc/113402] New: Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113402
   Summary: Incorrect symbol versions for
__builtin_nested_func_ptr_created,
__builtin_nested_func_ptr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

The symbols are about to be added to GCC 14, but they use a GCC_7.0.0 symbol
version in libgcc_s. The set of symbols associated with a version cannot be
changed after a release, otherwise dependency management based on symbol
versions does not work.

[Bug target/113401] New: Memory (resource) leak in -ftrampoline-impl=heap

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113401
   Summary: Memory (resource) leak in -ftrampoline-impl=heap
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*, aarch64-*

Consider this test program:

#include 
#include 
#include 

static void *volatile compiler_barrier;

void *
thread_routine (void *ignore)
{
  int local_variable;
  auto int *local_function (void)
  {
return _variable;
  }
  compiler_barrier = local_function;
  return NULL;
}

int
main (void)
{
  for (int i = 0; i < 1; ++i)
{
  pthread_t thread;
  int ret = pthread_create (, NULL, thread_routine, NULL);
  if (ret != 0)
{
  errno = ret;
  err (1, "pthread_create");
}
  ret = pthread_join (thread, NULL);
  if (ret != 0)
{
  errno = ret;
  err (1, "pthread_join");
}
}
}

With -ftrampoline-impl=stack, I get:

$ \time ./a.out 
0.01user 0.16system 0:00.18elapsed 102%CPU (0avgtext+0avgdata 3008maxresident)k
0inputs+0outputs (0major+68minor)pagefaults 0swaps

With -ftrampoline-impl=heap:

$ \time ./a.out 
0.03user 0.17system 0:00.20elapsed 101%CPU (0avgtext+0avgdata
41796maxresident)k
0inputs+0outputs (0major+10148minor)pagefaults 0swaps

The reason for the maxresident change is that __builtin_nested_func_ptr_created
and __builtin_nested_func_ptr_deleted cache the last trampoline page even if it
is completely unused. This is required for performance reasons. The fix is to
register a TLS destructor to deallocate that page, too. On glibc, that also
fixes another memory leak for -fno-exceptions compilations (the default for C)
if pthread_exit is called with an active trampoline.

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #12 from Florian Weimer  ---
Can you make fred_handler noreturn and use inline assembler to do the exit?
Will FRED restore the processor state in this case?

[Bug target/103370] [12/13/14 Regression] Assembler error building glibc for ColdFire soft-float

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #11 from Florian Weimer  ---
*** Bug 110627 has been marked as a duplicate of this bug. ***

[Bug target/110627] m68k: “Tried to convert PC relative branch to absolute jump” while building iconvdata/iso-2022-jp.c from glibc

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Florian Weimer  ---
Looks like it, the other bug is much more detailed, too.

*** This bug has been marked as a duplicate of bug 103370 ***

[Bug libstdc++/113159] More robust std::sort for silly comparator functions

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #6 from Florian Weimer  ---
We'll likely revert most of the qsort changes for glibc 2.39 because the new
implementation is both slower and has a significant backwards compatibility
impact.

[Bug target/113059] [14 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #8 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #3)
> Seems the package's configure is affected by most likely the modern C
> changes,
> I see
> --- config.h.good 2023-12-22 17:47:44.615207332 +0100
> +++ config.h.bad  2023-12-22 17:46:42.304068624 +0100
> @@ -37,7 +37,7 @@
>  /* #undef F77_FUNC_ */
>  
>  /* Define if F77_FUNC and F77_FUNC_ are equivalent. */
> -/* #undef F77_FUNC_EQUIV */
> +#define F77_FUNC_EQUIV 1
>  
>  /* Define if F77 and FC dummy `main' functions are identical. */
>  /* #undef FC_DUMMY_MAIN_EQ_F77 */
> @@ -404,7 +404,7 @@
>  
>  /* Include g77-compatible wrappers in addition to any other Fortran
> wrappers.
> */
> -/* #undef WITH_G77_WRAPPERS */
> +#define WITH_G77_WRAPPERS 1
>  
>  /* Use our own aligned malloc routine; mainly helpful for Windows systems
> lacking aligned allocation system-library routines. */
> diff in config.h between my system gcc 12 and gcc 14 snapshot.
> But that isn't the reason for the failure.

I don't see a different to system gcc 13. It has F77_FUNC_EQUIV and
WITH_G77_WRAPPERS set as well. Do you see this for all build variants of fftw?

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Florian Weimer  ---
I do not plan to backport this change.

[Bug middle-end/113082] builtin transforms do not honor errno

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
(In reply to Richard Biener from comment #1)
> Joseph - I wonder if the standard folks can be convinced to amend most
> library function documentation as to not altering 'errno' (like memcpy,
> strlen, etc.)?
> 
> Should we simply document our constraints on supported library
> implementations?

We can add attributes to the glibc headers, similar to the throw and leaf
annotation we have today. It would act as a reminder that if we clobber errno
in these functions due to some implementation detail, we need to save/restore
errno.

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-17
 Status|UNCONFIRMED |ASSIGNED

--- Comment #4 from Florian Weimer  ---
Patch submitted:

[PATCH] c-family: Use -Wdiscarded-qualifiers for ignored qualifiers in
__atomic_*
<https://inbox.sourceware.org/gcc-patches/87edfk6dr6@oldenburg.str.redhat.com/>

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Florian Weimer  ---
(In reply to Florian Weimer from comment #1)
> The warning should be -Wdiscared-qualifiers, which is not an error for C.
> 
> What confused me is that the volatile qualifier is already accepted for the
> first argument. I believe it's valid for the second argument.

Sorry, I wanted to say: “I believe [the warning is] valid for the second
argument.”

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Florian Weimer  ---
The warning should be -Wdiscared-qualifiers, which is not an error for C.

What confused me is that the volatile qualifier is already accepted for the
first argument. I believe it's valid for the second argument.

[Bug preprocessor/110558] __has_include argument expansion results in unexpected filename

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Florian Weimer  ---
It tries to read "my. header.h" for some reason, even though the
MAKE_INCLUDE_PATH macro produces "my.header.h" in other contexts (not just in
#include directives). I doubt this is related to bug 80753.

[Bug c/112954] New: Spelling hint for typos in parameter types in function prototypes

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112954
   Summary: Spelling hint for typos in parameter types in function
prototypes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

This is used to be accepted with a warning as a function declaration without a
prototype, treating “int32t” as an untyped parameter name rather than a type:

void function (int32t);

In GCC 14, this is now a declaration-missing-parameter-type permerror. However,
the wording of the diagnostic did not change. We could provide a spelling hint
or header inclusion hint for such errors.

[Bug tree-optimization/112831] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
Created attachment 56776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56776=edit
valgrind output

[Bug tree-optimization/112831] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC|fweimer at redhat dot com  |fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
For me, it ICEs on the previous commit as well.

Could it be a latent bug? I'm going to attach some valgrind output.

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Florian Weimer  ---
What I can I do here to help? What's an easy emutls target to build?

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Florian Weimer  ---
Jan, do you actually experience a build failure? The part you quoted only shows
warnings.

Thomas, the safe thing to do would be to use __builtin_calloc and
__builtin_realloc in those spots because it avoids a dependency on an external
header that might not exist at this point.

[Bug c/108476] Please turn -Wreturn-type on by default for C

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #4 from Florian Weimer  ---
For GCC 14, we have -Wreturn-mismatch turned on by default, as an error. This
diagnoses cases of extra or missing expressions in return statements. Together
with the other warnings-as-errors changes, this seems to cover the request in
the description.

[Bug c/96284] Outdated C features should be made errors with newer standards

[fw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
Bug 96284 depends on bug 91093, which changed state.

Bug 91093 Summary: Error on implicit int by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c/91093] Error on implicit int by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Florian Weimer  ---
Fixed for GCC 14.

[Bug c/91092] Error on implicit function declarations by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Florian Weimer  ---
Fixed for GCC 14.

[Bug c/96284] Outdated C features should be made errors with newer standards

[fw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
Bug 96284 depends on bug 106416, which changed state.

Bug 106416 Summary: -Wint-conversion should be an error, not a pedwarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Florian Weimer  ---
Fixed for GCC 14.

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #55 from Florian Weimer  ---
(In reply to post+gcc from comment #52)
> For the point discussed earlier with the `restrict` in the musl memcpy, I
> had another look at the definition of `restrict` and it's not entirely clear
> to me any more that there is UB here. The restrict rules only apply to
> objects that are "also modified (by any means)". Now the question is, does
> "*X = *X" modify the object?

C11 says this:

| NOTE: “Modify” includes the case where the new value being stored is the same
as the previous value.

So at least this should be quite clear (although I think notes are supposedly
informal).

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #32 from Florian Weimer  ---
There's this in standards.texi:

Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions.  GCC requires the
freestanding environment provide @code{memcpy}, @code{memmove},
@code{memset} and @code{memcmp}.
Finally, if @code{__builtin_trap} is used, and the target does
not implement the @code{trap} pattern, then GCC emits a call
to @code{abort}.

Maybe that would be a place to mention this issue, too?

[Bug c++/111918] #pragma GCC diagnostic pop does not restore error status of -Wnarrowing

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
It does not work.

I think the problem is the quoted reset code with old_kind.  It was introduced
in r5-2858 to fix PR59304. It's necessary because global warning options serve
a dual purpose: recording the command line state, and activating warning
processing code (or put differently, to skip over analysis for a warning if the
warning is not active).  The diagnostics pragma code has to set global warnings
to disable the shortcuts, but this clobbers the command line state.

[Bug c++/111918] #pragma GCC diagnostic pop does not restore permerror status of -Wnarrowing

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Florian Weimer  ---
diagnostic_classify_diagnostic overwrites DK_UNSPECIFIED in
context->classify_diagnostic[OPT_Wnarrowing] with DK_WARNING here:

  /* Record the command-line status, so we can reset it back on DK_POP. */
  if (old_kind == DK_UNSPECIFIED)
{
  old_kind = !context->option_enabled (option_index,
   context->lang_mask,
   context->option_state)
? DK_IGNORED : (context->warning_as_error_requested
? DK_ERROR : DK_WARNING);
  context->classify_diagnostic[option_index] = old_kind;
}

In diagnostic_enabled, we use that to switch the diagnostic kind to DK_WARNING
because update_effective_level_from_pragmas return DK_UNSPECIFIED:

  /* This tests for #pragma diagnostic changes.  */
  diagnostic_t diag_class
= update_effective_level_from_pragmas (context, diagnostic);

  /* This tests if the user provided the appropriate -Werror=foo
 option.  */
  if (diag_class == DK_UNSPECIFIED
  && (context->classify_diagnostic[diagnostic->option_index]
  != DK_UNSPECIFIED))
diagnostic->kind
  = context->classify_diagnostic[diagnostic->option_index];

We cannot treat permerrors differently in either function because they are an
emerging property, not associated with the warning option itself. This fixes
the test case, though:

  /* This tests if the user provided the appropriate -Werror=foo
 option.  */
  if (diag_class == DK_UNSPECIFIED
  && (context->classify_diagnostic[diagnostic->option_index] == DK_ERROR))
diagnostic->kind = DK_ERROR;

I see what it does to the test suite.

[Bug c++/111918] New: #pragma GCC diagnostic pop does not restore permerror status of -Wnarrowing

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 111918
   Summary: #pragma GCC diagnostic pop does not restore permerror
status of -Wnarrowing
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org, jason at gcc dot gnu.org
  Target Milestone: ---

Consider this test case:

float f1{123456789};
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wnarrowing"
float f2{123456789};
#pragma GCC diagnostic pop
float f3{123456789};

It reports (with GCC 13.2 and trunk):

t.cc:1:10: error: narrowing conversion of ‘123456789’ from ‘int’ to ‘float’
[-Wnarrowing]
1 | float f1{123456789};
  |  ^
t.cc:6:10: warning: narrowing conversion of ‘123456789’ from ‘int’ to ‘float’
[-Wnarrowing]
6 | float f3{123456789};
  |  ^

I would have expected an error at line 6 because the original diagnostics state
should have been restored by the pop pragma.

This might be a more generic issue, not specific to -Wnarrowing.  I see it with
newly added permerrors in the C front end, too.

[Bug c/109827] Pointer/integer mismatch in ?: not covered by -Wint-conversion

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Florian Weimer  ---
Fixed for GCC 14.

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

[fw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
Bug 44209 depends on bug 109827, which changed state.

Bug 109827 Summary: Pointer/integer mismatch in ?: not covered by 
-Wint-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109827

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

[fw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
Bug 44209 depends on bug 109826, which changed state.

Bug 109826 Summary: Incompatible pointer types in ?: not covered by 
-Wincompatible-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Florian Weimer  ---
Fixed for GCC 14.

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Florian Weimer  ---
Patch posted:
https://inbox.sourceware.org/gcc-patches/87pm19znaa@oldenburg.str.redhat.com/

[Bug c/109827] Pointer/integer mismatch in ?: not covered by -Wint-conversion

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Florian Weimer  ---
Patch posted:
https://inbox.sourceware.org/gcc-patches/87y1fxzszn@oldenburg.str.redhat.com/

[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #31 from Florian Weimer  ---
(In reply to Andrew Pinski from comment #30)
> And you can even make it a pointer to a pointer of char to hit the same bug
> to get around the even more fuzziness of freeing an int rather than a
> pointer:
> ```
> int yyparse (char **yyvsp)
> ```
> See https://godbolt.org/z/v7xKxWE3K

-int yyparse (void)
+int yyparse (char **yyvsp)
 {
 int yystate = 0;
-int *yyvsp = 0;


Nice, thank you.

[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #28 from Florian Weimer  ---
(In reply to Richard Biener from comment #1)
> Created attachment 53207 [details]
> reduced testcase

Do you happen to have the unreduced test case still?

int *yyvsp = 0;

followed by:

  if (strncmp( yyvsp[0], "~", 1) == 0) {

and

   free(yyvsp[0]);

looks rather bogus.

[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #14 from Florian Weimer  ---
(In reply to Martin Liška from comment #4)
> Started with r12-6754-g30f2c22def739211.

And this was backported as r11-9991-g8d2f59c8e26960df, so this issue currently
exists on the gcc-11 branch.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Florian Weimer  ---
(In reply to Michael Matz from comment #9)
> > > I don't see how that helps.  Imagine a preserve_all function foo that 
> > > calls
> > > printf.  How do you propose that 'foo' saves all parts of the SSE 
> > > registers,
> > > even those that aren't invented yet, or those that can't be touched by the
> > > current ISA?  (printf might clobber all of these)
> > 
> > Vector registers are out of scope for this.
> 
> Why do you say that?  From clang: "Furthermore it also preserves all
> floating-point registers (XMMs/YMMs)."  (for preserve_all, but this
> bugreport does include that variant of the attribute).

Ugh, I preferred not to look at it because it's likely that the Clang
implementation is broken (not future-proof).

> > But lets look at APX. If printf is recompiled to use APX, then it will
> > clobber the extended register file. If we define __preserve_most__ the way
> > we do in my psABI proposal (i.e., *not* as everything but %r11), the
> > extended APX registers are still caller-saved.
> 
> Right, for preserve_most _with your wording_ it works out.  preserve_all
> or preserve_most with clang wording doesn't.

In glibc, we already use a full context switch with XSAVE for the dynamic
loader trampoline. As far as I understand it, it's not future-proof. The kernel
could provide an interface that is guaranteed to work because it only enables
those parts of the register file that it can context-switch. I can probably get
the userspace-only implementation into glibc, but the kernel interface seems
unlikely. We'd also have to work out the interaction of preserve_all and
unwinding, setjmp etc.; not sure if there is a proper solution for that.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Florian Weimer  ---
(In reply to Michael Matz from comment #7)
> > > Does the clang implementation take into account the various problematic
> > > cases that arise when calling a normal function from a (say) preserve_all
> > > function
> > > (hint: such call can't usually be done)?
> > 
> > How so? We need to version the __preserve_most__ attribute with the ISA
> > level, of course.
> 
> I don't see how that helps.  Imagine a preserve_all function foo that calls
> printf.  How do you propose that 'foo' saves all parts of the SSE registers,
> even those that aren't invented yet, or those that can't be touched by the
> current ISA?  (printf might clobber all of these)

Vector registers are out of scope for this.

But lets look at APX. If printf is recompiled to use APX, then it will clobber
the extended register file. If we define __preserve_most__ the way we do in my
psABI proposal (i.e., *not* as everything but %r11), the extended APX registers
are still caller-saved. We will have to introduce a __preserve_most_apx__
attribute and a different psABI specification that says that the new APX
registers are callee-saved, too.

(These details are the main reason why I want this in the psABI documentation.
This stuff is out there and will be used, so let's make sure that it's somewhat
reasonable.)

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Florian Weimer  ---
(In reply to Michael Matz from comment #3)
> For ABIs you generally want a good mix between caller- and callee-saved
> registers. The x86-64 psABI didn't do that on the SSE regs for conscious, but
> meanwhile irrelevant, reasons, so my approach above tried to rectify this.
> 
> The clang attributes seem to go against that general idea, they move all regs
> (or all general regs) into being callee-saved (except, strangely for
> aarch64?).

This is intended for functions that are called conditionally, but rarely, such
as debug logging. It's not a generally useful calling convention.

> It also makes argument registers be callee-saved, which is very
> unconventional.

Isn't this done for the this pointer in some C++ ABIs?

> Does the clang implementation take into account the various problematic
> cases that arise when calling a normal function from a (say) preserve_all
> function
> (hint: such call can't usually be done)?

How so? We need to version the __preserve_most__ attribute with the ISA level,
of course.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
I tried to write up something for the x86-64 psABI:

Document the ABI for __preserve_most__ function calls
<https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/45>

This should match what Clang implements (but not what it documents).

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #37 from Florian Weimer  ---
Backported to 13, the only impacted release.

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #35 from Florian Weimer  ---
Backport posted, along with the warning fix:

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


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

[Bug target/110627] New: m68k: “Tried to convert PC relative branch to absolute jump” while building iconvdata/iso-2022-jp.c from glibc

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110627
   Summary: m68k: “Tried to convert PC relative branch to absolute
jump” while building iconvdata/iso-2022-jp.c from
glibc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-linux-gnu-coldfire-soft

Created attachment 55521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55521=edit
iso-2022-jp.i

The attached source file fails in assembly with:

Fatal error: Tried to convert PC relative branch to absolute jump

when building with “-O2 -fpic” or “-O2 -fPIC”.

GCC was configured like this (trunk sources from today):

/home/bmg/src/gcc/configure
--prefix=/home/bmg/install/compilers/m68k-linux-gnu-coldfire-soft
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=m68k-glibc-linux-gnu
--with-sysroot=/home/bmg/install/compilers/m68k-linux-gnu-coldfire-soft/sysroot
--with-arch=cf --with-cpu=54455 --disable-multilib --enable-initfini-array
--disable-libssp --disable-libcilkrts
--with-gmp=/home/bmg/install/host-libraries
--with-mpfr=/home/bmg/install/host-libraries
--with-mpc=/home/bmg/install/host-libraries --enable-languages=c
--disable-shared --disable-threads --disable-libatomic --disable-decimal-float
--disable-gcov --disable-libffi --disable-libgomp --disable-libitm
--disable-libmpx --disable-libquadmath --disable-libsanitizer --without-headers
--with-newlib --with-glibc-version=2.37

As a workaround, I tried “-O2 -fpic -mpcrel“, but this ICEs:

during RTL pass: sched2
In file included from iso-2022-jp.c:1033:
../iconv/skeleton.c: In function ‘gconv’:
../iconv/skeleton.c:663:1: internal compiler error: in sched_attr_op_type, at
config/m68k/m68k.cc:6123
0x741144 sched_attr_op_type
/home/bmg/src/gcc/gcc/config/m68k/m68k.cc:6123
0x11ba2d1 m68k_sched_attr_opy_type(rtx_insn*, int)
/home/bmg/src/gcc/gcc/config/m68k/m68k.cc:6180
0x11b0564 sched_get_opxy_mem_type
/home/bmg/src/gcc/gcc/config/m68k/m68k.cc:6354
0x11ba32e m68k_sched_attr_op_mem(rtx_insn*)
/home/bmg/src/gcc/gcc/config/m68k/m68k.cc:6387
0x14cd471 internal_dfa_insn_code(rtx_insn*)
/home/bmg/src/gcc/gcc/config/m68k/m68k.md:154
0x14c9334 dfa_insn_code
   
/home/bmg/build/compilers/m68k-linux-gnu-coldfire-soft/gcc-first/gcc/insn-automata.cc:4146
0x14c9334 insn_has_dfa_reservation_p(rtx_insn*)
   
/home/bmg/build/compilers/m68k-linux-gnu-coldfire-soft/gcc-first/gcc/insn-automata.cc:4788
0x11b1cac m68k_sched_md_init_global
/home/bmg/src/gcc/gcc/config/m68k/m68k.cc:6714
0x15d1c2f sched_init()
/home/bmg/src/gcc/gcc/haifa-sched.cc:7354
0x15d33fc haifa_sched_init()
/home/bmg/src/gcc/gcc/haifa-sched.cc:7368
0xdf7ffa schedule_insns()
/home/bmg/src/gcc/gcc/sched-rgn.cc:3524
0xdf86fd schedule_insns()
/home/bmg/src/gcc/gcc/sched-rgn.cc:3518
0xdf86fd rest_of_handle_sched2
/home/bmg/src/gcc/gcc/sched-rgn.cc:3756
0xdf86fd execute
/home/bmg/src/gcc/gcc/sched-rgn.cc:3895
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Florian Weimer  ---
(In reply to Xi Ruoyao from comment #10)
> But Zack's reason against using __nonnull is __nonnull may cause unwanted
> optimizations to *the user code*.

GCC already offers options to control function call behavior in the presence of
nonnull attributes:

 For function calls:
• If the compiler determines that a null pointer is passed in an
  argument slot marked as non-null, and the ‘-Wnonnull’ option
  is enabled, a warning is issued.  *Note Warning Options::.
• The ‘-fisolate-erroneous-paths-attribute’ option can be
  specified to have GCC transform calls with null arguments to
  non-null functions into traps.  *Note Optimize Options::.
• The compiler may also perform optimizations based on the
  knowledge that certain function arguments cannot be null.
  These optimizations can be disabled by the
  ‘-fno-delete-null-pointer-checks’ option.  *Note Optimize
  Options::.

So I don't think we need another way to disable nonnull attributes in installed
glibc headers.

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Florian Weimer  ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Richard Biener from comment #5)
> > I think a -f... option to disable the code generation effects would make
> > more sense than adding another attribute kind.
> 
> Then maybe we'd just add a -D_GLIBC_NONNULL={0,1} (?) into Glibc cdefs.h
> instead.  Anyway I'm already too frustrated about this so I'll not continue
> working on nonnull within Glibc headers.  If you don't like this just close
> it as WONTFIX.

For those who are not following libc-alpha, glibc already disables __nonnull
during its build, so it should be totally fine to use __nonnull in installed
headers to improve diagnostics.

We have this in include/sys/cdefs.h (which augments ):

/* The compiler will optimize based on the knowledge the parameter is
   not NULL.  This will omit tests.  A robust implementation cannot allow
   this so when compiling glibc itself we ignore this attribute.  */
# undef __nonnull
# define __nonnull(params)

We'd like the diagnostics for building glibc itself, and a new -f option would
help with that.

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Florian Weimer  ---
Fixed in trunk.

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-10
   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109712

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #33 from Florian Weimer  ---
(In reply to Andrew Pinski from comment #32)
> (In reply to Florian Weimer from comment #31)
> > Will propose a backport to 13 in ~2 weeks.
> 
> Any news on the backport? There is aim to release GCC 13.2.0 at the end of
> July.

I managed to produce a warning regression. I should have time this week to fix
that, and do the backport this week.

[Bug tree-optimization/110546] New: Function clone not treated as valid allocator with -Wmismatched-dealloc

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110546
   Summary: Function clone not treated as valid allocator with
-Wmismatched-dealloc
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
Blocks: 99715
  Target Milestone: ---

If compiled with -Wall -Werror -O3, the code below produces the following
diagnostic:

t.c: In function ‘f’:
t.c:16:3: error: ‘dealloc’ called on pointer returned from a mismatched
allocation function [-Werror=mismatched-dealloc]
   16 |   dealloc (alloc (1));
  |   ^~~
t.c:16:3: note: returned from ‘alloc.constprop’
   16 |   dealloc (alloc (1));
  |   ^~~


I believe this happens because the compiler does not recognize that
alloc.constprop is a valid allocation function for alloc because its internal
name is distinct from the expected name dealloc.


extern void *alloc0 (int n);

void dealloc (void *);

void *__attribute__ ((noinline, malloc (dealloc, 1)))
alloc (int n)
{
  if (n <= 0)
__builtin_abort ();
  return alloc0 (n);
}

void
f (void)
{
  dealloc (alloc (1));
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99715
[Bug 99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings

[Bug c/110442] New: IFUNC resolvers which use __builtin_cpu_supports crash with -fsanitize=address

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110442
   Summary: IFUNC resolvers which use __builtin_cpu_supports crash
with -fsanitize=address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

With -O2 -fsanitize=address, this code:

“
#include 

void
f1 (void)
{
  puts ("f1");
}

void
f2 (void)
{
  puts ("f2");
}

void *
resolve (void)
{
  __builtin_cpu_init ();
  if (__builtin_cpu_supports ("f16c"))
return f1;
  else
return f2;
}

void f (void) __attribute__ ((ifunc ("resolve")));

int
main (void)
{
  f ();
}
”

In the store to the shadow mapping:

Dump of assembler code for function resolve:
   0x00402320 <+0>: sub$0x8,%rsp
   0x00402324 <+4>: call   0x4010f0 <__cpu_indicator_init>
   0x00402329 <+9>: mov$0x4050f0,%eax
   0x0040232e <+14>:shr$0x3,%rax
=> 0x00402332 <+18>:movzbl 0x7fff8000(%rax),%eax
   0x00402339 <+25>:test   %al,%al
   0x0040233b <+27>:je 0x402341 
   0x0040233d <+29>:cmp$0x3,%al
[…]

This happens because with IRELATIVE relocations (or BIND_NOW), IFUNC resolvers
run early, before libasan had a chance to set up the shadow mapping.

Setting the component to the C front-end because the ifunc function attribute
probably needs to be changed to imply no_sanitize_address. IFUNC resolvers are
not supposed to call functions (although it works in some cases on x86), so I
think this would really help building random code with -fsanitize=address.

(In theory, if libasan were an audit module, it would be possible to set up the
mapping before relocation, but that's a change that seems unlikely to happen.)

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #5 from Florian Weimer  ---
printf is a cancellation point, and can therefore throw. Cancellation is in
POSIX, it's not a glibc extension. I don't think anyone has ever brought up the
need for cancellation handlers that call va_end. I do not think it is possible
to write them.

POSIX should probably specify that va_end is a no-op, or that it is not
required if vfprintf etc. are canceled.

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #31 from Florian Weimer  ---
Will propose a backport to 13 in ~2 weeks.

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 Target|x86_64-linux-gnu|
   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Status|REOPENED|ASSIGNED

--- Comment #27 from Florian Weimer  ---
Patch posted:

[PATCH] libgcc: Fix eh_frame fast path in find_fde_tail
<https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620731.html>

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from Florian Weimer  ---
(With the missing ; added, of course.)

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from Florian Weimer  ---
(In reply to Thomas Neumann from comment #21)
> It must be something more complex. value is small here (more precisely: 1888
> in the crashes later), which is not a valid pointer address. We probably
> have to add this to some base pointer? But it is not obvious to me to which
> one.

read_encoded_value_with_base has this:

  result += ((encoding & 0x70) == DW_EH_PE_pcrel
 ? (_Unwind_Internal_Ptr) u : base);

u is the original read pointer as far as I can see. So it looks like it should
look like this:

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 6223f5f18a2..5a6352227cc 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,

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #20 from Florian Weimer  ---
Thanks for looking into this, Thomas.  I suspect it's a simple typo, which
happens not to matter in many cases because both dbase and eh_frame are unused:

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

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Florian Weimer  ---
(In reply to Nikolas Klauser from comment #6)
> Does that make sense?

Not quite. I was trying to suggest that you also need to suppress all
inter-procedural analysis. This will inhibit quite a few useful optimizations.

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #5 from Florian Weimer  ---
How hard is this to use in practice? With current Clang, this:

“
template 
class S {
  __attribute__ ((visibility ("hidden"), exclude_from_explicit_instantiation))
  int f1 ();
  int f2 ();
};

template  int
S::f1 ()
{
  return 1;
}

template  int
S::f2 ()
{
  return f1 ();
}

template class S;
”

still inlines S::f1 into S::f2. This may not threaten future
evolution of the implementation in this particular case, but it would certainly
be helpful to have some guides similar to
<https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B>.
Clang's attribute documentation describes what happens, but it doesn't comment
on the actual implications for ABI compatibility.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #6)
> I think aarch64 defaults to -fno-omit-frame-pointer anyway.
> /* Disable fomit-frame-pointer by default.  */
> { OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },

It's required by some (all?) AArch64 ABIs, certainly on GNU/Linux.

[Bug c/109836] New: -Wpointer-sign must be enabled by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109836
   Summary: -Wpointer-sign must be enabled by default
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Assignment between incompatible pointers is a constraint violation and has to
be diagnosed in some way. If GCC does not want to error on it (perhaps
understandable), it still needs to warn.

[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Florian Weimer  ---
Presumably the idea is to enable -Werror=incompatible-function-pointer-types
(in spirit) because it is more severe than -Wincompatible-pointer-types? I'm
not sure this is actually true.

Your first example will not have ABI problems or strict-aliasing issues. It
seems rather harmless.

Your second example (even with “int x;” instead, which we do not warn about by
default) is likely to introduce strict-aliasing issues (obviously not in this
minimal fragment, but still).

If we want to error on incompatible-function-pointer-types by default, I think
we need to make some effort to refine what such incompatible function pointers
should be.

[Bug c/95445] diagnose incompatible calls to functions declared without prototype

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
Current Clang warns like this:

t.c:17:5: warning: passing arguments to 'g' without a prototype is deprecated
in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
  g (1); // (presumably) okay, f's type is 'void (int)'
^
t.c:18:5: warning: passing arguments to 'g' without a prototype is deprecated
in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
  g ("foo"); // should be diagnosed
^
t.c:19:5: warning: passing arguments to 'g' without a prototype is deprecated
in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
  g (1, "bar");  // ditto
^

Maybe that's sufficient?

Trying to infer the type of g from its uses seems to be rather questionable.
For K projects, GCC already has -flto -Wlto-type-mismatch, which can diagnose
violations across translation units.

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Florian Weimer  ---
I guess the main issue here is that the common type void * for both the second
and third operand is implicitly converted to many pointer types, including the
original types of those operands. So while converting to void * is harmless at
first, it may still result in an incompatible-pointer-types for the overall
expression.

[Bug c/109827] New: Pointer/integer mismatch in ?: not covered by -Wint-conversion

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109827
   Summary: Pointer/integer mismatch in ?: not covered by
-Wint-conversion
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

This:

int p;
long *q;

void *
f1 (int x)
{
  return x ? p : q;
}

void *
f2 (int x)
{
  return x ? q : p;
}

warns as (twice):

warning: pointer/integer type mismatch in conditional expression

So it does not error with -Werror=int-conversion, which I think is unexpected.

[Bug c/109826] New: Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

[fw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109826
   Summary: Incompatible pointer types in ?: not covered by
-Wincompatible-pointer-types
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

This:

int *p;
long *q;

char *
f (int x)
{
  return x ? p : q;
}

warns as follows:

warning: pointer type mismatch in conditional expression

So it doesn't fail to compile with -Werror=incompatible-pointer-types, which it
probably should given what the warning is about.

[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103133
 CC||fw at gcc dot gnu.org

--- Comment #13 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the
> > weak refs in gthr-posix.h
> 
> I think that is indeed the correct fix, as you originally asked about. But
> only for glibc 2.34 and later.

Only glibc 2.34 and later have this problem because previous upstream versions
lack dual-API time64 support. I would like to claim that we did this
deliberately, but the version alignment between libpthread removal and the new
time64 support was a bit of a coincidence.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #50 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #49)
> All that means is for APIs for which cast to void as silencing is meant to
> be ok should be using [[nodiscard]] rather than
> __attribute__((warn_unused_result)).  APIs which do not want that should
> keep using warn_unused_result.  When that attribute was being added, the
> glibc folks that requested it specially asked for casts to void not being a
> way to silence the attribute because the attributes were added to functions
> where users really should use the return value rather than silently ignore
> it.

I don't think these folks work on glibc anymore. 8-)

For glibc, I think we will use nodiscard by default (outside non-fortify mode)
in most cases where we use __wur now (and some), and restrict __attribute__
((warn_unused_result)) to old compilers in fortify mode. Other libraries should
probably do the same. The __attribute__ ((warn_unused_result)) remaisn too
problematic because it encourages non-portable code to suppress it, such as
__attribute__ ((unused)).

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #20)
> So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts
> into the binary not just one but both symbols and so the aliasing isn't
> broken.

I'm not sure this is sufficient because old programs will only have the
@GLIBCXX_3.4 reference and still break the aliases if copy relocations are
involved. The internal libstdc++ things we could perhaps resolve, but even with
that, it will only work if everything in the executable either uses the old
version, or the new version. Mixed-mode operation still won't work because of
the separation of the aliases.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #2)
> --- a/libstdc++-v3/src/c++98/globals_io.cc
> +++ b/libstdc++-v3/src/c++98/globals_io.cc
> @@ -43,6 +43,12 @@
>  // In macro form:
>  // _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2)
>  
> +#if __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION
> +# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31")))
> +#else
> +# define SYMVER(sym)
> +#endif

Is there anything that prevents these symbol versions getting added for
libstdc++.a? I think that could be problematic because a custom DSO typically
will not have a version node for GLIBCXX_3.4.31.

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #30 from Florian Weimer  ---
(In reply to Segher Boessenkool from comment #29)
> (In reply to Florian Weimer from comment #28)
> > Maybe this belongs in the ABI manual? For example, the POWER ABI says that
> > memcpy needs to work on device memory.
> 
> Huh?!
> 
> Where do you see this?  The way you state it it is trivially impossible to
> implement, so if we really say that it needs fixing asap.

I thought I had an explicit documented reference somewhere, but for now, all we
have is an undocumented requirement (so not a good example in the context of
this bug at all):

[PATCH] powerpc: Use aligned stores in memset


(There's also a CPU quirk in this area, but I think this wasn't about that.)

[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #4 from Florian Weimer  ---
Shouldn't this be an -f switch if it's an official compiler feature?

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
Clang now has -Wdeprecated-non-prototype apparently:
https://discourse.llvm.org/t/unresolved-issues-from-the-llvm-15-x-release/66071/36

This is probably not very useful as a warning:

> void func3 (); /* warning: an empty parameter list in function declarators 
> will have a different meaning in ISO C23 */

“()” is going to be fine when matched with an empty parameter list in a
definition, or an empty argument list in a call. I don't think it's necessary
to warn in those cases. It distracts from the real issue.

[Bug sanitizer/100114] libasan built against latest glibc doesn't work

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Florian Weimer  ---
(In reply to Alexander Enaldiev from comment #12)
> But here I see status 'RESOLVED FIXED'. Do you presume, my today's issue
> isn't connected?

It could still be the same bug. It's supposed to be fixed in LLVM 13 and later,
but maybe your program links against system libasan.a, which may not have been
fixed yet by your distribution.