[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support

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

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

--- Comment #2 from Xi Ruoyao  ---
I applied the LoongArch port patch (upstream PR 678, config.guess and
config.sub changes stripped and Makefile.am conflict resolved manually) and use
autogen.sh to regenerate the build system.  But libgo build still fails with:

libtool: compile:  /home/xry111/git-repos/gcc-build/./gcc/gccgo
-B/home/xry111/git-repos/gcc-build/./gcc/
-B/home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/bin/
-B/home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/lib/ -isystem
/home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/include -isystem
/home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=internal/goarch ../../../gcc/libgo/go/internal/goarch/goarch.go
zgoarch.go  -fPIC -o internal/.libs/goarch.o
zgoarch.go:7:14: error: expected ‘;’ or ‘)’ or newline
7 |   _BigEndian =
  |  ^
zgoarch.go:7:3: error: reference to undefined name ‘_BigEndian’
7 |   _BigEndian =
  |   ^
../../../gcc/libgo/go/internal/goarch/goarch.go:18:19: error: reference to
undefined name ‘_BigEndian’
   18 | const BigEndian = _BigEndian
  |   ^
../../../gcc/libgo/go/internal/goarch/goarch.go:21:29: error: reference to
undefined name ‘_DefaultPhysPageSize’
   21 | const DefaultPhysPageSize = _DefaultPhysPageSize
  | ^
../../../gcc/libgo/go/internal/goarch/goarch.go:25:19: error: reference to
undefined name ‘_PCQuantum’
   25 | const PCQuantum = _PCQuantum
  |   ^
../../../gcc/libgo/go/internal/goarch/goarch.go:28:20: error: reference to
undefined name ‘_Int64Align’
   28 | const Int64Align = _Int64Align
  |^
../../../gcc/libgo/go/internal/goarch/goarch.go:35:22: error: reference to
undefined name ‘_MinFrameSize’
   35 | const MinFrameSize = _MinFrameSize
  |  ^
../../../gcc/libgo/go/internal/goarch/goarch.go:39:20: error: reference to
undefined name ‘_StackAlign’
   39 | const StackAlign = _StackAlign
  |^

[Bug fortran/109003] New: memory leak in module loading (mio_formal_arglist)

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

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

Bug ID: 109003
   Summary: memory leak in module loading (mio_formal_arglist)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

valgrind complains when building SPEC 2017 521.wrf

==24177== 32 bytes in 2 blocks are possibly lost in loss record 66 of 2,272
==24177==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24177==by 0x1C071F0: xcalloc (xmalloc.c:164)
==24177==by 0x766248: mio_formal_arglist (module.cc:3201)
==24177==by 0x766248: mio_symbol(gfc_symbol*) (module.cc:4586)
==24177==by 0x766836: load_needed(pointer_info*) (module.cc:5195)
==24177==by 0x7667E0: load_needed(pointer_info*) (module.cc:5154)
==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153)
==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153)
==24177==by 0x7667E0: load_needed(pointer_info*) (module.cc:5154)
==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153)
==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153)
==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153) 
==24177==by 0x767C0B: read_module() (module.cc:5697)

I'm not sure what actually happens, but I guess sym->formal is eventually
replaced so the allocated memory gets dangling?  Or we free some of the
module memory later but not everything.

It seems valgrind complains about a lot of leaks when modules are involved.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

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

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

--- Comment #9 from Jonathan Wakely  ---
You can skip things not relevant to this issue by configuring with:

--disable-multilib --disable-bootstrap --enable-languages=c++,c
--disable-libcc1 --disable-libitm --disable-libvtv --disable-libgomp
--disable-libsanitizer

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

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

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

--- Comment #8 from Andrew Pinski  ---
Plus you can use --disable-bootstrap and maybe not rebuild llvm and just set
LD_LIBRARY_PATH.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Tom Stellard from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Tom Stellard from comment #4)
> > > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> > > so I bisected it down to this commit:
> > > https://github.com/llvm/llvm-project/commit/
> > > 6747fc07d1aa94e22622e278e5a02ba70675ac9b
> > 
> > can you bisect GCC instead?
> 
> I can try do you have any tips for speeding up the build?

Maybe try before and after the revisions I mentioned first.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Tom Stellard  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Tom Stellard from comment #4)
> > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> > so I bisected it down to this commit:
> > https://github.com/llvm/llvm-project/commit/
> > 6747fc07d1aa94e22622e278e5a02ba70675ac9b
> 
> can you bisect GCC instead?

I can try do you have any tips for speeding up the build?

[Bug c++/108165] -Wdangling-reference false positive

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

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

