[Bug c++/105696] invalid use of constexpr static class member accepted as constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92171

--- Comment #2 from Andrew Pinski  ---
Or is a dup of bug 92171.

[Bug c++/105696] invalid use of constexpr static class member accepted as constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79083

--- Comment #1 from Andrew Pinski  ---
I suspect this is basically the same as PR 79083.

[Bug c++/105696] New: invalid use of constexpr static class member accepted as constant expression

[yiz152 at ucsd dot edu via Gcc-bugs]

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

Bug ID: 105696
   Summary: invalid use of constexpr static class member accepted
as constant expression
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yiz152 at ucsd dot edu
  Target Milestone: ---

Created attachment 53017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53017=edit
Test case

G++ 12.1.0 accepts constexpr static class members referenced using class member
access syntax (see below/attached). The working draft states
(https://eel.is/c++draft/class.static#general-1) that in such cases, the object
expression (this->val) is evaluated, thereby breaking constexpr-ness (cf.
https://eel.is/c++draft/expr.const#5.1).

Compiled/tested with gcc 12.1.0, clang 13.0.1, -pedantic -Wall -Wextra
-std=c++1z. Also tested with -std=c++11,-std=c++14. Code/error (same as the
attached file):

#include 
struct A {
constexpr static int a = 17;
};

struct B {
A val;
int foo() {
// gcc compiles without warning; clang rejects
return std::integral_constant::value;
}
int good_foo() {
// gcc compiles without warning, correct
return std::integral_constant::value;
}
void bar() {
char a[val.a]; // gcc compiles without warning, clang warns -Wvla
(void) a;
}
void var_bar(int len) {
char a[len]; // gcc compiles with -Wvla, clang does as well
(void) a;
}
};

int main() {}


gcc -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)

Re: [PATCH v2 1/1] RISC-V: Fix canonical extension order (K and J)

[Kito Cheng via Gcc-patches]

Pushed, thanks!

On Sun, May 22, 2022 at 5:30 PM Tsukasa OI via Gcc-patches
 wrote:
>
> This commit fixes canonical extension order to follow the RISC-V ISA
> Manual draft-20210402-1271737 or later.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc (riscv_supported_std_ext):
> Fix "K" extension prefix to be placed before "J".
> * config/riscv/arch-canonicalize: Likewise.
>
> Signed-off-by: Tsukasa OI 
> ---
>  gcc/common/config/riscv/riscv-common.cc | 2 +-
>  gcc/config/riscv/arch-canonicalize  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc 
> b/gcc/common/config/riscv/riscv-common.cc
> index 1501242e296..0b0ec2c4ec5 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -594,7 +594,7 @@ riscv_subset_list::lookup (const char *subset, int 
> major_version,
>  static const char *
>  riscv_supported_std_ext (void)
>  {
> -  return "mafdqlcbjktpvn";
> +  return "mafdqlcbkjtpvn";
>  }
>
>  /* Parsing subset version.
> diff --git a/gcc/config/riscv/arch-canonicalize 
> b/gcc/config/riscv/arch-canonicalize
> index 41bab69193c..71b2232b29e 100755
> --- a/gcc/config/riscv/arch-canonicalize
> +++ b/gcc/config/riscv/arch-canonicalize
> @@ -32,7 +32,7 @@ import itertools
>  from functools import reduce
>
>  SUPPORTED_ISA_SPEC = ["2.2", "20190608", "20191213"]
> -CANONICAL_ORDER = "imafdgqlcbjktpvn"
> +CANONICAL_ORDER = "imafdgqlcbkjtpvn"
>  LONG_EXT_PREFIXES = ['z', 's', 'h', 'x']
>
>  #
> --
> 2.34.1
>

Re: [committed] wwwdocs: gcc-12: Fix HTML around RISC-V entries

[Kito Cheng via Gcc-patches]

Thank you, Gerald :)

On Sun, May 22, 2022 at 6:29 AM Gerald Pfeifer  wrote:
>
> I'm not sure when that sneaked in (and it predates that last entry),
> but  followed by  is one too many in any case. :-)
>
> Pushed.
>
> Gerald
> ---
>  htdocs/gcc-12/changes.html | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 3b94378e..ae03c3c6 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -820,7 +820,6 @@ function Multiply (S1, S2 : Sign) return Sign is
>  libstdc++ no longer attempts to detect built-in atomics.
> Distributions that have out-of-tree workarounds for
> -latomic should check their ABIs again.
> -  
>  
>
>  
> --
> 2.36.0
>

Re: [PATCH] rs6000: add support for sanitizers on FreeBSD

[Kewen.Lin via Gcc-patches]

Hi Piotr,

on 2022/5/23 05:36, Piotr Kubaj wrote:
> Ping.
> 
> FreeBSD has already enabled sanitizers in its base system in 
> https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66
> The upstream (LLVM) patch was reviewed by a couple of people already.
> 
> Our llvm-devel port also has sanitizers enabled by default since 
> https://cgit.freebsd.org/ports/commit/?id=70d8d9125c9f5b1da36b134408b3d580a39f1aa8
> 

Thanks for the patch.  I think you also need to introduce a new subtarget
ASAN_SHADOW_OFFSET for freebsd?  One reference case is the
SUBTARGET_SHADOW_OFFSET in freebsd.h under i386.

BR,
Kewen

> On 22-05-15 12:57:13, Piotr Kubaj wrote:
>> GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
>> 315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
>> PowerPC on FreeBSD, so this commit only enables building it.
>>
>> Enabled sanitizers are the same as on powerpc*-*-linux*.
>>
>> libsanitizer
>>  * configure.tgt: add powerpc*-*-freebsd* as supported
>> ---
>>  libsanitizer/ChangeLog | 4 
>>  libsanitizer/configure.tgt | 2 ++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
>> index 52050be9476..17cc395aea1 100644
>> --- a/libsanitizer/ChangeLog
>> +++ b/libsanitizer/ChangeLog
>> @@ -1,3 +1,7 @@
>> +2022-05-15  Piotr Kubaj 
>> +
>> +* configure.tgt: add powerpc*-*-freebsd*
>> +
>>  2022-05-05  Martin Liska  
>>  
>>  * LOCAL_PATCHES: Update.
>> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
>> index fb89df4935c..affe8964f84 100644
>> --- a/libsanitizer/configure.tgt
>> +++ b/libsanitizer/configure.tgt
>> @@ -31,6 +31,8 @@ case "${target}" in
>>  TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_amd64.lo
>>  fi
>>  ;;
>> +  powerpc*-*-freebsd*)
>> +;;
>>powerpc*-*-linux*)
>>  if test x$ac_cv_sizeof_void_p = x8; then
>>  TSAN_SUPPORTED=yes
>> -- 
>> 2.36.0
>>

[PATCH V2]rs6000: Store complicated constant into pool

[Jiufu Guo via Gcc-patches]

Hi,

And after some discussions in the previous review:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591509.html
This patch simply updates the rtx_cost hook to accurate cost on
constant by using 'COSTS_N_INSNS' with 'num_insns_constant'.  This
could avoid CSE eliminate constant loading.

Compare with previous patch, this patch update cost for prefixed
load('pld') slightly faster.

To set a constant to a reg, one way is building the constant through
instructions, like lis/ori/sldi...  Another way is loading it from
the constant pool through instruction 'ld'(or 'pld' for P10).

Loading a constant may need 2 instructions (or just 'pld' on P10),
and according to testing, if building the constant needs more than 2
instructions (or more than 1 instruction on P10), it is faster to load
it from constant pool.

This patch reduces the threshold of instruction number for storing
constant to pool and update cost for constant and mem accessing.

Bootstrap and regtest pass on ppc64le and ppc64.
Is this ok for trunk?


BR,
Jiufu


PR target/63281

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
Exclude rtx with code 'HIGH'.
(rs6000_emit_move): Update threshold of const insn.
(rs6000_rtx_costs): Update cost of constant and mem.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/medium_offset.c: Update.
* gcc.target/powerpc/pr93012.c: Update.
* gcc.target/powerpc/pr63281.c: New test.


---
 gcc/config/rs6000/rs6000.cc   | 23 +++
 .../gcc.target/powerpc/medium_offset.c|  2 +-
 gcc/testsuite/gcc.target/powerpc/pr63281.c| 11 +
 gcc/testsuite/gcc.target/powerpc/pr93012.c|  2 +-
 4 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr63281.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index cd291f93019..90c91a8e1ea 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -9706,8 +9706,9 @@ rs6000_init_stack_protect_guard (void)
 static bool
 rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
 {
-  if (GET_CODE (x) == HIGH
-  && GET_CODE (XEXP (x, 0)) == UNSPEC)
+  /* Exclude CONSTANT HIGH part.  e.g.
+ (high:DI (symbol_ref:DI ("var") [flags 0xc0] )).  */
+  if (GET_CODE (x) == HIGH)
 return true;
 
   /* A TLS symbol in the TOC cannot contain a sum.  */
@@ -11139,7 +11140,7 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode 
mode)
&& FP_REGNO_P (REGNO (operands[0])))
   || !CONST_INT_P (operands[1])
   || (num_insns_constant (operands[1], mode)
-  > (TARGET_CMODEL != CMODEL_SMALL ? 3 : 2)))
+  > (TARGET_PREFIXED ? 1 : 2)))
   && !toc_relative_expr_p (operands[1], false, NULL, NULL)
   && (TARGET_CMODEL == CMODEL_SMALL
   || can_create_pseudo_p ()
@@ -22101,6 +22102,14 @@ rs6000_rtx_costs (rtx x, machine_mode mode, int 
outer_code,
 
 case CONST_DOUBLE:
 case CONST_WIDE_INT:
+  /* Set a const to reg, it may needs a few insns.  */
+  if (outer_code == SET)
+   {
+ *total = COSTS_N_INSNS (num_insns_constant (x, mode));
+ return true;
+   }
+  /* FALLTHRU */
+
 case CONST:
 case HIGH:
 case SYMBOL_REF:
@@ -22110,8 +22119,12 @@ rs6000_rtx_costs (rtx x, machine_mode mode, int 
outer_code,
 case MEM:
   /* When optimizing for size, MEM should be slightly more expensive
 than generating address, e.g., (plus (reg) (const)).
-L1 cache latency is about two instructions.  */
-  *total = !speed ? COSTS_N_INSNS (1) + 1 : COSTS_N_INSNS (2);
+L1 cache latency is about two instructions.
+For prefixed load (pld), we would set it slightly faster than
+than two instructions. */
+  *total = !speed
+? COSTS_N_INSNS (1) + 1
+: TARGET_PREFIXED ? COSTS_N_INSNS (2) - 1 : COSTS_N_INSNS (2);
   if (rs6000_slow_unaligned_access (mode, MEM_ALIGN (x)))
*total += COSTS_N_INSNS (100);
   return true;
diff --git a/gcc/testsuite/gcc.target/powerpc/medium_offset.c 
b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
index f29eba08c38..4889e8fa8ec 100644
--- a/gcc/testsuite/gcc.target/powerpc/medium_offset.c
+++ b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-options "-O" } */
-/* { dg-final { scan-assembler-not "\\+4611686018427387904" } } */
+/* { dg-final { scan-assembler-times {\msldi|pld\M} 1 } } */
 
 static int x;
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr63281.c 
b/gcc/testsuite/gcc.target/powerpc/pr63281.c
new file mode 100644
index 000..469a8f64400
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr63281.c
@@ -0,0 +1,11 @@
+/* PR 

gcc-13-20220522 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20220522 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20220522/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision a60228404f2ac11b5eb66270037ff3fa6bf948e5

You'll find:

 gcc-13-20220522.tar.xz   Complete GCC

  SHA256=6d859e85b8009cc049acc840dba06ddcc345362ffb6744759b8a6ac4e7061af1
  SHA1=a4bfdad103e35ef8729fe06dd2395e37de39df60

Diffs from 13-20220515 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug libcc1/105695] GCC 10.3.1 (20220519) build failure with GCC 12

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

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

--- Comment #1 from Andrew Pinski  ---
The problem is -std=gnu++98 I think.

[Bug libcc1/105695] New: GCC 10.3.1 (20220519) build failure with GCC 12

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 105695
   Summary: GCC 10.3.1 (20220519) build failure with GCC 12
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libcc1
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---

Created attachment 53016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53016=edit
build.log.xz

```
/bin/bash ./libtool  --tag=CXX   --mode=compile x86_64-pc-linux-gnu-g++
-std=gnu++98 -DHAVE_CONFIG_H -I.
-I/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1
 -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../include
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../libgcc
-I ../gcc
-I/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/c-family
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../libcpp/include
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/c
  -W -Wall  -fvisibility=hidden  -pipe -march=native -fdiagnostics-color=always
-D_GLIBCXX_ASSERTIONS -ggdb3 -O2 -MT libcc1plugin.lo -MD -MP -MF
.deps/libcc1plugin.Tpo -c -o libcc1plugin.lo
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/libcc1plugin.cc
libtool: compile:  x86_64-pc-linux-gnu-g++ -std=gnu++98 -DHAVE_CONFIG_H -I.
-I/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../include
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../libgcc
-I ../gcc
-I/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/c-family
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../libcpp/include
-I
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/c
-W -Wall -fvisibility=hidden -pipe -march=native -fdiagnostics-color=always
-D_GLIBCXX_ASSERTIONS -ggdb3 -O2 -MT libcc1plugin.lo -MD -MP -MF
.deps/libcc1plugin.Tpo -c
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/libcc1plugin.cc
 -fPIC -DPIC -o .libs/libcc1plugin.o
In file included from
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/hash-table.h:248,
 from
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/coretypes.h:461,
 from
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/gcc-plugin.h:29,
 from
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/libcc1plugin.cc:34:
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/vec.h:
In member function ‘void vec::reverse()’:
/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/gcc-10-20220519/libcc1/../gcc/vec.h:2086:10:
error: ‘swap’ is not a member of ‘std’
 2086 | std::swap (ptr[i], ptr[l - i - 1]);
  |  ^~~~
make[2]: *** [Makefile:600: libcc1plugin.lo] Error 1
make[2]: Leaving directory
'/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/build/libcc1'
make[1]: *** [Makefile:14552: install-libcc1] Error 2
make[1]: Leaving directory
'/var/tmp/portage.notmp/portage/sys-devel/gcc-10.3.1_p20220519/work/build'
make: *** [Makefile:2438: install] Error 2
 * ERROR: sys-devel/gcc-10.3.1_p20220519::gentoo failed (install phase):
```

I've attached the full log (xz compressed b/c of size).

```
$ gcc --version
gcc (Gentoo Hardened 12.1.1_p20220521 p5) 12.1.1 20220521
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

Re:

[David Edelsohn via Gcc]

On Sun, May 22, 2022 at 5:21 PM Skrab Skrab via Gcc  wrote:
>
> How can i contribute to gcc.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re: [PATCH] rs6000: add support for sanitizers on FreeBSD

[Piotr Kubaj]

Ping.

FreeBSD has already enabled sanitizers in its base system in 
https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66
The upstream (LLVM) patch was reviewed by a couple of people already.

Our llvm-devel port also has sanitizers enabled by default since 
https://cgit.freebsd.org/ports/commit/?id=70d8d9125c9f5b1da36b134408b3d580a39f1aa8

On 22-05-15 12:57:13, Piotr Kubaj wrote:
> GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
> 315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
> PowerPC on FreeBSD, so this commit only enables building it.
> 
> Enabled sanitizers are the same as on powerpc*-*-linux*.
> 
> libsanitizer
>   * configure.tgt: add powerpc*-*-freebsd* as supported
> ---
>  libsanitizer/ChangeLog | 4 
>  libsanitizer/configure.tgt | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
> index 52050be9476..17cc395aea1 100644
> --- a/libsanitizer/ChangeLog
> +++ b/libsanitizer/ChangeLog
> @@ -1,3 +1,7 @@
> +2022-05-15  Piotr Kubaj 
> +
> + * configure.tgt: add powerpc*-*-freebsd*
> +
>  2022-05-05  Martin Liska  
>  
>   * LOCAL_PATCHES: Update.
> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> index fb89df4935c..affe8964f84 100644
> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -31,6 +31,8 @@ case "${target}" in
>   TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_amd64.lo
>   fi
>   ;;
> +  powerpc*-*-freebsd*)
> + ;;
>powerpc*-*-linux*)
>   if test x$ac_cv_sizeof_void_p = x8; then
>   TSAN_SUPPORTED=yes
> -- 
> 2.36.0
> 


signature.asc
Description: PGP signature

[no subject]

[Skrab Skrab via Gcc]

How can i contribute to gcc.

[Bug c++/105694] New: ICE: in finish_expr_stmt, at cp/semantics.cc:892

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105694
   Summary: ICE: in finish_expr_stmt, at cp/semantics.cc:892
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

11.3 Regression

#include 

int main() {
  std::apply([](auto...) {
[](std::index_sequence) {
  ([](auto... tuples) {
(std::get(tuples), ...);
  }(I), ...);
}(std::make_index_sequence<3>{});
  }, std::tuple(1, 2, 3.0));
}

https://godbolt.org/z/KPorc1fnK

Re: [PATCH] Add divide by zero side effect.

[Alexander Monakov via Gcc-patches]

On Fri, 20 May 2022, Richard Biener wrote:

> > > > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is 
> > > > actually
> > > > doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC 
> > > > might be
> > > > called like 'deduce_ranges_from_stmt'.
> > >
> > > So how would you call determining the range of 'c' from the ranges of
> > > 'a' and 'b', isn't that 'deduction' as well?
> >
> > Kind of, yes, but for this sort of forward inference I imagine you're 
> > already
> > using 'propagate [ranges through a stmt]', like in 'value range 
> > propagation'.
> >
> > If you'd like to avoid 'propagate'/'deduce' asymmetry, I could suggest
> > 'forward inference' / 'backward inference', but I like it a bit less.
> 
> Hmm, maybe "guarantees" - if the stmt executed (without traps) then
> it's guaranteed that the divisor isn't zero.  I've almost said 'assertions'
> but then asserts also have separate meanings, not to mention ASSERT_EXPR
> as currently used by the old-style VRP.

I feel the word 'assumptions' captures that nicely.

Alexander

[Bug c++/105693] New: Requires-clause constructor is not selected

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 105693
   Summary: Requires-clause constructor is not selected
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

In the following program struct template A has deleted default constructor for
T=int:

#include 

template
struct A {
A() = default;
A() requires (std::same_as) = delete;
};

A a;

The program is rejected by Clang and MSVC, but not by GCC. Demo:
https://gcc.godbolt.org/z/G7T5xv35q

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
There is no need to special case the substring length of 1 case with my
suggested patch.  Here's an update to eliminate the special case.

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 233cc42137f..fa9938d6a1e 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3589,49 +3589,31 @@ gfc_simplify_index (gfc_expr *x, gfc_expr *y, gfc_expr
*b, gfc_expr *kind)
  mpz_set_si (result->value.integer, len + 1);
  return result;
}
-  else if (lensub == 1)
+  else
{
- for (i = 0; i < len; i++)
+ /* Start at the tail of the string, offset by the length of the
+substring, and search for a match moving towards the head of
+string.  */
+ for (i = len - lensub; i >= 0; i--)
{
- for (j = 0; j < lensub; j++)
+ /* If the first character does not match, then the rest of the
+string cannot match.  */
+ if (x->value.character.string[i]
+ == y->value.character.string[0])
{
- if (y->value.character.string[j]
- == x->value.character.string[len - i])
+
+ /* Compare substring to starting location in string.  */  
+ for (j = 0, count = 0; j < lensub; j++, count++)
{
- index = len - i + 1;
- goto done;
+ if (x->value.character.string[i + j]
+ != y->value.character.string[j])
+   break;
}
-   }
-   }
-   }
-  else
-   {
- for (i = 0; i < len; i++)
-   {
- for (j = 0; j < lensub; j++)
-   {
- if (y->value.character.string[j]
- == x->value.character.string[len - i])
+
+ if (count == lensub)
{
- start = len - i;
- if (start <= len - lensub)
-   {
- count = 0;
- for (k = 0; k < lensub; k++)
-   if (y->value.character.string[k]
-   == x->value.character.string[k + start])
- count++;
-
- if (count == lensub)
-   {
- index = start + 1;
- goto done;
-   }
-   }
- else
-   {
- continue;
-   }
+ index = i + 1;
+ goto done;
}
}
}

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-05-22
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW

--- Comment #2 from kargl at gcc dot gnu.org ---
There is some torched logic looking for the substring, which can never find it.

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 233cc42137f..16b231f5707 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3606,32 +3606,29 @@ gfc_simplify_index (gfc_expr *x, gfc_expr *y, gfc_expr
*b, gfc_expr *kind)
}
   else
{
- for (i = 0; i < len; i++)
+ /* Start at the tail of the string, offset by the length of the
+substring, and search for a match moving towards the head of
+string.  */
+ for (i = len - lensub; i >= 0; i--)
{
- for (j = 0; j < lensub; j++)
+ /* If the first character does not match, then the rest of the
+string cannot match.  */
+ if (x->value.character.string[i]
+ == y->value.character.string[0])
{
- if (y->value.character.string[j]
- == x->value.character.string[len - i])
+
+ /* Compare substring to starting location in string.  */  
+ for (j = 0, count = 0; j < lensub; j++, count++)
{
- start = len - i;
- if (start <= len - lensub)
-   {
- count = 0;
- for (k = 0; k < lensub; k++)
-   if (y->value.character.string[k]
-   == x->value.character.string[k + start])
- count++;
-
- if (count == lensub)
-   {
- index = start + 1;
- goto done;
-   }
-   }
- else
-   {
- continue;
-   }
+ if (x->value.character.string[i + j]
+ != y->value.character.string[j])
+   break;
+   }
+
+ if (count == lensub)
+   {
+ index = i + 1;
+ goto done;
}
}
}

[Bug c++/104230] Non-type template arguments of reference and pointer type fail when initialized by pointer to member operator

[anton at socialhacker dot com via Gcc-bugs]

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

--- Comment #3 from anton at socialhacker dot com ---
I've found the relevant discussion about the correct way to mangle subobject
references in template parameters here:

https://github.com/itanium-cxx-abi/cxx-abi/issues/47

It looks like Clang already has this implemented.  but I'm not sure which
version of the compiler has the referenced commits.

[Bug c++/105692] New: internal compiler error: in finish_expr_stmt, at cp/semantics.cc:872

[elmar.braun at web dot de via Gcc-bugs]

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

Bug ID: 105692
   Summary: internal compiler error: in finish_expr_stmt, at
cp/semantics.cc:872
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elmar.braun at web dot de
  Target Milestone: ---

Created attachment 53015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53015=edit
output of compiling with -freport-bug

Reduced testcase:

  template 
  using lambda = decltype([] {});

  template 
  void f3() {}

  template 
  void f2() {
f3>();
  }

  void f1() {
f2();
  }

Compiling this with GCC 12.1.0, using the command line "g++-12.1 -std=c++20
-Wall -Wextra bug.cpp", results in the following error message:

  bug.cpp: In instantiation of ‘void f2() [with T = int]’:
  bug.cpp:13:10:   required from here
  bug.cpp:9:3: internal compiler error: in finish_expr_stmt, at
cp/semantics.cc:872
  9 |   f3>();

Exact version of GCC, system type, and options given when GCC was configured
can be found in the attached output from -freport-bug.

I was also able to reproduce the issue on godbolt.org
(https://godbolt.org/z/3344WMcWT). Clang 14 and the latest MSVC compile this
code without problems.

Re: [PATCH] [x86_64]: Zhaoxin lujiazui enablement

[Uros Bizjak via Gcc-patches]

On Tue, May 17, 2022 at 11:34 AM Mayshao-oc  wrote:
>
> > On Tue, May 17, 2022 at 5:15 AM mayshao  wrote:
> >> Hi Uros:
> >> This patch fix Zhaoxin CPU vendor ID detection problem and add 
> >> zhaoxin "lujiazui" processor support.
> >> Currently gcc can't recognize Zhaoxin CPU(vendor ID "CentaurHauls" 
> >> and "Shanghai") if user use -march=native option, which is confusing for 
> >> users.
> >> This patch enables -march=native in zhaoxin family 7th processor 
> >> and -march/-mtune=lujiazui, costs and tunning are set according to the 
> >> characteristics of the processor.We add a new md file to describe lujiazui 
> >> pipeline.
> >> Testing:
> >> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> >> Ok for master?
> >> Background:
> >> Related Zhaoxin linux kernel patch can be found at:
> >> https://lore.kernel.org/lkml/01042674b2f741b2aed1f797359bd...@zhaoxin.com/
> >> Related Zhaoxin glibc patch can be found at:
> >> https://sourceware.org/git/?p=glibc.git;a=commit;h=32ac0b988466785d6e3cc1dffc364bb26fc63193
> >> gcc/ChangeLog:
> > The entries below are suspiciously empty - please fill in the details.
>
> Sorry for forgetting this. Update patch. Thanks.
>
> * common/config/i386/cpuinfo.h (get_zhaoxin_cpu): Detect
> the specific type of Zhaoxin CPU, and return Zhaoxin CPU name.
> (cpu_indicator_init): Handle Zhaoxin processors.
> * common/config/i386/i386-common.cc: Add lujiazui.
> * common/config/i386/i386-cpuinfo.h (enum processor_vendor): Add
> VENDOR_ZHAOXIN.
> (enum processor_types): Add ZHAOXIN_FAM7H.
> (enum processor_subtypes): Add ZHAOXIN_FAM7H_LUJIAZUI.
> * config.gcc: Add lujiazui.
> * config/i386/cpuid.h (signature_SHANGHAI_ebx): Add
> Signatures for zhaoxin
> (signature_SHANGHAI_ecx): Ditto.
> (signature_SHANGHAI_edx): Ditto.
> * config/i386/driver-i386.cc (host_detect_local_cpu): Let
> -march=native recognize lujiazui processors.
> * config/i386/i386-c.cc (ix86_target_macros_internal): Add lujiazui.
> * config/i386/i386-options.cc (m_LUJIAZUI): New_definition.
> * config/i386/i386.h (enum processor_type): Ditto.
> * config/i386/i386.md: Add lujiazui.
> * config/i386/x86-tune-costs.h (struct processor_costs): Add
> lujiazui costs.
> * config/i386/x86-tune-sched.cc (ix86_issue_rate): Add lujiazui.
> (ix86_adjust_cost): Ditto.
> * config/i386/x86-tune.def (X86_TUNE_SCHEDULE): Add lujiazui tunnings.
> (X86_TUNE_PARTIAL_REG_DEPENDENCY): Ditto.
> (X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY): Ditto.
> (X86_TUNE_SSE_PARTIAL_REG_FP_CONVERTS_DEPENDENCY): Ditto.
> (X86_TUNE_SSE_PARTIAL_REG_CONVERTS_DEPENDENCY): Ditto.
> (X86_TUNE_MOVX): Ditto.
> (X86_TUNE_MEMORY_MISMATCH_STALL): Ditto.
> (X86_TUNE_FUSE_CMP_AND_BRANCH_32): Ditto.
> (X86_TUNE_FUSE_CMP_AND_BRANCH_64): Ditto.
> (X86_TUNE_FUSE_CMP_AND_BRANCH_SOFLAGS): Ditto.
> (X86_TUNE_FUSE_ALU_AND_BRANCH): Ditto.
> (X86_TUNE_ACCUMULATE_OUTGOING_ARGS): Ditto.
> (X86_TUNE_USE_LEAVE): Ditto.
> (X86_TUNE_PUSH_MEMORY): Ditto.
> (X86_TUNE_LCP_STALL): Ditto.
> (X86_TUNE_USE_INCDEC): Ditto.
> (X86_TUNE_INTEGER_DFMODE_MOVES): Ditto.
> (X86_TUNE_OPT_AGU): Ditto.
> (X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB): Ditto.
> (X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES): Ditto.
> (X86_TUNE_USE_SAHF): Ditto.
> (X86_TUNE_USE_BT): Ditto.
> (X86_TUNE_AVOID_FALSE_DEP_FOR_BMI): Ditto.
> (X86_TUNE_ONE_IF_CONV_INSN): Ditto.
> (X86_TUNE_AVOID_MFENCE): Ditto.
> (X86_TUNE_EXPAND_ABS): Ditto.
> (X86_TUNE_USE_SIMODE_FIOP): Ditto.
> (X86_TUNE_USE_FFREEP): Ditto.
> (X86_TUNE_EXT_80387_CONSTANTS): Ditto.
> (X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL): Ditto.
> (X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL): Ditto.
> (X86_TUNE_SSE_TYPELESS_STORES): Ditto.
> (X86_TUNE_SSE_LOAD0_BY_PXOR): Ditto.
> * doc/extend.texi: Add details about lujiazui.
> * doc/invoke.texi: Add details about lujiazui.
> * config/i386/lujiazui.md: Introduce lujiazui cpu and include new md file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/funcspec-56.inc: Test -arch=lujiauzi and -tune=lujiazui.
> * g++.target/i386/mv32.C: Ditto.

The patch looks good to me (However, I didn't review the .md file in details).

BTW: The approval applies to the technical part, the legal part should
be handled by someone else - if it is still needed after the project
was changed from copyright assignment style to the developer's
certificate of origin style.

Also, can you handle the commit by yourself, or should I do it for you?

Thanks,
Uros.

>
> >> * common/config/i386/cpuinfo.h (get_zhaoxin_cpu):
> >> (cpu_indicator_init):
> >> * common/config/i386/i386-common.cc:
> >> * common/config/i386/i386-cpuinfo.h (enum processor_vendor):
> >> (enum processor_types):
> >> (enum processor_subtypes):
> >> * config.gcc:
> >> * config/i386/cpuid.h (signature_SHANGHAI_ebx):
> >> (signature_SHANGHAI_ecx):
> >> (signature_SHANGHAI_edx):
> >> * config/i386/driver-i386.cc (host_detect_local_cpu):
> >> * config/i386/i386-c.cc 

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
I can reproduce in a cross to --target=msp430-unknown-elf
--enable-languages=c,c++ with binutils-2.38 and newlib-4.2.0.20211231.
gcc-11.3.0 builds fine, but gcc-12.1.0 build fails with

In file included from
/mnt/scratch/cross/sources/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:61:
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/random:355:69:
error: narrowing conversion of '86243' from 'long int' to 'unsigned int'
[-Wnarrowing]
  355 | 0xU, 0xe9528d85U>
  | ^
(several more)

and

In file included from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:475,
 from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/detail/standard_policies.hpp:45,
 from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:47,
 from
/mnt/scratch/cross/sources/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:72:
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:73:32:
error: narrowing conversion of '116731' from 'long unsigned int' to
'std::size_t' {aka 'unsigned int'} [-Wnarrowing]
   73 |   /* 14*/  116731ul,
  |^~~~
(many more)

OMPD: 5.5.8 Display Control Variables

[Mohamed Atef via Gcc]

To implement this
,
should I add a function in the runtime to dump all the
environment variables. Or should I use variables from helper functions?
To make the icv-name=icv-value pair I think it will be too costly
to use helper functions.

[Bug ada/100486] Ada build fails for 32bit Windows

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

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

--- Comment #74 from Arnaud Charlet  ---
The patch is desirable even outside of this PR, so we'll keep it. And as shown
by PR105507, we have other exception propagation that crept in unintentionally,
so I'll also have a look at these when I get a chance.

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #73 from Christoph Reiter  ---
In a similar bug 105507 we figured out that the MSYS2 build was broken because
it was linking libgcc both statically and dynamically via dependencies, and
that breaks exceptions with dwarf-2.

So in theory the above patch could be reverted. I can try building with it
being reverted to confirm, if wanted.

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #11 from Christoph Reiter  ---
I went with --with-boot-ldflags="-static-libstdc++" and
--with-stage1-ldflags="-static-libstdc++" now, and everything works nicely.

Thanks for your help and insight.

I'll document the dwarf-2 limitation downstream, so this hopefully wont happen
again.

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

[xecej4 at outlook dot com via Gcc-bugs]

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

--- Comment #1 from mecej4  ---
When a program contains an expression that involves the INDEX intrinsic
function, and it is possible to calculate its result value at compile time, the
computed value is sometimes incorrect.

program main
   i = index("fortran.f90", "fortran", back=.true.) ! It should get '1'
   call prnt(i)
contains
   subroutine prnt(i)
   integer i
   print *,'i = ',i
   end subroutine
end program

The program prints '0' instead of '1'. Looking at the assembly code generated
shows that the argument value in the argument I passed to PRNT() is zero.

[Bug fortran/105691] New: Incorrect calculation of INDEX(str1,str2) at compile time

[xecej4 at outlook dot com via Gcc-bugs]

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

Bug ID: 105691
   Summary: Incorrect calculation of INDEX(str1,str2) at compile
time
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xecej4 at outlook dot com
  Target Milestone: ---

[Bug c/105690] New: -Warray-bounds sensitive false positive with -O2

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

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

Bug ID: 105690
   Summary: -Warray-bounds sensitive false positive with -O2
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Hi,

this minimized testcase issues

# gcc-12 -O2 -Warray-bounds -c testcase.c
testcase.c: In function 'fun3.part.0':
testcase.c:16:13: warning: array subscript [0, 19] is outside array bounds of
'table_t[20]' [-Warray-bounds=]
   16 |   if (gtable[idx].mode)
  |   ~~^
testcase.c:8:9: note: while referencing 'gtable'
8 | table_t gtable[20];
  | ^~

with target linux-x86_64. It happens with gcc-12@r12-r8405 or
gcc-trunk@r13-555. The testcase is quite sensitive, even choosing a buffer size
smaller than 257 stops the warning. With gcc-7 to gcc-11 I don't get the
warning.

int gvar1;
void fun1(int, char *, int);
void fun2(int, char *);
typedef struct {
  int exist;
  int mode;
} table_t;
table_t gtable[20];

void fun3(int idx)
{
  char buffer[257];
  if (idx < 0 || idx >= 20 || gtable[idx].exist == 0)
return;
  fun2(idx, buffer);
  if (gtable[idx].mode)
fun2(idx, buffer);
}

void fun4()
{
  fun3(gvar1);
}

int fun2_maxlen;
void fun2(int idx, char * text)
{
  if (!(idx < 0 || idx >= 20 || gtable[idx].exist == 0))
fun1(idx, text, fun2_maxlen);
}

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #5 from Artem S. Tashkinov  ---
Using the official tar.xz file of course, without any
changes/modifications/patches.

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #4 from Artem S. Tashkinov  ---
(In reply to Andrew Pinski from comment #3)
> How are you building gcc?
> What configure options are being passed?
> What make options are being passed?
> Do you have any env variables set that might effect configure/make?
> Are you building in the source directory or a different directory?

#! /bin/sh

WD=/tmp/OBJDIR
GD=`pwd`

export CFLAGS="-O2 -pipe -mtune=generic"
export CXXFLAGS=$CFLAGS
export LDFLAGS="-Wl,-O1"

mkdir -p "$WD" && cd "$WD" && \
"$GD"/configure --disable-stage1-checking --with-system-zlib \
--enable-languages="c,c++,lto" --prefix=/opt/gcc \
--disable-sjlj-exceptions --enable-newlib-io-long-long \
--with-gcc-major-version-only --without-isl --enable-multilib

nice make -j16

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Andrew Pinski  ---
How are you building gcc?
What configure options are being passed?
What make options are being passed?
Do you have any env variables set that might effect configure/make?
Are you building in the source directory or a different directory?

[Bug c/105675] Segmentation fault

[watarai775 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Ruslan Mkoyan  ---
(In reply to Andrew Pinski from comment #3)
> This is a won't fix stitutation. 
> 
> You have & on a type repeated 237,679 times. 
> 
> With a recusive decent compiler, you run out of stack space with that many
> times.
> #17 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #18 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #19 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #20 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #21 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #22 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #23 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #24 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #25 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #26 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #27 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #28 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #29 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #30 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #31 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #32 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
> #33 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
> dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
> parenthesized_p=, member_p=false, friend_p=false,
> static_p=false) at 

[Bug c/105689] New: Bogus `-Wstringop-overflow=` after accessing field, then containing struct (wrong "region size")

[sagebar at web dot de via Gcc-bugs]

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

Bug ID: 105689
   Summary: Bogus `-Wstringop-overflow=` after accessing field,
then containing struct (wrong "region size")
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

The following code wrongly produces a warning `[-Wstringop-overflow=`:

Compile (using `gcc -c -O2 infile.c`)

```
struct subobject {
int field1;
int field2;
};

struct myobject {
struct subobject sub;
};

extern void access_1(int *a);
extern __attribute__((access(read_write, 1))) void access_2(struct subobject
*);

void myfunc(struct myobject *me) {
// { void *p __attribute__((unused)) = >sub; }
access_1(>sub.field1);
access_2(>sub);
}
```

=== Output (gcc-12) ===
>infile.c: In function 'myfunc':
>infile.c:16:9: warning: 'access_2' accessing 8 bytes in a region of size 4 
>[-Wstringop-overflow=]
>   16 | access_2(>sub);
>  | ^~
>infile.c:11:52: note: in a call to function 'access_2' declared with attribute 
>'access (read_write, 1)'
>   11 | extern __attribute__((access(read_write, 1))) void access_2(struct 
> subobject *);
>  |^~~~

=== Output (expected) ===
>


=== Notes ===

- By uncommenting the line `{ void *p __attribute__((unused)) = >sub; }`,
the warning goes away, even though that line literally does nothing. (see
Theory below)
- I was able to observe this bug in gcc-12.1.0 and gcc-11.2.0


=== Theory ===

It seems that this has got something to do with some internal, hidden attribute
(relating to the "region size") attached to some field-expression the first
time that field is accessed, only that when accessing `me->sub.field1` (where
`offsetof(field1) == 0`) before `me->sub`, that "region size" attribute
wrongfully also gets attached to `me->sub`. Then, when an access to `me->sub`
actually happens, gcc seems to think that the "region size" of `me->sub` as a
whole matches the size of the previously accessed field (`me->sub.field1`).

This seems further compounded by the fact that this only happens when `field1`
is the first field of `subobject` (i.e. has offset 0). If we insert another
field `int field0;` before it, the warning also disappears (so something in
gcc's logic appears to make it think that `region_size_of()
== region_size_of()`)

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #2 from Artem S. Tashkinov  ---
This workaround of mine is not really good: after `make install` you end up
with /opt/gcc/lib64/libstdc++.so.6.0.29 which is not GCC's but the system one
(/usr/lib64/libstdc++.so.6.0.30.so).

[Bug c/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #1 from Artem S. Tashkinov  ---
In /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs I replaced the built
libstdc++.so.29 _three times_ with the system one (libstdc++.so.30) and it all
worked.

Still this looks like a serious bug which is worth resolving.

Google doesn't find anything relevant, so people may get stuck.

[Bug c/105688] New: Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com via Gcc-bugs]

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

Bug ID: 105688
   Summary: Cannot build GCC 11.3 on Fedora 36
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aros at gmx dot com
  Target Milestone: ---

When trying to make gcc-11.3.0.tar.xz:

/bin/sh /tmp/gcc-11.3.0/libgcc/../mkinstalldirs 32
/tmp/OBJDIR/./gcc/xgcc -B/tmp/OBJDIR/./gcc/ -B/opt/gcc/x86_64-pc-linux-gnu/bin/
-B/opt/gcc/x86_64-pc-linux-gnu/lib/ -isystem
/opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include   -fno-checking -O2  -g -O2 -pipe
-mtune=generic -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o
32/libgcc_s.so.1.tmp -g -O2 -pipe -mtune=generic -m32 -B./ _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o tf-signs_s.o
sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o
multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o
floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o
floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc &&
rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1
32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp
32/libgcc_s.so.1 && (echo "/* GNU ld script"; echo "   Use the shared library,
but some functions are only in"; echo "   the static library.  */"; echo "GROUP
( libgcc_s.so.1 -lgcc )" ) > 32/libgcc_s.so
/usr/bin/ld:
/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version
`GLIBCXX_3.4.30' not found (required by /usr/bin/ld)
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:995: libgcc_s.so] Error 1

I've no idea what to, please help.

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

On 2022/05/19 12:40, Nelson Chu wrote:
> Seems like gcc and llvm have already committed this patch, so LGTM, committed.

Sorry, the same change is applied to LLVM but not yet on GCC (because I
forgot to add "Signed-off-by" line).  I sent PATCH v2 to gcc-patches
today so that would be okay.  On PATCH v2, I made the same change to
gcc/config/riscv/arch-canonicalize script (not just
gcc/common/config/riscv/riscv-common.cc).



Thanks,
Tsukasa

> 
> Thanks
> Nelson
> 
> On Mon, Apr 25, 2022 at 11:53 AM Palmer Dabbelt  wrote:
>>
>> On Mon, 28 Mar 2022 17:12:55 PDT (-0700), Palmer Dabbelt wrote:
>>> On Mon, 28 Mar 2022 06:12:01 PDT (-0700), binut...@sourceware.org wrote:
 This commit fixes canonical extension order to follow the RISC-V ISA
 Manual draft-20210402-1271737 or later.

 bfd/ChangeLog:

  * elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension
  prefix to be placed before "J".
 ---
  bfd/elfxx-riscv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
 index cb2cc146c04..1219a7b44d4 100644
 --- a/bfd/elfxx-riscv.c
 +++ b/bfd/elfxx-riscv.c
 @@ -1338,7 +1338,7 @@ riscv_recognized_prefixed_ext (const char *ext)
  }

  /* Canonical order for single letter extensions.  */
 -static const char riscv_ext_canonical_order[] = "eigmafdqlcbjktpvn";
 +static const char riscv_ext_canonical_order[] = "eigmafdqlcbkjtpvn";

  /* Array is used to compare the orders of standard extensions quickly.  */
  static int riscv_ext_order[26] = {0};
>>>
>>> Looks like this was just a bug in binutils: K went from being
>>> unspecified to specified in 271737 ("Define canonical location of K
>>> extension in ISA string"), thus it was never allowed at that other bit
>>> position.
>>>
>>> It looks like GCC also has this wrong, which sort of doubles the
>>> headache: now we've got this odd coupling between the GCC version and
>>> binutils version.  I'm not sure what the right thing is to do here:
>>> certainly rejecting the valid ISA string should be fixed, but I think we
>>> might need to accept the invalid one for compatibility reasons.  That'll
>>> be a headache to implement, though, so I'm not sure it's worth it.
>>>
>>> Maybe someone has a clever solution to this one?
>>
>> After seeing the GCC patch go by, I think the clever solution here is to
>> just say that we never accepted any J stuff in the first place so it's
>> not a compatibility break.
> 

[PATCH v2 1/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

This commit fixes canonical extension order to follow the RISC-V ISA
Manual draft-20210402-1271737 or later.

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_supported_std_ext):
Fix "K" extension prefix to be placed before "J".
* config/riscv/arch-canonicalize: Likewise.

Signed-off-by: Tsukasa OI 
---
 gcc/common/config/riscv/riscv-common.cc | 2 +-
 gcc/config/riscv/arch-canonicalize  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 1501242e296..0b0ec2c4ec5 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -594,7 +594,7 @@ riscv_subset_list::lookup (const char *subset, int 
major_version,
 static const char *
 riscv_supported_std_ext (void)
 {
-  return "mafdqlcbjktpvn";
+  return "mafdqlcbkjtpvn";
 }
 
 /* Parsing subset version.
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
index 41bab69193c..71b2232b29e 100755
--- a/gcc/config/riscv/arch-canonicalize
+++ b/gcc/config/riscv/arch-canonicalize
@@ -32,7 +32,7 @@ import itertools
 from functools import reduce
 
 SUPPORTED_ISA_SPEC = ["2.2", "20190608", "20191213"]
-CANONICAL_ORDER = "imafdgqlcbjktpvn"
+CANONICAL_ORDER = "imafdgqlcbkjtpvn"
 LONG_EXT_PREFIXES = ['z', 's', 'h', 'x']
 
 #
-- 
2.34.1

[PATCH v2 0/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

PATCH v1:


Changes between v1 and v2:
-   Added Signed-off-by line (I didn't notice that this is required)
-   Applied the same change to Python script:
gcc/config/riscv/arch-canonicalize

Note that this kind of change is already made in GNU Binutils and LLVM.
GNU Binutils: commit c4dd8eb523fae5c9d312f4b7b21377eec66e70c3
LLVM: commit 7fe0630fcb6d52cb63463669c47f4846f7d9ccbf




Tsukasa OI (1):
  RISC-V: Fix canonical extension order (K and J)

 gcc/common/config/riscv/riscv-common.cc | 2 +-
 gcc/config/riscv/arch-canonicalize  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


base-commit: a60228404f2ac11b5eb66270037ff3fa6bf948e5
-- 
2.34.1

[PATCH] Minor improvement to genpreds.cc

[Roger Sayle]

This simple patch implements Richard Biener's suggestion in comment #6
of PR tree-optimization/52171 (from February 2013) that the insn-preds
code generated by genpreds can avoid using strncmp when matching constant
strings of length one.

The effect of this patch is best explained by the diff of insn-preds.cc:
<   if (!strncmp (str + 1, "g", 1))
---
>   if (str[1] == 'g')
3104c3104
<   if (!strncmp (str + 1, "m", 1))
---
>   if (str[1] == 'm')
3106c3106
<   if (!strncmp (str + 1, "c", 1))
---
>   if (str[1] == 'c')
...

The equivalent optimization is performed by GCC (but perhaps not by the
host compiler), but generating simpler/smaller code may encourage further
optimizations (such as use of a switch statement).

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check with no new failures.  Ok for mainline?


2022-05-22  Roger Sayle  

gcc/ChangeLog
* genpreds.cc (write_lookup_constraint_1): Avoid generating a call
to strncmp for strings of length one.

Roger
--

diff --git a/gcc/genpreds.cc b/gcc/genpreds.cc
index f71da09..4571ac7 100644
--- a/gcc/genpreds.cc
+++ b/gcc/genpreds.cc
@@ -1089,10 +1089,15 @@ write_lookup_constraint_1 (void)
{
  do
{
- printf ("  if (!strncmp (str + 1, \"%s\", %lu))\n"
- "return CONSTRAINT_%s;\n",
- c->name + 1, (unsigned long int) c->namelen - 1,
- c->c_name);
+ if (c->namelen > 2)
+   printf ("  if (!strncmp (str + 1, \"%s\", %lu))\n"
+   "return CONSTRAINT_%s;\n",
+   c->name + 1, (unsigned long int) c->namelen - 1,
+   c->c_name);
+ else
+   printf ("  if (str[1] == '%c')\n"
+   "return CONSTRAINT_%s;\n",
+   c->name[1], c->c_name);
  c = c->next_this_letter;
}
  while (c);

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[beagleboard at davidjohnsummers dot uk via Gcc-bugs]

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

--- Comment #2 from David Summers  ---
I suspect its the newlib includes that trigger the problem. As it I did one
compile, where the configure grabbed the host includes (and 64bit system); and
that compile I think worked fine.

My problem though, as my target is a small 16bit cpu, I need the smallest
library, and newlib nano seems to work well - so that will be the library on
the machine where the code is run ..,

Re: GCC 9.5 Release Candidate available

[Iain Sandoe]

Hi

> On 20 May 2022, at 09:02, Richard Biener via Gcc  wrote:

> The first release candidate for GCC 9.5 is available from
> 
> https://sourceware.org/pub/gcc/snapshots/9.5.0-RC-20220520/
> 
> and shortly its mirrors.  It has been generated from git commit
> 1bc79c506205b6a5db82897340bdebaaf7ada934.
> 
> I have so far bootstrapped and tested the release candidate
> on x86_64-suse-linux.

I have bootstrapped (using GCC5.4 on darwin9 and GCC7.5 elsewhere) r9-10192 on:
i686-darwin9,17
powerpc-darwin9
x86_64-darwin10 to 21.

As, expected (since I was not able to find enough time to do the backports),
although bootstrap succeeds on darwin21 (macOS 12) the resulting compiler
is not really usable.  I will have to provide a darwin branch with the necessary
changes.

One observation outside of this:

Several of the testsuite runs hung with cc1 spinning in reload for pr88414.
I was not really able to correlate exactly with CPU / tuning chosen.

Pretty sure this is a regression - I do not recall the testsuite hanging (for 
anything
other than D) for years.

thanks
Iain

[Bug fortran/105687] New: non-contiguous data in assumed rank

[martin.diehl at kuleuven dot be via Gcc-bugs]

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

Bug ID: 105687
   Summary: non-contiguous data in assumed rank
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.diehl at kuleuven dot be
  Target Milestone: ---

Created attachment 53014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53014=edit
small reproducer

When passing a strided array to a select-rank statement, the information that
that data is non-contiguous is somehow lost. At least when further passing the
data to an assumed-size function, the arriving data differs.

Note: This might be related to bug 105674. This report illustrates the actual
problem I've encountered (wrong data) while the other report shows intermediate
results when trying to write a minimal reproducer.


code

program test

  integer, dimension(2,2), target :: dim_2
  integer, dimension(:,:), pointer :: strided
  integer :: i

  dim_2 = reshape([(i,i=1,size(dim_2))],shape(dim_2))
  strided => dim_2(1:1,:)

  print*, 'is_contiguous(strided)', is_contiguous(strided)
  print*, 'is_contiguous((strided))', is_contiguous((strided))
  print*, ''

  print*, 'call show(strided)'
  call show(strided,size(strided))
  print*, 'call show((strided))'
  call show((strided),size((strided)))
  print*, 'call assumed_rank(strided)'
  call assumed_rank(strided)
  print*, 'call assumed_rank((strided))'
  call assumed_rank((strided))

  contains

  subroutine assumed_rank(dataset)

integer, intent(in), dimension(..) :: dataset

select rank(dataset)
  rank(2)
print*, 'is contiguous in select', is_contiguous(dataset)
print*, 'data in select', dataset
call show(dataset,size(dataset))
end select

print*, ''

  end subroutine assumed_rank

  subroutine show(dataset,s)

integer, intent(in) :: s
integer, intent(in), dimension(*) :: dataset

print*, 'is contiguous in show', is_contiguous(dataset)
print*, 'data in show', dataset(1:s)
print*, ''

  end subroutine show

end program test

output
==
 is_contiguous(strided) F
 is_contiguous((strided)) T

 call show(strided)
 is contiguous in show T
 data in show   1   3

 call show((strided))
 is contiguous in show T
 data in show   1   3

 call assumed_rank(strided)
 is contiguous in select T
 data in select   1   3
 is contiguous in show T
 data in show   1   2


 call assumed_rank((strided))
 is contiguous in select T
 data in select   1   3
 is contiguous in show T
 data in show   1   3

[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed

[judge.packham at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Chris Packham  ---
In terms of my proposed change which fixes the problem for GCC 11.3.0 it
actually triggers the same assert on GCC 12.1.0.


[ALL  ]In file included from
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:21:
[ERROR]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38:
error: static assertion failed
[ALL  ]   75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct
stat));
[ALL  ]  |~~^~
[ALL  ]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:348:44:
note: in definition of macro 'COMPILER_CHECK'
[ALL  ]  348 | #define COMPILER_CHECK(pred) static_assert(pred, "")
[ALL  ]  |^~~~
[ALL  ]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38:
note: the comparison reduces to '(104 == 216)'
[ALL  ]   75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct
stat));
[ALL  ]  |~~^~
[ALL  ]   
/home/bagas/cross/workdir/mips64-unknown/.build/mips64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:348:44:
note: in definition of macro 'COMPILER_CHECK'
[ALL  ]  348 | #define COMPILER_CHECK(pred) static_assert(pred, "")
[ALL  ]  |^~~~
[ERROR]make[5]: *** [Makefile:616: sanitizer_platform_limits_linux.lo]
Error 1

It appears that with GCC 12 we now end up with different values for _MIPS_SIM.

Removing my "fix" resolves the issue for GCC 12 but I suspect something like
the suggestion from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614#c7
might resolve the issue properly.