[committed] system.h: Include in system.h unconditionally

[Jakub Jelinek via Gcc-patches]

On Sun, May 01, 2022 at 07:06:53PM +0100, Jonathan Wakely wrote:
> > >> the reason is that "gcc/analyzer/region-model.cc” uses 
> > >> initializer_lists, and it seems that 
> > >> is not transitively included by any used headers for _LIBCPP_VERSION < 
> > >> 4000.  I fixed that locally by
> > >> adding initializer_list into system.h (and adding 
> > >> INCLUDE_INITIALIZER_LIST to the top of gcc/analyzer/region-model.cc)
> > >> - with that change those versions do bootstrap and test OK***
> > >
> > > From what I can see, with libstdc++ it works because  which is
> > > included by system.h includes .
> > > If I rename initializer_list in analyzer/region-model.ii to 
> > > initializer_listx, I
> > > also get:
> > > ../../gcc/analyzer/region-model.cc: In function ‘void 
> > > ana::selftest::test_binop_svalue_folding()’:
> > > ../../gcc/analyzer/region-model.cc:4966:48: error: deducing from 
> > > brace-enclosed initializer list requires ‘#include ’
> > > 4508 |
> > >  +++ |+#include 
> > > 4509 | static void
> > > ..
> > > 4966 | for (auto op : {BIT_IOR_EXPR, TRUTH_OR_EXPR})
> > >  |^
> > > ../../gcc/analyzer/region-model.cc:4978:49: error: deducing from 
> > > brace-enclosed initializer list requires ‘#include ’
> > > 4978 | for (auto op : {BIT_AND_EXPR, TRUTH_AND_EXPR})
> > >  | ^
> > >
> > > I think we have 2 options, one is do what you wrote above,
> > > INCLUDE_INITIALIZER_LIST defined before system.h to get #include 
> > > .
> > > The other option is just to include that unconditionally, it is a very 
> > > small
> > > header.  For libstdc++ it will make no difference as it is included anyway
> > > and the header is really small there, libc++ includes  which 
> > > isn't
> > > normally included and system.h includes  instead.
> >
> > I’d say unconditionally would be OK. I suppose the chance that any host
> > C++ is good enough to build GCC as-is but fails to provide
> >  is zero?
> >
> 
> Yes, definitely.
> 
> > I’d be OK to do this change without a new RC even.

I've bootstrapped/regtested this on 12 branch on x86_64-linux and
i686-linux, committed to both.

2022-05-02  Jakub Jelinek  

* system.h: Include initializer_list.

--- gcc/system.h.jj 2022-04-28 15:56:06.786792094 +0200
+++ gcc/system.h2022-05-01 20:23:04.373273340 +0200
@@ -239,6 +239,7 @@ extern int errno;
 # include 
 #endif
 # include 
+# include 
 # include 
 # include 
 # include 


Jakub

Re: [PATCH 1/2] libstdc++: case-sensitivity in hexfloat std::from_chars [PR105441]

[Jakub Jelinek via Gcc-patches]

On Sun, May 01, 2022 at 08:09:05PM +0100, Jonathan Wakely via Gcc-patches wrote:
> On Sun, 1 May 2022 at 19:22, Patrick Palka via Libstdc++
>  wrote:
> >
> > The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c
> > overlooked that the exponent part can also begin with an uppercase 'P'.
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11, and possibly 
> > the
> > 12 branch now for 12.1?
> 
> OK for trunk, and as it's a regression since gcc-11 I'd recommend
> release manager approval for 12.1 as well, but it's the RMs call.

Ok for 12.1.

> > PR libstdc++/105441
> >
> > libstdc++-v3/ChangeLog:
> >
> > * src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
> > Also accept 'P' as the start of the exponent.
> > * testsuite/20_util/from_chars/7.cc: Add corresponding testcase.

Jakub

[PATCH][PUSHED] libgcov: add ATTRIBUTE_UNUSED for dump_string

[Martin Liška]

Mitigates the following clang warning:
libgcc/libgcov-driver.c:416:1: warning: unused function 'dump_string' 
[-Wunused-function]

libgcc/ChangeLog:

* libgcov-driver.c: Add ATTRIBUTE_UNUSED.
---
 libgcc/libgcov-driver.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index d4517d269eb..aba62d588b8 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -413,6 +413,7 @@ dump_counter (gcov_type counter,
 /* Dump the STRING using the DUMP handler called with ARG.  */
 
 static inline void
+ATTRIBUTE_UNUSED
 dump_string (const char *string,
 void (*dump_fn) (const void *, unsigned, void *),
 void *arg)
-- 
2.36.0

Re: [PATCH v1] RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZERO

[Kito Cheng via Gcc-patches]

Ack, I am OoO during 5/1-5/4, I'll start looking at those patches in
the GCC 13 queue including this one :)

On Fri, Apr 29, 2022 at 6:12 AM Philipp Tomsich
 wrote:
>
> Kito,
>
> Did you have a chance to take a look at this one?
>
> I assume this will have to wait until we reopen for 13...
> OK for 13?  Also: OK for a backport (once a branch for that exists)?
>
> Philipp.
>
>
> On Sun, 24 Apr 2022 at 01:44, Philipp Tomsich  
> wrote:
> >
> > The Zbb support has introduced ctz and clz to the backend, but some
> > transformations in GCC need to know what the value of c[lt]z at zero
> > is. This affects how the optab is generated and may suppress use of
> > CLZ/CTZ in tree passes.
> >
> > Among other things, this is needed for the transformation of
> > table-based ctz-implementations, such as in deepsjeng, to work
> > (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838).
> >
> > Prior to this change, the test case from PR90838 would compile to
> > on RISC-V targets with Zbb:
> >   myctz:
> > lui a4,%hi(.LC0)
> > ld  a4,%lo(.LC0)(a4)
> > neg a5,a0
> > and a5,a5,a0
> > mul a5,a5,a4
> > lui a4,%hi(.LANCHOR0)
> > addia4,a4,%lo(.LANCHOR0)
> > srlia5,a5,58
> > sh2add  a5,a5,a4
> > lw  a0,0(a5)
> > ret
> >
> > After this change, we get:
> >   myctz:
> > ctz a0,a0
> > andia0,a0,63
> > ret
> >
> > Testing this with deepsjeng_r (from SPEC 2017) against QEMU, this
> > shows a clear reduction in dynamic instruction count:
> >  - before  1961888067076
> >  - after   1907928279874 (2.75% reduction)
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.h (CLZ_DEFINED_VALUE_AT_ZERO): Implement.
> > (CTZ_DEFINED_VALUE_AT_ZERO): Same.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
> >   when compiling for riscv64.
> > * gcc.target/riscv/zbb-ctz.c: New test.
> >
> > Signed-off-by: Philipp Tomsich 
> > Signed-off-by: Manolis Tsamis 
> > Co-developed-by: Manolis Tsamis 
> >
> > ---
> >  gcc/config/riscv/riscv.h|  5 ++
> >  gcc/testsuite/gcc.dg/pr90838.c  |  2 +
> >  gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c | 65 
> >  gcc/testsuite/gcc.target/riscv/zbb-ctz.c| 66 +
> >  4 files changed, 138 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-ctz.c
> >
> > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> > index 4210e252255..95f72e2fd3f 100644
> > --- a/gcc/config/riscv/riscv.h
> > +++ b/gcc/config/riscv/riscv.h
> > @@ -1019,4 +1019,9 @@ extern void riscv_remove_unneeded_save_restore_calls 
> > (void);
> >
> >  #define HARD_REGNO_RENAME_OK(FROM, TO) riscv_hard_regno_rename_ok (FROM, 
> > TO)
> >
> > +#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
> > +  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
> > +#define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
> > +  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
> > +
> >  #endif /* ! GCC_RISCV_H */
> > diff --git a/gcc/testsuite/gcc.dg/pr90838.c b/gcc/testsuite/gcc.dg/pr90838.c
> > index 41c5dab9a5c..162bd6f51d0 100644
> > --- a/gcc/testsuite/gcc.dg/pr90838.c
> > +++ b/gcc/testsuite/gcc.dg/pr90838.c
> > @@ -1,5 +1,6 @@
> >  /* { dg-do compile } */
> >  /* { dg-options "-O2 -fdump-tree-forwprop2-details" } */
> > +/* { dg-additional-options "-march=rv64gc_zbb" { target riscv64*-*-* } } */
> >
> >  int ctz1 (unsigned x)
> >  {
> > @@ -57,3 +58,4 @@ int ctz4 (unsigned long x)
> >  }
> >
> >  /* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
> > aarch64*-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
> > riscv64*-*-* } } } */
> > diff --git a/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c 
> > b/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
> > new file mode 100644
> > index 000..b903517197a
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
> > @@ -0,0 +1,65 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-march=rv32gc_zbb -mabi=ilp32" } */
> > +/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
> > +
> > +int ctz1 (unsigned x)
> > +{
> > +  static const char table[32] =
> > +{
> > +  0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
> > +  31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
> > +};
> > +
> > +  return table[((unsigned)((x & -x) * 0x077CB531U)) >> 27];
> > +}
> > +
> > +int ctz2 (unsigned x)
> > +{
> > +#define u 0
> > +  static short table[64] =
> > +{
> > +  32, 0, 1,12, 2, 6, u,13, 3, u, 7, u, u, u, u,14,
> > +  10, 4, u, u, 8, u, u,25, u, u, u, u, u,21,27,15,
> > +  31,11, 5, u, u, u, u, u, 9, u, u,24, u, u,20,26,
> > +  30, u, u, u, u,23, u,19,29, u,22,18,28,17,16, u
> > +};
> > +
> > +  x = (x 

Re: [PATCH 1/2] libstdc++: case-sensitivity in hexfloat std::from_chars [PR105441]

[Jonathan Wakely via Gcc-patches]

On Sun, 1 May 2022 at 19:22, Patrick Palka via Libstdc++
 wrote:
>
> The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c
> overlooked that the exponent part can also begin with an uppercase 'P'.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11, and possibly 
> the
> 12 branch now for 12.1?

OK for trunk, and as it's a regression since gcc-11 I'd recommend
release manager approval for 12.1 as well, but it's the RMs call.



>
> PR libstdc++/105441
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
> Also accept 'P' as the start of the exponent.
> * testsuite/20_util/from_chars/7.cc: Add corresponding testcase.
> ---
>  libstdc++-v3/src/c++17/floating_from_chars.cc  | 2 +-
>  libstdc++-v3/testsuite/20_util/from_chars/7.cc | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
> b/libstdc++-v3/src/c++17/floating_from_chars.cc
> index 13de1e346ab..e7f3a58cf18 100644
> --- a/libstdc++-v3/src/c++17/floating_from_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
> @@ -664,7 +664,7 @@ namespace
>
>  // Parse the written exponent.
>  int written_exponent = 0;
> -if (first != last && *first == 'p')
> +if (first != last && (*first == 'p' || *first == 'P'))
>{
> // Tentatively consume the 'p' and try to parse a decimal number.
> const char* const fallback_first = first;
> diff --git a/libstdc++-v3/testsuite/20_util/from_chars/7.cc 
> b/libstdc++-v3/testsuite/20_util/from_chars/7.cc
> index 2a78c7441e2..1aa9b230531 100644
> --- a/libstdc++-v3/testsuite/20_util/from_chars/7.cc
> +++ b/libstdc++-v3/testsuite/20_util/from_chars/7.cc
> @@ -96,6 +96,7 @@ constexpr testcase testcases[] = {
>{ "1p-1", 4, {}, 0x1p-1 },
>{ "0", 1, {}, 0.0 },
>{ "A", 1, {}, 0xA },
> +  { "1.ABCDEFP+10", 12, {}, 0x1.ABCDEFP+10 },
>{ "-1", 2, {}, -1.0 },
>{ "-0", 2, {}, -0.0 },
>{ "42", 2, {}, 0x42p0 },
> --
> 2.36.0.44.g0f828332d5
>

Re: [PATCH 2/2] libstdc++: Don't use std::tolower in [PR103911]

[Jonathan Wakely via Gcc-patches]

On Sun, 1 May 2022 at 19:21, Patrick Palka via Libstdc++
 wrote:
>
> As in r12-6281-gc83ecfbe74a5cf for std::isdigit,  shouldn't
> use std::tolower either I think.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11 and the
> 12 branch after it's thawed?

OK, thanks.

>
> PR libstdc++/103911
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17/floating_from_chars.cc (find_end_of_float): Accept
> two possible delimeters for the exponent part in the form of a
> (possibly NULL) string of length two.  Don't use std::tolower.
> (pattern): Adjust calls to find_end_of_float accordingly.
> ---
>  libstdc++-v3/src/c++17/floating_from_chars.cc | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
> b/libstdc++-v3/src/c++17/floating_from_chars.cc
> index e7f3a58cf18..5d2a931d5dd 100644
> --- a/libstdc++-v3/src/c++17/floating_from_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
> @@ -40,7 +40,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #if _GLIBCXX_HAVE_XLOCALE_H
> @@ -142,10 +141,10 @@ namespace
>
>// Find initial portion of [first, last) containing a floating-point 
> number.
>// The string `digits` is either `dec_digits` or `hex_digits`
> -  // and `exp` is 'e' or 'p' or '\0'.
> +  // and `exp` is "eE", "pP" or NULL.
>const char*
>find_end_of_float(const char* first, const char* last, const char* digits,
> -   char exp)
> +   const char *exp)
>{
>  while (first < last && strchr(digits, *first) != nullptr)
>++first;
> @@ -155,7 +154,7 @@ namespace
> while (first < last && strchr(digits, *first))
>   ++first;
>}
> -if (first < last && exp != 0 && std::tolower((unsigned char)*first) == 
> exp)
> +if (first < last && exp != nullptr && (*first == exp[0] || *first == 
> exp[1]))
>{
> ++first;
> if (first < last && (*first == '-' || *first == '+'))
> @@ -237,7 +236,7 @@ namespace
>
> if ((last - first + 2) > buffer_resource::guaranteed_capacity())
>   {
> -   last = find_end_of_float(first + neg, last, digits, 'p');
> +   last = find_end_of_float(first + neg, last, digits, "pP");
>  #ifndef __cpp_exceptions
> if ((last - first + 2) > buffer_resource::guaranteed_capacity())
>   {
> @@ -261,7 +260,7 @@ namespace
> if ((last - first) > buffer_resource::guaranteed_capacity())
>   {
> last = find_end_of_float(first + neg, last, digits,
> -"e"[fmt == chars_format::fixed]);
> +fmt == chars_format::fixed ? nullptr : 
> "eE");
>  #ifndef __cpp_exceptions
> if ((last - first) > buffer_resource::guaranteed_capacity())
>   {
> --
> 2.36.0.44.g0f828332d5
>

[PATCH 2/2] libstdc++: Don't use std::tolower in [PR103911]

[Patrick Palka via Gcc-patches]

As in r12-6281-gc83ecfbe74a5cf for std::isdigit,  shouldn't
use std::tolower either I think.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11 and the
12 branch after it's thawed?

PR libstdc++/103911

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc (find_end_of_float): Accept
two possible delimeters for the exponent part in the form of a
(possibly NULL) string of length two.  Don't use std::tolower.
(pattern): Adjust calls to find_end_of_float accordingly.
---
 libstdc++-v3/src/c++17/floating_from_chars.cc | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index e7f3a58cf18..5d2a931d5dd 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -40,7 +40,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #if _GLIBCXX_HAVE_XLOCALE_H
@@ -142,10 +141,10 @@ namespace
 
   // Find initial portion of [first, last) containing a floating-point number.
   // The string `digits` is either `dec_digits` or `hex_digits`
-  // and `exp` is 'e' or 'p' or '\0'.
+  // and `exp` is "eE", "pP" or NULL.
   const char*
   find_end_of_float(const char* first, const char* last, const char* digits,
-   char exp)
+   const char *exp)
   {
 while (first < last && strchr(digits, *first) != nullptr)
   ++first;
@@ -155,7 +154,7 @@ namespace
while (first < last && strchr(digits, *first))
  ++first;
   }
-if (first < last && exp != 0 && std::tolower((unsigned char)*first) == exp)
+if (first < last && exp != nullptr && (*first == exp[0] || *first == 
exp[1]))
   {
++first;
if (first < last && (*first == '-' || *first == '+'))
@@ -237,7 +236,7 @@ namespace
 
if ((last - first + 2) > buffer_resource::guaranteed_capacity())
  {
-   last = find_end_of_float(first + neg, last, digits, 'p');
+   last = find_end_of_float(first + neg, last, digits, "pP");
 #ifndef __cpp_exceptions
if ((last - first + 2) > buffer_resource::guaranteed_capacity())
  {
@@ -261,7 +260,7 @@ namespace
if ((last - first) > buffer_resource::guaranteed_capacity())
  {
last = find_end_of_float(first + neg, last, digits,
-"e"[fmt == chars_format::fixed]);
+fmt == chars_format::fixed ? nullptr : 
"eE");
 #ifndef __cpp_exceptions
if ((last - first) > buffer_resource::guaranteed_capacity())
  {
-- 
2.36.0.44.g0f828332d5

[PATCH 1/2] libstdc++: case-sensitivity in hexfloat std::from_chars [PR105441]

[Patrick Palka via Gcc-patches]

The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c
overlooked that the exponent part can also begin with an uppercase 'P'.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11, and possibly the
12 branch now for 12.1?

PR libstdc++/105441

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
Also accept 'P' as the start of the exponent.
* testsuite/20_util/from_chars/7.cc: Add corresponding testcase.
---
 libstdc++-v3/src/c++17/floating_from_chars.cc  | 2 +-
 libstdc++-v3/testsuite/20_util/from_chars/7.cc | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index 13de1e346ab..e7f3a58cf18 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -664,7 +664,7 @@ namespace
 
 // Parse the written exponent.
 int written_exponent = 0;
-if (first != last && *first == 'p')
+if (first != last && (*first == 'p' || *first == 'P'))
   {
// Tentatively consume the 'p' and try to parse a decimal number.
const char* const fallback_first = first;
diff --git a/libstdc++-v3/testsuite/20_util/from_chars/7.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/7.cc
index 2a78c7441e2..1aa9b230531 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/7.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/7.cc
@@ -96,6 +96,7 @@ constexpr testcase testcases[] = {
   { "1p-1", 4, {}, 0x1p-1 },
   { "0", 1, {}, 0.0 },
   { "A", 1, {}, 0xA },
+  { "1.ABCDEFP+10", 12, {}, 0x1.ABCDEFP+10 },
   { "-1", 2, {}, -1.0 },
   { "-0", 2, {}, -0.0 },
   { "42", 2, {}, 0x42p0 },
-- 
2.36.0.44.g0f828332d5

Re: [PATCH v4] x86: Add -m[no-]direct-extern-access

[Fāng-ruì Sòng via Gcc-patches]

On Tue, Feb 8, 2022 at 7:05 PM H.J. Lu via Gcc-patches
 wrote:
>
> On Tue, Feb 8, 2022 at 6:38 PM Hongtao Liu  wrote:
> >
> > On Fri, Jan 28, 2022 at 5:53 AM H.J. Lu via Gcc-patches
> >  wrote:
> > >
> > > The v3 patch was posted at
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574847.html
> > >
> > > There is no progress with repeated pings since then.  Glibc 2.35 and
> > > binutils 2.38 will support GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
> > > I'd like to remove copy relocation to improve security and performance
> > > on x86 in GCC 12.  Here is the v4 patch
> >   This patch won't change default behavior for copy relocation(to
> > avoid conflict with existing .so files),
> > just give users an option under which copy relocation can be removed.
> >   The removal of copy relocation is an optimization of the linker(Also
> > improves security), whose
> > patches have been approved and committed to glibc2.35[1], binutils2.38[2].
> >   The compiler part is the final step in completing this optimization.
>
> Thanks for looking into it.  Since the new behavior is off by default and
> none of the maintainers feel comfortable to review my patch,  which is
> related to linker and glibc, for the last 6 months,  now is the good time
> to check it in as any other time.  I will check it in tomorrow.

Shall we move forward with "x86-64: Remove HAVE_LD_PIE_COPYRELOC"
(https://gcc.gnu.org/pipermail/gcc-patches/2021-November/582987.html)?
It's more about the correct behavior for -fpie.

The -mno-direct-extern-access transition will certainly take a long
time, but we should not let that block fixing the GCC 5 x86-64
regression.

> > [1] https://sourceware.org/pipermail/libc-alpha/2021-October/131742.html
> > [2] https://sourceware.org/pipermail/binutils/2021-July/117308.html
> > >
> > > 1. Rename the common option to x86 specific -mdirect-extern-access option.
> > > 2. Remove GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS linker check.
> > > 3. Use the existing GNU property function in x86 backend.
> > >
> > > This new behavior is off by default.  Are there any objections?
> > >
> > > Changes in the v3 patch.
> > >
> > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to
> > > GNU binutils 2.38.  But the -z indirect-extern-access linker option is
> > > only available for Linux/x86.  However, the --max-cache-size=SIZE linker
> > > option was also addded within a day.  --max-cache-size=SIZE is used to
> > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support.
> > >
> > > Changes in the v2 patch.
> > >
> > > 1. Rename the option to -fdirect-extern-access.
> > >
> > > ---
> > > On systems with copy relocation:
> > > * A copy in executable is created for the definition in a shared library
> > > at run-time by ld.so.
> > > * The copy is referenced by executable and shared libraries.
> > > * Executable can access the copy directly.
> > >
> > > Issues are:
> > > * Overhead of a copy, time and space, may be visible at run-time.
> > > * Read-only data in the shared library becomes read-write copy in
> > > executable at run-time.
> > > * Local access to data with the STV_PROTECTED visibility in the shared
> > > library must use GOT.
> > >
> > > On systems without function descriptor, function pointers vary depending
> > > on where and how the functions are defined.
> > > * If the function is defined in executable, it can be the address of
> > > function body.
> > > * If the function, including the function with STV_PROTECTED visibility,
> > > is defined in the shared library, it can be the address of the PLT entry
> > > in executable or shared library.
> > >
> > > Issues are:
> > > * The address of function body may not be used as its function pointer.
> > > * ld.so needs to search loaded shared libraries for the function pointer
> > > of the function with STV_PROTECTED visibility.
> > >
> > > Here is a proposal to remove copy relocation and use canonical function
> > > pointer:
> > >
> > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must
> > > use GOT.
> > >   a. Linker may optimize out GOT access if the data is defined in PIE or
> > >   non-PIE.
> > > 2. Read-only data in the shared library remain read-only at run-time
> > > 3. Address of global data with the STV_PROTECTED visibility in the shared
> > > library is the address of data body.
> > >   a. Can use IP-relative access.
> > >   b. May need GOT without IP-relative access.
> > > 4. For systems without function descriptor,
> > >   a. All global function pointers of undefined functions in PIE and
> > >   non-PIE must use GOT.  Linker may optimize out GOT access if the
> > >   function is defined in PIE or non-PIE.
> > >   b. Function pointer of functions with the STV_PROTECTED visibility in
> > >   executable and shared library is the address of function body.
> > >i. Can use IP-relative access.
> > >ii. May need GOT without IP-relative access.
> > >iii. Branches to undefined functions may 

New Swedish PO file for 'gcc' (version 12.1-b20220403)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-12.1-b20220403.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: PING: [PATCH v2] x86: Fix -fsplit-stack feature detection via TARGET_CAN_SPLIT_STACK

[Sören Tempel via Gcc-patches]

Pinging this again. This time with i386 port maintainers in CC.

Summary: The macro guards for TARGET_CAN_SPLIT_STACK on i386 are not
aligned with the implementation of ix86_supports_split_stack. That is,
on systems using musl libc ix86_supports_split_stack errors-out (since
-fsplit-stack is not supported in conjunction with musl) but the feature
test macro TARGET_CAN_SPLIT_STACK is still defined on these systems.
This prevents gccgo from compiling on musl-based systems. On other
architectures which support -fsplit-stack TARGET_CAN_SPLIT_STACK
seems to be defined correctly.

See: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590688.html

Greetings,
Sören Tempel

Sören Tempel  wrote:
> Ping.
> 
> Summary: Currently, the macro guards for TARGET_CAN_SPLIT_STACK are not
> aligned with the implementation of ix86_supports_split_stack on x86.
> That is, on musl systems TARGET_CAN_SPLIT_STACK is defined even though
> -fsplit-stack is not supported (via ix86_supports_split_stack). This
> prevents gccgo (which uses TARGET_CAN_SPLIT_STACK) from compiling on
> musl systems. The proposed patch attempts to align the behavior of
> ix86_supports_split_stack and TARGET_CAN_SPLIT_STACK.
> 
> See: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590688.html
> 
> Greetings,
> Sören
> 
> Sören Tempel  wrote:
> > Since commit c163647ffbc9a20c8feb6e079dbecccfe016c82e -fsplit-stack
> > is only supported on glibc targets. However, this original commit
> > required some fixups. As part of the fixup, the changes to the
> > gnu-user-common.h and gnu.h were partially reverted in commit
> > 60953a23d57b13a672f751bec0c6eefc059eb1ab thus causing TARGET_CAN_SPLIT_STACK
> > to be defined for non-glibc targets even though -fsplit-stack is
> > actually not supported and attempting to use it causes a runtime error.
> > 
> > This causes gcc internal code, such as ./gcc/go/gospec.c to not
> > correctly detect that -fsplit-stack is not supported and thus causes
> > gccgo to fail compilation on non-glibc targets.
> > 
> > This commit ensures that TARGET_CAN_SPLIT_STACK is only set if the
> > default libc is glibc. It is presently unclear to me if there is a
> > better way to detect glibc at pre-processor time.
> > 
> > The proposed changes have been tested on x86 and x86_64 Alpine Linux
> > (which uses musl libc) and fix compilation of gccgo for this target.
> > 
> > Signed-off-by: Sören Tempel 
> > 
> > gcc/ChangeLog:
> > 
> > * config/i386/gnu-user-common.h (defined): Only define
> > TARGET_CAN_SPLIT_STACK for glibc targets.
> > * config/i386/gnu.h (defined): Ditto.
> > ---
> > Changes since v1: Use (DEFAULT_LIBC == LIBC_GLIBC) instead of
> > OPTION_GLIBC_P to detect use of glibc in a pre-processor context.
> > 
> > Is there a better way to detect use of glibc in the config header?
> > 
> >  gcc/config/i386/gnu-user-common.h | 5 +++--
> >  gcc/config/i386/gnu.h | 5 +++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/gcc/config/i386/gnu-user-common.h 
> > b/gcc/config/i386/gnu-user-common.h
> > index 00226f5a455..e126c3fa9fa 100644
> > --- a/gcc/config/i386/gnu-user-common.h
> > +++ b/gcc/config/i386/gnu-user-common.h
> > @@ -66,7 +66,8 @@ along with GCC; see the file COPYING3.  If not see
> >  #define STACK_CHECK_STATIC_BUILTIN 1
> >  
> >  /* We only build the -fsplit-stack support in libgcc if the
> > -   assembler has full support for the CFI directives.  */
> > -#if HAVE_GAS_CFI_PERSONALITY_DIRECTIVE
> > +   assembler has full support for the CFI directives.  Also
> > +   we only support -fsplit-stack on glibc targets.  */
> > +#if HAVE_GAS_CFI_PERSONALITY_DIRECTIVE && (DEFAULT_LIBC == LIBC_GLIBC)
> >  #define TARGET_CAN_SPLIT_STACK
> >  #endif
> > diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
> > index 25fbc07f58c..17494333bb9 100644
> > --- a/gcc/config/i386/gnu.h
> > +++ b/gcc/config/i386/gnu.h
> > @@ -41,8 +41,9 @@ along with GCC.  If not, see 
> > .
> >  #define TARGET_THREAD_SSP_OFFSET0x14
> >  
> >  /* We only build the -fsplit-stack support in libgcc if the
> > -   assembler has full support for the CFI directives.  */
> > -#if HAVE_GAS_CFI_PERSONALITY_DIRECTIVE
> > +   assembler has full support for the CFI directives.  Also
> > +   we only support -fsplit-stack on glibc targets.  */
> > +#if HAVE_GAS_CFI_PERSONALITY_DIRECTIVE && (DEFAULT_LIBC == LIBC_GLIBC)
> >  #define TARGET_CAN_SPLIT_STACK
> >  #endif
> >  /* We steal the last transactional memory word.  */

[COMMITTED] Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw.

[Aldy Hernandez via Gcc-patches]

We are ICEing in set_range_info_raw because value_range_kind cannot be
VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE /
VR_ANTI_RANGE.  Most of the time setting a VR_VARYING as a global
range makes no sense.  However, we can have a range spanning the
entire domain (VR_RANGE of [MIN,MAX] which is essentially a
VR_VARYING), if the nonzero bits are set.

This was working before because set_range_info_raw allows setting
VR_RANGE of [MIN, MAX].  However, when going through an irange, we
normalize this to a VR_VARYING, thus causing the ICE.  It's
interesting that other calls to set_range_info with an irange haven't
triggered this.

One solution would be to just ignore VR_VARYING and bail, since
set_range_info* is really an update of the current range semantic
wise.  After all, we keep the nonzero bits which provide additional
info.  But this would be a change in behavior, so not suitable until
after GCC 12 is released.  So in order to keep with current behavior
we can just denormalize the varying to VR_RANGE.

Tested on x86-64 Linux.

PR tree-optimization/105432

gcc/ChangeLog:

* tree-ssanames.cc (set_range_info): Denormalize VR_VARYING to
VR_RANGE before passing a piecewise range to set_range_info_raw.
---
 gcc/tree-ssanames.cc | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-ssanames.cc b/gcc/tree-ssanames.cc
index c957597af4f..05536cd2f74 100644
--- a/gcc/tree-ssanames.cc
+++ b/gcc/tree-ssanames.cc
@@ -395,8 +395,17 @@ set_range_info (tree name, enum value_range_kind 
range_type,
 {
   gcc_assert (!POINTER_TYPE_P (TREE_TYPE (name)));
 
-  /* A range of the entire domain is really no range at all.  */
   tree type = TREE_TYPE (name);
+  if (range_type == VR_VARYING)
+{
+  /* SSA_NAME_RANGE_TYPE can only hold a VR_RANGE or
+VR_ANTI_RANGE.  Denormalize VR_VARYING to VR_RANGE.  */
+  range_type = VR_RANGE;
+  gcc_checking_assert (min == wi::min_value (type));
+  gcc_checking_assert (max == wi::max_value (type));
+}
+
+  /* A range of the entire domain is really no range at all.  */
   if (min == wi::min_value (TYPE_PRECISION (type), TYPE_SIGN (type))
   && max == wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type)))
 {
-- 
2.35.1

[patch, wwwdocs, committed] Update mail links and dates for GCC 12 and GCC 13 status

[Thomas Koenig via Gcc-patches]

Hi,

I just pushed the attached patch to update the mail links and dates for
GCC 12 and GCC 13, as simple and obvious.

Regards

Thomasdiff --git a/htdocs/index.html b/htdocs/index.html
index 199181b1..e1bb584e 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -172,7 +172,7 @@ More news? Let ger...@pfeifer.com know!
 
   Status:
   
-  https://gcc.gnu.org/pipermail/gcc/2022-April/238491.html;>2022-04-04
+  https://gcc.gnu.org/pipermail/gcc/2022-April/238617.html;>2022-04-28
   
   (frozen for release). 
   
@@ -244,7 +244,7 @@ More news? Let ger...@pfeifer.com know!
 
   Status:
   
-  https://gcc.gnu.org/pipermail/gcc/2022-April/238491.html;>2022-04-04
+  https://gcc.gnu.org/pipermail/gcc/2022-April/238619.html;>2022-04-28
   
   (general development).