--- Comment #14 from Martin Liška  ---
(In reply to Marek Polacek from comment #13)
> I would really not like to do that, the false positives rate is pretty low.

You right! I noticed the warning for about 3 packages of 3300 we have in a
testing CI.

[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Should be fixed now.  I think the issue is likely latent earlier but unless we
run into it in real world lets wait and see.

[Bug target/108738] compile-time and memory-hog in mdreorg

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Keywords||compile-time-hog
   Target Milestone|--- |13.0
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Richard Biener  ---
This has been mitigated for GCC 13, in theory backporting is possible but
there's a workaround available (-mno-stv), so I think that's not strictly
necessary since the issue is quite old already.

[Bug target/108738] compile-time and memory-hog in mdreorg

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:6010189923908501ca5b02bd1f4aee05d2283118

commit r13-6439-g6010189923908501ca5b02bd1f4aee05d2283118
Author: Richard Biener 
Date:   Thu Mar 2 13:43:51 2023 +0100

target/108738 - limit STV chain discovery

The following puts a hard limit on the inherently quadratic STV chain
discovery.  Without a limit for the compiler.i testcase in PR26854
we see at -O2

 machine dep reorg  : 574.45 ( 53%)

with release checking while with the proposed limit it's

 machine dep reorg  :   2.86 (  1%)

PR target/108738
* config/i386/i386.opt (--param x86-stv-max-visits): New param.
* doc/invoke.texi (--param x86-stv-max-visits): Document it.
* config/i386/i386-features.h (scalar_chain::max_visits): New.
(scalar_chain::build): Add bitmap parameter, return boolean.
(scalar_chain::add_insn): Likewise.
(scalar_chain::analyze_register_chain): Likewise.
* config/i386/i386-features.cc (scalar_chain::scalar_chain):
Initialize max_visits.
(scalar_chain::analyze_register_chain): When we exhaust
max_visits, abort.  Also abort when running into any
disallowed insn.
(scalar_chain::add_insn): Propagate abort.
(scalar_chain::build): Likewise.  When aborting amend
the set of disallowed insn with the insns set.
(convert_scalars_to_vector): Adjust.  Do not convert aborted
chains.

[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:33ca5c92dfa7e2f591a838bb768d9d6eea56793b

commit r13-6438-g33ca5c92dfa7e2f591a838bb768d9d6eea56793b
Author: Richard Biener 
Date:   Wed Mar 1 10:01:10 2023 +0100

debug/108772 - ICE with late debug generated with -flto

When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics.  In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early generated DIE.  The limbo handling then tries
to force a DIE for the context chain which ultimatively fails and
ICEs at the std namespace decl because at -g1 we don't represent that.

The following avoids this situation by making sure to never generate
any DIEs from dwarf2out_late_global_decl in the in_lto_p path
for function scope globals but rely on DIE generation for
the function to output a DIE for the local static (which doesn't
happen for -g1).

I explored a lot of other options to fix this but in the end this
seems to be the most spot-on fix with the least risk of unwanted
effects.

PR debug/108772
* dwarf2out.cc (dwarf2out_late_global_decl): Do not
generate a DIE for a function scope static.

* g++.dg/lto/pr108772_0.C: New testcase.

Re: [PATCH] target/108738 - limit STV chain discovery

[Uros Bizjak via Gcc-patches]

On Thu, Mar 2, 2023 at 2:28 PM Richard Biener  wrote:
>
> The following puts a hard limit on the inherently quadratic STV chain
> discovery.  Without a limit for the compiler.i testcase in PR26854
> we see at -O2
>
>  machine dep reorg  : 574.45 ( 53%)
>
> with release checking while with the proposed limit it's
>
>  machine dep reorg  :   2.86 (  1%)
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> PR target/108738
> * config/i386/i386.opt (--param x86-stv-max-visits): New param.
> * doc/invoke.texi (--param x86-stv-max-visits): Document it.
> * config/i386/i386-features.h (scalar_chain::max_visits): New.
> (scalar_chain::build): Add bitmap parameter, return boolean.
> (scalar_chain::add_insn): Likewise.
> (scalar_chain::analyze_register_chain): Likewise.
> * config/i386/i386-features.cc (scalar_chain::scalar_chain):
> Initialize max_visits.
> (scalar_chain::analyze_register_chain): When we exhaust
> max_visits, abort.  Also abort when running into any
> disallowed insn.
> (scalar_chain::add_insn): Propagate abort.
> (scalar_chain::build): Likewise.  When aborting amend
> the set of disallowed insn with the insns set.
> (convert_scalars_to_vector): Adjust.  Do not convert aborted
> chains.

LGTM.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386-features.cc | 77 +++-
>  gcc/config/i386/i386-features.h  | 10 +++--
>  gcc/config/i386/i386.opt |  4 ++
>  gcc/doc/invoke.texi  |  4 ++
>  4 files changed, 70 insertions(+), 25 deletions(-)
>
> diff --git a/gcc/config/i386/i386-features.cc 
> b/gcc/config/i386/i386-features.cc
> index eff91301009..c09abf8fc20 100644
> --- a/gcc/config/i386/i386-features.cc
> +++ b/gcc/config/i386/i386-features.cc
> @@ -296,6 +296,8 @@ scalar_chain::scalar_chain (enum machine_mode smode_, 
> enum machine_mode vmode_)
>
>n_sse_to_integer = 0;
>n_integer_to_sse = 0;
> +
> +  max_visits = x86_stv_max_visits;
>  }
>
>  /* Free chain's data.  */
> @@ -354,10 +356,12 @@ scalar_chain::mark_dual_mode_def (df_ref def)
>  }
>
>  /* Check REF's chain to add new insns into a queue
> -   and find registers requiring conversion.  */
> +   and find registers requiring conversion.  Return true if OK, false
> +   if the analysis was aborted.  */
>
> -void
> -scalar_chain::analyze_register_chain (bitmap candidates, df_ref ref)
> +bool
> +scalar_chain::analyze_register_chain (bitmap candidates, df_ref ref,
> + bitmap disallowed)
>  {
>df_link *chain;
>bool mark_def = false;
> @@ -371,6 +375,9 @@ scalar_chain::analyze_register_chain (bitmap candidates, 
> df_ref ref)
>if (!NONDEBUG_INSN_P (DF_REF_INSN (chain->ref)))
> continue;
>
> +  if (--max_visits == 0)
> +   return false;
> +
>if (!DF_REF_REG_MEM_P (chain->ref))
> {
>   if (bitmap_bit_p (insns, uid))
> @@ -381,6 +388,10 @@ scalar_chain::analyze_register_chain (bitmap candidates, 
> df_ref ref)
>   add_to_queue (uid);
>   continue;
> }
> +
> + /* If we run into parts of an aborted chain discovery abort.  */
> + if (bitmap_bit_p (disallowed, uid))
> +   return false;
> }
>
>if (DF_REF_REG_DEF_P (chain->ref))
> @@ -401,15 +412,19 @@ scalar_chain::analyze_register_chain (bitmap 
> candidates, df_ref ref)
>
>if (mark_def)
>  mark_dual_mode_def (ref);
> +
> +  return true;
>  }
>
> -/* Add instruction into a chain.  */
> +/* Add instruction into a chain.  Return true if OK, false if the search
> +   was aborted.  */
>
> -void
> -scalar_chain::add_insn (bitmap candidates, unsigned int insn_uid)
> +bool
> +scalar_chain::add_insn (bitmap candidates, unsigned int insn_uid,
> +   bitmap disallowed)
>  {
>if (!bitmap_set_bit (insns, insn_uid))
> -return;
> +return true;
>
>if (dump_file)
>  fprintf (dump_file, "  Adding insn %d to chain #%d\n", insn_uid, 
> chain_id);
> @@ -426,22 +441,27 @@ scalar_chain::add_insn (bitmap candidates, unsigned int 
> insn_uid)
>df_ref ref;
>for (ref = DF_INSN_UID_DEFS (insn_uid); ref; ref = DF_REF_NEXT_LOC (ref))
>  if (!HARD_REGISTER_P (DF_REF_REG (ref)))
> -  analyze_register_chain (candidates, ref);
> +  if (!analyze_register_chain (candidates, ref, disallowed))
> +   return false;
>
>/* The operand(s) of VEC_SELECT don't need to be converted/convertible.  */
>if (def_set && GET_CODE (SET_SRC (def_set)) == VEC_SELECT)
> -return;
> +return true;
>
>for (ref = DF_INSN_UID_USES (insn_uid); ref; ref = DF_REF_NEXT_LOC (ref))
>  if (!DF_REF_REG_MEM_P (ref))
> -  analyze_register_chain (candidates, ref);
> +  if (!analyze_register_chain (candidates, ref, disallowed))
> +   return false;
> +
> +  

[Bug tree-optimization/109002] -O1 -ftree-pre -ftree-partial-pre results in stall value

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

--- Comment #2 from Akihiko Odaki  ---
Oops. Replacing i++ with i = !i removes the undefined behavior while the bug
still remains.

[Bug tree-optimization/109002] -O1 -ftree-pre -ftree-partial-pre results in stall value

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

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

--- Comment #1 from Andrew Pinski  ---
Note there will be undefined behavior when i become INT_MAx.

[Bug tree-optimization/109002] New: -O1 -ftree-pre -ftree-partial-pre results in stall value

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

Bug ID: 109002
   Summary: -O1 -ftree-pre -ftree-partial-pre results in stall
value
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akihiko.odaki at daynix dot com
  Target Milestone: ---

The following should emit an executable which prints "a" forever, but the
actual compiled executable prints nothing and just hangs. It seems the code
sees a stall value of variable g.

gcc -O1 -ftree-pre -ftree-partial-pre -x c - <

int g;
int h;

int main(void)
{
for (int i = 0; ; i++) {
for (int j = 0; j < g; j++);

if (i & 1) {
if (h)
continue;

if (g)
puts("a");

g = 1;
}
}
}
EOF

I reproduced this bug with the current master. gcc -v says:
Using built-in specs.
COLLECT_GCC=/home/alarm/gcc-installation/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap : (reconfigured)
../gcc/configure --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230302 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64'

/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/cc1
-quiet -v -iprefix
/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/
/home/alarm/a.c -quiet -dumpbase a.c -dumpbase-ext .c -mlittle-endian
-mabi=lp64 -version -o /tmp/ccetU9yt.s
GNU C17 (GCC) version 13.0.1 20230302 (experimental)
(aarch64-unknown-linux-gnu)
compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version
4.2.0, MPC version 1.3.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../../aarch64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include"
ignoring duplicate directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include-fixed"
ignoring nonexistent directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../../aarch64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include

/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include-fixed
 /usr/local/include
 /usr/include
End of search list.
Compiler executable checksum: 374b2759695ed1b72f52cb0f1847fbb3
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64'
 as -v -EL -mabi=lp64 -o /tmp/ccTu98hj.o /tmp/ccetU9yt.s
GNU assembler version 2.38 (aarch64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/:/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/
LIBRARY_PATH=/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/:/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/:/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../../lib64/:/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64' '-dumpdir' 'a.'

/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/collect2
-plugin
/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/liblto_plugin.so
-plugin-opt=/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccup8iGA.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux
/lib/crt1.o /lib/crti.o
/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/crtbegin.o
-L/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1
-L/home/alarm/

[Bug target/106770] powerpc64le: Unnecessary xxpermdi before mfvsrd

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

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

--- Comment #12 from Surya Kumari Jangala  ---
(In reply to Jens Seifert from comment #6)
> The left part of VSX registers overlaps with floating point registers, that
> is why no register xxpermdi is required and mfvsrd can access all (left)
> parts of VSX registers directly.
> The xxpermdi x,y,y,3 indicates to me that gcc prefers right part of register
> which might also cause the xxpermdi at the beginning. At the end the mystery
> is why gcc adds 3 xxpermdi to the code.

The 3rd xxpermdi is incorrect.

Re: [PATCH 01/07] RISC-V: Add auto-vectorization support

[Xi Ruoyao via Gcc-patches]

Please don't use the same title for all the patches.  This will puzzle
people running "git log" once they are committed.

And when you send 01-07, use "reply" instead of "new" so they will show
up in the correct location in a mail client.  Or use git send-email
which is much eaiser to use.

On Thu, 2023-03-02 at 23:52 -0500, Michael Collison wrote:
> This patch adds foundational support in the form of:
> 
> 1. New predicates
> 
> 2. New function prototypes
> 
> 3. Exporting emit_vlmax_vsetvl to global scope
> 
> 4. Add a new command line option -mriscv_vector_lmul
> 
> gcc/ChangeLog:
> 
>  * config/riscv/riscv-protos.h (riscv_classify_vlmul_field):

The change log entries should be indented with one tab, not some
whitespaces.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:1e4122f1159ace52c114c011013adce25172d77b

commit r13-6437-g1e4122f1159ace52c114c011013adce25172d77b
Author: Alexandre Oliva 
Date:   Fri Mar 3 01:47:00 2023 -0300

[PR100127] Test for coroutine header in clang-compatible tests

The test is compatible with clang as well as gcc, but ISTM that
testing for the __clang__ macro is just as potentially error-prone as
macros that used to be GCC-specific are now defined in compilers that
aim for GCC compatibility.  Use a __has_include feature test instead.


for  gcc/testsuite/ChangeLog

PR c++/100127
* g++.dg/coroutines/pr100127.C: Test for header rather than
compiler macro.
* g++.dg/coroutines/pr100772-a.C: Likewise.
* g++.dg/coroutines/pr100772-b.C: Likewise.

[PATCH 07/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patch adds tests for autovectorization of integer add and subtract.

gcc/testsuite/ChangeLog:

    * gcc.target/riscv/rvv/autovec: New directory
    for autovectorization tests.
    * gcc.target/riscv/rvv/autovec/loop-add-rv32.c: New
    test to verify code generation of vector add on rv32.
    * gcc.target/riscv/rvv/autovec/loop-add.c: New
    test to verify code generation of vector add on rv64.
    * gcc.target/riscv/rvv/autovec/loop-sub-rv32.c: New
    test to verify code generation of vector subtract on rv32.
    * gcc.target/riscv/rvv/autovec/loop-sub.c: New
    test to verify code generation of vector subtract on rv64.

---
 .../riscv/rvv/autovec/loop-add-rv32.c | 24 +++
 .../gcc.target/riscv/rvv/autovec/loop-add.c   | 24 +++
 .../riscv/rvv/autovec/loop-sub-rv32.c | 24 +++
 .../gcc.target/riscv/rvv/autovec/loop-sub.c   | 24 +++
 4 files changed, 96 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add-rv32.c

 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub-rv32.c

 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add-rv32.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add-rv32.c

new file mode 100644
index 000..bdc3b6892e9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add-rv32.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -ftree-vectorize -march=rv32gcv 
-mabi=ilp32d" } */

+
+#include 
+
+#define TEST_TYPE(TYPE)                 \
+  void vadd_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)    \
+  {                            \
+    for (int i = 0; i < n; i++)                \
+  dst[i] = a[i] + b[i];                \
+  }
+
+/* *int8_t not autovec currently. */
+#define TEST_ALL()    \
+ TEST_TYPE(int16_t)    \
+ TEST_TYPE(uint16_t)    \
+ TEST_TYPE(int32_t)    \
+ TEST_TYPE(uint32_t)    \
+ TEST_TYPE(int64_t)    \
+ TEST_TYPE(uint64_t)
+
+TEST_ALL()
+
+/* { dg-final { scan-assembler-times {\tvadd\.vv} 6 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add.c

new file mode 100644
index 000..d7f992c7d27
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -ftree-vectorize -march=rv64gcv 
-mabi=lp64d" } */

+
+#include 
+
+#define TEST_TYPE(TYPE)                 \
+  void vadd_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)    \
+  {                            \
+    for (int i = 0; i < n; i++)                \
+  dst[i] = a[i] + b[i];                \
+  }
+
+/* *int8_t not autovec currently. */
+#define TEST_ALL()    \
+ TEST_TYPE(int16_t)    \
+ TEST_TYPE(uint16_t)    \
+ TEST_TYPE(int32_t)    \
+ TEST_TYPE(uint32_t)    \
+ TEST_TYPE(int64_t)    \
+ TEST_TYPE(uint64_t)
+
+TEST_ALL()
+
+/* { dg-final { scan-assembler-times {\tvadd\.vv} 6 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub-rv32.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub-rv32.c

new file mode 100644
index 000..7d0a40ec539
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub-rv32.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -ftree-vectorize -march=rv32gcv 
-mabi=ilp32d" } */

+
+#include 
+
+#define TEST_TYPE(TYPE)                 \
+  void vadd_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)    \
+  {                            \
+    for (int i = 0; i < n; i++)                \
+  dst[i] = a[i] - b[i];                \
+  }
+
+/* *int8_t not autovec currently. */
+#define TEST_ALL()    \
+ TEST_TYPE(int16_t)    \
+ TEST_TYPE(uint16_t)    \
+ TEST_TYPE(int32_t)    \
+ TEST_TYPE(uint32_t)    \
+ TEST_TYPE(int64_t)    \
+ TEST_TYPE(uint64_t)
+
+TEST_ALL()
+
+/* { dg-final { scan-assembler-times {\tvsub\.vv} 6 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub.c

new file mode 100644
index 000..c8900884f83
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -ftree-vectorize -march=rv64gcv 
-mabi=lp64d" } */

+
+#include 
+
+#define TEST_TYPE(TYPE)                 \
+  void vadd_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)    \
+  {                            \
+    for (int i = 0; i < n; i++)                \
+  dst[i] = a[i] - b[i];                \
+  }
+
+/* *int8_t not autovec currently. */
+#define TEST_ALL()    \
+ TEST_TYPE(int16_t)    \
+ TEST_TYPE(uint16_t)    \
+ TEST_TYPE(int32_t)    \
+ TEST_TYPE(uint32_t)    \
+ TEST_TYPE(int64_t)    \
+ TEST_TYPE(uint64_t)
+
+TEST_ALL()
+
+/* { dg-final { 

[PATCH 06/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patch adds patterns that provide basic autovectorization support 
for integer adds and subtracts.


gcc/ChangeLog:

    * config/riscv/riscv.md (riscv_classify_vlmul_field):
    New external declaration.
    (riscv_vector_preferred_simd_mode): Include
    vector-iterators.md.
    * config/riscv/vector-auto.md: New file containing
    autovectorization patterns.
    * config/riscv/vector-iterators.md (UNSPEC_VADD/UNSPEC_VSUB):
    New unspecs for autovectorization patterns.
    * config/riscv/vector.md: Remove include of vector-iterators.md
    and include vector-auto.md.

---
 gcc/config/riscv/riscv.md    |   1 +
 gcc/config/riscv/vector-auto.md  | 172 +++
 gcc/config/riscv/vector-iterators.md |   2 +
 gcc/config/riscv/vector.md   |   4 +-
 4 files changed, 177 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/riscv/vector-auto.md

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 05924e9bbf1..c34124095f7 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -131,6 +131,7 @@
 (include "predicates.md")
 (include "constraints.md")
 (include "iterators.md")
+(include "vector-iterators.md")

 ;; 
 ;;
diff --git a/gcc/config/riscv/vector-auto.md 
b/gcc/config/riscv/vector-auto.md

new file mode 100644
index 000..e5a19663d18
--- /dev/null
+++ b/gcc/config/riscv/vector-auto.md
@@ -0,0 +1,172 @@
+;; Machine description for RISC-V 'V' Extension for GNU compiler.
+;; Copyright (C) 2022-2023 Free Software Foundation, Inc.
+;; Contributed by Juzhe Zhong (juzhe.zh...@rivai.ai), RiVAI 
Technologies Ltd.

+;; Contributed by Michael Collison (colli...@rivosinc.com, Rivos Inc.
+
+;; This file is part of GCC.
+
+;; GCC is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+
+;; GCC is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; .
+
+
+;; 
-

+;;  [INT] Addition
+;; 
-

+;; Includes:
+;; - vadd.vv
+;; - vadd.vx
+;; - vadd.vi
+;; 
-

+
+(define_expand "add3"
+  [(match_operand:VI 0 "register_operand")
+   (match_operand:VI 1 "register_operand")
+   (match_operand:VI 2 "vector_arith_operand")]
+  "TARGET_VECTOR"
+{
+  using namespace riscv_vector;
+
+  rtx merge = gen_rtx_UNSPEC (mode, gen_rtvec (1, const0_rtx), 
UNSPEC_VUNDEF);

+  rtx vl = emit_vlmax_vsetvl (mode);
+  rtx mask_policy = get_mask_policy_no_pred();
+  rtx tail_policy = get_tail_policy_no_pred();
+  rtx mask = CONSTM1_RTX(mode);
+  rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);
+
+  emit_insn(gen_pred_add(operands[0], mask, merge, operands[1], 
operands[2],

+                vl, tail_policy, mask_policy, vlmax_avl_p));
+
+  DONE;
+})
+
+(define_expand "cond_add"
+  [(match_operand:VI 0 "register_operand")
+   (match_operand: 1 "register_operand")
+   (match_operand:VI 2 "register_operand")
+   (match_operand:VI 3 "vector_reg_or_const_dup_operand")
+   (match_operand:VI 4 "register_operand")]
+  "TARGET_VECTOR"
+{
+  using namespace riscv_vector;
+
+  rtx merge = operands[4];
+  rtx vl = emit_vlmax_vsetvl (mode);
+  rtx mask_policy = get_mask_policy_no_pred();
+  rtx tail_policy = get_tail_policy_no_pred();
+  rtx mask = operands[1];
+  rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);
+
+  emit_insn(gen_pred_add(operands[0], mask, merge, operands[2], 
operands[3],

+                vl, tail_policy, mask_policy, vlmax_avl_p));
+  DONE;
+})
+
+(define_expand "len_add"
+  [(match_operand:VI 0 "register_operand")
+   (match_operand:VI 1 "register_operand")
+   (match_operand:VI 2 "vector_reg_or_const_dup_operand")
+   (match_operand 3 "p_reg_or_const_csr_operand")]
+  "TARGET_VECTOR"
+{
+  using namespace riscv_vector;
+
+  rtx merge = gen_rtx_UNSPEC (mode, gen_rtvec (1, const0_rtx), 
UNSPEC_VUNDEF);

+  rtx vl = operands[3];
+  rtx mask_policy = get_mask_policy_no_pred();
+  rtx tail_policy = get_tail_policy_no_pred();
+  rtx mask = CONSTM1_RTX(mode);
+  rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);
+
+  emit_insn(gen_pred_add(operands[0], mask, merge, operands[1], 
operands[2],

+                vl, tail_policy, mask_policy, vlmax_avl_p));
+  DONE;
+})
+
+
+;; 
-

+;;  [INT] Subtraction
+;; 

[PATCH 05/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patch adds support for registering target hooks for basic 
autovectorization support as well as basic tuning information for the 
vector extension.


gcc/ChangeLog:

    * config/riscv/riscv-cores.def (RISCV_TUNE):
    Add VECTOR_TUNE_INFO parameter and
    * common/config/riscv/riscv-common.cc (RISCV_TUNE):
    Add VECTOR_TUNE_INFO parameter.
    * config/riscv/riscv.cc (riscv_vector_tune_param):
    New struct for vector tuning information.
    (riscv_tune_info): add vector_tune_param.
    (vector_tune_param): New static variable.
    (riscv_vectorization_factor): New variable.
    (generic_rvv_insn_scale_table): New struct.
    (generic_rvv_stmt_scale_table): New struct.
    (generic_rvv_insn_cost_table): New vector insn cost table.
    (generic_rvv_stmt_cost_table): New vector statement cost table.
    (generic_rvv_tune_info): New rvv tuning table.
    (RISCV_TUNE): Add VECTOR_TUNE_INFO parameter.
    (riscv_rtx_costs): Return vector estimate if vector mode.
    (riscv_option_override): Set vector_tune_param.
    (riscv_option_override): Set riscv_vectorization_factor.
    (riscv_estimated_poly_value): Implement
    TARGET_ESTIMATED_POLY_VALUE.
    (riscv_preferred_simd_mode): Implement
    TARGET_VECTORIZE_PREFERRED_SIMD_MODE.
    (riscv_autovectorize_vector_modes): Implement
    TARGET_AUTOVECTORIZE_VECTOR_MODES.
    (riscv_get_mask_mode): Implement TARGET_VECTORIZE_GET_MASK_MODE.
    (riscv_empty_mask_is_expensive): Implement
    TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE.
    (riscv_builtin_vectorization_cost): Implement
    TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST.
    (riscv_vectorize_create_costs): Implement
    TARGET_VECTORIZE_CREATE_COSTS.
    (TARGET_ESTIMATED_POLY_VALUE): Register target macro.
    (TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST): Ditto.
    (TARGET_VECTORIZE_PREFERRED_SIMD_MODE): Ditto.
    (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Ditto.
    (TARGET_VECTORIZE_GET_MASK_MODE): Ditto.
    (TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE): Ditto.
    (TARGET_VECTORIZE_LOOP_LEN_OVERRIDE_MASK): Ditto.
    (TARGET_VECTORIZE_CREATE_COSTS): Ditto

---
 gcc/common/config/riscv/riscv-common.cc |   2 +-
 gcc/config/riscv/riscv-cores.def    |  14 +-
 gcc/config/riscv/riscv.cc   | 321 +++-
 3 files changed, 325 insertions(+), 12 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc

index ebc1ed7d7e4..6b8d92af986 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -246,7 +246,7 @@ static const riscv_cpu_info riscv_cpu_tables[] =

 static const char *riscv_tunes[] =
 {
-#define RISCV_TUNE(TUNE_NAME, PIPELINE_MODEL, TUNE_INFO) \
+#define RISCV_TUNE(TUNE_NAME, PIPELINE_MODEL, TUNE_INFO, 
VECTOR_TUNE_INFO)    \

 TUNE_NAME,
 #include "../../../config/riscv/riscv-cores.def"
 NULL
diff --git a/gcc/config/riscv/riscv-cores.def 
b/gcc/config/riscv/riscv-cores.def

index 2a834cae21d..4feb0366222 100644
--- a/gcc/config/riscv/riscv-cores.def
+++ b/gcc/config/riscv/riscv-cores.def
@@ -30,15 +30,15 @@
    identifier, reference to riscv.cc.  */

 #ifndef RISCV_TUNE
-#define RISCV_TUNE(TUNE_NAME, PIPELINE_MODEL, TUNE_INFO)
+#define RISCV_TUNE(TUNE_NAME, PIPELINE_MODEL, TUNE_INFO, VECTOR_TUNE_INFO)
 #endif

-RISCV_TUNE("rocket", generic, rocket_tune_info)
-RISCV_TUNE("sifive-3-series", generic, rocket_tune_info)
-RISCV_TUNE("sifive-5-series", generic, rocket_tune_info)
-RISCV_TUNE("sifive-7-series", sifive_7, sifive_7_tune_info)
-RISCV_TUNE("thead-c906", generic, thead_c906_tune_info)
-RISCV_TUNE("size", generic, optimize_size_tune_info)
+RISCV_TUNE("rocket", generic, rocket_tune_info, generic_rvv_tune_info)
+RISCV_TUNE("sifive-3-series", generic, rocket_tune_info, 
generic_rvv_tune_info)
+RISCV_TUNE("sifive-5-series", generic, rocket_tune_info, 
generic_rvv_tune_info)
+RISCV_TUNE("sifive-7-series", sifive_7, sifive_7_tune_info, 
generic_rvv_tune_info)
+RISCV_TUNE("thead-c906", generic, thead_c906_tune_info, 
generic_rvv_tune_info)

+RISCV_TUNE("size", generic, optimize_size_tune_info, generic_rvv_tune_info)

 #undef RISCV_TUNE

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index f11b7949a49..16b38ba4d76 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -60,6 +60,16 @@ along with GCC; see the file COPYING3.  If not see
 #include "opts.h"
 #include "tm-constrs.h"
 #include "rtl-iter.h"
+#include "gimple.h"
+#include "cfghooks.h"
+#include "cfgloop.h"
+#include "cfgrtl.h"
+#include "sel-sched.h"
+#include "fold-const.h"
+#include "gimple-iterator.h"
+#include "gimple-expr.h"
+#include "tree-vectorizer.h"
+#include "riscv-vector-cost.h"

 /* This file should be included last.  */
 #include "target-def.h"
@@ -238,6 +248,12 @@ struct riscv_tune_param
   bool slow_unaligned_access;
 };

