[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

--- Comment #2 from Florian Weimer  ---
The problem is that if GCC is not configured for SHF_GNU_RETAIN,
__has_attribute (retain) should not be true.

That is, __has_attribute needs to reflect the actual attribute support status,
and not what happens to be registered as attributes in the GCC codebase. 
__has_builtin has the same problem, see bug 96952 for an example.

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

--- Comment #4 from Florian Weimer  ---
For retain, something along these lines might work:

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index c1f652d1dc9..cdae464ab8a 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -329,8 +329,10 @@ const struct attribute_spec c_common_attribute_table[] =
  handle_used_attribute, NULL },
   { "unused", 0, 0, false, false, false, false,
  handle_unused_attribute, NULL },
+#if SUPPORTS_SHF_GNU_RETAIN
   { "retain", 0, 0, true,  false, false, false,
  handle_retain_attribute, NULL },
+#endif
   { "externally_visible", 0, 0, true,  false, false, false,
  handle_externally_visible_attribute, NULL },
   { "no_reorder",0, 0, true, false, false, false,

In other cases, it's more difficult because those are subtarget-dependent.

It's not particularly useful to know that a particular source code base of GCC
knows about the attribute in principle, if built for the right target and with
the right binutils/glibc versions etc. A programmer can already use a version
check for that. __has_attribute and __has_builtin are only useful if they
reflect the current GCC build and its target flags.

[Bug libstdc++/100117] FAIL testsuite/17_intro/headers/c++1998/49745.cc with trunk glibc

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

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

--- Comment #1 from Florian Weimer  ---
This looks like the old C++ _GNU_SOURCE issue.

But I do not really see why  includes . Is this some PCH
test?

Should  really include all the C headers?

[Bug libstdc++/100117] FAIL testsuite/17_intro/headers/c++1998/49745.cc with trunk glibc

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

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

--- Comment #3 from Florian Weimer  ---
I was looking at the 17_intro/headers/c++1998/49745.cc file contents and can't
make sense of the error message in that context. There's no  in it.

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #5 from Florian Weimer  ---
(In reply to H.J. Lu from comment #4)
> x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.

It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good enough?

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #7 from Florian Weimer  ---
(In reply to H.J. Lu from comment #6)
> (In reply to Florian Weimer from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define 
> > > __CX16__.
> > 
> > It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good
> > enough?
> 
> Yes. But a test is missing.

Fair enough.  Are you going to send a patch?

[Bug tree-optimization/97424] New: Warn on invalid shift amount after inlining

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

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

Bug ID: 97424
   Summary: Warn on invalid shift amount after inlining
   Product: gcc
   Version: unknown
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
  Target Milestone: ---

Consider this program:

#include 

static inline uint32_t
_dl_hwcaps_subdirs_build_bitmask (int subdirs, int active)
{
  /* Leading subdirectories that are not active.  */
  int inactive = subdirs - active;
  if (inactive == 32)
return 0;

  uint32_t mask;
  if (subdirs != 32)
mask = (1 << subdirs) - 1;
  else
mask = -1;
  return mask ^ ((1U << inactive) - 1);
}

void f1 (int);

void
f2 (void)
{
  f1 (_dl_hwcaps_subdirs_build_bitmask (1, 2));
  f1 (_dl_hwcaps_subdirs_build_bitmask (33, 31));
}

This has invalid shifts involving a negative shift amount and larger-than-width
shift amount. This does not result in a warning because the current shift
warnings are implemented in the front end. But the computed values as the
argument to f1 are garbage, so it would make sense to warn.

[Bug tree-optimization/97424] Warn on invalid shift amount after inlining

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

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

--- Comment #2 from Florian Weimer  ---
Indeed, Martin Sebor has suggested that it would have to be coupled with
__builtin_warning:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/msg01015.html

[Bug tree-optimization/97424] Warn on invalid shift amount after inlining

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

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

--- Comment #6 from Florian Weimer  ---
(In reply to David Malcolm from comment #5)
> The above commit implements it as an analyzer warning.  Should I close this
> out, or should we keep it open for the __builtin_warning approach?

Thanks for the analyzer warning. I think the __builtin_warning approach is very
desirable here. To me, it looks like GCC already did all the work to figure out
this undefined.

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

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

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

--- Comment #8 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #6)
> on the mov %fs:0x10,%rax perhaps %fs isn't initialized yet?

Yes, that's why the access is guarded by flags & DL_LOOKUP_GSCOPE_LOCK. During
initial relocation, _dl_lookup_symbol_x is called without this flag.

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

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

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

--- Comment #9 from Florian Weimer  ---
And we should not end up in the add_dependency part, either because l_type
won't be lt_loaded and the DL_LOOKUP_ADD_DEPENDENCY flag hasn't been set,
either.

The inline asm is marked as volatile, and that should prevent it from being
moved across these checks.

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

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

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

--- Comment #12 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #11)
> Ah, RTL loop_invariant.  Perhaps because the inline asm is buggy?
> asm ("mov %%fs:%c1,%0" : "=r" (__self) : "i" (__builtin_offsetof (struct
> pthread, header.self)));
> The only input of the asm is the constant, so really nothing tells the
> optimizers it can't move it arbitrarily.  I think it needs to have some
> memory input or clobber to properly model that it reads from unknown memory.

Ahh, do you mean the THREAD_SELF macro?

# define THREAD_SELF \
  ({ struct pthread *__self;  \
 asm ("mov %%fs:%c1,%0" : "=r" (__self)   \
  : "i" (offsetof (struct pthread, header.self)));\
 __self;})

I had only looked at the other macros.

glibc relies on GCC optimizing away THREAD_SELF reads on x86-64 because most of
the TCB access does not need it.

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

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

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

--- Comment #17 from Florian Weimer  ---
Jakub's glibc test failures were due to --prefix=/usr/local, so that glibc
wouldn't find the installed system libgcc_s in /usr/lib64.

[Bug target/98121] New: __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

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

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

Bug ID: 98121
   Summary: __attribute__ ((used)) should not imply
SHF_RETAIN_SECTION
   Product: gcc
   Version: 11.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: ---

The used attribute has already a defined meaning. I think it's wrong to cause
it to change section attributes because people use it to interface with
assembler code, so section flags conflicts are rather likely.

Using a separate attribute would also avoid the need for the configure check in
GCC.

This is related to this commit (note the date is off, it's actually GCC 11
only):

commit 6fbec038f7a7ddf29f074943611b53210d17c40c
Author: H.J. Lu 
Date:   Mon Feb 3 11:55:43 2020 -0800

Use SHF_GNU_RETAIN to preserve symbol definitions

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

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

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

Florian Weimer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #18 from Florian Weimer  ---
This is a glibc bug.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

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

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

--- Comment #6 from Florian Weimer  ---
(In reply to Jozef Lawrynowicz from comment #4)
> GAS merges the "R" flag state in .section declarations, silently, and with
> logical OR, and GCC should do the same. So if you have:
> 
> int __attribute__((section(".data.foo"))) foo1 = 1;
> int __attribute__((used,section(".data.foo"))) foo2 = 2;
> 
> .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> "used" attribute to the second declaration of section(".data.foo") should
> not cause any warning/error messages to be emitted either. So option 3 from
> above.
> 
> Just need to do something similar to what is already done for SECTION_NOTYPE
> in varasm.c:get_section.

I don't now the details, but I think foo1 should not implicitly be marked as
“used”. The difference matters for static functions, for example. GCC should
still drop them if they are not referenced, even if they are located in a
retained section.  So free_slotinfo in comment 5.

[Bug target/97250] New: Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

Bug ID: 97250
   Summary: Implement -march=x86-64-v2, -march=x86-64-v3,
-march=x86-64-v4 for x86-64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: fw at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

x86-64-v2, x86-64-v3, x86-64-v4 have been added to the psABI as new
micro-architecture levels:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9a6b9396884b67c7c

GCC should provide -march= options so that programmers can easily built
programs and shared objects that are optimized for these levels.

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

Florian Weimer  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-30
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #1 from Florian Weimer  ---
First patch committed (preparatory only):
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=92e652d8c21bd7e66c

Second patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555174.html

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #3 from Florian Weimer  ---
Fixed for GCC 11.

[Bug tree-optimization/98512] New: “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

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

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

Bug ID: 98512
   Summary: “#pragma GCC diagnostic ignored” ineffective in
conjunction with alias attribute
   Product: gcc
   Version: 11.0
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
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case has been extracted from a glibc build failure on
powerpc64le, but it appears to be target-independent.

This produces a -WWstringop-overread warning at -O2, even though the warning
has been suppressed.

void *
__rawmemchr_ppc (const void *s, int c)
{
#pragma GCC diagnostics push
#pragma GCC diagnostic ignored "-Wstringop-overflow="
#pragma GCC diagnostic ignored "-Wstringop-overread"
  if (c != 0)
return __builtin_memchr (s, c, (unsigned long)-1);
#pragma GCC diagnostics pop
  return (char *)s + __builtin_strlen (s);
}
extern __typeof (__rawmemchr_ppc) __EI___rawmemchr_ppc
  __attribute__((alias ("__rawmemchr_ppc")));

t.c:8:12: warning: ‘__builtin_memchr’ specified bound 18446744073709551615
exceeds maximum object size 9223372036854775807 [-Wstringop-overread]   
8 | return __builtin_memchr (s, c, (unsigned long)-1); 
  |^~

Seen with: 11.0.0 20210104 (experimental)

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

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

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

--- Comment #1 from Florian Weimer  ---
Is the test case really valid? It involves an out-of-bounds array access, after
all.

[Bug rtl-optimization/98788] New: simplify_replace_fn_rtx crash on riscv64-glibc-linux-gnu for glibc sincos32.c

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

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

Bug ID: 98788
   Summary: simplify_replace_fn_rtx crash on
riscv64-glibc-linux-gnu for glibc sincos32.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Created attachment 50026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50026&action=edit
sincos32.i

riscv64-glibc-linux-gnu-gcc -O2 -c sincos32.i

results in:

during RTL pass: reload
../sysdeps/ieee754/dbl-64/sincos32.c: In function ‘__c32’:
../sysdeps/ieee754/dbl-64/sincos32.c:128:1: internal compiler error:
Segmentation fault
  128 | }
  | ^
0xd7358f crash_signal
/var/tmp/bmg/src/gcc/gcc/toplev.c:327
0xd57c77 simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
/var/tmp/bmg/src/gcc/gcc/simplify-rtx.c:408
0xbf60e8 update_equiv
/var/tmp/bmg/src/gcc/gcc/lra-constraints.c:504
0xbf60e8 lra_constraints(bool)
/var/tmp/bmg/src/gcc/gcc/lra-constraints.c:5035
0xbe31ea lra(_IO_FILE*)
/var/tmp/bmg/src/gcc/gcc/lra.c:2332
0xb9f511 do_reload
/var/tmp/bmg/src/gcc/gcc/ira.c:5821
0xb9f511 execute
/var/tmp/bmg/src/gcc/gcc/ira.c:6007

GCC version:

gcc version 11.0.0 20210121 (experimental) [releases/gcc-10 revision
3531f987b2b:b283473daa9:a8800cf79ea7078392bed241aae300a1e0925271] (GCC) 

(I have applied Martin Sebor's fix for PR98512 locally, but that shouldn't
matter.)

[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
This bug is still present.

[Bug rtl-optimization/98788] simplify_replace_fn_rtx crash on riscv64-glibc-linux-gnu for glibc sincos32.c

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

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

--- Comment #2 from Florian Weimer  ---
Indeed, thanks, seems to be working again.

[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

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

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

--- Comment #3 from Florian Weimer  ---
Thanks. The -Werror failure you reported is due to PR98512. Martin has posted a
patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html

Should I open a binutils bug with the generated .s file?

[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

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

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=27243
 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #5 from Florian Weimer  ---
Marking as moved.

[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

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

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

--- Comment #5 from Florian Weimer  ---
Note, patch has been superseded:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html

[Bug c++/58118] Local variables specified with asm("reg") may not work

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #1 from Florian Weimer  ---
Seems to be a duplicate of bug 33661 and bug 98847.

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

[Bug c++/33661] template methods forget explicit local register asm vars

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||nate at verse dot com

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

[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #7 from Florian Weimer  ---
I think libsanitizer falls back to a version-less lookup if the version cannot
be found. Therefore, if the glibc baseline is after 2.3.4, the version-less
lookup will find the unversioned symbol, which has the right behavior.

I don't see any architecture that has two regexec symbols, but does not use
GLIBC_2.3.4 for the most recent symbol, based on this command in the glibc
source tree:

git grep -c ' regexec F' | grep :2$ | cut -d: -f1 | xargs grep ' regexec F'

A comment in the interceptor might make sense, though.

[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address

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

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

--- Comment #9 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #8)
> Even if it does, exporting regexec@@GLIBC_2.3.4 from libsanitizer when glibc
> doesn't support that symbol looks wrong.

I think all the interceptors use unversioned symbols, so this doesn't matter.

Yes, it's quite broken, but when fixing this, you might as well go with the
flow …

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

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

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

--- Comment #45 from Florian Weimer  ---
Statically linking libstdc++ into shared objects is also not too uncommon. 
With luck, the libstdc++ symbols are hidden, but operating on globally shared
across multiple libstdc++s exposes similar issues even without inlining.

[Bug ada/99264] Ada doesn't build against latest glibc

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Florian Weimer  ---
The reason for this change in glibc 2.34 is that the size of the context
information pushed by the kernel has increased by about an order of magnitude
over the last decade.

Missing size check in sigaltstack 
https://bugzilla.kernel.org/show_bug.cgi?id=153531

x86: MINSIGSTKSZ too small for AVX-512F support 
https://sourceware.org/bugzilla/show_bug.cgi?id=20305

Small signal stacks needed to be allocated at run time, using the
kernel-supplied size plus the extra part that the application needs.

[Bug ada/99264] Ada doesn't build against latest glibc

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

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

--- Comment #3 from Florian Weimer  ---
As a stop-gap measure, it might be possible to replace the preprocessor check
with a run-time check during initialization.

[Bug ada/99264] Ada doesn't build against latest glibc

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

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

--- Comment #5 from Florian Weimer  ---
(In reply to Eric Botcazou from comment #4)
> This looks like a serious compatibility breakage on the glibc side though.

POSIX does not require that the constant is usable in preprocessor macros, so
the code has always been invalid (technically speaking).

However, there is little that we can do. The hardware requirements have changed
under us, so even the kernel does not have much choice here. Applications
really have to adapt to the massively increased size of the register file,
there really is no way around that.

[Bug tree-optimization/98512] [11/12 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

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

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

--- Comment #8 from Florian Weimer  ---
This glibc commit works around the GCC issue:

commit 044e603b698093cf48f6e6229e0b66acf05227e4
Author: Florian Weimer 
Date:   Fri Feb 19 13:29:00 2021 +0100

string: Work around GCC PR 98512 in rawmemchr

[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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
I expect that profilers will soon be able to use the shadow stack on x86, which
will be more efficient and reliable than traversing frame pointers.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #32 from Florian Weimer  ---
Fixed via r12-6210-g790854ea7670f1 for dynamically linked code:

commit 790854ea7670f11c14d431c102a49181d2915965
Author: Florian Weimer 
Date:   Tue Jan 4 15:47:30 2022 +0100

libgcc: Use _dl_find_object in _Unwind_Find_FDE

libgcc/ChangeLog:

* unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Call _dl_find_object
if available.

And r13-2706-g6e80a1d164d1f9 for the run-time code registration interface:

commit 6e80a1d164d1f996ad08a512c25a7c2ca893
Author: Thomas Neumann 
Date:   Tue Mar 1 21:57:35 2022 +0100

eliminate mutex in fast path of __register_frame

The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is somewhat expensive even if single-threaded.
There was already a fast-path that avoided taking the mutex if no
frame was registered at all.

This commit eliminates both the mutex and the sorted list from
the atomic fast path, and replaces it with a btree that uses
optimistic lock coupling during lookup. This allows for fully parallel
unwinding and is essential to scale exception handling to large
core counts.

libgcc/ChangeLog:

* unwind-dw2-fde.c (release_registered_frames): Cleanup at
shutdown.
(__register_frame_info_table_bases): Use btree in atomic fast path.
(__deregister_frame_info_bases): Likewise.
(_Unwind_Find_FDE): Likewise.
(base_from_object): Make parameter const.
(classify_object_over_fdes): Add query-only mode.
(get_pc_range): Compute PC range for lookup.
* unwind-dw2-fde.h (last_fde): Make parameter const.
* unwind-dw2-btree.h: New file.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #35 from Florian Weimer  ---
I backported the fixes for building glibc to 2.34 last week, I really expect
the testsuite to be clean there (on x86-64), and on later releases as well.

[Bug libgcc/108433] canadian cross aarch64/x86_64/aarch64 fails to build

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
Sorry, I don't see how this could have ever worked. How can “cc” be the right
compiler in this context?

[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.

[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/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 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 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 c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #11 from Florian Weimer  ---
Clang does not appear to treat this pragma as a statement. Is this also the
MSVC behavior?

int
f (int i)
{
  if (i)
#pragma region
return 1;
#pragma endregion
  return 0;
}

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

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

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

--- Comment #3 from Florian Weimer  ---
I feel we should give AMD some time to comment here. If they can commit
supporting it like Intel did, that alters the design space somewhat.

[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble

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

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

--- Comment #8 from Florian Weimer  ---
(In reply to Peter Bergner from comment #7)
> Florian, can you confirm that -mlong-double-64 comes after the
> -mabi=ibmlongdouble option in the problematical glibc build?

The mailing list post referenced in comment 0 quotes the full command line.
Stripped to the vaguely ABI-ish flags, it's 

-std=gnu11 -fgnu89-inline -O2 -g -m64 -mabi=ibmlongdouble -frounding-math
-fmath-errno  -mno-gnu-attribute -mlong-double-64

So yes, it comes afterwards for this particular command line (and also in
general I think, but we'll know for sure only once we can get past this
particular error).

[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble

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

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

--- Comment #13 from Florian Weimer  ---
Thanks, I can confirm that we can build the glibc test suite once more in
Fedora rawhide.

(Fedora only needs the GCC 12 fix, it's our first GCC version with the float128
default).

[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

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
This will likely need the same preparatory treatment as rejecting implicit
function declarations (bug 91092), for the same reason: Without some care
upfront, introducing the new compiler error will change configure test results
in fully consistent ways, resulting in silently dropped features.

[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

--- Comment #2 from Florian Weimer  ---
It seems that

auto x = 1.0;

will change meaning in C2X (as implemented by GCC) and use type double instead
of int for x. We are probably way too late to fix this (by rejecting the
construct in earlier language modes) before C2X support arrives in GCC.

This may require the same careful treatment as bug 91092 and bug 106416.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #21 from Florian Weimer  ---
(In reply to Richard Biener from comment #20)
> Yeah.  Not sure how often dynamic objects are opened from within threads
> though.

We know that some shared objects call pthread_create from ELF constructors,
which is enough to potentially expose the issue if the ELF constructors are
ordered in certain ways.

> That said, a possibility to enforce "consistency" at least would
> be to save/restore the FP state around dlopen() so that shared objects
> loaded not at program startup would not affect FP state at all?
> The same could be done for shared objects loaded at program startup of
> course.

I think GCC should not automatically link crtfastmath.o with -shared. That will
fix this particular issue for new shared objects, where the
action-at-a-distance issue is most prominent and least desirable I think.

> The other way around would eventually be to make the CTOR __tls, that
> should eventually force all threads to change their FP state(?).

No, all current TLS constructors run lazily when some language construct is
used. There is no way to run TLS constructors at dlopen time. We can in theory
change CPU state using glibc's SETXID broadcast, but it will impact legitimate
uses of the control register (e.g., changes to the FP control word around a
block of code that is executed in a non-default mode).

These days, we'd probably use GNU property notes for something like this
(although we'd likely not make it a global property in the first place, not for
this).

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

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

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

--- Comment #25 from Florian Weimer  ---
(In reply to H.J. Lu from comment #24)
> Dropping crtfastmath.o with -shared makes sense.

Are you going to send a patch? I can give it a try as well (although I'm not
familiar with the GCC specs language).

[Bug tree-optimization/103964] [9/10/11/12 Regression] OVS miscompilation since r0-92313-g5006671f1aaa63cd

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
The kernel version of the macro is called list_for_each_entry. There's a
Stackoverflow question about this issue:

Does Linux kernel list implementation cause UB?
https://stackoverflow.com/questions/64859526/does-linux-kernel-list-implementation-cause-ub

[Bug libgcc/104207] New: [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

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

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

Bug ID: 104207
   Summary: [12 Regression] Crash in _Unwind_Find_FDE if object
lacks unwind information
   Product: gcc
   Version: 12.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: ---
 Build: *-*-linux-gnu

r12-6210 lacks a NULL check for dlfo_eh_frame. This causes crashes when
unwinding through signal frames if the kernel vDSO has not been built with
debuginfo.

[Bug target/104208] New: -mlong-double-64 should override a previous -mabi=ibmlongdouble

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

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

Bug ID: 104208
   Summary: -mlong-double-64 should override a previous
-mabi=ibmlongdouble
   Product: gcc
   Version: 12.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: ---
 Build: powerpc64le-*-linux-gnu

We have trouble building glibc 2.35 with GCC 12 because -mlong-double-64 and
-mabi=ibmlongdouble conflict:

ppc64le: gcc 12 vs -mabi=ibmlongdouble
https://sourceware.org/pipermail/libc-alpha/2022-January/135647.html

glibc needs to build itself with -mabi=ibmlongdouble because that's how the
source tree defaults are laid out, and given our build system, it's very
difficult to remove that for individual files. So I'd appreciate a GCC-side fix
for this.

[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble

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

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

Florian Weimer  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #1 from Florian Weimer  ---
Setting P1 based on off-bug discussions.

[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

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

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

Florian Weimer  changed:

   What|Removed |Added

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

[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

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

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

--- Comment #2 from Florian Weimer  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589177.html

[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

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

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

Florian Weimer  changed:

   What|Removed |Added

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

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

[Bug libstdc++/103133] Binary built with -static using std::thread crashes

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
libstdc++.a still uses weak symbols. I assumed we had already removed all that
weak symbol stuff from libstdc++ for __GLIBC_PREREQ (2, 34).

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #13 from Florian Weimer  ---
Maybe it's possible to provide specific, architecture-independent constraints
for Systemtap-like use cases?

[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34

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

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

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

[PATCH] Avoid expecting nonzero size for access none void* arguments [PR101751]
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585377.html

[Bug rtl-optimization/103762] [12 Regression] glibc master branch is miscompiled by r12-897

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #9 from Florian Weimer  ---
glibc cannot easily work around such unexpected relocations for static or
hidden variables. Static PIE currently requires PI_STATIC_AND_HIDDEN, and with
the GCC 12 behavior, x86 would not be a PI_STATIC_AND_HIDDEN target anymore.
This really has to be fixed in GCC. It's also important to avoid such runtime
relocations for PIE startup time.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #4 from Florian Weimer  ---
I think it's a test bug:

  std::atomic_ref a{ aa };

  std::thread t([&]
{
  a.store(bb);
  a.notify_one();
});
  a.wait(aa);

Due to the use of std::atomic_ref, store() overwrites aa with the value of bb.
If the notify_one() call completes before the wait() call, wait() blocks
because aa == bb (due to the previous store()), and the wakeup never happens
because wakes are not queued.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #7 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Florian Weimer from comment #4)
> >   a.wait(aa);
> 
> This line is undefined and needs to be a.wait(va) anyway.

Yes, that's what I meant. Or  the test needs to use std::atomic, not
std::atomic_ref.

[Bug libstdc++/102567] New: Missing noexcept specialization of std::function

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

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

Bug ID: 102567
   Summary: Missing noexcept specialization of std::function
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

When C++17 made noexcept part of the type system, std::function was not updated
accordingly. As a result, this program fails to compile:

#include 
std::function f;

t.cc:2:32: error: aggregate ‘std::function f’ has incomplete
type and cannot be defined
2 | std::function f;
  |^

In earlier language versions, code like this used to compile because noexcept
was not part of the type system.

Seen with: gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)

[Bug libstdc++/102567] Missing noexcept specialization of std::function

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

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

--- Comment #3 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a libstdc++ bug, we implement what the standard says.
> 
> Maybe it used to compile, but it was meaningless. You could say it was a
> function of void() noexcept, but you could still store a target function
> that throwed, and its operator() could still throw.

Sure, but in my code, I did not do this. The call operator was invoked in a
noexcept context, and the type was expected to match (but of course the
compiler did not check this).

> Both std::move_only_function (P0288) and std::function_ref (P0792) support
> using a function type that is optionally const-qualified and optionally
> noexcept, and it actually means something (it affects what you can store in
> there, and whether they can modify a stateful target object, and whether
> their operator() is noexcept or not). std::function is not going to get
> updated though.

Neither paper seems to cover a polymorphic function type that takes ownership,
though, so I don't quite see how these replace std::function.

Or is std::function semi-deprecated because it poorly matches
capture-by-reference in lambdas?

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

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

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=28458

--- Comment #7 from Florian Weimer  ---
We need to suppress this warning for pthread_setspecific in glibc because it is
incorrect there. There is currently no good way to implement that suppression
unfortunately.

[Bug target/102625] [meta-bug] -mcmodel=large can't link

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
libc_nonshared.a and crt1.o from glibc need build changes even for dynamic
linking.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

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

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

--- Comment #39 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #38)
> Please see PR104688 .  We got a response from Intel, where they guaranteed
> atomicity of certain 16-byte load instructions for Intel CPUs with AVX
> support.
> AFAIK we didn't get similar guarantee from AMD.

I'm trying to work with AMD to get an official statement that covers older CPUs
as well. I have a preliminary statement, but I hope to get to the point that we
can say the rule is the same as for Intel (AVX support can act as a proxy).

[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K&R style is obsolescent

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

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

--- Comment #11 from Florian Weimer  ---
(In reply to David Brown from comment #9)
> Could -Wstrict-prototypes be added to -Wall, or even considered enabling by
> default?  The next C standard will make "void foo()" mean the same as "void
> foo(void)", like in C++, which makes the scope for confusion high.

I think the churn from changing void foo() to void foo(void) to avoid the
warning is too high, and unnecessary for the upcoming C language change. A more
target warning could make sense, though.

[Bug target/107606] New: rs6000: Option not to use parameter save area in variadic function implementations

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

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

Bug ID: 107606
   Summary: rs6000: Option not to use parameter save area in
variadic function implementations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
CC: bergner at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-*-linux-gnu

Programmers tend to call functions like open, openat and prctl through
non-variadic prototypes. As a result, the caller does not set up the parameter
save area. Use of the parameter save area in the glibc implementation then
leads to difficult-to-diagnose (non-localized) memory corruption.

For glibc, we could use either a command-line option or a function attribute.

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

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

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

--- Comment #2 from Florian Weimer  ---
(In reply to Segher Boessenkool from comment #1)
> Or what else is the intention?  Do you have an example of something that was
> hard to debug, maybe?

The prctl(2) manual page documents the prctl function as:

   int prctl(int option, unsigned long arg2, unsigned long arg3,
 unsigned long arg4, unsigned long arg5);



But if you use this prototype to call prctl (potentially through a function
pointer), then the glibc implementation will corrupt the stack in the caller
because it is defined as:

int
prctl (int option, ...)
{
…
}

The prototype in  matches this definition. We use to have an
assembler implementation that did not clobber the caller stack even if called
as a non-variadic function. But that got replaced in glibc 2.32, breaking some
programs. We had similar portability issues with open/openat.

Technically these things are all undefined, and the glibc headers and
implementations are consistent. Users can even declare their own matching
(variadic) prototypes, as required by POSIX for such functions. On the other
hand, the prctl prototype is misdocumented, so it's easy to get that wrong, and
the variadic nature of open/openat is not that widely realized, either.
Basically this is an avoidable portability trap for powerpc64le-linux-gnu, and
maybe we can make life for programmers a bit easier.

[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs

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

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

--- Comment #3 from Florian Weimer  ---
Would you please put a breakpoint on fde_single_encoding_compare and report the
backtrace? Which target are you testing?

[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs

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

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

--- Comment #8 from Florian Weimer  ---
(In reply to Tamar Christina from comment #4)
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111
> #6  __register_frame_info (begin=, ob=0x48cfe8 ) at
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:150
> #7  0x00400798 in frame_dummy () at
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361
> #8  0x00400f90 in __libc_csu_init () at
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361
> #9  0x00400a78 in __libc_start_main () at
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361
> #10 0x00400688 in _start () at
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361

Looks like a build with USE_EH_FRAME_REGISTRY. Unless you have configured with
--explicit-exception-frame-registration=yes, it may mean that
USE_PT_GNU_EH_FRAME was not detected correctly.

[Bug c/107805] New: Spurious warning after redefinition of type

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

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

Bug ID: 107805
   Summary: Spurious warning after redefinition of type
   Product: gcc
   Version: 12.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
  Target Milestone: ---

With gcc-11.3.1-3.fc35.x86_64, this program

typedef int t;
typedef struct { double a; int b; } t;
t x;

produces:

t.c:2:37: error: conflicting types for ‘t’; have ‘struct ’
2 | typedef struct { double a; int b; } t;
  | ^
t.c:1:13: note: previous declaration of ‘t’ with type ‘t’ {aka ‘int’}
1 | typedef int t;
  | ^

which is expected.  But with gcc-12.2.1-3.fc38.x86_64, I get this instead:

t.c:2:37: error: conflicting types for ‘t’; have ‘struct ’
2 | typedef struct { double a; int b; } t;
  | ^
t.c:1:13: note: previous declaration of ‘t’ with type ‘t’ {aka ‘int’}
1 | typedef int t;
  | ^
t.c:3:3: warning: type defaults to ‘int’ in declaration of ‘x’ [-Wimplicit-int]
3 | t x;
  |   ^

Note the spurious warning.  This causes problems with attempts to eliminate
implicit int, so it would be nice to fix this.

[Bug c/107805] [12/13 Regression] Spurious “type defaults to ‘int’” warning after redefinition of type

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79412

--- Comment #1 from Florian Weimer  ---
Started with:

commit 823685221de986afb729910a6f2237f07a377f17
Author: Roger Sayle 
Date:   Wed Sep 1 08:38:39 2021 +0100

C: PR c/79412: Poison decls with error_mark_node after type mismatch

This patch fixes an ICE during error-recovery regression in the C
front-end.
The symptom is that the middle-end's sanity checking assertions fail during
gimplification when being asked to increment an array, which is non-sense.
The issue is that the C-front end has detected the type mismatch and
reported an error to the user, but hasn't provided any indication of this
to the middle-end, simply passing bogus trees that the optimizers recognize
as invalid.

This appears to be a frequently reported ICE with 94730, 94731, 101036
and 101365 all marked as duplicates.

I believe the correct (polite) fix is to mark the mismatched types as
problematic/dubious in the front-end, when the error is spotted, so that
the middle-end has a heads-up and can be a little more forgiving.  This
patch to c-decl.c's duplicate_decls sets (both) mismatched types to
error_mark_node if they are significantly different, and we've issued
an error message.  Alas, this is too punitive for FUNCTION_DECLs where
we store return types, parameter lists, parameter types and attributes
in the type, but fortunately the middle-end is already more cautious
about trusting possibly suspect function types.

This fix required one minor change to the testsuite, typedef-var-2.c
where after conflicting type definitions, we now no longer assume that
the (first or) second definition is the correct one.  This change only
affects the behaviour after seen_error(), so should be relatively safe.

2021-09-01  Roger Sayle  
Joseph Myers  

gcc/c/ChangeLog
PR c/79412
* c-decl.c (duplicate_decls): On significant mismatches, mark the
types of both (non-function) decls as error_mark_node, so that the
middle-end can see the code is malformed.
(free_attr_access_data): Don't process if the type has been set to
error_mark_node.

gcc/testsuite/ChangeLog
PR c/79412
* gcc.dg/pr79412.c: New test case.
* gcc.dg/typedef-var-2.c: Update expeted errors.

[Bug c/107805] [12/13 Regression] Spurious “type defaults to ‘int’” warning after redefinition of type

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

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

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

[PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

[Bug c/107805] [12/13 Regression] Spurious “type defaults to ‘int’” warning after redefinition of type

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

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

Florian Weimer  changed:

   What|Removed |Added

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

[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 #28 from Florian Weimer  ---
(In reply to Peter Cordes from comment #27)
> (In reply to Alexander Monakov from comment #26)
> > Sure, the right course of action seems to be to simply document that atomic
> > types and built-ins are meant to be used on "common" (writeback) memory
> 
> Agreed.  Where in the manual should this go?  Maybe a new subsection of the
> chapter about __atomic builtins where we document per-ISA requirements for
> them to actually work?

Maybe this belongs in the ABI manual? For example, the POWER ABI says that
memcpy needs to work on device memory. Documenting the required memory types
for automics seems along the same lines.

The rules are also potentially different for different targets sharing the same
processor architecture.

[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953

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

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

--- Comment #2 from Florian Weimer  ---
Fixed with the revert in commit 455acc43518744b89d6a795bbba5045bd228060b.

[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953

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

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

Florian Weimer  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Florian Weimer  ---
.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

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

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

--- Comment #8 from Florian Weimer  ---
I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have
fixed this?

I also brought up the initialization issue on the gcc list:

Default initialization of poly-ints

[Bug lto/105727] __builtin_constant_p expansion in LTO

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
(In reply to Martin Liška from comment #1)
> So the question is if the LTO time expansion is correct or not?

What's the argument in favor of it being incorrect? Sorry, I just don't see it.

[Bug middle-end/101415] New: [12 Regression] Bogus -Warray-bounds warning with stpcpy

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

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

Bug ID: 101415
   Summary: [12 Regression] Bogus -Warray-bounds warning with
stpcpy
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

This (derived from the glibc function of the same name):

char *
nis_local_group (char *cptr)
{
  static char __nisgroup[1025];

  if (*cptr != '\0' && __builtin_strlen (cptr) < 1024)
{
  char *cp = __builtin_stpcpy (__nisgroup, cptr);

  if (cp[-1] != '.')
__builtin_abort ();
}

  return __nisgroup;
}

results in 

/tmp/t.c: In function ‘nis_local_group’:
/tmp/t.c:10:13: error: array subscript -1 is outside array bounds of
‘char[1025]
’ [-Werror=array-bounds]
   10 |   if (cp[-1] != '.')
  |   ~~^~~~
/tmp/t.c:4:15: note: at offset -1 into object ‘__nisgroup’ of size 1025
4 |   static char __nisgroup[1025];
  |   ^~

with -O2 -Wall on x86-64 gcc version 12.0.0 20210711 (experimental) [master
revision :97a8a2829:269256f33c51222167ad461f775d5468bb5ecaf5].

The warning is bogus because stpcpy returns a pointer to the NUL byte, which is
not at the first byte of __nisgroup after the stpcpy. The glibc original does
not have this check, so it is buggy, but the warning seems overly aggressive if
it cannot detect non-empty strings for stpcpy.

[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
Martin and I discussed this before. I believe the use of attribute access with
pthread_setspecific is quite wrong because it does not dereference the pointer
at all.

Consider this example:

#include 
#include 

void
f (pthread_key_t key)
{
  pthread_setspecific (key, MAP_FAILED);
}

There is no way POSIX would consider this code invalid, but yet we warn:

t.c: In function ‘f’:
t.c:7:3: warning: ‘pthread_setspecific’ expecting 1 byte in a region of size 0
[-Wstringop-overread]
7 |   pthread_setspecific (key, MAP_FAILED);
  |   ^
In file included from t.c:1:
/usr/include/pthread.h:1308:12: note: in a call to function
‘pthread_setspecific’ declared with attribute ‘access (none, 2)’
 1308 | extern int pthread_setspecific (pthread_key_t __key,
  |^~~


Removing attribute access is not a solution because the warning is implied by
the const void * argument type already. Access type none is merely declaration
that the pointed-to memory need not be initialized, it still needs to be a
valid address.

So yes, I consider this a GCC diagnostics bug: not for access type none, but
the fact that the diagnostic cannot be disabled at all for functions like
pthread_setspecific.

[Bug lto/102059] New: Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")

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

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

Bug ID: 102059
   Summary: Incorrect always_inline diagnostic in LTO mode with
#pragma GCC target("cpu=power10")
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Keywords: diagnostic, rejects-valid
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le-redhat-linux

Created attachment 51354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51354&action=edit
basic_op.ii.xz

To reproduce, compile the attached file with:

g++ -c -O2 -flto -mcpu=power8 basic_op.ii

In file included from
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProduct.h:18,
 from /usr/include/eigen3/Eigen/Core:350,
 from /builddir/build/BUILD/gdl-1.0.0/src/includefirst.hpp:49,
 from /builddir/build/BUILD/gdl-1.0.0/src/basegdl.hpp:21,
 from /builddir/build/BUILD/gdl-1.0.0/src/nullgdl.hpp:21,
 from /builddir/build/BUILD/gdl-1.0.0/src/basic_op.cpp:27:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In function 
 Eigen::internal::ploadRhsMMA(float const*, float
__vector(4)&)void’:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductCommon.h:215:46:
error: inlining failed in call to ‘always_inline’
‘Eigen::internal::ploadRhs(float const*)float
__vector(4)’: target specific option mismatch
  215 | EIGEN_ALWAYS_INLINE Packet ploadRhs(const Scalar* rhs)
  |  ^~~~
In file included from
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProduct.h:38,
 from /usr/include/eigen3/Eigen/Core:350,
 from /builddir/build/BUILD/gdl-1.0.0/src/includefirst.hpp:49,
 from /builddir/build/BUILD/gdl-1.0.0/src/basegdl.hpp:21,
 from /builddir/build/BUILD/gdl-1.0.0/src/nullgdl.hpp:21,
 from /builddir/build/BUILD/gdl-1.0.0/src/basic_op.cpp:27:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h:128:34:
note: called from here
  128 |   rhsV = ploadRhs((const Scalar*)(rhs));
  |  ^~


The reproducer is minimally reduced code from gdl (GNU Data Language) which
uses the Eigen library.

The error does not happen if -flto is removed.

[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")

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

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

--- Comment #12 from Florian Weimer  ---
(In reply to Richard Biener from comment #10)
> As of HTM it would make the testcase a user error - when using -mcpu=power10
> it would require building with -mcpu=power8 -mno-htm?

Or -mcpu=power8 should imply -mno-htm. It's not 100% compatible for sure, but
so is removing a feature from a later CPU that was present in an earlier
version and enabled by default in GCC. I suspect it's better to take the
compatibility hit at run time, rather than later at run time (once the users
get their hands on POWER10 hardware).

[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 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] 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 #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 #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 #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 #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 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 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 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.