+/* Cost for vector insn classes.  */
+struct riscv_vector_tune_param {
+    const vector_insn_cost_table* rvv_insn_costs_table;

[PATCH 04/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patch adds support for functions used in implementing various 
portions of autovectorization support.


gcc/ChangeLog:

    * config/riscv/riscv-v.cc (riscv_classify_vlmul_field):
    New function.
    (riscv_vector_preferred_simd_mode): Ditto.
    (get_mask_policy_no_pred): Ditto.
    (get_tail_policy_no_pred): Ditto.
    (riscv_tuple_mode_p): Ditto.
    (riscv_classify_nf): Ditto.
    (riscv_vlmul_regsize): Ditto.
    (riscv_vector_mask_mode_p): Ditto.
    (riscv_vector_get_mask_mode): Ditto.

---
 gcc/config/riscv/riscv-v.cc | 176 
 1 file changed, 176 insertions(+)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 58007cc16eb..58f69e259c0 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -39,9 +39,11 @@
 #include "emit-rtl.h"
 #include "tm_p.h"
 #include "target.h"
+#include "targhooks.h"
 #include "expr.h"
 #include "optabs.h"
 #include "tm-constrs.h"
+#include "riscv-vector-builtins.h"

 using namespace riscv_vector;

@@ -108,6 +110,41 @@ const_vec_all_same_in_range_p (rtx x, HOST_WIDE_INT 
minval,

   && IN_RANGE (INTVAL (elt), minval, maxval));
 }

+/* Return the vlmul field for a specific machine mode. */
+unsigned int
+riscv_classify_vlmul_field (enum machine_mode mode)
+{
+  /* Make the decision based on the mode's enum value rather than its
+ properties, so that we keep the correct classification regardless
+ of -mriscv-vector-bits.  */
+  switch (mode)
+    {
+    case E_VNx8BImode:
+  return VLMUL_FIELD_111;
+
+    case E_VNx4BImode:
+  return VLMUL_FIELD_110;
+
+    case E_VNx2BImode:
+  return VLMUL_FIELD_101;
+
+    case E_VNx16BImode:
+  return VLMUL_FIELD_000;
+
+    case E_VNx32BImode:
+  return VLMUL_FIELD_001;
+
+    case E_VNx64BImode:
+  return VLMUL_FIELD_010;
+
+    default:
+  break;
+    }
+
+  /* we don't care about VLMUL for Mask */
+  return VLMUL_FIELD_000;
+}
+
 rtx
 emit_vlmax_vsetvl (machine_mode vmode)
 {
@@ -162,6 +199,64 @@ calculate_ratio (unsigned int sew, enum vlmul_type 
vlmul)

   return ratio;
 }

+/* Implement TARGET_VECTORIZE_PREFERRED_SIMD_MODE for RVV.  */
+
+machine_mode
+riscv_vector_preferred_simd_mode (scalar_mode mode, unsigned vf)
+{
+  if (!TARGET_VECTOR)
+    return word_mode;
+
+  switch (mode)
+    {
+    case E_QImode:
+  return vf == 1   ? VNx8QImode
+     : vf == 2 ? VNx16QImode
+     : vf == 4 ? VNx32QImode
+           : VNx64QImode;
+  break;
+    case E_HImode:
+  return vf == 1   ? VNx4HImode
+     : vf == 2 ? VNx8HImode
+     : vf == 4 ? VNx16HImode
+           : VNx32HImode;
+  break;
+    case E_SImode:
+  return vf == 1   ? VNx2SImode
+     : vf == 2 ? VNx4SImode
+     : vf == 4 ? VNx8SImode
+           : VNx16SImode;
+  break;
+    case E_DImode:
+  if (riscv_vector_elen_flags != MASK_VECTOR_ELEN_32
+      && riscv_vector_elen_flags != MASK_VECTOR_ELEN_FP_32)
+    return vf == 1     ? VNx1DImode
+       : vf == 2 ? VNx2DImode
+       : vf == 4 ? VNx4DImode
+             : VNx8DImode;
+  break;
+    case E_SFmode:
+  if (TARGET_HARD_FLOAT && riscv_vector_elen_flags != 
MASK_VECTOR_ELEN_32

+      && riscv_vector_elen_flags != MASK_VECTOR_ELEN_64)
+    return vf == 1     ? VNx2SFmode
+       : vf == 2 ? VNx4SFmode
+       : vf == 4 ? VNx8SFmode
+             : VNx16SFmode;
+  break;
+    case E_DFmode:
+  if (TARGET_DOUBLE_FLOAT && TARGET_VECTOR_ELEN_FP_64)
+    return vf == 1     ? VNx1DFmode
+       : vf == 2 ? VNx2DFmode
+       : vf == 4 ? VNx4DFmode
+             : VNx8DFmode;
+  break;
+    default:
+  break;
+    }
+
+  return word_mode;
+}
+
 /* Emit an RVV unmask && vl mov from SRC to DEST.  */
 static void
 emit_pred_op (unsigned icode, rtx mask, rtx dest, rtx src, rtx len,
@@ -374,6 +469,87 @@ get_avl_type_rtx (enum avl_type type)
   return gen_int_mode (type, Pmode);
 }

+rtx
+get_mask_policy_no_pred ()
+{
+  return get_mask_policy_for_pred(PRED_TYPE_none);
+}
+
+rtx
+get_tail_policy_no_pred ()
+{
+  return get_mask_policy_for_pred(PRED_TYPE_none);
+}
+
+/* Return true if it is a RVV tuple mode. */
+bool
+riscv_tuple_mode_p (machine_mode mode ATTRIBUTE_UNUSED)
+{
+  return false;
+}
+
+/* Return nf for a machine mode. */
+int
+riscv_classify_nf (machine_mode mode)
+{
+  switch (mode)
+    {
+
+    default:
+  break;
+    }
+
+  return 1;
+}
+
+/* Return vlmul register size for a machine mode. */
+int
+riscv_vlmul_regsize (machine_mode mode)
+{
+  if (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL)
+    return 1;
+  switch (riscv_classify_vlmul_field (mode))
+    {
+    case VLMUL_FIELD_001:
+  return 2;
+    case VLMUL_FIELD_010:
+  return 4;
+    case VLMUL_FIELD_011:
+  return 8;
+    case VLMUL_FIELD_100:
+  gcc_unreachable ();
+    default:
+  return 1;
+    }
+}
+
+/* Return true if it is a RVV mask mode. */
+bool
+riscv_vector_mask_mode_p (machine_mode mode)

[PATCH 03/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patches adds two new files to support the vector cost model and 
modifies the Makefile fragment to build the cost model c++ file. Due to 
the large size this patch is provided as an attachment.


gcc/ChangeLog:

    * gcc/config.gcc (riscv-vector-cost.o): New object file to build.
    * config/riscv/riscv-vector-cost.cc: New file for riscv vector cost
    model
    * config/riscv/riscv-vector-cost.h: New header file for riscv vector
    cost model.
    * config/riscv/t-riscv: Add make rule for riscv-vector-cost.o.


From eb995818cd5f77f85e8df93b690b00ce1fd1aa35 Mon Sep 17 00:00:00 2001
From: Michael Collison 
Date: Thu, 2 Mar 2023 12:27:36 -0500
Subject: [PATCH] Autovectorization patch set 2

---
 gcc/config.gcc|   2 +-
 gcc/config/riscv/riscv-vector-cost.cc | 620 ++
 gcc/config/riscv/riscv-vector-cost.h  | 400 +
 gcc/config/riscv/t-riscv  |   5 +
 4 files changed, 1026 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/riscv/riscv-vector-cost.cc
 create mode 100644 gcc/config/riscv/riscv-vector-cost.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index c070e6ecd2e..a401187 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,7 @@ pru-*-*)
 riscv*)
 	cpu_type=riscv
 	extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o riscv-selftests.o riscv-v.o riscv-vsetvl.o"
-	extra_objs="${extra_objs} riscv-vector-builtins.o riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
+	extra_objs="${extra_objs} riscv-vector-cost.o riscv-vector-builtins.o riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
 	d_target_objs="riscv-d.o"
 	extra_headers="riscv_vector.h"
 	target_gtfiles="$target_gtfiles \$(srcdir)/config/riscv/riscv-vector-builtins.cc"
diff --git a/gcc/config/riscv/riscv-vector-cost.cc b/gcc/config/riscv/riscv-vector-cost.cc
new file mode 100644
index 000..5a33b20843a
--- /dev/null
+++ b/gcc/config/riscv/riscv-vector-cost.cc
@@ -0,0 +1,620 @@
+/* Cost model implementation for RISC-V 'V' Extension for GNU compiler.
+   Copyright (C) 2022-2023 Free Software Foundation, Inc.
+   Contributed by Juzhe Zhong (juzhe.zh...@rivai.ai), RiVAI Technologies Ltd.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#define INCLUDE_STRING
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "backend.h"
+#include "rtl.h"
+#include "regs.h"
+#include "insn-config.h"
+#include "insn-attr.h"
+#include "recog.h"
+#include "rtlanal.h"
+#include "output.h"
+#include "alias.h"
+#include "tree.h"
+#include "stringpool.h"
+#include "attribs.h"
+#include "varasm.h"
+#include "stor-layout.h"
+#include "calls.h"
+#include "function.h"
+#include "explow.h"
+#include "memmodel.h"
+#include "emit-rtl.h"
+#include "reload.h"
+#include "tm_p.h"
+#include "target.h"
+#include "basic-block.h"
+#include "expr.h"
+#include "optabs.h"
+#include "bitmap.h"
+#include "df.h"
+#include "diagnostic.h"
+#include "builtins.h"
+#include "predict.h"
+#include "tree-pass.h"
+#include "opts.h"
+#include "langhooks.h"
+#include "rtl-iter.h"
+#include "gimple.h"
+#include "cfghooks.h"
+#include "cfgloop.h"
+#include "fold-const.h"
+#include "gimple-iterator.h"
+#include "tree-vectorizer.h"
+#include "tree-ssa-loop-niter.h"
+#include "riscv-vector-builtins.h"
+
+/* This file should be included last.  */
+#include "riscv-vector-cost.h"
+#include "target-def.h"
+
+bool vector_insn_cost_table::get_cost(rtx x, machine_mode mode, int *cost,
+  bool speed) const {
+  rtx op0, op1, op2;
+  enum rtx_code code = GET_CODE(x);
+  scalar_int_mode int_mode;
+
+  /* By default, assume that everything has equivalent cost to the
+ cheapest instruction.  Any additional costs are applied as a delta
+ above this default.  */
+  *cost = COSTS_N_INSNS(1);
+
+  switch (code) {
+  case SET:
+/* The cost depends entirely on the operands to SET.  */
+*cost = 0;
+op0 = SET_DEST(x);
+op1 = SET_SRC(x);
+
+switch (GET_CODE(op0)) {
+case MEM:
+  if (speed) {
+*cost += store->cost(x, mode);
+  }
+
+  //*cost += rtx_cost(op1, mode, SET, 1, speed);
+  return true;
+
+case SUBREG:
+  if (!REG_P(SUBREG_REG(op0)))
+*cost += rtx_cost(SUBREG_REG(op0), VOIDmode, SET, 0, speed);
+
+  /* 

[PATCH 02/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patch adds foundational support by making two functions that handle 
predication policies visibly globally.


gcc/ChangeLog:

    * config/riscv/riscv-vector-builtins.cc (get_tail_policy_for_pred):
    Remove static declaration to to make externally visible.
    (get_mask_policy_for_pred): Ditto.
    * config/riscv/riscv-vector-builtins.h (get_tail_policy_for_pred):
    New external declaration.
    (get_mask_policy_for_pred): Ditto.

---
 gcc/config/riscv/riscv-vector-builtins.cc | 4 ++--
 gcc/config/riscv/riscv-vector-builtins.h  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc

index 2e92ece3b64..90fc73a5bcf 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -1850,7 +1850,7 @@ use_real_merge_p (enum predication_type_index pred)

 /* Get TAIL policy for predication. If predication indicates TU, 
return the TU.

    Otherwise, return the prefer default configuration.  */
-static rtx
+rtx
 get_tail_policy_for_pred (enum predication_type_index pred)
 {
   if (pred == PRED_TYPE_tu || pred == PRED_TYPE_tum || pred == 
PRED_TYPE_tumu)
@@ -1860,7 +1860,7 @@ get_tail_policy_for_pred (enum 
predication_type_index pred)


 /* Get MASK policy for predication. If predication indicates MU, 
return the MU.

    Otherwise, return the prefer default configuration.  */
-static rtx
+rtx
 get_mask_policy_for_pred (enum predication_type_index pred)
 {
   if (pred == PRED_TYPE_tumu || pred == PRED_TYPE_mu)
diff --git a/gcc/config/riscv/riscv-vector-builtins.h 
b/gcc/config/riscv/riscv-vector-builtins.h

index ede08c6a480..135e2463b1e 100644
--- a/gcc/config/riscv/riscv-vector-builtins.h
+++ b/gcc/config/riscv/riscv-vector-builtins.h
@@ -433,6 +433,8 @@ extern const char *const operand_suffixes[NUM_OP_TYPES];
 extern const rvv_builtin_suffixes type_suffixes[NUM_VECTOR_TYPES + 1];
 extern const char *const predication_suffixes[NUM_PRED_TYPES];
 extern rvv_builtin_types_t builtin_types[NUM_VECTOR_TYPES + 1];
+extern rtx get_tail_policy_for_pred (enum predication_type_index pred);
+extern rtx get_mask_policy_for_pred (enum predication_type_index pred);

 inline bool
 function_instance::operator!= (const function_instance ) const
--
2.34.1

[PATCH 01/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This patch adds foundational support in the form of:

1. New predicates

2. New function prototypes

3. Exporting emit_vlmax_vsetvl to global scope

4. Add a new command line option -mriscv_vector_lmul

gcc/ChangeLog:

    * config/riscv/riscv-protos.h (riscv_classify_vlmul_field):
    New external declaration.
    (riscv_vector_preferred_simd_mode): Ditto.
    (riscv_tuple_mode_p): Ditto.
    (riscv_vector_mask_mode_p): Ditto.
    (riscv_classify_nf): Ditto.
    (riscv_vlmul_regsize): Ditto.
    (riscv_vector_preferred_simd_mode): Ditto.
    (riscv_vector_get_mask_mode): Ditto.
    (emit_vlmax_vsetvl): Ditto.
    (get_mask_policy_no_pred): Ditto.
    (get_tail_policy_no_pred): Ditto.
    * config/riscv/riscv-opts.h (riscv_vector_bits_enum): New enum.
    (riscv_vector_lmul_enum): Ditto.
    (vlmul_field_enum): Ditto.
    * config/riscv/riscv-v.cc (emit_vlmax_vsetvl):
    Remove static scope.
    * config/riscv/riscv.opt (riscv_vector_lmul):
    New option -mriscv_vector_lmul.
    * config/riscv/predicates.md (p_reg_or_const_csr_operand):
    New predicate.
    (vector_reg_or_const_dup_operand): Ditto.

---
 gcc/config/riscv/predicates.md  | 13 +++
 gcc/config/riscv/riscv-opts.h   | 40 +
 gcc/config/riscv/riscv-protos.h | 16 +
 gcc/config/riscv/riscv-v.cc |  2 +-
 gcc/config/riscv/riscv.opt  | 20 +
 5 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 7bc7c0b4f4d..31517ae4606 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -264,6 +264,14 @@
 })

 ;; Predicates for the V extension.
+(define_special_predicate "p_reg_or_const_csr_operand"
+  (match_code "reg, subreg, const_int")
+{
+  if (CONST_INT_P (op))
+    return satisfies_constraint_K (op);
+  return GET_MODE (op) == Pmode;
+})
+
 (define_special_predicate "vector_length_operand"
   (ior (match_operand 0 "pmode_register_operand")
    (match_operand 0 "const_csr_operand")))
@@ -287,6 +295,11 @@
   (ior (match_operand 0 "register_operand")
    (match_test "op == CONSTM1_RTX (GET_MODE (op))")))

+(define_predicate "vector_reg_or_const_dup_operand"
+  (ior (match_operand 0 "register_operand")
+   (match_test "const_vec_duplicate_p (op)
+  && !CONST_POLY_INT_P (CONST_VECTOR_ELT (op, 0))")))
+
 (define_predicate "vector_mask_operand"
   (ior (match_operand 0 "register_operand")
    (match_operand 0 "vector_all_trues_mask_operand")))
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index ff398c0a2ae..2057a14e153 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -67,6 +67,46 @@ enum stack_protector_guard {
   SSP_GLOBAL            /* global canary */
 };

+/* RVV vector register sizes.  */
+enum riscv_vector_bits_enum
+{
+  RVV_SCALABLE,
+  RVV_NOT_IMPLEMENTED = RVV_SCALABLE,
+  RVV_64 = 64,
+  RVV_128 = 128,
+  RVV_256 = 256,
+  RVV_512 = 512,
+  RVV_1024 = 1024,
+  RVV_2048 = 2048,
+  RVV_4096 = 4096,
+  RVV_8192 = 8192,
+  RVV_16384 = 16384,
+  RVV_32768 = 32768,
+  RVV_65536 = 65536
+};
+
+/* vectorization factor.  */
+enum riscv_vector_lmul_enum
+{
+  RVV_LMUL1 = 1,
+  RVV_LMUL2 = 2,
+  RVV_LMUL4 = 4,
+  RVV_LMUL8 = 8
+};
+
+enum vlmul_field_enum
+{
+  VLMUL_FIELD_000, /* LMUL = 1 */
+  VLMUL_FIELD_001, /* LMUL = 2 */
+  VLMUL_FIELD_010, /* LMUL = 4 */
+  VLMUL_FIELD_011, /* LMUL = 8 */
+  VLMUL_FIELD_100, /* RESERVED */
+  VLMUL_FIELD_101, /* LMUL = 1/8 */
+  VLMUL_FIELD_110, /* LMUL = 1/4 */
+  VLMUL_FIELD_111, /* LMUL = 1/2 */
+  MAX_VLMUL_FIELD
+};
+
 #define MASK_ZICSR    (1 << 0)
 #define MASK_ZIFENCEI (1 << 1)

diff --git a/gcc/config/riscv/riscv-protos.h 
b/gcc/config/riscv/riscv-protos.h

index 37c634eca1d..70c8dc4ce69 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -200,4 +200,19 @@ const unsigned int RISCV_BUILTIN_SHIFT = 1;
 /* Mask that selects the riscv_builtin_class part of a function code.  */
 const unsigned int RISCV_BUILTIN_CLASS = (1 << RISCV_BUILTIN_SHIFT) - 1;

+/* Routines implemented in riscv-v.cc*/
+
+namespace riscv_vector {
+extern unsigned int riscv_classify_vlmul_field (enum machine_mode m);
+extern machine_mode riscv_vector_preferred_simd_mode (scalar_mode mode, 
unsigned vf);

+extern bool riscv_tuple_mode_p (machine_mode);
+extern bool riscv_vector_mask_mode_p (machine_mode);
+extern int riscv_classify_nf (machine_mode);
+extern int riscv_vlmul_regsize(machine_mode);
+extern machine_mode riscv_vector_preferred_simd_mode (scalar_mode mode, 
unsigned vf);

+extern opt_machine_mode riscv_vector_get_mask_mode (machine_mode mode);
+extern rtx emit_vlmax_vsetvl (machine_mode vmode);
+extern rtx get_mask_policy_no_pred ();
+extern rtx get_tail_policy_no_pred ();
+}
 #endif /* ! GCC_RISCV_PROTOS_H */
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 59c25c65cd5..58007cc16eb 100644
--- 

[PATCH 00/07] RISC-V: Add auto-vectorization support

[Michael Collison]

This series of patches adds foundational support for RISC-V 
autovectorization. These patches are based on the current upstream rvv 
vector intrinsic support and is not a new implementation. Most of the 
implementation consists of adding the new vector cost model, the 
autovectorization patterns themselves and target hooks.


This implementation only provides support for integer addition and 
subtraction as a proof of concept.


As discussed on this list, if these patches are approved they will be 
merged into a "auto-vectorization" branch once gcc-13 branches for release.


There are two known issues related to crashes (assert failures) 
associated with tree vectorization; one of which I have sent a patch for 
and have received feedback. I will be sending a patch for the second 
issue tomorrow.



 gcc/common/config/riscv/riscv-common.cc   |   2 +-
 gcc/config.gcc    |   2 +-
 gcc/config/riscv/predicates.md    |  13 +
 gcc/config/riscv/riscv-cores.def  |  14 +-
 gcc/config/riscv/riscv-opts.h |  40 ++
 gcc/config/riscv/riscv-protos.h   |  15 +
 gcc/config/riscv/riscv-v.cc   | 178 -
 gcc/config/riscv/riscv-vector-builtins.cc |   4 +-
 gcc/config/riscv/riscv-vector-builtins.h  |   2 +
 gcc/config/riscv/riscv-vector-cost.cc | 620 ++
 gcc/config/riscv/riscv-vector-cost.h  | 400 +++
 gcc/config/riscv/riscv.cc | 321 -
 gcc/config/riscv/riscv.md |   1 +
 gcc/config/riscv/riscv.opt    |  20 +
 gcc/config/riscv/t-riscv  |   5 +
 gcc/config/riscv/vector-auto.md   | 172 +
 gcc/config/riscv/vector-iterators.md  |   2 +
 gcc/config/riscv/vector.md    |   4 +-
 .../riscv/rvv/autovec/loop-add-rv32.c |  24 +
 .../gcc.target/riscv/rvv/autovec/loop-add.c   |  24 +
 .../riscv/rvv/autovec/loop-sub-rv32.c |  24 +
 .../gcc.target/riscv/rvv/autovec/loop-sub.c   |  24 +
 22 files changed, 1893 insertions(+), 18 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-vector-cost.cc
 create mode 100644 gcc/config/riscv/riscv-vector-cost.h
 create mode 100644 gcc/config/riscv/vector-auto.md
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add-rv32.c

 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-add.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub-rv32.c

 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/loop-sub.c

[Bug c++/109001] New: “no declaration matches” for complicated non-type template parameters

[headch at gmail dot com via Gcc-bugs]

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

Bug ID: 109001
   Summary: “no declaration matches” for complicated non-type
template parameters
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

I’m reasonably certain (but not completely) that this is valid code:

#include 
#include 

template
class C {
public:
template
C set();
};

template
template
C C::set() {
return {};
}

however, GCC rejects it with “error: no declaration matches ‘C(x, y)> C::set()’” on the out-of-body function definition. This
is accepted in GCC 11.3, as well as the latest versions of Clang and MSVC on
gcc.godbolt.org. Interestingly, GCC 12 also accepts the code if I change the
function definition (just the definition, not the in-body declaration) to use
trailing-return-type syntax:

#include 
#include 

template
class C {
public:
template
C set();
};

template
template
auto C::set() -> C {
return {};
}

[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support

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

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

--- Comment #1 from Xi Ruoyao  ---
Merging libffi is a big change and not suitable for stage 3 IMO.

Can we can apply the LoongArch patch locally instead?  It will not affect other
targets and even if does not work perfectly on LoongArch we don't lose
anything.

[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||xry111 at gcc dot gnu.org
   Last reconfirmed||2023-03-03

Re: [PATCH] LoongArch: Stop -mfpu from silently breaking ABI

[Xi Ruoyao via Gcc-patches]

On Fri, 2023-03-03 at 10:12 +0800, Yujie Yang wrote:
> However, "loongarch64" is defined to include the "fpu64" ISA module[1]
> (i.e. enable "-mfpu=64" when -mfpu is not explicitly used). So I believe
> the above behavior you observed is expected.

Ah this make things much simpler and aligns with my gut feeling :).  I
can drop the change in loongarch-opts.cc now.  And the smaller changeset
also makes me more confident about a backport to gcc-12.

V2 patch is being tested and I'll send it after the testing.  Meanwhile
I created PR109000 to track the issue.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug target/109000] LoongArch: "unmatched" -mabi and -mfpu setting can break ABI silently

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

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

Xi Ruoyao  changed:

   What|Removed |Added

  Known to fail||12.2.0, 13.0
   Last reconfirmed||2023-03-03
 Target||loongarch64-linux-gnu
   Assignee|unassigned at gcc dot gnu.org  |xry111 at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |12.3

--- Comment #1 from Xi Ruoyao  ---
I've already made the patch.  Just create a PR to track the issue.

[Bug target/109000] New: LoongArch: "unmatched" -mabi and -mfpu setting can break ABI silently

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

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

Bug ID: 109000
   Summary: LoongArch: "unmatched" -mabi and -mfpu setting can
break ABI silently
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

$ cat t.c
double t(double x)
{
return 1.0 / x;
}
$ ~/gcc-trunk/bin/gcc t.c -O2 -c -mabi=lp64s
$ readelf -a t.o | grep FLOAT
  Flags: 0x41, SOFT-FLOAT, OBJ-v1
$ objdump -d t.o

t.o: file format elf64-loongarch


Disassembly of section .text:

 :
   0:   01145800frecip.d$fa0, $fa0
   4:   4c20jirl$zero, $ra, 0

So we now have a SOFT-FLOAT object using FPR for arguments and return values
:(.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Tom Stellard from comment #4)
> This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> so I bisected it down to this commit:
> https://github.com/llvm/llvm-project/commit/
> 6747fc07d1aa94e22622e278e5a02ba70675ac9b

can you bisect GCC instead?

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Tom Stellard  ---
This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, so I
bisected it down to this commit:
https://github.com/llvm/llvm-project/commit/6747fc07d1aa94e22622e278e5a02ba70675ac9b

[Bug d/108877] Explicit immutable struct import internal compiler error

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from ibuclaw at gcc dot gnu.org ---
Fix committed and backported.

[Bug d/108877] Explicit immutable struct import internal compiler error

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:c90e68bffa37edd655dd2f5d14bb7b213c9e2431

commit r10-11235-gc90e68bffa37edd655dd2f5d14bb7b213c9e2431
Author: Iain Buclaw 
Date:   Mon Feb 27 20:46:18 2023 +0100

d: Fix ICE on explicit immutable struct import [PR108877]

Const and immutable types are built as variants of the type they are
derived from, and TYPE_STUB_DECL is not set for these variants.

PR d/108877

gcc/d/ChangeLog:

* imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call
make_import on TYPE_MAIN_VARIANT.
(ImportVisitor::visit (AggregateDeclaration *)): Likewise.
(ImportVisitor::visit (ClassDeclaration *)): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr108877a.d: New test.
* gdc.dg/pr108877.d: New test.

(cherry picked from commit ce1cea3e22f58bbddde017f8a92e59bae8892339)

RE: [PATCH v2] RISC-V: Bugfix for rvv bool mode precision adjustment

[Li, Pan2 via Gcc-patches]

Got it. Thank you and very appreciate for your help and patient. Updated the 
PATCH to below link.

https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613257.html

Pan

-Original Message-
From: Richard Sandiford  
Sent: Friday, March 3, 2023 1:55 AM
To: Li, Pan2 
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; 
rguent...@suse.de
Subject: Re: [PATCH v2] RISC-V: Bugfix for rvv bool mode precision adjustment

"Li, Pan2"  writes:
> Oops, looks I missed that part for assertion. Thank you for coaching.
> Added and tested the below changes at the end of emit_mode_adjustments 
> already but looks we may have other problems about the size, the precision 
> and the C types.
>
> Looks like I need to hold this PATCH for a while until we have a conclusion. 
> Feel free to let me know if there is mistake or misleading.
>
> + 
> +  for_all_modes (c, m)
> +printf ("  gcc_checking_assert (!mode_size[E_%smode].is_constant()"
> +   " || mode_size[E_%smode].coeffs[0] != -1);\n", m->name, 
> + m->name);
> +

Using:

  gcc_assert (maybe_ne (mode_size[E_%smode], -1));

would be simpler.  We might as well make it a full assert (rather than a 
checking assert) because this code isn't executed very often.

Thanks,
Richard

>
> Thank you and have a nice day!
>
> Pan
>
>
> -Original Message-
> From: Richard Sandiford 
> Sent: Thursday, March 2, 2023 5:44 PM
> To: Li, Pan2 
> Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; 
> kito.ch...@sifive.com; rguent...@suse.de
> Subject: Re: [PATCH v2] RISC-V: Bugfix for rvv bool mode precision 
> adjustment
>
> pan2...@intel.com writes:
>> From: Pan Li 
>>
>>  Fix the bug of the rvv bool mode precision with the adjustment.
>>  The bits size of vbool*_t will be adjusted to
>>  [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
>>  adjusted mode precison of vbool*_t will help underlying pass to
>>  make the right decision for both the correctness and optimization.
>>
>>  Given below sample code:
>>  void test_1(int8_t * restrict in, int8_t * restrict out)
>>  {
>>vbool8_t v2 = *(vbool8_t*)in;
>>vbool16_t v5 = *(vbool16_t*)in;
>>*(vbool16_t*)(out + 200) = v5;
>>*(vbool8_t*)(out + 100) = v2;
>>  }
>>
>>  Before the precision adjustment:
>>  addia4,a1,100
>>  vsetvli a5,zero,e8,m1,ta,ma
>>  addia1,a1,200
>>  vlm.v   v24,0(a0)
>>  vsm.v   v24,0(a4)
>>  // Need one vsetvli and vlm.v for correctness here.
>>  vsm.v   v24,0(a1)
>>
>>  After the precision adjustment:
>>  csrrt0,vlenb
>>  sllit1,t0,1
>>  csrra3,vlenb
>>  sub sp,sp,t1
>>  sllia4,a3,1
>>  add a4,a4,sp
>>  sub a3,a4,a3
>>  vsetvli a5,zero,e8,m1,ta,ma
>>  addia2,a1,200
>>  vlm.v   v24,0(a0)
>>  vsm.v   v24,0(a3)
>>  addia1,a1,100
>>  vsetvli a4,zero,e8,mf2,ta,ma
>>  csrrt0,vlenb
>>  vlm.v   v25,0(a3)
>>  vsm.v   v25,0(a2)
>>  sllit1,t0,1
>>  vsetvli a5,zero,e8,m1,ta,ma
>>  vsm.v   v24,0(a1)
>>  add sp,sp,t1
>>  jr  ra
>>
>>  However, there may be some optimization opportunates after
>>  the mode precision adjustment. It can be token care of in
>>  the RISC-V backend in the underlying separted PR(s).
>>
>>  PR 108185
>>  PR 108654
>>
>> gcc/ChangeLog:
>>
>>  * config/riscv/riscv-modes.def (ADJUST_PRECISION):
>>  * config/riscv/riscv.cc (riscv_v_adjust_precision):
>>  * config/riscv/riscv.h (riscv_v_adjust_precision):
>>  * genmodes.cc (ADJUST_PRECISION):
>>  (emit_mode_adjustments):
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * gcc.target/riscv/pr108185-1.c: New test.
>>  * gcc.target/riscv/pr108185-2.c: New test.
>>  * gcc.target/riscv/pr108185-3.c: New test.
>>  * gcc.target/riscv/pr108185-4.c: New test.
>>  * gcc.target/riscv/pr108185-5.c: New test.
>>  * gcc.target/riscv/pr108185-6.c: New test.
>>  * gcc.target/riscv/pr108185-7.c: New test.
>>  * gcc.target/riscv/pr108185-8.c: New test.
>>
>> Signed-off-by: Pan Li 
>> ---
>>  gcc/config/riscv/riscv-modes.def|  8 +++
>>  gcc/config/riscv/riscv.cc   | 12 
>>  gcc/config/riscv/riscv.h|  1 +
>>  gcc/genmodes.cc | 20 +-
>>  gcc/testsuite/gcc.target/riscv/pr108185-1.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-2.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-3.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-4.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-5.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-6.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-7.c | 68 ++ 
>> gcc/testsuite/gcc.target/riscv/pr108185-8.c | 77 
>> +
>>  12 files changed, 592 insertions(+), 

[Bug d/108877] Explicit immutable struct import internal compiler error

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:fe6cd1ba23ecbce9c0206c08db182cb5164e3b7d

commit r11-10554-gfe6cd1ba23ecbce9c0206c08db182cb5164e3b7d
Author: Iain Buclaw 
Date:   Mon Feb 27 20:46:18 2023 +0100

d: Fix ICE on explicit immutable struct import [PR108877]

Const and immutable types are built as variants of the type they are
derived from, and TYPE_STUB_DECL is not set for these variants.

PR d/108877

gcc/d/ChangeLog:

* imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call
make_import on TYPE_MAIN_VARIANT.
(ImportVisitor::visit (AggregateDeclaration *)): Likewise.
(ImportVisitor::visit (ClassDeclaration *)): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr108877a.d: New test.
* gdc.dg/pr108877.d: New test.

(cherry picked from commit ce1cea3e22f58bbddde017f8a92e59bae8892339)

[PATCH v3] RISC-V: Bugfix for rvv bool mode precision adjustment

[pan2.li--- via Gcc-patches]

From: Pan Li 

Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make the right decision for both the correctness and optimization.

Given below sample code:
void test_1(int8_t * restrict in, int8_t * restrict out)
{
  vbool8_t v2 = *(vbool8_t*)in;
  vbool16_t v5 = *(vbool16_t*)in;
  *(vbool16_t*)(out + 200) = v5;
  *(vbool8_t*)(out + 100) = v2;
}

Before the precision adjustment:
addia4,a1,100
vsetvli a5,zero,e8,m1,ta,ma
addia1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a4)
// Need one vsetvli and vlm.v for correctness here.
vsm.v   v24,0(a1)

After the precision adjustment:
csrrt0,vlenb
sllit1,t0,1
csrra3,vlenb
sub sp,sp,t1
sllia4,a3,1
add a4,a4,sp
sub a3,a4,a3
vsetvli a5,zero,e8,m1,ta,ma
addia2,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
addia1,a1,100
vsetvli a4,zero,e8,mf2,ta,ma
csrrt0,vlenb
vlm.v   v25,0(a3)
vsm.v   v25,0(a2)
sllit1,t0,1
vsetvli a5,zero,e8,m1,ta,ma
vsm.v   v24,0(a1)
add sp,sp,t1
jr  ra

However, there may be some optimization opportunates after
the mode precision adjustment. It can be token care of in
the RISC-V backend in the underlying separted PR(s).

PR 108185
PR 108654

gcc/ChangeLog:

* config/riscv/riscv-modes.def (ADJUST_PRECISION):
* config/riscv/riscv.cc (riscv_v_adjust_precision):
* config/riscv/riscv.h (riscv_v_adjust_precision):
* genmodes.cc (ADJUST_PRECISION):
(emit_mode_adjustments):

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr108185-1.c: New test.
* gcc.target/riscv/pr108185-2.c: New test.
* gcc.target/riscv/pr108185-3.c: New test.
* gcc.target/riscv/pr108185-4.c: New test.
* gcc.target/riscv/pr108185-5.c: New test.
* gcc.target/riscv/pr108185-6.c: New test.
* gcc.target/riscv/pr108185-7.c: New test.
* gcc.target/riscv/pr108185-8.c: New test.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-modes.def|  8 +++
 gcc/config/riscv/riscv.cc   | 12 
 gcc/config/riscv/riscv.h|  1 +
 gcc/genmodes.cc | 26 ++-
 gcc/testsuite/gcc.target/riscv/pr108185-1.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-2.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-3.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-4.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-5.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-6.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-7.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-8.c | 77 +
 12 files changed, 598 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-8.c

diff --git a/gcc/config/riscv/riscv-modes.def b/gcc/config/riscv/riscv-modes.def
index d5305efa8a6..110bddce851 100644
--- a/gcc/config/riscv/riscv-modes.def
+++ b/gcc/config/riscv/riscv-modes.def
@@ -72,6 +72,14 @@ ADJUST_BYTESIZE (VNx16BI, riscv_vector_chunks * 
riscv_bytes_per_vector_chunk);
 ADJUST_BYTESIZE (VNx32BI, riscv_vector_chunks * riscv_bytes_per_vector_chunk);
 ADJUST_BYTESIZE (VNx64BI, riscv_v_adjust_nunits (VNx64BImode, 8));
 
+ADJUST_PRECISION (VNx1BI, riscv_v_adjust_precision (VNx1BImode, 1));
+ADJUST_PRECISION (VNx2BI, riscv_v_adjust_precision (VNx2BImode, 2));
+ADJUST_PRECISION (VNx4BI, riscv_v_adjust_precision (VNx4BImode, 4));
+ADJUST_PRECISION (VNx8BI, riscv_v_adjust_precision (VNx8BImode, 8));
+ADJUST_PRECISION (VNx16BI, riscv_v_adjust_precision (VNx16BImode, 16));
+ADJUST_PRECISION (VNx32BI, riscv_v_adjust_precision (VNx32BImode, 32));
+ADJUST_PRECISION (VNx64BI, riscv_v_adjust_precision (VNx64BImode, 64));
+
 /*
| Mode| MIN_VLEN=32 | MIN_VLEN=32 | MIN_VLEN=64 | MIN_VLEN=64 |
| | LMUL| SEW/LMUL| LMUL| SEW/LMUL|
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 

[Bug d/108877] Explicit immutable struct import internal compiler error

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:2583365912c8700abe1f4a23ed611acb80fac09d

commit r12-9212-g2583365912c8700abe1f4a23ed611acb80fac09d
Author: Iain Buclaw 
Date:   Mon Feb 27 20:46:18 2023 +0100

d: Fix ICE on explicit immutable struct import [PR108877]

Const and immutable types are built as variants of the type they are
derived from, and TYPE_STUB_DECL is not set for these variants.

PR d/108877

gcc/d/ChangeLog:

* imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call
make_import on TYPE_MAIN_VARIANT.
(ImportVisitor::visit (AggregateDeclaration *)): Likewise.
(ImportVisitor::visit (ClassDeclaration *)): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr108877a.d: New test.
* gdc.dg/pr108877.d: New test.

(cherry picked from commit ce1cea3e22f58bbddde017f8a92e59bae8892339)

Re: [PATCH] LoongArch: Stop -mfpu from silently breaking ABI

[Yujie Yang]

On Fri, Mar 03, 2023 at 12:01:22AM +0800, Xi Ruoyao via Gcc-patches wrote:
> But then it causes "-mabi=lp64s -march=loongarch64" to generate code like:
> 
>   movgr2fr.d $fa0, $a0
>   frecip.d   $fa0, $fa0
>   movfr2gr.d $a0, $fa0
> 
> The problem here is "loongarch64" is never strictly defined.  So we
> consider "loongarch64" a "64-bit LoongArch CPU with the simplest FPU
> needed by the ABI", and if -march=loongarch64 but -mfpu is not
> explicitly used, we set -mfpu such a simplest one.

Thanks for the fix on TARGET_*_FLOAT_ABI usage! Certainly more testing
needs to be done on the soft-float side.

However, "loongarch64" is defined to include the "fpu64" ISA module[1]
(i.e. enable "-mfpu=64" when -mfpu is not explicitly used). So I believe
the above behavior you observed is expected.

[1] Table 5. Target CPU Models,
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html

[Bug target/108315] -mcpu=power10 changes ABI

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

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

--- Comment #12 from David Edelsohn  ---
We're working to add a Power10 system to the Compile Farm.  The systems are at
OSUOSL, but Power10 doesn't have official KVM support so the interface to the
OpenStack management system is complicated.

[Bug rtl-optimization/108999] New: Maybe LRA produce inaccurate hardware register occupancy information for subreg operand

[lehua.ding at rivai dot ai via Gcc-bugs]

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

Bug ID: 108999
   Summary: Maybe LRA produce inaccurate hardware register
occupancy information for subreg operand
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lehua.ding at rivai dot ai
  Target Milestone: ---

The problem code on the compiler explorer is here:
https://godbolt.org/z/GaGWEahPY

The problem is that the line `mov z1.d, z4.d` of the assembly code[1] is
unnecessary. I find the reason is the LRA pass[2] thinks the hard registers
`(subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) [16, 16])` occupied is in
conflict with `(reg/v:VNx2DI 98 [ v19 ])`[3]. That is not true because r103
occupied 32 and 33, and r98 occupied 34 according to the dump information of
IRA[4]. This is because the function process_alt_operands in lra-constraints.cc
source file[5]. When it checks whether the operand 0 of insn 39 is in conflict
with other operands of insn 39, it set operand 0 occupied 33 and 34 according
to the mode(`biggest_mode[i]`) and the start hard regno
33(`clobbered_hard_regno`). The mode it used is VNx4DI, I think it should use
Vnx2DI which is the proper mode for the entire operand 0. So for getting the
occupied hard register of the normal subreg operand, it is maybe too wider if
use the inner reg's mode.

References:

[1] assembly code
```
subreg_coalesce5:
mov p1.b, p0.b
ld2d{z0.d - z1.d}, p0/z, [x0]
cmp w1, 0
ble .L2
sxtwx1, w1
mov x0, 0
.L3:
ld1dz3.d, p1/z, [x2, x0, lsl 3]
ld1dz2.d, p1/z, [x3, x0, lsl 3]
add x0, x0, 1
movprfx z4.d, p0/z, z1.d
mla z4.d, p0/m, z3.d, z2.d
movprfx z0.d, p0/z, z0.d
mla z0.d, p0/m, z3.d, z2.d
mov z1.d, z4.d
cmp x1, x0
bne .L3
.L2:
st2d{z0.d - z1.d}, p0, [x4]
ret
```

[2] partial content of LRA dump info
```
...
0 Early clobber: reject++
0 Conflict early clobber reload: reject--
  alt=0,overall=6,losers=1,rld_nregs=0
0 Early clobber: reject++
  alt=1,overall=1,losers=0,rld_nregs=0
 Choosing alt 1 in insn 36:  (0)   (1) Upl  (2) w  (3) w  (4) 0  (5)
Dz {*cond_fmavnx2di_any}
0 Early clobber: reject++
0 Matched conflict early clobber reloads: reject--
  alt=0,overall=6,losers=1,rld_nregs=0
0 Early clobber: reject++
0 Conflict early clobber reload: reject--
  alt=1,overall=6,losers=1,rld_nregs=0
0 Early clobber: reject++
2 Matching earlyclobber alt: reject--
  alt=2,overall=6,losers=1,rld_nregs=1
0 Early clobber: reject++
3 Matching earlyclobber alt: reject--
  alt=3,overall=6,losers=1,rld_nregs=1
0 Early clobber: reject++
5 Matching earlyclobber alt: reject--
5 Non-pseudo reload: reject+=2
5 Non input pseudo reload: reject++
alt=4,overall=9,losers=1 -- refuse
Staticly defined alt reject+=6
0 Early clobber: reject++
5 Non-pseudo reload: reject+=2
5 Non input pseudo reload: reject++
alt=5,overall=16,losers=1 -- refuse
 Choosing alt 0 in insn 39:  (0) =  (1) Upl  (2) w  (3) w  (4) w  (5)
Dz {*cond_fmavnx2di_any}
  Creating newreg=117, assigning class FP_REGS to r117
   39:
r117:VNx2DI=unspec[r104:VNx16BI#0,r97:VNx2DI*r98:VNx2DI+r103:VNx4DI#[16,16],const_vector]
284
  REG_DEAD r98:VNx2DI
  REG_DEAD r97:VNx2DI
Inserting insn reload after:
   76: r103:VNx4DI#[16,16]=r117:VNx2DI
...
```

[3] partial rtl of IRA pass
```lisp
(insn 36 43 37 4 (set (subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) 0)
(unspec:VNx2DI [
(subreg:VNx2BI (reg/v:VNx16BI 104 [ pg ]) 0)
(plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 97 [ v18 ])
(reg/v:VNx2DI 98 [ v19 ]))
(subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) 0))
(const_vector:VNx2DI repeat [
(const_int 0 [0])
])
] UNSPEC_SEL)) "/app/example.c":13:25 discrim 1 7465
{*cond_fmavnx2di_any}
 (nil))
(insn 39 37 40 4 (set (subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) [16, 16])
(unspec:VNx2DI [
(subreg:VNx2BI (reg/v:VNx16BI 104 [ pg ]) 0)
(plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 97 [ v18 ])
(reg/v:VNx2DI 98 [ v19 ]))
(subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) [16, 16]))
(const_vector:VNx2DI repeat [
(const_int 0 [0])
])
] UNSPEC_SEL)) "/app/example.c":14:25 

[Bug target/108315] -mcpu=power10 changes ABI

[rui314 at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Rui Ueyama  ---
I'll try to add a POWER10 support to mold using Qemu.

[Bug d/108167] d: internal compiler error: in binary_op, at d/expr.cc:117

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Fix has already been committed as part of a previous upstream/dmd merge.  Added
test.

[Bug d/108945] [13.0] d: vector float comparison doesn't result in 0 or -1

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Fix committed.

[Bug d/108946] [13.0] d: Identity comparison of vectors not supported

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Fix committed.

[Bug d/108877] Explicit immutable struct import internal compiler error

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:ce1cea3e22f58bbddde017f8a92e59bae8892339

commit r13-6432-gce1cea3e22f58bbddde017f8a92e59bae8892339
Author: Iain Buclaw 
Date:   Mon Feb 27 20:46:18 2023 +0100

d: Fix ICE on explicit immutable struct import [PR108877]

Const and immutable types are built as variants of the type they are
derived from, and TYPE_STUB_DECL is not set for these variants.

PR d/108877

gcc/d/ChangeLog:

* imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call
make_import on TYPE_MAIN_VARIANT.
(ImportVisitor::visit (AggregateDeclaration *)): Likewise.
(ImportVisitor::visit (ClassDeclaration *)): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr108877a.d: New test.
* gdc.dg/pr108877.d: New test.

[Bug d/108946] [13.0] d: Identity comparison of vectors not supported

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:929c6b8cd12a3bd338a4c250274a9d86da5b2ea7

commit r13-6433-g929c6b8cd12a3bd338a4c250274a9d86da5b2ea7
Author: Iain Buclaw 
Date:   Fri Mar 3 00:00:44 2023 +0100

d: Allow vectors to be compared for identity [PR108946]

Vector equality and comparisons are now accepted by the language
implementation, but identity wasn't.  Implement it as an extra integer
comparison of the bit-casted bitmask.

PR d/108946

gcc/d/ChangeLog:

* d-target.cc (Target::isVectorOpSupported): Allow identity ops.
* expr.cc (ExprVisitor::visit (IdentityExp *)): Handle vector
identity
comparisons.

gcc/testsuite/ChangeLog:

* gdc.dg/simd2a.d: Update test.
* gdc.dg/simd2b.d: Likewise.
* gdc.dg/simd2c.d: Likewise.
* gdc.dg/simd2d.d: Likewise.
* gdc.dg/simd2e.d: Likewise.
* gdc.dg/simd2f.d: Likewise.
* gdc.dg/simd2g.d: Likewise.
* gdc.dg/simd2h.d: Likewise.
* gdc.dg/simd2i.d: Likewise.
* gdc.dg/simd2j.d: Likewise.

[Bug d/108167] d: internal compiler error: in binary_op, at d/expr.cc:117

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:33a7811896a6c8e6fa71e385dbdf5013d833a116

commit r13-6431-g33a7811896a6c8e6fa71e385dbdf5013d833a116
Author: Iain Buclaw 
Date:   Mon Feb 27 18:38:53 2023 +0100

d: Add test for PR d/108167 to the testsuite [PR108167]

The D front-end implementation got fixed in upstream, add test to the
gdc testsuite to check we don't regress on it.

PR d/108167

gcc/testsuite/ChangeLog:

* gdc.dg/pr108167.d: New test.

[Bug d/108945] [13.0] d: vector float comparison doesn't result in 0 or -1

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:51af8a6401eea726d3498e6b2aba456b6af246d6

commit r13-6430-g51af8a6401eea726d3498e6b2aba456b6af246d6
Author: Iain Buclaw 
Date:   Mon Feb 27 16:02:21 2023 +0100

d: vector float comparison doesn't result in 0 or -1 [PR108945]

When comparing two vectors, the type of vector was used as the result of
the condition result.  This meant that for floating point comparisons,
each value would either be `0.0' or `-1.0' reinterpreted as an integer,
not the expected integral bitmask values `0' and `-1'.

Instead, use the comparison type determined by truth_type_for as the
result of the comparison.  If a reinterpret is later required by the
final conversion for generating CmpExp, it is still only going to
reinterpret one integer kind as another.

PR d/108945

gcc/d/ChangeLog:

* d-codegen.cc (build_boolop): Evaluate vector comparison as
the truth_type_for vector type.

gcc/testsuite/ChangeLog:

* gdc.dg/pr108945.d: New test.

[committed] d: vector float comparison doesn't result in 0 or -1 [PR108945]

[Iain Buclaw via Gcc-patches]

Hi,

When comparing two vectors, the type of vector was used as the result of
the condition result.  This meant that for floating point comparisons,
each value would either be `0.0' or `-1.0' reinterpreted as an integer,
not the expected integral bitmask values `0' and `-1'.

Instead, use the comparison type determined by truth_type_for as the
result of the comparison.  If a reinterpret is later required by the
final conversion for generating CmpExp, it is still only going to
reinterpret one integer kind as another.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.

Regards,
Iain.

---
PR d/108945

gcc/d/ChangeLog:

* d-codegen.cc (build_boolop): Evaluate vector comparison as
the truth_type_for vector type.

gcc/testsuite/ChangeLog:

* gdc.dg/pr108945.d: New test.
---
 gcc/d/d-codegen.cc  |  9 -
 gcc/testsuite/gdc.dg/pr108945.d | 12 
 2 files changed, 16 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr108945.d

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 0e8e07366ee..5a041927ec9 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1453,13 +1453,12 @@ build_boolop (tree_code code, tree arg0, tree arg1)
 {
   /* Build a vector comparison.
 VEC_COND_EXPR ; */
-  tree type = TREE_TYPE (arg0);
-  tree cmptype = truth_type_for (type);
+  tree cmptype = truth_type_for (TREE_TYPE (arg0));
   tree cmp = fold_build2_loc (input_location, code, cmptype, arg0, arg1);
 
-  return fold_build3_loc (input_location, VEC_COND_EXPR, type, cmp,
- build_minus_one_cst (type),
- build_zero_cst (type));
+  return fold_build3_loc (input_location, VEC_COND_EXPR, cmptype, cmp,
+ build_minus_one_cst (cmptype),
+ build_zero_cst (cmptype));
 }
 
   if (code == EQ_EXPR || code == NE_EXPR)
diff --git a/gcc/testsuite/gdc.dg/pr108945.d b/gcc/testsuite/gdc.dg/pr108945.d
new file mode 100644
index 000..03b9de8e758
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr108945.d
@@ -0,0 +1,12 @@
+// { dg-options "-fdump-tree-gimple" }
+// { dg-additional-options "-mavx" { target avx_runtime } }
+// { dg-do compile { target { avx_runtime || vect_sizes_16B_8B } } }
+
+alias f4 = __vector(float[4]);
+
+auto pr108945(f4 a, f4 b)
+{
+return a < b;
+}
+
+// { dg-final { scan-tree-dump-not "VEC_COND_EXPR" "gimple" } }
-- 
2.37.2

[committed] d: Fix ICE on explicit immutable struct import [PR10887]

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes an ICE in the D front-end when importing an immutable
struct.  Const and immutable types are built as variants of the type
they are derived from, and TYPE_STUB_DECL is not set for these variants.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline, and backported to the release branches for gcc-10, gcc-11,
and gcc-12.

Regards,
Iain.

---
PR d/108877

gcc/d/ChangeLog:

* imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call
make_import on TYPE_MAIN_VARIANT.
(ImportVisitor::visit (AggregateDeclaration *)): Likewise.
(ImportVisitor::visit (ClassDeclaration *)): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr108877a.d: New test.
* gdc.dg/pr108877.d: New test.
---
 gcc/d/imports.cc | 7 ++-
 gcc/testsuite/gdc.dg/imports/pr108877a.d | 6 ++
 gcc/testsuite/gdc.dg/pr108877.d  | 9 +
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gdc.dg/imports/pr108877a.d
 create mode 100644 gcc/testsuite/gdc.dg/pr108877.d

diff --git a/gcc/d/imports.cc b/gcc/d/imports.cc
index 3b46d1b7560..2efef4ed54f 100644
--- a/gcc/d/imports.cc
+++ b/gcc/d/imports.cc
@@ -106,12 +106,16 @@ public:
 tree type = build_ctype (d->type);
 /* Not all kinds of D enums create a TYPE_DECL.  */
 if (TREE_CODE (type) == ENUMERAL_TYPE)
-  this->result_ = this->make_import (TYPE_STUB_DECL (type));
+  {
+   type = TYPE_MAIN_VARIANT (type);
+   this->result_ = this->make_import (TYPE_STUB_DECL (type));
+  }
   }
 
   void visit (AggregateDeclaration *d) final override
   {
 tree type = build_ctype (d->type);
+type = TYPE_MAIN_VARIANT (type);
 this->result_ = this->make_import (TYPE_STUB_DECL (type));
   }
 
@@ -119,6 +123,7 @@ public:
   {
 /* Want the RECORD_TYPE, not POINTER_TYPE.  */
 tree type = TREE_TYPE (build_ctype (d->type));
+type = TYPE_MAIN_VARIANT (type);
 this->result_ = this->make_import (TYPE_STUB_DECL (type));
   }
 
diff --git a/gcc/testsuite/gdc.dg/imports/pr108877a.d 
b/gcc/testsuite/gdc.dg/imports/pr108877a.d
new file mode 100644
index 000..a23c78ddf84
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/imports/pr108877a.d
@@ -0,0 +1,6 @@
+immutable struct ImmutableS { }
+const struct ConstS { }
+immutable class ImmutableC { }
+const class ConstC { }
+immutable enum ImmutableE { _ }
+const enum ConstE { _ }
diff --git a/gcc/testsuite/gdc.dg/pr108877.d b/gcc/testsuite/gdc.dg/pr108877.d
new file mode 100644
index 000..710551f3f9a
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr108877.d
@@ -0,0 +1,9 @@
+// { dg-options "-I $srcdir/gdc.dg" }
+// { dg-do compile }
+import imports.pr108877a :
+ImmutableS,
+ConstS,
+ImmutableC,
+ConstC,
+ImmutableE,
+ConstE;
-- 
2.37.2

[committed] d: Allow vectors to be compared for identity (PR108946)

[Iain Buclaw via Gcc-patches]

Hi,

Vector equality and comparisons are now accepted by the language
implementation, but identity wasn't.  This patch implements it as an
extra integer comparison of the bit-casted bitmask.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.

Regards,
Iain.

---
PR d/108946

gcc/d/ChangeLog:

* d-target.cc (Target::isVectorOpSupported): Allow identity ops.
* expr.cc (ExprVisitor::visit (IdentityExp *)): Handle vector identity
comparisons.

gcc/testsuite/ChangeLog:

* gdc.dg/simd2a.d: Update test.
* gdc.dg/simd2b.d: Likewise.
* gdc.dg/simd2c.d: Likewise.
* gdc.dg/simd2d.d: Likewise.
* gdc.dg/simd2e.d: Likewise.
* gdc.dg/simd2f.d: Likewise.
* gdc.dg/simd2g.d: Likewise.
* gdc.dg/simd2h.d: Likewise.
* gdc.dg/simd2i.d: Likewise.
* gdc.dg/simd2j.d: Likewise.
---
 gcc/d/d-target.cc |  5 -
 gcc/d/expr.cc | 25 +
 gcc/testsuite/gdc.dg/simd2a.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2b.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2c.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2d.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2e.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2f.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2g.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2h.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2i.d |  5 +++--
 gcc/testsuite/gdc.dg/simd2j.d |  5 +++--
 12 files changed, 55 insertions(+), 25 deletions(-)

diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc
index 5eab5706ead..4c7a212703e 100644
--- a/gcc/d/d-target.cc
+++ b/gcc/d/d-target.cc
@@ -323,11 +323,6 @@ Target::isVectorOpSupported (Type *type, EXP op, Type *)
   /* Logical operators must have a result type of bool.  */
   return false;
 
-case EXP::identity:
-case EXP::notIdentity:
-  /* Comparison operators must have a result type of bool.  */
-  return false;
-
 default:
   break;
 }
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index c8ec37d7103..4311edcc2d6 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -313,6 +313,31 @@ public:
 
this->result_ = build_struct_comparison (code, ts->sym, t1, t2);
   }
+else if (tb1->ty == TY::Tvector && tb2->ty == TY::Tvector)
+  {
+   /* For vectors, identity is defined as all values being equal.  */
+   tree t1 = build_expr (e->e1);
+   tree t2 = build_expr (e->e2);
+   tree mask = build_boolop (code, t1, t2);
+
+   /* To reinterpret the vector comparison as a boolean expression, bitcast
+  the bitmask result and generate an additional integer comparison.  */
+   opt_scalar_int_mode mode =
+ int_mode_for_mode (TYPE_MODE (TREE_TYPE (mask)));
+   gcc_assert (mode.exists ());
+
+   tree type = lang_hooks.types.type_for_mode (mode.require (), 1);
+   if (type == NULL_TREE)
+ type = make_unsigned_type (GET_MODE_BITSIZE (mode.require ()));
+
+   /* In `t1 is t2', all mask bits must be set for vectors to be equal.
+  Otherwise any bit set is enough for vectors to be not-equal.  */
+   tree mask_eq = (code == EQ_EXPR)
+ ? build_all_ones_cst (type) : build_zero_cst (type);
+
+   this->result_ = build_boolop (code, mask_eq,
+ build_vconvert (type, mask));
+  }
 else
   {
/* For operands of other types, identity is defined as being the
diff --git a/gcc/testsuite/gdc.dg/simd2a.d b/gcc/testsuite/gdc.dg/simd2a.d
index 373d5d1e229..d47175fd38b 100644
--- a/gcc/testsuite/gdc.dg/simd2a.d
+++ b/gcc/testsuite/gdc.dg/simd2a.d
@@ -5,6 +5,7 @@ import core.simd;
 void test2a()
 {
 byte16 v1, v2 = 1, v3 = 1;
+bool b1;
 v1 = v2;
 v1 = v2 + v3;
 v1 = v2 - v3;
@@ -16,8 +17,8 @@ void test2a()
 v1 = v2 ^ v3;
 static assert(!__traits(compiles, v1 ~ v2));
 static assert(!__traits(compiles, v1 ^^ v2));
-static assert(!__traits(compiles, v1 is v2));
-static assert(!__traits(compiles, v1 !is v2));
+b1 = v1 is v2;
+b1 = v1 !is v2;
 static assert( __traits(compiles, v1 == v2));
 static assert( __traits(compiles, v1 != v2));
 static assert( __traits(compiles, v1 < v2));
diff --git a/gcc/testsuite/gdc.dg/simd2b.d b/gcc/testsuite/gdc.dg/simd2b.d
index e72da0d9b77..a1b2a10caaf 100644
--- a/gcc/testsuite/gdc.dg/simd2b.d
+++ b/gcc/testsuite/gdc.dg/simd2b.d
@@ -5,6 +5,7 @@ import core.simd;
 void test2b()
 {
 ubyte16 v1, v2 = 1, v3 = 1;
+bool b1;
 v1 = v2;
 v1 = v2 + v3;
 v1 = v2 - v3;
@@ -16,8 +17,8 @@ void test2b()
 v1 = v2 ^ v3;
 static assert(!__traits(compiles, v1 ~ v2));
 static assert(!__traits(compiles, v1 ^^ v2));
-static assert(!__traits(compiles, v1 is v2));
-static assert(!__traits(compiles, v1 !is v2));
+b1 = v1 is v2;
+b1 = v1 !is v2;
 static assert( __traits(compiles, v1 == v2));
 static assert( __traits(compiles, v1 != v2));
 static assert( __traits(compiles, 

[committed] d: Add test for PR d/108167 to the testsuite [PR108167]

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds the test for checking PR108167.  The D front-end
implementation got fixed in upstream, add test to the gdc testsuite to
check we don't regress on it.

Regression tested on x86_64-linux-gnu/-m32, and committed to mainline.

Regards,
Iain.

---
PR d/108167

gcc/testsuite/ChangeLog:

* gdc.dg/pr108167.d: New test.
---
 gcc/testsuite/gdc.dg/pr108167.d | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 gcc/testsuite/gdc.dg/pr108167.d

diff --git a/gcc/testsuite/gdc.dg/pr108167.d b/gcc/testsuite/gdc.dg/pr108167.d
new file mode 100644
index 000..1337a494171
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr108167.d
@@ -0,0 +1,5 @@
+// { dg-do compile }
+auto pr108167(const(ubyte[32])[] a)
+{
+return cast(const(ubyte)*)[1][0];
+}
-- 
2.37.2

[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Nikita Kniazev from comment #3)
> For cond == 789
>   if (cond_2(D) == 789)
> goto ; [20.24%]
>   else
> goto ; [79.76%]
> 
> For cond != 789
>   if (cond_2(D) != 789)
> goto ; [48.88%]
>   else
> goto ; [51.12%]

an intergal type equaling a specific # is handled this way on purpose. Bool
should be handled differently because it only has two values, 0/1.
Anyways != is not handled specially except for the zero value case ...

[Bug c++/108998] [13 Regression] ICE in tsubst, at cp/pt.cc:16037

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #3 from waffl3x  ---
I made a mistake in my previous comment, the version on my system that fails is
12.2.1, sorry for any possible confusion.

[Bug c++/108998] [13 Regression] ICE in tsubst, at cp/pt.cc:16037

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Priority|P3  |P1
 Ever confirmed|0   |1
Summary|ICE in tsubst, at   |[13 Regression] ICE in
   |cp/pt.cc:16037  |tsubst, at cp/pt.cc:16037
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2023-03-03

--- Comment #2 from Marek Polacek  ---
Started with r13-4730:

commit 18499b9f848707aee42d810e99ac0a4c9788433c
Author: Patrick Palka 
Date:   Thu Dec 15 16:02:05 2022 -0500

c++: extract_local_specs and unevaluated contexts [PR100295]

[Bug c++/108998] ICE in tsubst, at cp/pt.cc:16037

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from waffl3x  ---
I ran it on my local system, just to get some line numbers, and I accidentally
ran it on an older version (12.1) and found that it has a similar result, I'm
posting the output of -v and the error of both here. As a reminder, gcc 12.2 on
godbolt does not ICE.

[waffl3x@waffl3x-manjaro-desktop gcc]$ /opt/compiler/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/compiler/bin/g++
COLLECT_LTO_WRAPPER=/opt/compiler/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13-20230115/configure --enable-languages=c,c++,lto
--enable-bootstrap --prefix=/opt/compiler --mandir=/usr/share/man
--infodir=/usr/share/info --with-linker-hash-style=gnu --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-link-serialization=1 --enable-linker-build-id --enable-lto
--enable-plugin --enable-shared --enable-threads=posix --disable-libssp
--disable-werror --enable-clocale=gnu --enable-libstdcxx-backtrace
--enable-multilib --disable-libstdcxx-pch --with-build-config=bootstrap-lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20230115 (experimental) (GCC) 

[waffl3x@waffl3x-manjaro-desktop gcc]$ /opt/compiler/bin/g++ test.cpp
test.cpp: In instantiation of ‘ice(int):: [with int I = 0]’:
test.cpp:11:34:   required from ‘void ice(T) [with T = int]’
test.cpp:15:8:   required from here
test.cpp:7:10: internal compiler error: in tsubst, at cp/pt.cc:16025
7 | auto aa = a;
  |  ^~
0x635279 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:16025
0x8278de tsubst_decl
../../gcc-13-20230115/gcc/cp/pt.cc:15194
0x8302c8 tsubst_copy
../../gcc-13-20230115/gcc/cp/pt.cc:17267
0x8200fc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:21530
0x8248c8 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:16547
0x829de5 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:13659
0x821322 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:20299
0x80d340 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:19764
0x80e512 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:18711
0x80e512 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:19041
0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:18711
0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:19105
0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:18711
0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:19105
0x80d0d9 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-13-20230115/gcc/cp/pt.cc:26702
0x80d0d9 instantiate_body
../../gcc-13-20230115/gcc/cp/pt.cc:26702
0x81219d instantiate_decl(tree_node*, bool, bool)
../../gcc-13-20230115/gcc/cp/pt.cc:26992
0x6ffcb3 maybe_instantiate_decl(tree_node*)
../../gcc-13-20230115/gcc/cp/decl2.cc:5448
0x6ffcb3 maybe_instantiate_decl(tree_node*)
../../gcc-13-20230115/gcc/cp/decl2.cc:5435
0x718092 mark_used(tree_node*, int)
../../gcc-13-20230115/gcc/cp/decl2.cc:5747

[waffl3x@waffl3x-manjaro-desktop gcc]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/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++,d --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-build-config=bootstrap-lto --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-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.1 20230111 (GCC) 

[waffl3x@waffl3x-manjaro-desktop gcc]$ g++ test.cpp
test.cpp: In instantiation of ‘ice(int):: [with int I = 0]’:
test.cpp:11:34:   required from ‘void ice(T) [with T = int]’
test.cpp:15:8:   required from 

[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong

[nok.raven at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Nikita Kniazev  ---
For cond == 789
  if (cond_2(D) == 789)
goto ; [20.24%]
  else
goto ; [79.76%]

For cond != 789
  if (cond_2(D) != 789)
goto ; [48.88%]
  else
goto ; [51.12%]

Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension

[Qing Zhao via Gcc-patches]

Ping.

Qing

> On Feb 24, 2023, at 1:35 PM, Qing Zhao  wrote:
> 
> on a structure with a C99 flexible array member being nested in
> another structure.
> 
> "GCC extension accepts a structure containing an ISO C99 "flexible array
> member", or a union containing such a structure (possibly recursively)
> to be a member of a structure.
> 
> There are two situations:
> 
>   * The structure with a C99 flexible array member is the last field of
> another structure, for example:
> 
>  struct flex  { int length; char data[]; };
>  union union_flex { int others; struct flex f; };
> 
>  struct out_flex_struct { int m; struct flex flex_data; };
>  struct out_flex_union { int n; union union_flex flex_data; };
> 
> In the above, both 'out_flex_struct.flex_data.data[]' and
> 'out_flex_union.flex_data.f.data[]' are considered as flexible
> arrays too.
> 
>   * The structure with a C99 flexible array member is the middle field
> of another structure, for example:
> 
>  struct flex  { int length; char data[]; };
> 
>  struct mid_flex { int m; struct flex flex_data; int n; };
> 
> In the above, 'mid_flex.flex_data.data[]' is allowed to be extended
> flexibly to the padding.  E.g, up to 4 elements.
> 
> However, relying on space in struct padding is a bad programming
> practice, compilers do not handle such extension consistently, Any
> code relying on this behavior should be modified to ensure that
> flexible array members only end up at the ends of structures.
> 
> Please use warning option '-Wgnu-variable-sized-type-not-at-end' to
> identify all such cases in the source code and modify them.  This
> extension will be deprecated from gcc in the next release.
> "
> 
> gcc/c-family/ChangeLog:
> 
>   * c.opt: New option -Wgnu-variable-sized-type-not-at-end.
> 
> gcc/c/ChangeLog:
> 
>   * c-decl.cc (finish_struct): Issue warnings for new option.
> 
> gcc/ChangeLog:
> 
>   * doc/extend.texi: Document GCC extension on a structure containing
>   a flexible array member to be a member of another structure.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/variable-sized-type-flex-array.c: New test.
> ---
> gcc/c-family/c.opt|  5 ++
> gcc/c/c-decl.cc   |  7 +++
> gcc/doc/extend.texi   | 48 ++-
> .../gcc.dg/variable-sized-type-flex-array.c   | 31 
> 4 files changed, 90 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.dg/variable-sized-type-flex-array.c
> 
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index cddeece..660ac07f3d4 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -737,6 +737,11 @@ Wformat-truncation=
> C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_format_trunc) 
> Warning LangEnabledBy(C ObjC C++ LTO ObjC++,Wformat=, warn_format >= 1, 0) 
> IntegerRange(0, 2)
> Warn about calls to snprintf and similar functions that truncate output.
> 
> +Wgnu-variable-sized-type-not-at-end
> +C C++ Var(warn_variable_sized_type_not_at_end) Warning
> +Warn about structures or unions with C99 flexible array members are not
> +at the end of a structure.
> +
> Wif-not-aligned
> C ObjC C++ ObjC++ Var(warn_if_not_aligned) Init(1) Warning
> Warn when the field in a struct is not aligned.
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index f589a2f5192..c5b54f07965 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -9296,6 +9296,13 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
> tree attributes,
>  && is_last_field)
>   TYPE_INCLUDE_FLEXARRAY (t) = true;
> 
> +  if (warn_variable_sized_type_not_at_end
> +   && !is_last_field
> +   && TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x)))
> + warning_at (DECL_SOURCE_LOCATION (x),
> + OPT_Wgnu_variable_sized_type_not_at_end,
> + "variable sized type not at the end of a struct");
> +
>   if (DECL_NAME (x)
> || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
>   saw_named_field = true;
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index c1122916255..e278148c332 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -1748,7 +1748,53 @@ Flexible array members may only appear as the last 
> member of a
> A structure containing a flexible array member, or a union containing
> such a structure (possibly recursively), may not be a member of a
> structure or an element of an array.  (However, these uses are
> -permitted by GCC as extensions.)
> +permitted by GCC as extensions, see details below.)
> +@end itemize
> +
> +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array
> +member}, or a union containing such a structure (possibly recursively)
> +to be a member of a structure.
> +
> +There are two situations:
> +
> +@itemize @bullet
> +@item
> +The structure with a C99 flexible array 

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

[Qing Zhao via Gcc-patches]

Ping.

Qing

> On Feb 24, 2023, at 1:35 PM, Qing Zhao  wrote:
> 
> GCC extension accepts the case when a struct with a C99 flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible size.
> 
> gcc/c/ChangeLog:
> 
>   PR tree-optimization/101832
>   * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
>   struct/union type.
> 
> gcc/cp/ChangeLog:
> 
>   PR tree-optimization/101832
>   * module.cc (trees_out::core_bools): Stream out new bit
>   type_include_flexarray.
>   (trees_in::core_bools): Stream in new bit type_include_flexarray.
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/101832
>   * print-tree.cc (print_node): Print new bit type_include_flexarray.
>   * tree-core.h (struct tree_type_common): New bit
>   type_include_flexarray.
>   * tree-object-size.cc (addr_object_size): Handle structure/union type
>   when it has flexible size.
>   * tree-streamer-in.cc (unpack_ts_type_common_value_fields): Stream
>   in new bit type_include_flexarray.
>   * tree-streamer-out.cc (pack_ts_type_common_value_fields): Stream
>   out new bit type_include_flexarray.
>   * tree.h (TYPE_INCLUDE_FLEXARRAY): New macro
>   TYPE_INCLUDE_FLEXARRAY.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/101832
>   * gcc.dg/builtin-object-size-pr101832.c: New test.
> ---
> gcc/c/c-decl.cc   |  12 ++
> gcc/cp/module.cc  |   2 +
> gcc/print-tree.cc |   5 +
> .../gcc.dg/builtin-object-size-pr101832.c | 134 ++
> gcc/tree-core.h   |   4 +-
> gcc/tree-object-size.cc   |  79 +++
> gcc/tree-streamer-in.cc   |   1 +
> gcc/tree-streamer-out.cc  |   1 +
> gcc/tree.h|   6 +
> 9 files changed, 215 insertions(+), 29 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> 
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 08078eadeb8..f589a2f5192 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -9284,6 +9284,18 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
> tree attributes,
>   /* Set DECL_NOT_FLEXARRAY flag for FIELD_DECL x.  */
>   DECL_NOT_FLEXARRAY (x) = !is_flexible_array_member_p (is_last_field, x);
> 
> +  /* Set TYPE_INCLUDE_FLEXARRAY for the context of x, t
> +   * when x is an array.  */
> +  if (TREE_CODE (TREE_TYPE (x)) == ARRAY_TYPE)
> + TYPE_INCLUDE_FLEXARRAY (t) = flexible_array_member_type_p (TREE_TYPE 
> (x)) ;
> +  /* Recursively set TYPE_INCLUDE_FLEXARRAY for the context of x, t
> +  when x is the last field.  */
> +  else if ((TREE_CODE (TREE_TYPE (x)) == RECORD_TYPE
> + || TREE_CODE (TREE_TYPE (x)) == UNION_TYPE)
> +&& TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x))
> +&& is_last_field)
> + TYPE_INCLUDE_FLEXARRAY (t) = true;
> +
>   if (DECL_NAME (x)
> || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
>   saw_named_field = true;
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index ac2fe66b080..c750361b704 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -5371,6 +5371,7 @@ trees_out::core_bools (tree t)
>   WB (t->type_common.lang_flag_5);
>   WB (t->type_common.lang_flag_6);
>   WB (t->type_common.typeless_storage);
> +  WB (t->type_common.type_include_flexarray);
> }
> 
>   if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
> @@ -5551,6 +5552,7 @@ trees_in::core_bools (tree t)
>   RB (t->type_common.lang_flag_5);
>   RB (t->type_common.lang_flag_6);
>   RB (t->type_common.typeless_storage);
> +  RB (t->type_common.type_include_flexarray);
> }
> 
>   if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
> diff --git a/gcc/print-tree.cc b/gcc/print-tree.cc
> index 1f3afcbbc86..efacdb7686f 100644
> --- a/gcc/print-tree.cc
> +++ b/gcc/print-tree.cc
> @@ -631,6 +631,11 @@ print_node (FILE *file, const char *prefix, tree node, 
> int indent,
> && TYPE_CXX_ODR_P (node))
>   fputs (" cxx-odr-p", file);
> 
> +  if ((code == RECORD_TYPE
> +|| code == UNION_TYPE)
> +   && TYPE_INCLUDE_FLEXARRAY (node))
> + fputs (" include-flexarray", file);
> +
>   /* The transparent-union flag is used for different things in
>different nodes.  */
>   if ((code == UNION_TYPE || code == RECORD_TYPE)
> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c 
> b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> new file mode 100644
> index 000..60078e11634
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> @@ -0,0 +1,134 @@
> +/* PR 101832: 
> +   GCC extension accepts the case when a struct with a C99 flexible array
> +   member is embedded into 

Re: [V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

[Qing Zhao via Gcc-patches]

Ping

Qing

> On Feb 24, 2023, at 1:35 PM, Qing Zhao  wrote:
> 
> Hi, Joseph and Richard,
> 
> Could you please review this patch and let me know whether it’s ready
> for committing into GCC13?
> 
> The fix to Bug PR101832 is an important patch for kernel security
> purpose. it's better to be put into GCC13.
> 
> =
> 
> These are the 4th version of the patches for PR101832, to fix
> builtin_object_size to correctly handle component_ref to a
> structure/union field that includes a flexible array member.
> 
> also includes a documentation update for the GCC extension on embedding
> a structure/union with flexible array member into another structure.
> which includes a fix to PR77650.
> 
> compared to the 3rd version of the patch, the major changes are:
> 
> 1. update the documentation part per Joseph's comments.
> 
> compared to the 2nd version of the patch, the major changes are:
> 
> 1. only include C99 flexible array member to this extension, trailing [0], [1]
>  and [4] are all excluded.
> 2. for the new bit type_include_flexarray in tree_type_common, print it
>  and also stream in/out it. 
> 3. update testing cases.
> 4. more clarification on the documentation. warnings for deprecating the 
>  case when the structure with C99 FAM is embedded in the middle of
>  another structure. 
> 5. add a new warning option -Wgnu-variable-sized-type-not-at-end for
>  identifing all such cases.
> 
> bootstrapped and regression tested on aarch64 and x86.
> 
> Okay for commit?
> 
> thanks.
> 
> Qing
> 
> Qing Zhao (2):
>  Handle component_ref to a structre/union field including C99 FAM
>[PR101832]
>  Update documentation to clarify a GCC extension
> 
> gcc/c-family/c.opt|   5 +
> gcc/c/c-decl.cc   |  19 +++
> gcc/cp/module.cc  |   2 +
> gcc/doc/extend.texi   |  48 ++-
> gcc/print-tree.cc |   5 +
> .../gcc.dg/builtin-object-size-pr101832.c | 134 ++
> .../gcc.dg/variable-sized-type-flex-array.c   |  31 
> gcc/tree-core.h   |   4 +-
> gcc/tree-object-size.cc   |  79 +++
> gcc/tree-streamer-in.cc   |   1 +
> gcc/tree-streamer-out.cc  |   1 +
> gcc/tree.h|   6 +
> 12 files changed, 305 insertions(+), 30 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> create mode 100644 gcc/testsuite/gcc.dg/variable-sized-type-flex-array.c
> 
> -- 
> 2.31.1
> 

[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557

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

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

--- Comment #5 from Marek Polacek  ---
I think p_c_e just needs to handle constexpr functors in templates.  I'll poke
more tomorrow.

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

[Jeff Law via Gcc]

On 2/22/23 01:18, Florian Weimer via Gcc wrote:

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

We currently build the distribution with -ffat-lto-objects, and I want
to switch away from that.  Packages will need to opt in to
-ffat-lto-objects if static objects they build escape the buildroot.
And to make sure that this opt-in happens, I want to fail the build if
there would be any -fno-fat-lto-objects objects leaking.
Thanks for taking care of this.  It's one of the things I wish I'd had 
time to fix before leaving Red Hat.   We burn a fair amount of builder 
time due to this issue right now.


jeff

[Bug c++/108998] New: ICE in tsubst, at cp/pt.cc:16037

[waffl3x at protonmail dot com via Gcc-bugs]

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

Bug ID: 108998
   Summary: ICE in tsubst, at cp/pt.cc:16037
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: waffl3x at protonmail dot com
  Target Milestone: ---

Created attachment 54573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54573=edit
the output of -v on godbolt at the time of posting this report

template
inline constexpr bool templ = false;

template
void ice(T a)
{
auto aa = a;
auto lambda = [](){
if constexpr (templ) {}
};
lambda.template operator()<0>();
}

void go() {
ice(0);
}

https://godbolt.org/z/4qn9s6cad

The conditions for this were rather complicated, this was as far as I could
reduce it. Some things to note,
it does not trigger when the lambda's template parameter is a type parameter,
it does not trigger with an auto function parameter,
it does not trigger outside of if constexpr,
and it does not trigger when the first argument to templ is not a lambda's
template parameter.
I couldn't find a way to trigger it without a lambda's non type template
parameter.

: In instantiation of 'ice(int):: [with int I = 0]':
:11:34:   required from 'void ice(T) [with T = int]'
:15:8:   required from here
:7:10: internal compiler error: in tsubst, at cp/pt.cc:16037
7 | auto aa = a;
  |  ^~
0x247996e internal_error(char const*, ...)
???:0
0xae93fe fancy_abort(char const*, int, char const*)
???:0
0xd11fdd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd13f4d tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xd09c65 instantiate_decl(tree_node*, bool, bool)
???:0
0xbdf731 maybe_instantiate_decl(tree_node*)
???:0
0xbe11be mark_used(tree_node*, int)
???:0
0xb16f0e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xd09c65 instantiate_decl(tree_node*, bool, bool)
???:0
0xd35ffb instantiate_pending_templates(int)
???:0
0xbe4325 c_parse_final_cleanups()
???:0
0xe215f8 c_common_parse_file()
???:0

[Bug testsuite/108991] [13 regression] gcc.dg/memchr-3.c fails after r13-6414-g62a8d31ecc0704

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #2 from Jakub Jelinek  ---
Should be fixed now.

[committed] testsuite: Fix up memchr-3.c test [PR108991]

[Jakub Jelinek via Gcc-patches]

On Thu, Mar 02, 2023 at 01:43:30PM +, Jonathan Yong via Gcc-patches wrote:
> On 3/2/23 10:46, Richard Sandiford wrote:
> > > diff --git a/gcc/testsuite/gcc.dg/memchr-3.c 
> > > b/gcc/testsuite/gcc.dg/memchr-3.c
> > > index c38d9cf3349..af1b26ef3ae 100644
> > > --- a/gcc/testsuite/gcc.dg/memchr-3.c
> > > +++ b/gcc/testsuite/gcc.dg/memchr-3.c
> > > @@ -6,7 +6,7 @@
> > >   typedef __INT8_TYPE__  int8_t;
> > >   typedef __INT32_TYPE__ int32_t;
> > > -extern void* memchr (const void*, int, long);
> > > +extern void* memchr (const void*, int, long); /* { dg-warning 
> > > "-Wbuiltin-declaration-mismatch" { target llp64 } } */
> > >   struct SX
> > >   {
> > 
> > OK, thanks.
> 
> Thanks, pushed to master branch.

The newly added dg-warning directive was missing the comment argument,
so the target selector was treated as comment and the warning was expected
on all targets when it should be expected only on llp64 targets.

Tested on x86_64-linux -m32/-m64, committed to trunk as obvious:

2023-03-03  Jakub Jelinek  

PR testsuite/108991
* gcc.dg/memchr-3.c: Add missing comment argument to dg-warning
before target selector.

--- gcc/testsuite/gcc.dg/memchr-3.c.jj  2023-03-02 19:09:45.466594110 +0100
+++ gcc/testsuite/gcc.dg/memchr-3.c 2023-03-03 00:48:04.368348282 +0100
@@ -6,7 +6,7 @@
 typedef __INT8_TYPE__  int8_t;
 typedef __INT32_TYPE__ int32_t;
 
-extern void* memchr (const void*, int, long); /* { dg-warning 
"-Wbuiltin-declaration-mismatch" { target llp64 } } */
+extern void* memchr (const void*, int, long); /* { dg-warning 
"-Wbuiltin-declaration-mismatch" "" { target llp64 } } */
 
 struct SX
 {


Jakub

[Bug testsuite/108991] [13 regression] gcc.dg/memchr-3.c fails after r13-6414-g62a8d31ecc0704

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:73bbfd5970ba3b7a5bcb3f7043d93fec89ccb991

commit r13-6428-g73bbfd5970ba3b7a5bcb3f7043d93fec89ccb991
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:50:10 2023 +0100

testsuite: Fix up memchr-3.c test [PR108991]

The newly added dg-warning directive was missing the comment argument,
so the target selector was treated as comment and the warning was expected
on all targets when it should be expected only on llp64 targets.

2023-03-03  Jakub Jelinek  

PR testsuite/108991
* gcc.dg/memchr-3.c: Add missing comment argument to dg-warning
before target selector.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Costas Argyris from comment #15)
> Sounds like I am hitting a separate existing limitation that has nothing to
> do with this bug.
> 
> Do we need a new bug report for that one then?

No one bug report is enough really in this case. 
It should not be hard to come up with a secondary patch which fixes that issue.
I might give it a go in a few weeks if someone has not already.

[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Fixed now on the trunk.  I'd wait a little bit with backports, though I think
the gmp-param.h change doesn't need backporting.

[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows

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

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

--- Comment #13 from Jakub Jelinek  ---
Fixed now on the trunk.  I'd wait a little bit with backports, though I think
the gmp-param.h change doesn't need backporting.

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed now.

[Bug c++/16151] Poor diagnostics

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa

commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:40:13 2023 +0100

libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756]

This patch cherry-pickx 8 commits from glibc which fix various strtod_l
bugs.  Additionally, it makes mp_limb_t 64-bit on llp64 targets like
64-bit cygwin.

2023-03-03  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t,
BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

[Bug target/26137] Cannot connect to target board h8 using GDB

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa

commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:40:13 2023 +0100

libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756]

This patch cherry-pickx 8 commits from glibc which fix various strtod_l
bugs.  Additionally, it makes mp_limb_t 64-bit on llp64 targets like
64-bit cygwin.

2023-03-03  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t,
BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

[Bug target/18247] [4.0 regression] ada runtime bootstrap failure on powerpc-linux

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa

commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:40:13 2023 +0100

libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756]

This patch cherry-pickx 8 commits from glibc which fix various strtod_l
bugs.  Additionally, it makes mp_limb_t 64-bit on llp64 targets like
64-bit cygwin.

2023-03-03  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t,
BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

[Bug c++/16965] [3.4/4.0 regression] Confusing mismatch in error messages

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa

commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:40:13 2023 +0100

libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756]

This patch cherry-pickx 8 commits from glibc which fix various strtod_l
bugs.  Additionally, it makes mp_limb_t 64-bit on llp64 targets like
64-bit cygwin.

2023-03-03  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t,
BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa

commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:40:13 2023 +0100

libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756]

This patch cherry-pickx 8 commits from glibc which fix various strtod_l
bugs.  Additionally, it makes mp_limb_t 64-bit on llp64 targets like
64-bit cygwin.

2023-03-03  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t,
BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa

commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:40:13 2023 +0100

libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756]

This patch cherry-pickx 8 commits from glibc which fix various strtod_l
bugs.  Additionally, it makes mp_limb_t 64-bit on llp64 targets like
64-bit cygwin.

2023-03-03  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t,
BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:6978df2c04df165eaa6aac9e17b6c770bed460e3

commit r13-6426-g6978df2c04df165eaa6aac9e17b6c770bed460e3
Author: Jakub Jelinek 
Date:   Fri Mar 3 00:34:59 2023 +0100

c++, v3: Emit fundamental tinfos for _Float16/decltype(0.0bf16) types on
ia32 with -mno-sse2 [PR108883]

_Float16 and decltype(0.0bf16) types are on x86 supported only with
-msse2.  On x86_64 that is the default, but on ia32 it is not.
We should still emit fundamental type tinfo for those types in
libsupc++.a/libstdc++.*, regardless of whether libsupc++/libstdc++
is compiled with -msse2 or not, as user programs can be compiled
with different ISA flags from libsupc++/libstdc++ and if they
are compiled with -msse2 and use std::float16_t or std::bfloat16_t
and need RTTI for it, it should work out of the box.  Furthermore,
libstdc++ ABI on ia32 shouldn't depend on whether the library
is compiled with -mno-sse or -msse2.

Unfortunately, just hacking up libsupc++ Makefile/configure so that
a single source is compiled with -msse2 isn't appropriate, because
that TU emits also code and the code should be able to run on CPUs
which libstdc++ supports.  We could add [[gnu::attribute ("no-sse2")]]
there perhaps conditionally, but it all gets quite ugly.

The following patch instead adds a target hook which allows the backend
to temporarily tweak registered types such that emit_support_tinfos
emits whatever is needed.

Additionally, it makes emit_support_tinfos_1 call emit_tinfo_decl
immediately, so that temporarily created dummy types for emit_support_tinfo
purposes only can be nullified again afterwards.  And removes the
previous fallback_* types used for dfloat*_type_node tinfos even when
decimal types aren't supported.

2023-03-03  Jakub Jelinek  

PR target/108883
gcc/
* target.h (emit_support_tinfos_callback): New typedef.
* targhooks.h (default_emit_support_tinfos): Declare.
* targhooks.cc (default_emit_support_tinfos): New function.
* target.def (emit_support_tinfos): New target hook.
* doc/tm.texi.in (emit_support_tinfos): Document it.
* doc/tm.texi: Regenerated.
* config/i386/i386.cc (ix86_emit_support_tinfos): New function.
(TARGET_EMIT_SUPPORT_TINFOS): Redefine.
gcc/cp/
* cp-tree.h (enum cp_tree_index): Remove CPTI_FALLBACK_DFLOAT*_TYPE
enumerators.
(fallback_dfloat32_type, fallback_dfloat64_type,
fallback_dfloat128_type): Remove.
* rtti.cc (emit_support_tinfo_1): If not emitted already, call
emit_tinfo_decl and remove from unemitted_tinfo_decls right away.
(emit_support_tinfos): Move *_type_node from fundamentals
array
into new fundamentals_with_fallback array.  Call
emit_support_tinfo_1
on elements of that array too, with the difference that if
the type is NULL, use a fallback REAL_TYPE for it temporarily.
Drop the !targetm.decimal_float_supported_p () handling.  Call
targetm.emit_support_tinfos at the end.
* mangle.cc (write_builtin_type): Remove references to
fallback_dfloat*_type.  Handle bfloat16_type_node mangling.

[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Nikita Kniazev from comment #6)
> > The duplication happens even if I make cond int and compare with any other
> > value
> > 
> > void use(int *);
> > void use2(int *);
> > 
> > void foo(int * p, int cond)
> > {
> > if (cond == 789) {
> > use(p);
> > }
> > use2(p);
> > }
> 
> Yes and no, Yes it does in GCC 7/8 but starting in GCC 9 there is not.
> GCC before GCC 10.x is no longer supported so there is not much we can do
> there.

Well actually I was wrong, the duplication is there but you can see why GCC
does the code duplication really. To also do shrink wrapping.
That is GCC 9+ does not need to setup a stack frame for the != 789 case and
just tail call to use2.

[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Nikita Kniazev from comment #6)
> The duplication happens even if I make cond int and compare with any other
> value
> 
> void use(int *);
> void use2(int *);
> 
> void foo(int * p, int cond)
> {
> if (cond == 789) {
> use(p);
> }
> use2(p);
> }

Yes and no, Yes it does in GCC 7/8 but starting in GCC 9 there is not.
GCC before GCC 10.x is no longer supported so there is not much we can do
there.

[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Nikita Kniazev from comment #1)
> Is it about bool?
YES.

[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong

[nok.raven at gmail dot com via Gcc-bugs]

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

Nikita Kniazev  changed:

   What|Removed |Added

 CC||nok.raven at gmail dot com

--- Comment #1 from Nikita Kniazev  ---
Is it about bool?

void use(int *);
void use2(int *);

void foo(int * p, int cond)
{
if (cond == 789) {
use(p);
}
use2(p);
}

[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

[nok.raven at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Nikita Kniazev  ---
> Did you see this in real code or you just noticed this while looking at code 
> generation?

If you mean do I have any benchmark - unfortunately no. I noticed it for a
while by poking different code to compare Clang codegen to GCC.

> In the first case GCC predicts that the cond is going to be true 66% of the 
> time

The 66% thing is what I also noticed for a while.

> because there is comparison against 0 prediction going in the heurstics.

The duplication happens even if I make cond int and compare with any other
value

void use(int *);
void use2(int *);

void foo(int * p, int cond)
{
if (cond == 789) {
use(p);
}
use2(p);
}

[Bug middle-end/108990] Too restrictive precision check in fold and simplify pattern for PR70920

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70920
   Last reconfirmed||2023-03-02
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
There are other patterns which handle different precision integeral types
though.

e.g.
match.pd:5780
 /* If possible, express the comparison in the shorter mode.  */
 (if ((cmp == EQ_EXPR || cmp == NE_EXPR
   || TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@00))
   || (!TYPE_UNSIGNED (TREE_TYPE (@0))
   && TYPE_UNSIGNED (TREE_TYPE (@00
  && (types_match (TREE_TYPE (@10), TREE_TYPE (@00))
  || ((TYPE_PRECISION (TREE_TYPE (@00))
   >= TYPE_PRECISION (TREE_TYPE (@10)))
  && (TYPE_UNSIGNED (TREE_TYPE (@00))
  == TYPE_UNSIGNED (TREE_TYPE (@10
  || (TREE_CODE (@10) == INTEGER_CST
  && INTEGRAL_TYPE_P (TREE_TYPE (@00))
  && int_fits_type_p (@10, TREE_TYPE (@00)
  (cmp @00 (convert @10))

I wonder if the pattern for PR 70920 should be combined with the above one and
fixed up.

[PATCH v2] libcpp: Handle extended characters in user-defined literal suffix [PR103902]

[Lewis Hyatt via Gcc-patches]

The PR complains that we do not handle UTF-8 in the suffix for a user-defined
literal, such as:

bool operator ""_π (unsigned long long);

In fact we don't handle any extended identifier characters there, whether
UTF-8, UCNs, or the $ sign. We do handle it fine if the optional space after
the "" tokens is included, since then the identifier is lexed in the "normal"
way as its own token. But when it is lexed as part of the string token, this
is handled in lex_string() with a one-off loop that is not aware of extended
characters.

This patch fixes it by adding a new function scan_cur_identifier() that can be
used to lex an identifier while in the middle of lexing another token.

BTW, the other place that has been mis-lexing identifiers is
lex_identifier_intern(), which is used to implement #pragma push_macro
and #pragma pop_macro. This does not support extended characters either.
I will add that in a subsequent patch, because it can't directly reuse the
new function, but rather needs to lex from a string instead of a cpp_buffer.

With scan_cur_identifier(), we do also correctly warn about bidi and
normalization issues in the extended identifiers comprising the suffix.

libcpp/ChangeLog:

PR preprocessor/103902
* lex.cc (identifier_diagnostics_on_lex): New function refactoring
some common code.
(lex_identifier_intern): Use the new function.
(lex_identifier): Don't run identifier diagnostics here, rather let
the call site do it when needed.
(_cpp_lex_direct): Adjust the call sites of lex_identifier ()
acccordingly.
(struct scan_id_result): New struct.
(scan_cur_identifier): New function.
(create_literal2): New function.
(lit_accum::create_literal2): New function.
(is_macro): Folded into new function...
(maybe_ignore_udl_macro_suffix): ...here.
(is_macro_not_literal_suffix): Folded likewise.
(lex_raw_string): Handle UTF-8 in UDL suffix via scan_cur_identifier ().
(lex_string): Likewise.

gcc/testsuite/ChangeLog:

PR preprocessor/103902
* g++.dg/cpp0x/udlit-extended-id-1.C: New test.
* g++.dg/cpp0x/udlit-extended-id-2.C: New test.
* g++.dg/cpp0x/udlit-extended-id-3.C: New test.
* g++.dg/cpp0x/udlit-extended-id-4.C: New test.
---

Notes:
Hello-

This is the updated version of the patch, incorporating feedback from Jakub
and Jason, most recently discussed here:

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612073.html

Please let me know how it looks? It is simpler than before with the new
approach. Thanks!

One thing to note. As Jason clarified for me, a usage like this:

 #pragma GCC poison _x
const char * operator "" _x (const char *, unsigned long);

The space between the "" and the _x is currently allowed but will be
deprecated in C++23. GCC currently will complain about the poisoned use of
_x in this case, and this patch, which is just focused on handling UTF-8
properly, does not change this. But it seems that it would be correct
not to apply poison in this case. I can try to follow up with a patch to do
so, if it seems worthwhile? Given the syntax is deprecated, maybe it's not
worth it...

For the time being, this patch does add a testcase for the above and xfails
it. For the case where no space is present, which is the part touched by the
present patch, existing behavior is preserved correctly and no diagnostics
such as poison are issued for the UDL suffix. (Contrary to v1 of this
patch.)

Thanks! bootstrap + regtested all languages on x86-64 Linux with
no regressions.

-Lewis

 .../g++.dg/cpp0x/udlit-extended-id-1.C|  68 
 .../g++.dg/cpp0x/udlit-extended-id-2.C|   6 +
 .../g++.dg/cpp0x/udlit-extended-id-3.C|  15 +
 .../g++.dg/cpp0x/udlit-extended-id-4.C|  14 +
 libcpp/lex.cc | 382 ++
 5 files changed, 317 insertions(+), 168 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-3.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-4.C

diff --git a/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C 
b/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C
new file mode 100644
index 000..411d4fdd0ba
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C
@@ -0,0 +1,68 @@
+// { dg-do run { target c++11 } }
+// { dg-additional-options "-Wno-error=normalized" }
+#include 
+using namespace std;
+
+constexpr unsigned long long operator "" _π (unsigned long long x)
+{
+  return 3 * x;
+}
+
+/* Historically we didn't parse properly as part of the "" token, so check that
+   as well.  */
+constexpr unsigned long long operator ""_Π2 

Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

[Jakub Jelinek via Gcc-patches]

On Fri, Mar 03, 2023 at 12:05:09AM +0100, Gerald Pfeifer wrote:
> On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> > +
> > +#include 
> 
> Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
> the above would be seen as a tag by the name of stdlib.h. ;-)
> 
> I pushed the follow-up patch below.

Oops, missed that.  Thanks.

Jakub

Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> +
> +#include 

Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
the above would be seen as a tag by the name of stdlib.h. ;-)

I pushed the follow-up patch below.

Gerald


commit 935fcdebfb2fb4dcd89edb51ebed5f1be0fb41e5
Author: Gerald Pfeifer 
Date:   Thu Mar 2 23:58:29 2023 +0100

gcc-13: Use  and  where necessary

diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index f0ccef69..953e1453 100644
--- a/htdocs/gcc-13/porting_to.html
+++ b/htdocs/gcc-13/porting_to.html
@@ -129,7 +129,7 @@ constants and expressions.  E.g. for 
FLT_EVAL_METHOD equal
 to 2 on ia32:
 
 
-#include 
+#include stdlib.h
 void foo (void) { if (1.1f + 3.3f != 1.1L + 3.3L) abort (); }
 void bar (void) { double d = 4.2; if (d == 4.2) abort (); }
 

[r13-6414 Regression] FAIL: gcc.dg/memchr-3.c target llp64 (test for warnings, line 9) on Linux/x86_64

[haochen.jiang via Gcc-patches]

On Linux/x86_64,

62a8d31ecc07041af4a81353c2d57d9845c4b771 is the first bad commit
commit 62a8d31ecc07041af4a81353c2d57d9845c4b771
Author: Jonathan Yong <10wa...@gmail.com>
Date:   Mon Feb 27 10:02:32 2023 +

gcc.dg/memchr-3.c: Account for LLP64 warnings

caused

FAIL: gcc.dg/memchr-3.c  target llp64  (test for warnings, line 9)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-6414/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/memchr-3.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/memchr-3.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/memchr-3.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/memchr-3.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)

[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above patch.

Given that this failure started with r13-4410-g7c01d029fca669263b9c2, no
backporting is needed.

Marking as resolved.

Re: [PATCH] libgccjit: Fix a failing test

[David Malcolm via Gcc-patches]

On Thu, 2023-03-02 at 23:35 +0100, Guillaume Gomez wrote:
> I don't have push rights so if you could push it, it'd be super
> appreciated!

Done, as r13-6425-g6b432c0f777ab9; I took the liberty of slightly
tweaking the subject line to add a "jit, testsuite: " prefix.

Thanks again for the patch
Dave

[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

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

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

--- Comment #5 from Andrew Pinski  ---
Note I filed PR 108997 for what seems like the wrong heurstic for the
prediction.

[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:6b432c0f777ab9b8436fb07f71de6ea4d259b869

commit r13-6425-g6b432c0f777ab9b8436fb07f71de6ea4d259b869
Author: Guillaume Gomez 
Date:   Thu Mar 2 17:52:07 2023 -0500

jit, testsuite: fix a failing test by updating its error string [PR107999]

gcc/testsuite/ChangeLog:
PR jit/107999
* jit.dg/test-error-array-bounds.c: Update test.

Signed-off-by: Guillaume Gomez 

[Bug tree-optimization/108997] New: GCC prediction on bool comparisons seems wrong

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

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

Bug ID: 108997
   Summary: GCC prediction on bool comparisons seems wrong
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

I noticed this while looking into 108992.
I suspect we look into this but I am not 100% sure this is a bug.
Testcase:
void use(int *);
void use2(int *);

void foo(bool cond, int * p)
{
if (cond) {
use(p);
}
use2(p);
}

GCC predicts the branch to be taken 66% of the time, but I would have assume it
should be 50% as it is a bool and there is no other information. I suspect this
is due to prediction when comparing against 0.

[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
A similar example

extern const int z;
template constexpr auto p = z;

works, because require_constant_expression is OK with 'z' here.  The difference
between 'z' here and 'q' in the previous test is
INTEGRAL_OR_ENUMERATION_TYPE_P, which makes decl_maybe_constant_var_p return
different answers:

  else if (CP_TYPE_CONST_NON_VOLATILE_P (type)
   && INTEGRAL_OR_ENUMERATION_TYPE_P (type))
/* And const integers.  */;

Ping: [PATCH 2/2] Rework 128-bit complex multiply and divide.

[Michael Meissner via Gcc-patches]

This patch is second in importance after the first patch in the series.  It is
needed to allow complex IBM 128-bit multiply/divide when long double is IEEE
128-bit.

| Date: Fri, 3 Feb 2023 00:53:05 -0500
| From: Michael Meissner 
| Subject: [PATCH 2/2] Rework 128-bit complex multiply and divide.
| Message-ID: 

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I suspect this is not a bug, GCC tries to optimze the fast path into straight
line code without any waste of space.
In the first case GCC predicts that the cond is going to be true 66% of the
time because there is comparison against 0 prediction going in the heurstics.

For the first testcase if you do:
void use(int *);
void use2(int *);

void foo(bool cond, int * p)
{
if (__builtin_expect(cond, 1)) {
use(p);
}
use2(p);
}

Then you get the result you want.
Adding the builtin_expect for the second case you get the same too.
Basically GCC is pushing what it thinks as cold code away from the original
path.

Ping: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

[Michael Meissner via Gcc-patches]

This is the most important patch.  It is needed to allow the boostrap to work
again when long double is IEEE 128-bit.

| Date: Fri, 3 Feb 2023 00:49:12 -0500
| From: Michael Meissner 
| Subject: [PATCH 1/2] PR target/107299: Fix build issue when long double is 
IEEE 128-bit
| Message-ID: 

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

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

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

--- Comment #3 from Andrew Pinski  ---
Did you see this in real code or you just noticed this while looking at code
generation?