[Bug rtl-optimization/108681] [13 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Target||aarch64

--- Comment #3 from Richard Biener  ---
there's another endless DCE bug somewhere.

[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-06
   Priority|P3  |P1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection

--- Comment #1 from Richard Biener  ---
Confirmed with just -O2.

during IPA pass: inline
t.i: In function 'main':
t.i:18:3: internal compiler error: in modify_call, at
ipa-param-manipulation.cc:656
   18 |   func_6(l_10);
  |   ^~~~
0x129b0a1 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
/home/rguenther/src/trunk/gcc/ipa-param-manipulation.cc:656
0xec3b06 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
/home/rguenther/src/trunk/gcc/cgraph.cc:1530
0x16a9db7 redirect_all_calls(copy_body_data*, basic_block_def*)
/home/rguenther/src/trunk/gcc/tree-inline.cc:2990
0x16aa5a3 copy_cfg_body
/home/rguenther/src/trunk/gcc/tree-inline.cc:3145
0x16aadf8 copy_body
/home/rguenther/src/trunk/gcc/tree-inline.cc:3326
0x16afd47 expand_call_inline
/home/rguenther/src/trunk/gcc/tree-inline.cc:5112
0x16b0b2d gimple_expand_calls_inline
/home/rguenther/src/trunk/gcc/tree-inline.cc:5307
0x16b12f3 optimize_inline_calls(tree_node*)
/home/rguenther/src/trunk/gcc/tree-inline.cc:5479
0x12452ec inline_transform(cgraph_node*)
/home/rguenther/src/trunk/gcc/ipa-inline-transform.cc:790

[Bug tree-optimization/108677] wrong vectorization (when copy constructor is present?)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-02-06

[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions

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

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

--- Comment #1 from Richard Biener  ---
These tests are known to be a bit awkwardly implemented to check for
optimizations done ...

There might be a better way to provide definitions of fprintf, but is it
possible to short-circuit those definitions in the stdio.h header with
some macro definition?  And would that make the execution succeed?

[Bug tree-optimization/108667] Spurious "may be used uninitialized [-Wmaybe-uninitialized]" warning

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

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

--- Comment #3 from Richard Biener  ---
Yes, having the original code as well would be nice.

[Bug analyzer/108661] [13 Regression] -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug debug/108656] [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0 since r12-5236

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

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

--- Comment #4 from Richard Biener  ---
In general we avoid disallowing attribute combinations that at least in theory
make sense.  pure/const are about memory side-effects while returns_twice is
about control flow, so in this regard I don't see how they should conflict.

That we exclude !gimple_has_side_effects from call_can_make_abnormal_goto
is somewhat of a chicken-and-egg thing - "side effect" is something not
explicitely encoded in the IL but a returns_twice results in explicit
encoding via abnormal edges.  But then we cannot use that for CFG
construction.

Re: [PATCH 0/8] PowerPC future support for Dense Math

[Richard Biener via Gcc-patches]

On Fri, Feb 3, 2023 at 10:16 PM Michael Meissner via Gcc-patches
 wrote:
>
> These patches were originally posted on November 10th.  Segher has asked that 
> I
> repost them.  These patches are somewhat changed since the original posting to
> address some of the comments.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605581.html
>
> In the first patch (adding -mcpu=future), I have taken out the code of making
> -mtune=future act as -mtune=power10.  Instead I went through all of the places
> that look at the tuning (mostly in power10.md and rs6000.cc), and added future
> as an option.  Obviously at a later time, we will provide a separate tuning
> file for future (or whatever the new name will be if the instructions are 
> added
> officially).  But for now, it will suffice.
>
> In patch #3, I fixed the opcode for clearing a dense math register that Peter
> had noticed.  I was using the name based on the existing clear instruction,
> instead of the new instruction.
>
> In patch #6, I fixed the code, relying on the changes for setting the 
> precision
> field to 16 bits.  Since that patch will not be able to go into GCC 13 at
> present, we might skip that support for now.  The important thing for existing
> users of the MMA code is the support for accumulators being in the separate
> dense math registers rather than overlapping does need to go in, and we can
> probably delay the 1,024 bit register support, or implement in a different
> fashion.
>
> In the insn names, I tried to switch to using _vsx instead of _fpr for the
> existing MMA support instructions.  I also tried to clear up the comments to
> specify ISA 3.1 instead of power10 when talking about the existing MMA
> support.
>
> The following is from the original posting (slightly modified):
>
> This patch is very preliminary support for a potential new feature to the
> PowerPC that extends the current power10 MMA architecture.  This feature may 
> or
> may not be present in any specific future PowerPC processor.
>
> In the current MMA subsystem for Power10, there are 8 512-bit accumulator
> registers.  These accumulators are each tied to sets of 4 FPR registers.  When
> you issue a prime instruction, it makes sure the accumulator is a copy of the 
> 4
> FPR registers the accumulator is tied to.  When you issue a deprime
> instruction, it makes sure that the accumulator data content is logically
> copied to the matching FPR register.
>
> In the potential dense math system, the accumulators are moved to separate
> registers called dense math registers (DM registers or DMR).  The DMRs are 
> then
> extended to 1,024 bits and new instructions will be added to deal with all
> 1,024 bits of the DMRs.
>
> If you take existing MMA code, it will work as long as you don't do anything
> with accumulators, and you follow the rules in the ISA 3.1 documentation for
> using the MMA subsystem.
>
> These patches add support for the 512-bit accumulators within the dense math
> system, and for allocation of the 1,024-bit DMRs.  At this time, no additional
> built-in functions will be done to support any dense math features other than
> doing data movement between the DMRs and the VSX registers.  Before we can 
> look
> at adding any new dense math support other than data movement, we need the GCC
> compiler to be able to allocate and use these DMRs.
>
> There are 8 patches in this patch set:
>
> 1) The first patch just adds -mcpu=future as an option to add new support.
> This is similar to the -mcpu=future that we did before power10 was announced.
>
> 2) The second patch enables GCC to use the load and store vector pair
> instructions to optimize memory copy operations in the compiler.  For power10,
> we needed to just stay with normal vector load/stores for memory copy
> operations.
>
> 3) The third patch enables 512-bit accumulators store in DMRs.  This patch
> enables the register allocation, but it does not move the existing MMA to use
> these registers.
>
> 4) The fourth patch switches the MMA subsystem to use 512-bit accumulators
> within DMRs if you use -mcpu=future.
>
> 5) The fifth patch switches the names of the MMA instructions to use the dense
> math equivalent name if -mcpu=future.
>
> 6) The sixth patch enables using the full 1,024-bit DMRs.  Right now, all you
> can do with DMRs is move a VSX register to a DMR register, and to move a DMR
> register to a VSX register.  [As I mentioned above, at the moment, this patch
> is problematical as is]
>
> 7) The seventh patch is not DMR related.  It adds support for variants of the
> load/store vector with length instruction that may be added in future PowerPC
> processors.  These variants eliminate having to shift the byte length left by
> 56 bits.
>
> 8) The eighth patch is also not DMR related.  It adds support for a saturating
> subtract operation that may be added to future PowerPC processors.
>
> In terms of changes, we now use the wD constraint for accumulators.  If you
> compile with 

Re: [PATCH] ubsan: Fix up another spot that should have been BUILT_IN_UNREACHABLE_TRAPS [PR108655]

[Richard Biener via Gcc-patches]

On Fri, Feb 3, 2023 at 9:15 PM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> We ICE on the following testcase, because ivcanon calls
> gimple_build_builtin_unreachable but doesn't expect it would need vops.
> BUILT_IN_UNREACHABLE_TRAP I've introduced yesterday doesn't need
> vops and should be used in that case instead of BUILT_IN_TRAP which
> needs them.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2023-02-03  Jakub Jelinek  
>
> PR tree-optimization/108655
> * ubsan.cc (sanitize_unreachable_fn): For -funreachable-traps
> or -fsanitize=unreachable -fsanitize-trap=unreachable return
> BUILT_IN_UNREACHABLE_TRAP decl rather than BUILT_IN_TRAP.
>
> * gcc.dg/pr108655.c: New test.
>
> --- gcc/ubsan.cc.jj 2023-01-02 09:32:38.393053992 +0100
> +++ gcc/ubsan.cc2023-02-03 11:40:47.047399386 +0100
> @@ -649,7 +649,7 @@ sanitize_unreachable_fn (tree *data, loc
>? (flag_sanitize_trap & SANITIZE_UNREACHABLE)
>: flag_unreachable_traps)
>  {
> -  fn = builtin_decl_explicit (BUILT_IN_TRAP);
> +  fn = builtin_decl_explicit (BUILT_IN_UNREACHABLE_TRAP);
>*data = NULL_TREE;
>  }
>else if (san)
> --- gcc/testsuite/gcc.dg/pr108655.c.jj  2023-02-03 11:46:39.533190031 +0100
> +++ gcc/testsuite/gcc.dg/pr108655.c 2023-02-03 11:46:28.272356439 +0100
> @@ -0,0 +1,15 @@
> +/* PR tree-optimization/108655 */
> +/* { dg-do compile } */
> +/* { dg-options "-w -O1 -funreachable-traps" } */
> +
> +void
> +foo (void)
> +{
> +  int i, j;
> +  for (; i;)
> +;
> +  for (; i < 6;)
> +for (j = 0; j < 6; ++j)
> +  i += j;
> +  __builtin_trap ();
> +}
>
> Jakub
>

Re: [DOC PATCH] Document the VEC_PERM_EXPR tree code (and minor clean-ups).

[Richard Biener via Gcc-patches]

On Sat, Feb 4, 2023 at 9:35 PM Roger Sayle  wrote:
>
>
> This patch (primarily) documents the VEC_PERM_EXPR tree code in
> generic.texi.  For ease of review, it is provided below as a pair
> of diffs.  The first contains just the new text added to describe
> VEC_PERM_EXPR, the second tidies up this part of the documentation
> by sorting the tree codes into alphabetical order, and providing
> consistent section naming/capitalization, so changing this section
> from "Vectors" to "Vector Expressions" (matching the nearby
> "Unary and Binary Expressions").
>
> Tested with make pdf and make html on x86_64-pc-linux-gnu.
> The reviewer(s) can decide whether to approve just the new content,
> or the content+clean-up.  Ok for mainline?

+@item VEC_PERM_EXPR
+This node represents a vector permute/blend operation.  The three operands
+must be vectors of the same number of elements.  The first and second
+operands must be vectors of the same type as the entire expression,

this was recently relaxed for the case of constant permutes in which case
the first and second operands only have to have the same element type
as the result.  See tree-cfg.cc:verify_gimple_assign_ternary.

The following description will become a bit more awkward here and
for rhs1/rhs2 with different number of elements the modulo interpretation
doesn't hold - I believe we require in-bounds elements for constant
permutes.  Richard can probably clarify things here.

Thanks,
Richard.

>
>
> 2023-02-04  Roger Sayle  
>
> gcc/ChangeLog
> * doc/generic.texi : Standardize capitalization
> of section titles from "Expression trees".
> : Likewise standardize capitalization
> from "Language-dependent trees".
> : Capitalized from "Constant Expressions".
> : Standardized section name from "Vectors".
> Document VEC_PERM_EXPR tree code.  Sort tree codes alphabetically.
>
>
> Thanks in advance,
> Roger
> --
>

Re: realpath() patch to fix symlinks resolution for win32

[Jonathan Yong via Gcc-patches]

On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:

hello again!

the final version of the path for 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350


successfully bootstraped for x86_64-mingw32 and x86_64-linux.

could anyone apply it please?



best!


Looks good to me, please supply the appropriate changelog.

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

[vital.had at gmail dot com via Gcc-bugs]

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

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #13 from Sergey Fedorov  ---
Is --enable-decimal-float supported on PowerPC Darwin?? It seems that it is
not, and DFP have been added in ISA 2.05.

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Jack Adrian Zappa from comment #9)

>   
>   Suggest fix is to either:
>   
>   1. Change the phase where this warning/error/ignored is tested so that the
>  #pragma GCC diagnostic is honoured or

That is fixed on the trunk for GCC 13 (by r13-1544-ge46f4d7430c52104657916) for
the C++ front-end, it was already working for the C front-end.

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

[adrianh.bsc at gmail dot com via Gcc-bugs]

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

Jack Adrian Zappa  changed:

   What|Removed |Added

 CC||adrianh.bsc at gmail dot com

--- Comment #9 from Jack Adrian Zappa  ---
Issue:
  Cannot turn off the `-Wcomment` option using `#pragma GCC diagnostic ignored
  "-Wcomment"`.  This is causing issues when I'm trying to document my macros
  and how to write them.  Our coding standards at my work state that we are to
  use /// for documenting functions/variables/macros and not /** */.

  I grudgingly tried to use a space after the \, but that didn't work either.
  Also inadvertently found that ending with a double backslash (\\) also didn't
  work for some reason, which is odd because the backslash is escaped, so it
  cannot cause a comment continuation.

  Suggest fix is to either:

  1. Change the phase where this warning/error/ignored is tested so that the
 #pragma GCC diagnostic is honoured or

  2. If a line comment end in an \ but the next line is a comment, then do
 the same thing as is done for a multi-line comment, ignore it as not an
 issue.

  In addition, a line comment ending in an escaped backslash shouldn't cause
  any issue.  It would be also preferable that an escaped whitespace that is
  not an eol character would be accepted (though it seems that this is unlikely
  given bug 8270).

GCC versions tested on:
  7.5, 11.3 12.2

System type:
  MSYS2 and whatever is running under godbolt.org

Options given:
  -Wall -Werror

Complete command line:
  g++ -Wall -Werror bug.cpp

Source file:
$ cat bug.cpp
  #pragma GCC diagnostic push
  #pragma GCC diagnostic ignored "-Wcomment"
  /// #define macro_to_document(x) \
  ///   blah blah x blah
  ///
  /// Also doesn't work with a space after the \
  /// as in this case.
  ///
  /// Also doesn't work with a double backslash \\
  /// as in this case.
  ///
  #pragma GCC diagnostic pop

Compiler output:
$  g++ -v -Wall -Werror -save-temps bug.cpp
  Using built-in specs.
  COLLECT_GCC=g++
  COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-msys/11.3.0/lto-wrapper.exe
  Target: x86_64-pc-msys
  Configured with: /c/S/gcc/src/gcc-11.3.0/configure --build=x86_64-pc-msys
--prefix=/usr --libexecdir=/usr/lib --enable-bootstrap --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--with-arch=x86-64 --with-tune=generic --disable-multilib --enable-__cxa_atexit
--with-dwarf2 --enable-languages=c,c++,fortran,lto --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --disable-libssp
--disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as
--disable-isl-version-check --enable-checking=release --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
  Thread model: posix
  Supported LTO compression algorithms: zlib
  gcc version 11.3.0 (GCC)
  COLLECT_GCC_OPTIONS='-v' '-Wall' '-Werror' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/cc1plus.exe -E -quiet -v -idirafter
/usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../lib/../include/w32api -idirafter
/usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../x86_64-pc-msys/lib/../lib/../../include/w32api
bug.cpp -mtune=generic -march=x86-64 -Wall -Werror -fpch-preprocess -o a-bug.ii
  ignoring nonexistent directory "/usr/local/include"
  ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../x86_64-pc-msys/include"
  ignoring duplicate directory
"/usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../x86_64-pc-msys/lib/../lib/../../include/w32api"
  #include "..." search starts here:
  #include <...> search starts here:
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/include/c++
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/include/c++/x86_64-pc-msys
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/include/c++/backward
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/include
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/include-fixed
   /usr/include
   /usr/lib/gcc/x86_64-pc-msys/11.3.0/../../../../lib/../include/w32api
  End of search list.
  bug.cpp:3:1: error: multi-line comment [-Werror=comment]
  3 | /// #define macro_to_document(x) \
| ^
  bug.cpp:6:1: error: multi-line comment [-Werror=comment]
  6 | /// Also doesn't work with a space after the \
| ^
  bug.cpp:9:1: error: multi-line comment [-Werror=comment]
  9 | /// Also doesn't work with a double backslash \\
| ^
  cc1plus: all warnings being treated as errors

Preprocessed file:
  $ cat a-bug.ii
  # 0 "bug.cpp"
  # 0 ""
  # 0 ""
  # 1 "bug.cpp"
  #pragma GCC diagnostic push
  #pragma GCC diagnostic ignored "-Wcomment"
  # 12 "bug.cpp"
  #pragma GCC diagnostic pop

[Bug rtl-optimization/108681] [13 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|gcc hangs compiling |[13 Regression] gcc hangs
   |opencv/channels_combine.cpp |compiling
   |for aarch64 |opencv/channels_combine.cpp
   ||for aarch64
  Component|middle-end  |rtl-optimization

--- Comment #2 from Andrew Pinski  ---
rtl_dce seems stuck and keeps on adding to the worklist for:

;; Function carotene_o4t::combine2
(_ZN12carotene_o4t8combine2ERKNS_6Size2DEPKllS4_lPll, funcdef_no=5226,
decl_uid=40999, cgraph_uid=4575, symbol_order=4584)

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

[Xi Ruoyao via Gcc]

On Sun, 2023-02-05 at 16:31 +0100, Alejandro Colomar via Libc-alpha wrote:

> The only correct way to use  different  types  in  an  API  is
> through  a  union.

I don't think this statement is true (in general).  Technically we can
write something like this:

struct sockaddr { ... };
struct sockaddr_in { ... };
struct sockaddr_in6 { ... };

int bind(int fd, const struct sockaddr *addr, socklen_t addrlen)
{
if (addrlen < sizeof(struct sockaddr) {
errno = EINVAL;
return -1;
}

/* cannot use "addr->sa_family" directly: it will be an UB */
sa_family_t sa_family;
memcpy(_family, addr, sizeof(sa_family));

switch (sa_family) {
case AF_INET:
return _do_bind_in(fd, (struct sockaddr_in *)addr, addrlen);
case AF_INET6:
return _do_bind_in6(fd, (struct sockaddr_in6 *)addr, addrlen);
/* more cases follow here */
default:
errno = EINVAL;
return -1;
}
}
}

In this way we can use sockaddr_{in,in6,...} for bind() safely, as long
as we can distinguish the "real" type of addr using the leading byte
sequence (and the caller uses it carefully).

But obviously sockaddr_storage can't be distinguished here, so casting a
struct sockaddr_stroage * to struct sockaddr * and passing it to bind()
will still be wrong (unless we make sockaddr_storage an union or add
[[gnu::may_alias]]).

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

[Bug middle-end/108681] gcc hangs compiling opencv/channels_combine.cpp for aarch64

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 54411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54411=edit
unreduced Testcase

[PATCH] RISC-V: Add vzext.vf2 C++ API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/vzext_vf2-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_mu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_mu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_mu-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tu-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tum-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tum-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tum-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tumu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tumu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf2_tumu-3.C: New test.

---
 .../g++.target/riscv/rvv/base/vzext_vf2-1.C   | 216 ++
 .../g++.target/riscv/rvv/base/vzext_vf2-2.C   | 216 ++
 .../g++.target/riscv/rvv/base/vzext_vf2-3.C   | 216 ++
 .../riscv/rvv/base/vzext_vf2_mu-1.C   | 111 +
 .../riscv/rvv/base/vzext_vf2_mu-2.C   | 111 +
 .../riscv/rvv/base/vzext_vf2_mu-3.C   | 111 +
 .../riscv/rvv/base/vzext_vf2_tu-1.C   | 111 +
 .../riscv/rvv/base/vzext_vf2_tu-2.C   | 111 +
 .../riscv/rvv/base/vzext_vf2_tu-3.C   | 111 +
 .../riscv/rvv/base/vzext_vf2_tum-1.C  | 111 +
 .../riscv/rvv/base/vzext_vf2_tum-2.C  | 111 +
 .../riscv/rvv/base/vzext_vf2_tum-3.C  | 111 +
 .../riscv/rvv/base/vzext_vf2_tumu-1.C | 111 +
 .../riscv/rvv/base/vzext_vf2_tumu-2.C | 111 +
 .../riscv/rvv/base/vzext_vf2_tumu-3.C | 111 +
 15 files changed, 1980 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_mu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_mu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_mu-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tu-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tum-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tum-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tum-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tumu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tumu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2_tumu-3.C

diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2-1.C 
b/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2-1.C
new file mode 100644
index 000..4e9c81cf87f
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf2-1.C
@@ -0,0 +1,216 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vuint16mf4_t test___riscv_vzext_vf2(vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint16mf2_t test___riscv_vzext_vf2(vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint16m1_t test___riscv_vzext_vf2(vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint16m2_t test___riscv_vzext_vf2(vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint16m4_t test___riscv_vzext_vf2(vuint8m2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint16m8_t test___riscv_vzext_vf2(vuint8m4_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint32mf2_t test___riscv_vzext_vf2(vuint16mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint32m1_t test___riscv_vzext_vf2(vuint16mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint32m2_t test___riscv_vzext_vf2(vuint16m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint32m4_t test___riscv_vzext_vf2(vuint16m2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint32m8_t test___riscv_vzext_vf2(vuint16m4_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint64m1_t test___riscv_vzext_vf2(vuint32mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2(op1,vl);
+}
+
+
+vuint64m2_t test___riscv_vzext_vf2(vuint32m1_t 

[PATCH] RISC-V: Add vzext.vf4 C++ API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/vzext_vf4-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_mu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_mu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_mu-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tu-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tum-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tum-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tum-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tumu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tumu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf4_tumu-3.C: New test.

---
 .../g++.target/riscv/rvv/base/vzext_vf4-1.C   | 132 ++
 .../g++.target/riscv/rvv/base/vzext_vf4-2.C   | 132 ++
 .../g++.target/riscv/rvv/base/vzext_vf4-3.C   | 132 ++
 .../riscv/rvv/base/vzext_vf4_mu-1.C   |  69 +
 .../riscv/rvv/base/vzext_vf4_mu-2.C   |  69 +
 .../riscv/rvv/base/vzext_vf4_mu-3.C   |  69 +
 .../riscv/rvv/base/vzext_vf4_tu-1.C   |  69 +
 .../riscv/rvv/base/vzext_vf4_tu-2.C   |  69 +
 .../riscv/rvv/base/vzext_vf4_tu-3.C   |  69 +
 .../riscv/rvv/base/vzext_vf4_tum-1.C  |  69 +
 .../riscv/rvv/base/vzext_vf4_tum-2.C  |  69 +
 .../riscv/rvv/base/vzext_vf4_tum-3.C  |  69 +
 .../riscv/rvv/base/vzext_vf4_tumu-1.C |  69 +
 .../riscv/rvv/base/vzext_vf4_tumu-2.C |  69 +
 .../riscv/rvv/base/vzext_vf4_tumu-3.C |  69 +
 15 files changed, 1224 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_mu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_mu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_mu-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tu-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tum-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tum-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tum-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tumu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tumu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4_tumu-3.C

diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4-1.C 
b/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4-1.C
new file mode 100644
index 000..5875271fa88
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf4-1.C
@@ -0,0 +1,132 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vuint32mf2_t test___riscv_vzext_vf4(vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint32m1_t test___riscv_vzext_vf4(vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint32m2_t test___riscv_vzext_vf4(vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint32m4_t test___riscv_vzext_vf4(vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint32m8_t test___riscv_vzext_vf4(vuint8m2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint64m1_t test___riscv_vzext_vf4(vuint16mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint64m2_t test___riscv_vzext_vf4(vuint16mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint64m4_t test___riscv_vzext_vf4(vuint16m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint64m8_t test___riscv_vzext_vf4(vuint16m2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(op1,vl);
+}
+
+
+vuint32mf2_t test___riscv_vzext_vf4(vbool64_t mask,vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(mask,op1,vl);
+}
+
+
+vuint32m1_t test___riscv_vzext_vf4(vbool32_t mask,vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(mask,op1,vl);
+}
+
+
+vuint32m2_t test___riscv_vzext_vf4(vbool16_t mask,vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4(mask,op1,vl);

[PATCH] RISC-V: Add vzext.vf8 C++ API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/vzext_vf8-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_mu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_mu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_mu-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tu-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tum-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tum-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tum-3.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tumu-1.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tumu-2.C: New test.
* g++.target/riscv/rvv/base/vzext_vf8_tumu-3.C: New test.

---
 .../g++.target/riscv/rvv/base/vzext_vf8-1.C   | 62 +++
 .../g++.target/riscv/rvv/base/vzext_vf8-2.C   | 62 +++
 .../g++.target/riscv/rvv/base/vzext_vf8-3.C   | 62 +++
 .../riscv/rvv/base/vzext_vf8_mu-1.C   | 34 ++
 .../riscv/rvv/base/vzext_vf8_mu-2.C   | 34 ++
 .../riscv/rvv/base/vzext_vf8_mu-3.C   | 34 ++
 .../riscv/rvv/base/vzext_vf8_tu-1.C   | 34 ++
 .../riscv/rvv/base/vzext_vf8_tu-2.C   | 34 ++
 .../riscv/rvv/base/vzext_vf8_tu-3.C   | 34 ++
 .../riscv/rvv/base/vzext_vf8_tum-1.C  | 34 ++
 .../riscv/rvv/base/vzext_vf8_tum-2.C  | 34 ++
 .../riscv/rvv/base/vzext_vf8_tum-3.C  | 34 ++
 .../riscv/rvv/base/vzext_vf8_tumu-1.C | 34 ++
 .../riscv/rvv/base/vzext_vf8_tumu-2.C | 34 ++
 .../riscv/rvv/base/vzext_vf8_tumu-3.C | 34 ++
 15 files changed, 594 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_mu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_mu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_mu-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tu-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tum-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tum-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tum-3.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tumu-1.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tumu-2.C
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8_tumu-3.C

diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8-1.C 
b/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8-1.C
new file mode 100644
index 000..caf23bc78d9
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/base/vzext_vf8-1.C
@@ -0,0 +1,62 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vuint64m1_t test___riscv_vzext_vf8(vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(op1,vl);
+}
+
+
+vuint64m2_t test___riscv_vzext_vf8(vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(op1,vl);
+}
+
+
+vuint64m4_t test___riscv_vzext_vf8(vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(op1,vl);
+}
+
+
+vuint64m8_t test___riscv_vzext_vf8(vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(op1,vl);
+}
+
+
+vuint64m1_t test___riscv_vzext_vf8(vbool64_t mask,vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(mask,op1,vl);
+}
+
+
+vuint64m2_t test___riscv_vzext_vf8(vbool32_t mask,vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(mask,op1,vl);
+}
+
+
+vuint64m4_t test___riscv_vzext_vf8(vbool16_t mask,vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(mask,op1,vl);
+}
+
+
+vuint64m8_t test___riscv_vzext_vf8(vbool8_t mask,vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf8(mask,op1,vl);
+}
+
+
+
+/* { dg-final { scan-assembler-times 
{vsetvli\s+zero,\s*[a-x0-9]+,\s*e64,\s*m1,\s*t[au],\s*m[au]\s+vzext\.vf8\s+v[0-9]+,\s*v[0-9]+\s+}
 1 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+zero,\s*[a-x0-9]+,\s*e64,\s*m2,\s*t[au],\s*m[au]\s+vzext\.vf8\s+v[0-9]+,\s*v[0-9]+\s+}
 1 } } */
+/* { dg-final { scan-assembler-times 

[Bug c++/108681] New: gcc hangs compiling opencv/channels_combine.cpp for aarch64

[raj.khem at gmail dot com via Gcc-bugs]

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

Bug ID: 108681
   Summary: gcc hangs compiling opencv/channels_combine.cpp for
aarch64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

GCC-trunk as of 31924665c86d47af6b1f22a74f594f2e1dc0ed2d is taking a long long
time, probably a hang since I cancelled it after 12 mins ) compiling this file

https://uclibc.org/~kraj/channels_combine.i

aarch64-yoe-linux/aarch64-yoe-linux-g++ channels_combine.i -O2 ( hangs )

It compiled ok with -O0,-Os,-Og,-Oz but not with -O1,-O2,-O3

[PATCH] RISC-V: Add vsext constraint tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/unop_v_constraint-2.c: New test.

---
 .../riscv/rvv/base/unop_v_constraint-2.c  | 132 ++
 1 file changed, 132 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/unop_v_constraint-2.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/unop_v_constraint-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/unop_v_constraint-2.c
new file mode 100644
index 000..19f9365b42b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/unop_v_constraint-2.c
@@ -0,0 +1,132 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gcv -mabi=ilp32d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+#include "riscv_vector.h"
+
+/*
+** f1:
+** vsetivli\tzero,4,e32,m1,tu,ma
+** vle16\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vle16\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vse32\.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void f1 (void * in, void *out)
+{
+vint16mf2_t v = __riscv_vle16_v_i16mf2 (in, 4);
+vint16mf2_t v2 = __riscv_vle16_v_i16mf2_tu (v, in, 4);
+vint32m1_t v3 = __riscv_vsext_vf2_i32m1 (v2, 4);
+vint32m1_t v4 = __riscv_vsext_vf2_i32m1_tu (v3, v2, 4);
+__riscv_vse32_v_i32m1 (out, v4, 4);
+}
+
+/*
+** f2:
+** vsetvli\t[a-x0-9]+,zero,e8,mf4,ta,ma
+** vlm.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsetivli\tzero,4,e32,m1,ta,ma
+** vle16\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vsetvli\tzero,zero,e64,m2,ta,ma
+** vsext\.vf2\tv[1-9][0-9]?,\s*v[0-9]+,\s*v0.t
+** vse64\.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void f2 (void * in, void *out)
+{
+vbool32_t mask = *(vbool32_t*)in;
+asm volatile ("":::"memory");
+vint16mf2_t v = __riscv_vle16_v_i16mf2 (in, 4);
+vint32m1_t v3 = __riscv_vsext_vf2_i32m1 (v, 4);
+vint64m2_t v4 = __riscv_vsext_vf2_i64m2_m (mask, v3, 4);
+__riscv_vse64_v_i64m2 (out, v4, 4);
+}
+
+/*
+** f3:
+** vsetvli\t[a-x0-9]+,zero,e8,mf4,ta,ma
+** vlm.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsetivli\tzero,4,e32,m1,tu,mu
+** vle16\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vle16\.v\tv[0-9]+,0\([a-x0-9]+\),v0.t
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vsext\.vf2\tv[1-9][0-9]?,\s*v[0-9]+,\s*v0.t
+** vse32.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void f3 (void * in, void *out)
+{
+vbool32_t mask = *(vbool32_t*)in;
+asm volatile ("":::"memory");
+vint16mf2_t v = __riscv_vle16_v_i16mf2 (in, 4);
+vint16mf2_t v2 = __riscv_vle16_v_i16mf2_tumu (mask, v, in, 4);
+vint32m1_t v3 = __riscv_vsext_vf2_i32m1 (v2, 4);
+vint32m1_t v4 = __riscv_vsext_vf2_i32m1_tumu (mask, v3, v2, 4);
+__riscv_vse32_v_i32m1 (out, v4, 4);
+}
+
+/*
+** f4:
+** vsetivli\tzero,4,e16,mf4,tu,ma
+** vle8\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vle8\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vse16\.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void f4 (void * in, void *out)
+{
+vint8mf8_t v = __riscv_vle8_v_i8mf8 (in, 4);
+vint8mf8_t v2 = __riscv_vle8_v_i8mf8_tu (v, in, 4);
+vint16mf4_t v3 = __riscv_vsext_vf2_i16mf4 (v2, 4);
+vint16mf4_t v4 = __riscv_vsext_vf2_i16mf4_tu (v3, v2, 4);
+__riscv_vse16_v_i16mf4 (out, v4, 4);
+}
+
+/*
+** f5:
+** vsetvli\t[a-x0-9]+,zero,e8,mf8,ta,ma
+** vlm.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsetivli\tzero,4,e16,mf4,ta,ma
+** vle8.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vsetvli\tzero,zero,e32,mf2,ta,ma
+** vsext\.vf2\tv[1-9][0-9]?,\s*v[0-9]+,\s*v0.t
+** vse32.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void f5 (void * in, void *out)
+{
+vbool64_t mask = *(vbool64_t*)in;
+asm volatile ("":::"memory");
+vint8mf8_t v = __riscv_vle8_v_i8mf8 (in, 4);
+vint16mf4_t v3 = __riscv_vsext_vf2_i16mf4 (v, 4);
+vint32mf2_t v4 = __riscv_vsext_vf2_i32mf2_m (mask, v3, 4);
+__riscv_vse32_v_i32mf2 (out, v4, 4);
+}
+
+/*
+** f6:
+** vsetvli\t[a-x0-9]+,zero,e8,mf8,ta,ma
+** vlm.v\tv[0-9]+,0\([a-x0-9]+\)
+** vsetivli\tzero,4,e16,mf4,tu,mu
+** vle8\.v\tv[0-9]+,0\([a-x0-9]+\)
+** vle8.v\tv[0-9]+,0\([a-x0-9]+\),v0.t
+** vsext\.vf2\tv[0-9]+,\s*v[0-9]+
+** vsext\.vf2\tv[1-9][0-9]?,\s*v[0-9]+,\s*v0.t
+** vse16.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void f6 (void * in, void *out)
+{
+vbool64_t mask = *(vbool64_t*)in;
+asm volatile ("":::"memory");
+vint8mf8_t v = __riscv_vle8_v_i8mf8 (in, 4);
+vint8mf8_t v2 = __riscv_vle8_v_i8mf8_tumu (mask, v, in, 4);
+vint16mf4_t v3 = __riscv_vsext_vf2_i16mf4 (v2, 4);
+vint16mf4_t v4 = __riscv_vsext_vf2_i16mf4_tumu (mask, v3, v2, 4);
+__riscv_vse16_v_i16mf4 (out, v4, 4);
+}
-- 
2.36.1

[PATCH] RISC-V: Add vsext.vf2 C API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vsext_vf2-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_m-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_m-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_m-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf2_tumu-3.c: New test.

---
 .../gcc.target/riscv/rvv/base/vsext_vf2-1.c   | 111 ++
 .../gcc.target/riscv/rvv/base/vsext_vf2-2.c   | 111 ++
 .../gcc.target/riscv/rvv/base/vsext_vf2-3.c   | 111 ++
 .../gcc.target/riscv/rvv/base/vsext_vf2_m-1.c | 111 ++
 .../gcc.target/riscv/rvv/base/vsext_vf2_m-2.c | 111 ++
 .../gcc.target/riscv/rvv/base/vsext_vf2_m-3.c | 111 ++
 .../riscv/rvv/base/vsext_vf2_mu-1.c   | 111 ++
 .../riscv/rvv/base/vsext_vf2_mu-2.c   | 111 ++
 .../riscv/rvv/base/vsext_vf2_mu-3.c   | 111 ++
 .../riscv/rvv/base/vsext_vf2_tu-1.c   | 111 ++
 .../riscv/rvv/base/vsext_vf2_tu-2.c   | 111 ++
 .../riscv/rvv/base/vsext_vf2_tu-3.c   | 111 ++
 .../riscv/rvv/base/vsext_vf2_tum-1.c  | 111 ++
 .../riscv/rvv/base/vsext_vf2_tum-2.c  | 111 ++
 .../riscv/rvv/base/vsext_vf2_tum-3.c  | 111 ++
 .../riscv/rvv/base/vsext_vf2_tumu-1.c | 111 ++
 .../riscv/rvv/base/vsext_vf2_tumu-2.c | 111 ++
 .../riscv/rvv/base/vsext_vf2_tumu-3.c | 111 ++
 18 files changed, 1998 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_m-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_m-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_m-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_mu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_mu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_mu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tum-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tum-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tum-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tumu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tumu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2_tumu-3.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2-1.c
new file mode 100644
index 000..eb8fdb8adff
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf2-1.c
@@ -0,0 +1,111 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vint16mf4_t test___riscv_vsext_vf2_i16mf4(vint8mf8_t op1,size_t vl)
+{
+return __riscv_vsext_vf2_i16mf4(op1,vl);
+}
+
+
+vint16mf2_t test___riscv_vsext_vf2_i16mf2(vint8mf4_t op1,size_t vl)
+{
+return __riscv_vsext_vf2_i16mf2(op1,vl);
+}
+
+
+vint16m1_t test___riscv_vsext_vf2_i16m1(vint8mf2_t op1,size_t vl)
+{
+return __riscv_vsext_vf2_i16m1(op1,vl);
+}
+
+
+vint16m2_t test___riscv_vsext_vf2_i16m2(vint8m1_t op1,size_t vl)
+{
+return __riscv_vsext_vf2_i16m2(op1,vl);
+}
+
+
+vint16m4_t test___riscv_vsext_vf2_i16m4(vint8m2_t op1,size_t vl)
+{
+return __riscv_vsext_vf2_i16m4(op1,vl);
+}
+
+
+vint16m8_t 

[PATCH] RISC-V: Add vsext.vf4 C API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vsext_vf4-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_m-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_m-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_m-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf4_tumu-3.c: New test.

---
 .../gcc.target/riscv/rvv/base/vsext_vf4-1.c   | 69 +++
 .../gcc.target/riscv/rvv/base/vsext_vf4-2.c   | 69 +++
 .../gcc.target/riscv/rvv/base/vsext_vf4-3.c   | 69 +++
 .../gcc.target/riscv/rvv/base/vsext_vf4_m-1.c | 69 +++
 .../gcc.target/riscv/rvv/base/vsext_vf4_m-2.c | 69 +++
 .../gcc.target/riscv/rvv/base/vsext_vf4_m-3.c | 69 +++
 .../riscv/rvv/base/vsext_vf4_mu-1.c   | 69 +++
 .../riscv/rvv/base/vsext_vf4_mu-2.c   | 69 +++
 .../riscv/rvv/base/vsext_vf4_mu-3.c   | 69 +++
 .../riscv/rvv/base/vsext_vf4_tu-1.c   | 69 +++
 .../riscv/rvv/base/vsext_vf4_tu-2.c   | 69 +++
 .../riscv/rvv/base/vsext_vf4_tu-3.c   | 69 +++
 .../riscv/rvv/base/vsext_vf4_tum-1.c  | 69 +++
 .../riscv/rvv/base/vsext_vf4_tum-2.c  | 69 +++
 .../riscv/rvv/base/vsext_vf4_tum-3.c  | 69 +++
 .../riscv/rvv/base/vsext_vf4_tumu-1.c | 69 +++
 .../riscv/rvv/base/vsext_vf4_tumu-2.c | 69 +++
 .../riscv/rvv/base/vsext_vf4_tumu-3.c | 69 +++
 18 files changed, 1242 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_m-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_m-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_m-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_mu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_mu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_mu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tum-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tum-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tum-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tumu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tumu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4_tumu-3.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4-1.c
new file mode 100644
index 000..f853ceafce9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf4-1.c
@@ -0,0 +1,69 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vint32mf2_t test___riscv_vsext_vf4_i32mf2(vint8mf8_t op1,size_t vl)
+{
+return __riscv_vsext_vf4_i32mf2(op1,vl);
+}
+
+
+vint32m1_t test___riscv_vsext_vf4_i32m1(vint8mf4_t op1,size_t vl)
+{
+return __riscv_vsext_vf4_i32m1(op1,vl);
+}
+
+
+vint32m2_t test___riscv_vsext_vf4_i32m2(vint8mf2_t op1,size_t vl)
+{
+return __riscv_vsext_vf4_i32m2(op1,vl);
+}
+
+
+vint32m4_t test___riscv_vsext_vf4_i32m4(vint8m1_t op1,size_t vl)
+{
+return __riscv_vsext_vf4_i32m4(op1,vl);
+}
+
+
+vint32m8_t test___riscv_vsext_vf4_i32m8(vint8m2_t op1,size_t vl)
+{
+return __riscv_vsext_vf4_i32m8(op1,vl);
+}
+
+
+vint64m1_t 

[PATCH] RISC-V: Add vsext.vf8 C API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vsext_vf8-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_m-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_m-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_m-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vsext_vf8_tumu-3.c: New test.

---
 .../gcc.target/riscv/rvv/base/vsext_vf8-1.c   | 34 +++
 .../gcc.target/riscv/rvv/base/vsext_vf8-2.c   | 34 +++
 .../gcc.target/riscv/rvv/base/vsext_vf8-3.c   | 34 +++
 .../gcc.target/riscv/rvv/base/vsext_vf8_m-1.c | 34 +++
 .../gcc.target/riscv/rvv/base/vsext_vf8_m-2.c | 34 +++
 .../gcc.target/riscv/rvv/base/vsext_vf8_m-3.c | 34 +++
 .../riscv/rvv/base/vsext_vf8_mu-1.c   | 34 +++
 .../riscv/rvv/base/vsext_vf8_mu-2.c   | 34 +++
 .../riscv/rvv/base/vsext_vf8_mu-3.c   | 34 +++
 .../riscv/rvv/base/vsext_vf8_tu-1.c   | 34 +++
 .../riscv/rvv/base/vsext_vf8_tu-2.c   | 34 +++
 .../riscv/rvv/base/vsext_vf8_tu-3.c   | 34 +++
 .../riscv/rvv/base/vsext_vf8_tum-1.c  | 34 +++
 .../riscv/rvv/base/vsext_vf8_tum-2.c  | 34 +++
 .../riscv/rvv/base/vsext_vf8_tum-3.c  | 34 +++
 .../riscv/rvv/base/vsext_vf8_tumu-1.c | 34 +++
 .../riscv/rvv/base/vsext_vf8_tumu-2.c | 34 +++
 .../riscv/rvv/base/vsext_vf8_tumu-3.c | 34 +++
 18 files changed, 612 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_m-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_m-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_m-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_mu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_mu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_mu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tum-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tum-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tum-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tumu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tumu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8_tumu-3.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8-1.c
new file mode 100644
index 000..e922129cd09
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vsext_vf8-1.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vint64m1_t test___riscv_vsext_vf8_i64m1(vint8mf8_t op1,size_t vl)
+{
+return __riscv_vsext_vf8_i64m1(op1,vl);
+}
+
+
+vint64m2_t test___riscv_vsext_vf8_i64m2(vint8mf4_t op1,size_t vl)
+{
+return __riscv_vsext_vf8_i64m2(op1,vl);
+}
+
+
+vint64m4_t test___riscv_vsext_vf8_i64m4(vint8mf2_t op1,size_t vl)
+{
+return __riscv_vsext_vf8_i64m4(op1,vl);
+}
+
+
+vint64m8_t test___riscv_vsext_vf8_i64m8(vint8m1_t op1,size_t vl)
+{
+return __riscv_vsext_vf8_i64m8(op1,vl);
+}
+
+
+
+/* { dg-final { scan-assembler-times 
{vsetvli\s+zero,\s*[a-x0-9]+,\s*e64,\s*m1,\s*t[au],\s*m[au]\s+vsext\.vf8\s+v[0-9]+,\s*v[0-9]+}
 1 } } */
+/* { dg-final { 

[PATCH] RISC-V: Add vzext.vf2 C API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vzext_vf2-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_m-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_m-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_m-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf2_tumu-3.c: New test.

---
 .../gcc.target/riscv/rvv/base/vzext_vf2-1.c   | 111 ++
 .../gcc.target/riscv/rvv/base/vzext_vf2-2.c   | 111 ++
 .../gcc.target/riscv/rvv/base/vzext_vf2-3.c   | 111 ++
 .../gcc.target/riscv/rvv/base/vzext_vf2_m-1.c | 111 ++
 .../gcc.target/riscv/rvv/base/vzext_vf2_m-2.c | 111 ++
 .../gcc.target/riscv/rvv/base/vzext_vf2_m-3.c | 111 ++
 .../riscv/rvv/base/vzext_vf2_mu-1.c   | 111 ++
 .../riscv/rvv/base/vzext_vf2_mu-2.c   | 111 ++
 .../riscv/rvv/base/vzext_vf2_mu-3.c   | 111 ++
 .../riscv/rvv/base/vzext_vf2_tu-1.c   | 111 ++
 .../riscv/rvv/base/vzext_vf2_tu-2.c   | 111 ++
 .../riscv/rvv/base/vzext_vf2_tu-3.c   | 111 ++
 .../riscv/rvv/base/vzext_vf2_tum-1.c  | 111 ++
 .../riscv/rvv/base/vzext_vf2_tum-2.c  | 111 ++
 .../riscv/rvv/base/vzext_vf2_tum-3.c  | 111 ++
 .../riscv/rvv/base/vzext_vf2_tumu-1.c | 111 ++
 .../riscv/rvv/base/vzext_vf2_tumu-2.c | 111 ++
 .../riscv/rvv/base/vzext_vf2_tumu-3.c | 111 ++
 18 files changed, 1998 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_m-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_m-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_m-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_mu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_mu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_mu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tum-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tum-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tum-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tumu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tumu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2_tumu-3.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2-1.c
new file mode 100644
index 000..f5599339a36
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf2-1.c
@@ -0,0 +1,111 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vuint16mf4_t test___riscv_vzext_vf2_u16mf4(vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf2_u16mf4(op1,vl);
+}
+
+
+vuint16mf2_t test___riscv_vzext_vf2_u16mf2(vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf2_u16mf2(op1,vl);
+}
+
+
+vuint16m1_t test___riscv_vzext_vf2_u16m1(vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2_u16m1(op1,vl);
+}
+
+
+vuint16m2_t test___riscv_vzext_vf2_u16m2(vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf2_u16m2(op1,vl);
+}
+
+
+vuint16m4_t test___riscv_vzext_vf2_u16m4(vuint8m2_t op1,size_t vl)
+{
+return __riscv_vzext_vf2_u16m4(op1,vl);
+}
+
+
+vuint16m8_t 

[PATCH] RISC-V: Add vzext.vf4 C API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vzext_vf4-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_m-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_m-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_m-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf4_tumu-3.c: New test.

---
 .../gcc.target/riscv/rvv/base/vzext_vf4-1.c   | 69 +++
 .../gcc.target/riscv/rvv/base/vzext_vf4-2.c   | 69 +++
 .../gcc.target/riscv/rvv/base/vzext_vf4-3.c   | 69 +++
 .../gcc.target/riscv/rvv/base/vzext_vf4_m-1.c | 69 +++
 .../gcc.target/riscv/rvv/base/vzext_vf4_m-2.c | 69 +++
 .../gcc.target/riscv/rvv/base/vzext_vf4_m-3.c | 69 +++
 .../riscv/rvv/base/vzext_vf4_mu-1.c   | 69 +++
 .../riscv/rvv/base/vzext_vf4_mu-2.c   | 69 +++
 .../riscv/rvv/base/vzext_vf4_mu-3.c   | 69 +++
 .../riscv/rvv/base/vzext_vf4_tu-1.c   | 69 +++
 .../riscv/rvv/base/vzext_vf4_tu-2.c   | 69 +++
 .../riscv/rvv/base/vzext_vf4_tu-3.c   | 69 +++
 .../riscv/rvv/base/vzext_vf4_tum-1.c  | 69 +++
 .../riscv/rvv/base/vzext_vf4_tum-2.c  | 69 +++
 .../riscv/rvv/base/vzext_vf4_tum-3.c  | 69 +++
 .../riscv/rvv/base/vzext_vf4_tumu-1.c | 69 +++
 .../riscv/rvv/base/vzext_vf4_tumu-2.c | 69 +++
 .../riscv/rvv/base/vzext_vf4_tumu-3.c | 69 +++
 18 files changed, 1242 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_m-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_m-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_m-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_mu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_mu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_mu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tum-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tum-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tum-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tumu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tumu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4_tumu-3.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4-1.c
new file mode 100644
index 000..43df7caf4e1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf4-1.c
@@ -0,0 +1,69 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vuint32mf2_t test___riscv_vzext_vf4_u32mf2(vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf4_u32mf2(op1,vl);
+}
+
+
+vuint32m1_t test___riscv_vzext_vf4_u32m1(vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf4_u32m1(op1,vl);
+}
+
+
+vuint32m2_t test___riscv_vzext_vf4_u32m2(vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4_u32m2(op1,vl);
+}
+
+
+vuint32m4_t test___riscv_vzext_vf4_u32m4(vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf4_u32m4(op1,vl);
+}
+
+
+vuint32m8_t test___riscv_vzext_vf4_u32m8(vuint8m2_t op1,size_t vl)
+{
+return __riscv_vzext_vf4_u32m8(op1,vl);
+}
+
+
+vuint64m1_t 

[PATCH] RISC-V: Add vzext.vf8 C API tests

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vzext_vf8-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_m-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_m-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_m-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vzext_vf8_tumu-3.c: New test.

---
 .../gcc.target/riscv/rvv/base/vzext_vf8-1.c   | 34 +++
 .../gcc.target/riscv/rvv/base/vzext_vf8-2.c   | 34 +++
 .../gcc.target/riscv/rvv/base/vzext_vf8-3.c   | 34 +++
 .../gcc.target/riscv/rvv/base/vzext_vf8_m-1.c | 34 +++
 .../gcc.target/riscv/rvv/base/vzext_vf8_m-2.c | 34 +++
 .../gcc.target/riscv/rvv/base/vzext_vf8_m-3.c | 34 +++
 .../riscv/rvv/base/vzext_vf8_mu-1.c   | 34 +++
 .../riscv/rvv/base/vzext_vf8_mu-2.c   | 34 +++
 .../riscv/rvv/base/vzext_vf8_mu-3.c   | 34 +++
 .../riscv/rvv/base/vzext_vf8_tu-1.c   | 34 +++
 .../riscv/rvv/base/vzext_vf8_tu-2.c   | 34 +++
 .../riscv/rvv/base/vzext_vf8_tu-3.c   | 34 +++
 .../riscv/rvv/base/vzext_vf8_tum-1.c  | 34 +++
 .../riscv/rvv/base/vzext_vf8_tum-2.c  | 34 +++
 .../riscv/rvv/base/vzext_vf8_tum-3.c  | 34 +++
 .../riscv/rvv/base/vzext_vf8_tumu-1.c | 34 +++
 .../riscv/rvv/base/vzext_vf8_tumu-2.c | 34 +++
 .../riscv/rvv/base/vzext_vf8_tumu-3.c | 34 +++
 18 files changed, 612 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_m-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_m-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_m-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_mu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_mu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_mu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tu-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tum-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tum-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tum-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tumu-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tumu-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8_tumu-3.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8-1.c
new file mode 100644
index 000..c0620ec27b1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vzext_vf8-1.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+
+#include "riscv_vector.h"
+
+vuint64m1_t test___riscv_vzext_vf8_u64m1(vuint8mf8_t op1,size_t vl)
+{
+return __riscv_vzext_vf8_u64m1(op1,vl);
+}
+
+
+vuint64m2_t test___riscv_vzext_vf8_u64m2(vuint8mf4_t op1,size_t vl)
+{
+return __riscv_vzext_vf8_u64m2(op1,vl);
+}
+
+
+vuint64m4_t test___riscv_vzext_vf8_u64m4(vuint8mf2_t op1,size_t vl)
+{
+return __riscv_vzext_vf8_u64m4(op1,vl);
+}
+
+
+vuint64m8_t test___riscv_vzext_vf8_u64m8(vuint8m1_t op1,size_t vl)
+{
+return __riscv_vzext_vf8_u64m8(op1,vl);
+}
+
+
+
+/* { dg-final { scan-assembler-times 
{vsetvli\s+zero,\s*[a-x0-9]+,\s*e64,\s*m1,\s*t[au],\s*m[au]\s+vzext\.vf8\s+v[0-9]+,\s*v[0-9]+}
 1 } } */
+/* { dg-final { 

[PATCH] RISC-V: Add vsext/vzext C/C++ intrinsic support

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/iterators.md: Add sign_extend/zero_extend.
* config/riscv/riscv-vector-builtins-bases.cc (class ext): New class.
(BASE): Ditto.
* config/riscv/riscv-vector-builtins-bases.h: Add vsext/vzext support.
* config/riscv/riscv-vector-builtins-functions.def (vsext): New macro 
define.
(vzext): Ditto.
* config/riscv/riscv-vector-builtins-shapes.cc (struct alu_def): Adjust 
for vsext/vzext support.
* config/riscv/riscv-vector-builtins-types.def (DEF_RVV_WEXTI_OPS): New 
macro define.
(DEF_RVV_QEXTI_OPS): Ditto.
(DEF_RVV_OEXTI_OPS): Ditto.
(DEF_RVV_WEXTU_OPS): Ditto.
(DEF_RVV_QEXTU_OPS): Ditto.
(DEF_RVV_OEXTU_OPS): Ditto.
(vint16mf4_t): Ditto.
(vint16mf2_t): Ditto.
(vint16m1_t): Ditto.
(vint16m2_t): Ditto.
(vint16m4_t): Ditto.
(vint16m8_t): Ditto.
(vint32mf2_t): Ditto.
(vint32m1_t): Ditto.
(vint32m2_t): Ditto.
(vint32m4_t): Ditto.
(vint32m8_t): Ditto.
(vint64m1_t): Ditto.
(vint64m2_t): Ditto.
(vint64m4_t): Ditto.
(vint64m8_t): Ditto.
(vuint16mf4_t): Ditto.
(vuint16mf2_t): Ditto.
(vuint16m1_t): Ditto.
(vuint16m2_t): Ditto.
(vuint16m4_t): Ditto.
(vuint16m8_t): Ditto.
(vuint32mf2_t): Ditto.
(vuint32m1_t): Ditto.
(vuint32m2_t): Ditto.
(vuint32m4_t): Ditto.
(vuint32m8_t): Ditto.
(vuint64m1_t): Ditto.
(vuint64m2_t): Ditto.
(vuint64m4_t): Ditto.
(vuint64m8_t): Ditto.
* config/riscv/riscv-vector-builtins.cc (DEF_RVV_WEXTI_OPS): Ditto.
(DEF_RVV_QEXTI_OPS): Ditto.
(DEF_RVV_OEXTI_OPS): Ditto.
(DEF_RVV_WEXTU_OPS): Ditto.
(DEF_RVV_QEXTU_OPS): Ditto.
(DEF_RVV_OEXTU_OPS): Ditto.
(rvv_arg_type_info::get_base_vector_type): Add sign_exted/zero_extend 
support.
(rvv_arg_type_info::get_tree_type): Ditto.
* config/riscv/riscv-vector-builtins.h (enum rvv_base_type): Ditto.
* config/riscv/vector-iterators.md (z): New attribute.
* config/riscv/vector.md (@pred__vf2): New pattern.
(@pred__vf4): Ditto.
(@pred__vf8): Ditto.

---
 gcc/config/riscv/iterators.md |   4 +-
 .../riscv/riscv-vector-builtins-bases.cc  |  25 
 .../riscv/riscv-vector-builtins-bases.h   |   2 +
 .../riscv/riscv-vector-builtins-functions.def |   6 +
 .../riscv/riscv-vector-builtins-shapes.cc |  21 ++-
 .../riscv/riscv-vector-builtins-types.def | 104 ++
 gcc/config/riscv/riscv-vector-builtins.cc | 131 +-
 gcc/config/riscv/riscv-vector-builtins.h  |   3 +
 gcc/config/riscv/vector-iterators.md  |  39 ++
 gcc/config/riscv/vector.md|  80 ++-
 10 files changed, 401 insertions(+), 14 deletions(-)

diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md
index 7e5415cc80b..f95dd405e12 100644
--- a/gcc/config/riscv/iterators.md
+++ b/gcc/config/riscv/iterators.md
@@ -207,7 +207,9 @@
 (ss_plus "ssadd")
 (us_plus "usadd")
 (ss_minus "sssub")
-(us_minus "ussub")])
+(us_minus "ussub")
+(sign_extend "extend")
+(zero_extend "zero_extend")])
 
 ;;  code attributes
 (define_code_attr or_optab [(ior "ior")
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 7e6ee1d7b53..1a9469a370a 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -197,6 +197,27 @@ public:
   }
 };
 
+/* Implements vsext.vf2/vsext.vf4/vsext.vf8/vzext.vf2/vzext.vf4/vzext.vf8.  */
+template
+class ext : public function_base
+{
+public:
+  rtx expand (function_expander ) const override
+  {
+switch (e.op_info->op)
+  {
+  case OP_TYPE_vf2:
+   return e.use_exact_insn (code_for_pred_vf2 (CODE, e.vector_mode ()));
+  case OP_TYPE_vf4:
+   return e.use_exact_insn (code_for_pred_vf4 (CODE, e.vector_mode ()));
+  case OP_TYPE_vf8:
+   return e.use_exact_insn (code_for_pred_vf8 (CODE, e.vector_mode ()));
+  default:
+   gcc_unreachable ();
+  }
+  }
+};
+
 static CONSTEXPR const vsetvl vsetvl_obj;
 static CONSTEXPR const vsetvl vsetvlmax_obj;
 static CONSTEXPR const loadstore vle_obj;
@@ -241,6 +262,8 @@ static CONSTEXPR const binop vdivu_obj;
 static CONSTEXPR const binop vremu_obj;
 static CONSTEXPR const unop vneg_obj;
 static CONSTEXPR const unop vnot_obj;
+static CONSTEXPR const ext vsext_obj;
+static CONSTEXPR const ext vzext_obj;
 static CONSTEXPR const binop vsadd_obj;
 static CONSTEXPR const binop vssub_obj;
 static CONSTEXPR const binop vsaddu_obj;
@@ -295,6 

[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function

[murugesandins at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Murugesan Nagarajan  ---
@Andrew,
Thank you for updating current bug id: 94810
Old bug reported:
On: Mon 27-Apr-2020 09:44:52 PM UTC
Old Bug URL:   
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810
Old Status: RESOLVED INVALID
@Andrew's comment on 2023-02-03 07:47:43 PM UTC
Related linked bug/url:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4e4e3ffd10f53e
Updated bug on: Sun 06-Nov-2022 04:16:00 PM UTC
Updated status: Bug fix completed using "__attribute__" and new
bug using "__has_attribute".

[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument

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

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

--- Comment #13 from Patrick Palka  ---
hb-aat-layout.cc.i and the comment #9 test should be accepted on trunk again
now, backport to the 12 branch to follow.

The comment #7 testcase I think is invalid because GCC incorrectly accepts the
substitution 'typename U::E [with U=E]', which seems to be PR34810.

[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:31924665c86d47af6b1f22a74f594f2e1dc0ed2d

commit r13-5707-g31924665c86d47af6b1f22a74f594f2e1dc0ed2d
Author: Patrick Palka 
Date:   Sun Feb 5 21:35:33 2023 -0500

c++: equivalence of non-dependent calls [PR107461]

After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependence of a CALL_EXPR before treating a FUNCTION_DECL callee as a
dependent name, which leads to us incorrectly accepting the first two
testcases below and rejecting the third:

 * In the first testcase, cp_tree_equal incorrectly returns true for
   the two non-dependent CALL_EXPRs f(0) and f(0) (whose CALL_EXPR_FN
   are different FUNCTION_DECLs) which causes us to treat #2 as a
   redeclaration of #1.

 * Same issue in the second testcase, for f() and f().

 * In the third testcase, cp_tree_equal incorrectly returns true for
   f() and f() which causes us to conflate the two
   dependent specializations A()(U()))> and
   A()(U()))>.

This patch fixes this by making called_fns_equal treat two callees as
dependent names only if the overall CALL_EXPRs are dependent, via a new
convenience function call_expr_dependent_name that is like dependent_name
but also checks dependence of the overall CALL_EXPR.

PR c++/107461

gcc/cp/ChangeLog:

* cp-tree.h (call_expr_dependent_name): Declare.
* pt.cc (iterative_hash_template_arg) : Use
call_expr_dependent_name instead of dependent_name.
* tree.cc (call_expr_dependent_name): Define.
(called_fns_equal): Adjust to take two CALL_EXPRs instead of
CALL_EXPR_FNs thereof.  Use call_expr_dependent_name instead
of dependent_name.
(cp_tree_equal) : Adjust call to called_fns_equal.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/overload5.C: New test.
* g++.dg/cpp0x/overload5a.C: New test.
* g++.dg/cpp0x/overload6.C: New test.

Re: [PATCH v3] c++: -Wdangling-reference with reference wrapper [PR107532]

[Jason Merrill via Gcc-patches]

On 1/24/23 17:49, Marek Polacek wrote:

On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:

On 1/19/23 21:03, Marek Polacek wrote:

On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:

On 1/18/23 20:13, Marek Polacek wrote:

On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:

On 1/18/23 12:52, Marek Polacek wrote:

Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

  const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

So I figured that perhaps we want to look at the object we're invoking
the member function(s) on and see if that is a temporary, as in, don't
warn about

  const Plane & meta = fm.planes().inner();

but do warn about

  const Plane & meta = FrameMetadata().planes().inner();

It's ugly, but better than asking users to add #pragmas into their code.


Hmm, that doesn't seem right; the former is only OK because Ref is in fact a
reference-like type.  If planes() returned a class that held data, we would
want to warn.


Sure, it's always some kind of tradeoff with warnings :/.

In this case, we might recognize the reference-like class because it has a
reference member and a constructor taking the same reference type.


That occurred to me too, but then I found out that std::reference_wrapper
actually uses T*, not T&, as you say.  But here's a patch to do that
(I hope).

That wouldn't help with std::reference_wrapper or std::ref_view because they
have pointer members instead of references, but perhaps loosening the check
to include that case would make sense?


Sorry, I don't understand what you mean by loosening the check.  I could
hardcode std::reference_wrapper and std::ref_view but I don't think that's
what you meant.


Indeed that's not what I meant, but as I was saying in our meeting I think
it's worth doing; the compiler has various tweaks to handle specific
standard-library classes better.

Okay, done in the patch below.  Except that I'm not including a test for
std::ranges::ref_view because I don't really know how that works.


Surely I cannot _not_ warn for any class that contains a T*.


I was thinking if a constructor takes a T& and the class has a T* that would
be close enough, though this also wouldn't handle the standard library
classes so the benefit is questionable.


Here's the patch so that we have some actual code to discuss...  Thanks.

-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

 const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

Perhaps we want to look at the member function's enclosing class
to see if it's a reference wrapper class (meaning, has a reference
member and a constructor taking the same reference type) and don't
warn if so, supposing that the member function returns a reference
to a non-temporary object.

It's ugly, but better than asking users to add #pragmas into their code.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (do_warn_dangling_reference): Don't warn when the
member function comes from a reference wrapper class.


Let's factor the new code out into e.g. reference_like_class_p


Done.  Thanks,

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

Perhaps we want to look at the member function's enclosing class
to see if it's a reference wrapper class (meaning, has a reference
member and a constructor taking the same reference type, or is
std::reference_wrapper or std::ranges::ref_view) and don't warn if so,
supposing that the member function returns a reference to a non-temporary
object.

It's ugly, but better than asking users to add #pragmas into their code.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc 

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc]

On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers  wrote:
>
> Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
> > On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
> >  wrote:
> >>
> >>> From: Ian Lance Taylor 
> >>> Date: Tue, 24 Jan 2023 09:58:10 -0800
> >>> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >>>
> >>> I'd rather that the patch look like the appended.  Can someone with a
> >>> Windows system test to see what that builds and passes the tests?
> >>
> >> ENOPATCH
> >
> > Gah.
> >
> > Ian
> >
> That seems to be my original patch, right? That one I have tested (and
> am actually using) on x86 and x64 windows.

It's very similar but I changed the windows_get_executable_path function.

Ian

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc-patches]

On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers  wrote:
>
> Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
> > On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
> >  wrote:
> >>
> >>> From: Ian Lance Taylor 
> >>> Date: Tue, 24 Jan 2023 09:58:10 -0800
> >>> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >>>
> >>> I'd rather that the patch look like the appended.  Can someone with a
> >>> Windows system test to see what that builds and passes the tests?
> >>
> >> ENOPATCH
> >
> > Gah.
> >
> > Ian
> >
> That seems to be my original patch, right? That one I have tested (and
> am actually using) on x86 and x64 windows.

It's very similar but I changed the windows_get_executable_path function.

Ian

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

[Rich Felker]

On Mon, Feb 06, 2023 at 12:59:48AM +0100, Alejandro Colomar wrote:
> Hi Rich,
> 
> On 2/6/23 00:43, Rich Felker wrote:
> >On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> >>As discussed before, and Bastien and I seem to agree, ideally we should
> >>define the following types:
> >>
> >> struct sockaddr_storage {
> >> union {
> >> struct {
> >> sa_family_t  ss_family;
> >> };
> >> struct sockaddr_in   sin;
> >> struct sockaddr_in6  sin6;
> >> struct sockaddr_un   sun;
> >> // ...
> >> };
> >> };
> >
> >AFAIK this is not permitted because of namespace. sys/socket.h is not
> >permitted to expose sockaddr_{in,in6,un}. And if you defined
> >differently-tagged structures with the same contents, it would not do
> >any good; accessing the members with the wrong-tagged struct type
> >would still be UB.
> 
> I'm not sure.  ISO C has that restriction that a header can only
> define what the standard says it defines.  However, does POSIX have
> the same restriction?

Yes.

> Doesn't POSIX allow including any other POSIX
> headers (maybe it does, but IIRC it doesn't)?

Not except where it's explicitly allowed.

> Since 
> is just a POSIX thing, that's the only standard we should care
> about.

The relevant text is here:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02

> >Really, there is no action needed here. Nothing is wrong on libc's
> >side. The problem is just that the type is *not useful for anything*
> >and should not be used except in the context of sizeof, which is
> >purely a documentation issue.
> >
> >> struct [[deprecated]] sockaddr {
> >> sa_family_t  sa_family;
> >> };
> >>
> >> union [[gnu::transparent_union]] sockaddr_ptr {
> >> struct sockaddr_storage  *ss;
> >> struct sockaddr  *sa;
> >> };
> >>
> >>And then we could define APIs like:
> >>
> >> int bind(int sockfd, const union sockaddr_ptr *addr, socklen_t len);
> >
> >You cannot just change APIs because you wish they were different.
> 
> This API is compatible.  In fact, it already is now like that:

Unless I'm mistaken, it's not. The function pointer the name 'bind'
produces will not have the right type, and will have problems being
stored in a function pointer object with the right type, as well as
wrong results with _Generic, etc. Only plain calls to it are
unaffected.

> alx@debian:/usr/include$ grepc bind
> ./x86_64-linux-gnu/sys/socket.h:112:
> extern int bind (int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)
>  __THROW;
> 
> alx@debian:/usr/include$ sed -n 83,84p x86_64-linux-gnu/sys/socket.h
> typedef union { __SOCKADDR_ALLTYPES
> } __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__));
> 
> 
> >Ideally bind, etc. would just take void *,
> 
> void * is a bit too much unsafe.  GCC's transparent unions are a
> restricted catch-many pointer, rather than a catch-all.
> 
> >which is what the struct
> >sockaddr * is being used as.
> 
> And in fact, void* wouldn't sole the union problem.
> 
> >But they don't, so callers have to cast.
> 
> With the current glibc implementation, you don't need to cast,
> thanks to the [[gnu::transparent_union]]:

This is just facilitating writing non-portable code, since correct
code written to the spec *does* have to cast.

> >It's ugly but it's really not a big deal. Much less of a big deal than
> >breaking the interface because you think it would look prettier if it
> >had been done differently.
> 
> It's not breaking the interface; not in GNU C.  Current code still
> falls back to the a POSIX-complying UB-invoking interface when you
> don't ask for _GNU_SOURCE, but we can keep that.  I'm only asking
> that we fix the GNU C version.  Moreover, in POSIX-complying code,
> you can keep the interface pointer, since you'll need to cast
> anyway, but can still make sockaddr_storage be implemented through
> an anonymous union.

If it's only for _GNU_SOURCE it's probably mostly harmless, and
allowable to violate the namespace rules, but also not terribly
helpful...

Rich

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

[Alejandro Colomar via Gcc]

Hi Rich,

On 2/6/23 00:43, Rich Felker wrote:

On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:

As discussed before, and Bastien and I seem to agree, ideally we should
define the following types:

 struct sockaddr_storage {
 union {
 struct {
 sa_family_t  ss_family;
 };
 struct sockaddr_in   sin;
 struct sockaddr_in6  sin6;
 struct sockaddr_un   sun;
 // ...
 };
 };


AFAIK this is not permitted because of namespace. sys/socket.h is not
permitted to expose sockaddr_{in,in6,un}. And if you defined
differently-tagged structures with the same contents, it would not do
any good; accessing the members with the wrong-tagged struct type
would still be UB.


I'm not sure.  ISO C has that restriction that a header can only define what the 
standard says it defines.  However, does POSIX have the same restriction? 
Doesn't POSIX allow including any other POSIX headers (maybe it does, but IIRC 
it doesn't)?  Since  is just a POSIX thing, that's the only 
standard we should care about.




Really, there is no action needed here. Nothing is wrong on libc's
side. The problem is just that the type is *not useful for anything*
and should not be used except in the context of sizeof, which is
purely a documentation issue.


 struct [[deprecated]] sockaddr {
 sa_family_t  sa_family;
 };

 union [[gnu::transparent_union]] sockaddr_ptr {
 struct sockaddr_storage  *ss;
 struct sockaddr  *sa;
 };

And then we could define APIs like:

 int bind(int sockfd, const union sockaddr_ptr *addr, socklen_t len);


You cannot just change APIs because you wish they were different.


This API is compatible.  In fact, it already is now like that:

alx@debian:/usr/include$ grepc bind
./x86_64-linux-gnu/sys/socket.h:112:
extern int bind (int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)
 __THROW;

alx@debian:/usr/include$ sed -n 83,84p x86_64-linux-gnu/sys/socket.h
typedef union { __SOCKADDR_ALLTYPES
  } __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__));



Ideally bind, etc. would just take void *,


void * is a bit too much unsafe.  GCC's transparent unions are a restricted 
catch-many pointer, rather than a catch-all.



which is what the struct
sockaddr * is being used as.


And in fact, void* wouldn't sole the union problem.


But they don't, so callers have to cast.


With the current glibc implementation, you don't need to cast, thanks to the 
[[gnu::transparent_union]]:



alx@debian:~/tmp$ cat sock.c
#define _GNU_SOURCE
#include 
#include 

int
bind_un(int sfd, const struct sockaddr_un *addr, socklen_t len)
{
return bind(sfd, addr, len);
}
alx@debian:~/tmp$ cc -Wall -Wextra sock.c -S
alx@debian:~/tmp$ clang -Wall -Wextra sock.c -S
alx@debian:~/tmp$



It's ugly but it's really not a big deal. Much less of a big deal than
breaking the interface because you think it would look prettier if it
had been done differently.


It's not breaking the interface; not in GNU C.  Current code still falls back to 
the a POSIX-complying UB-invoking interface when you don't ask for _GNU_SOURCE, 
but we can keep that.  I'm only asking that we fix the GNU C version.  Moreover, 
in POSIX-complying code, you can keep the interface pointer, since you'll need 
to cast anyway, but can still make sockaddr_storage be implemented through an 
anonymous union.


Cheers,

Alex



Rich


--

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

[Rich Felker]

On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> As discussed before, and Bastien and I seem to agree, ideally we should
> define the following types:
> 
> struct sockaddr_storage {
> union {
> struct {
> sa_family_t  ss_family;
> };
> struct sockaddr_in   sin;
> struct sockaddr_in6  sin6;
> struct sockaddr_un   sun;
> // ...
> };
> };

AFAIK this is not permitted because of namespace. sys/socket.h is not
permitted to expose sockaddr_{in,in6,un}. And if you defined
differently-tagged structures with the same contents, it would not do
any good; accessing the members with the wrong-tagged struct type
would still be UB.

Really, there is no action needed here. Nothing is wrong on libc's
side. The problem is just that the type is *not useful for anything*
and should not be used except in the context of sizeof, which is
purely a documentation issue.

> struct [[deprecated]] sockaddr {
> sa_family_t  sa_family;
> };
> 
> union [[gnu::transparent_union]] sockaddr_ptr {
> struct sockaddr_storage  *ss;
> struct sockaddr  *sa;
> };
> 
> And then we could define APIs like:
> 
> int bind(int sockfd, const union sockaddr_ptr *addr, socklen_t len);

You cannot just change APIs because you wish they were different.
Ideally bind, etc. would just take void *, which is what the struct
sockaddr * is being used as. But they don't, so callers have to cast.
It's ugly but it's really not a big deal. Much less of a big deal than
breaking the interface because you think it would look prettier if it
had been done differently.

Rich

[Bug other/108662] Cast between incompatible function types in libiberty/physmem.c under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #1 from Jan Dubiec  ---
Created attachment 54410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54410=edit
Proposed patch

gcc-13-20230205 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-13-20230205.tar.xz   Complete GCC

  SHA256=5526915b4bc9395ed5d03a98200c03040c578544988b29492236a8703697424e
  SHA1=6dc403e9ae7d4a577bfcbab64bb08ae747732aa6

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

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

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #2 from Hans-Peter Nilsson  ---
.

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #6 from Mikael Morin  ---
Fixed for gcc-13.1 and gcc-12.3.
Closing.

[Bug fortran/108592] In IF statements -Winteger-division is repeated 4 times

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.

[Bug fortran/108592] In IF statements -Winteger-division is repeated 4 times

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-5705-gd042f118798ae0648b45f97e63b0e5ab7c82c8ef
Author: Harald Anlauf 
Date:   Mon Jan 30 22:46:43 2023 +0100

Fortran: prevent redundant integer division truncation warnings [PR108592]

gcc/fortran/ChangeLog:

PR fortran/108592
* arith.cc (gfc_arith_divide): Emit integer division truncation
warnings using gfc_warning instead of gfc_warning_now to prevent
redundant messages.

gcc/testsuite/ChangeLog:

PR fortran/108592
* gfortran.dg/pr108592.f90: New test.

[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Mikael Morin
:

https://gcc.gnu.org/g:32502d82a5b54ca5b8e524df9fcad851727dc54a

commit r12-9108-g32502d82a5b54ca5b8e524df9fcad851727dc54a
Author: Mikael Morin 
Date:   Sun Jan 29 21:57:24 2023 +0100

fortran: Set name for *LOC default BACK argument [PR108450]

This change fixes an ICE caused by the double resolution of MINLOC,
MAXLOC and FINDLOC expressions which get a default value for the BACK
argument at resolution time.  That argument  is added without name,
and argument reordering code is not prepared to handle unnamed arguments
coming after named ones, so the second resolution causes a NULL pointer
dereference.
The problem is fixed by explicitly setting the argument name.

PR fortran/108450

gcc/fortran/ChangeLog:

* check.cc (gfc_check_minloc_maxloc): Explicitly set argument name.
(gfc_check_findloc): Ditto.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/minmaxloc_1.f90: New test.

(cherry picked from commit 2e32a12c04c72f692a7bd119fd3e4e5b74392c9d)

Re: *PING* [PATCH] Fortran: prevent redundant integer division truncation warnings [PR108592]

[Jerry D via Gcc-patches]

On 2/5/23 11:33 AM, Harald Anlauf via Fortran wrote:

Early gentle ping.

Am 30.01.23 um 22:55 schrieb Harald Anlauf via Gcc-patches:

Dear Fortranners,

the subject says it all: in some cases we emit redundant integer division
truncation warnings (2 or 4), where just one would have been sufficient.
This is solved by using gfc_warning instead of gfc_warning_now.

The testcase uses a suggestion by Andrew to verify that we get the
desired warning exactly once.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald





The patch is gentle enough to be OK to commit.

Thanks,

Jerry

Re: [PATCH 2/2] c++: speculative constexpr and is_constant_evaluated [PR108243]

[Jason Merrill via Gcc-patches]

On 2/3/23 15:51, Patrick Palka wrote:

On Mon, 30 Jan 2023, Jason Merrill wrote:


On 1/27/23 17:02, Patrick Palka wrote:

This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely fold the builtin to false if the
expression in question would be later manifestly constant evaluated (in
which case it must be folded to true).

This patch fixes this by permitting __builtin_is_constant_evaluated
to get folded as false during cp_fold_function, since at that point
we're sure we're doing manifestly constant evaluation.  To that end
we add a flags parameter to cp_fold that controls what mce_value the
CALL_EXPR case passes to maybe_constant_value.

bootstrapped and rgetsted no x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/108243

gcc/cp/ChangeLog:

* cp-gimplify.cc (enum fold_flags): Define.
(cp_fold_data::genericize): Replace this data member with ...
(cp_fold_data::fold_flags): ... this.
(cp_fold_r): Adjust cp_fold_data use and cp_fold_calls.
(cp_fold_function): Likewise.
(cp_fold_maybe_rvalue): Likewise.
(cp_fully_fold_init): Likewise.
(cp_fold): Add fold_flags parameter.  Don't cache if flags
isn't empty.
: Pass mce_false to maybe_constant_value
if if ff_genericize is set.

gcc/testsuite/ChangeLog:

* g++.dg/opt/pr108243.C: New test.
---
   gcc/cp/cp-gimplify.cc   | 76 ++---
   gcc/testsuite/g++.dg/opt/pr108243.C | 29 +++
   2 files changed, 76 insertions(+), 29 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/opt/pr108243.C

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index a35cedd05cc..d023a63768f 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -43,12 +43,20 @@ along with GCC; see the file COPYING3.  If not see
   #include "omp-general.h"
   #include "opts.h"
   +/* Flags for cp_fold and cp_fold_r.  */
+
+enum fold_flags {
+  ff_none = 0,
+  /* Whether we're being called from cp_fold_function.  */
+  ff_genericize = 1 << 0,
+};
+
   /* Forward declarations.  */
 static tree cp_genericize_r (tree *, int *, void *);
   static tree cp_fold_r (tree *, int *, void *);
   static void cp_genericize_tree (tree*, bool);
-static tree cp_fold (tree);
+static tree cp_fold (tree, fold_flags);
 /* Genericize a TRY_BLOCK.  */
   @@ -996,9 +1004,8 @@ struct cp_genericize_data
   struct cp_fold_data
   {
 hash_set pset;
-  bool genericize; // called from cp_fold_function?
-
-  cp_fold_data (bool g): genericize (g) {}
+  fold_flags flags;
+  cp_fold_data (fold_flags flags): flags (flags) {}
   };
 static tree
@@ -1039,7 +1046,7 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void
*data_)
 break;
   }
   -  *stmt_p = stmt = cp_fold (*stmt_p);
+  *stmt_p = stmt = cp_fold (*stmt_p, data->flags);
   if (data->pset.add (stmt))
   {
@@ -1119,12 +1126,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void
*data_)
 here rather than in cp_genericize to avoid problems with the
invisible
 reference transition.  */
   case INIT_EXPR:
-  if (data->genericize)
+  if (data->flags & ff_genericize)
cp_genericize_init_expr (stmt_p);
 break;
 case TARGET_EXPR:
-  if (data->genericize)
+  if (data->flags & ff_genericize)
cp_genericize_target_expr (stmt_p);
   /* Folding might replace e.g. a COND_EXPR with a TARGET_EXPR; in
@@ -1157,7 +1164,7 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void
*data_)
   void
   cp_fold_function (tree fndecl)
   {
-  cp_fold_data data (/*genericize*/true);
+  cp_fold_data data (ff_genericize);
 cp_walk_tree (_SAVED_TREE (fndecl), cp_fold_r, , NULL);
   }
   @@ -2375,7 +2382,7 @@ cp_fold_maybe_rvalue (tree x, bool rval)
   {
 while (true)
   {
-  x = cp_fold (x);
+  x = cp_fold (x, ff_none);
 if (rval)
x = mark_rvalue_use (x);
 if (rval && DECL_P (x)
@@ -2434,7 +2441,7 @@ cp_fully_fold_init (tree x)
 if (processing_template_decl)
   return x;
 x = cp_fully_fold (x);
-  cp_fold_data data (/*genericize*/false);
+  cp_fold_data data (ff_none);
 cp_walk_tree (, cp_fold_r, , NULL);
 return x;
   }
@@ -2469,7 +2476,7 @@ clear_fold_cache (void)
   Function returns X or its folded variant.  */
 static tree
-cp_fold (tree x)
+cp_fold (tree x, fold_flags flags)
   {
 tree op0, op1, op2, op3;
 tree org_x = x, r = NULL_TREE;
@@ -2490,8 +2497,11 @@ cp_fold (tree x)
 if (fold_cache == NULL)
   fold_cache = hash_map::create_ggc (101);
   -  if (tree *cached = fold_cache->get (x))
-return *cached;
+  bool cache_p = (flags == ff_none);
+
+  if (cache_p)
+if (tree *cached = fold_cache->get (x))
+  return *cached;
   uid_sensitive_constexpr_evaluation_checker c;
   @@ -2526,7 +2536,7 @@ cp_fold (tree x)

[Bug fortran/108680] New: Wrong DTIO arguments with -fdefault-integer-8

[albandil at atlas dot cz via Gcc-bugs]

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

Bug ID: 108680
   Summary: Wrong DTIO arguments with -fdefault-integer-8
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albandil at atlas dot cz
  Target Milestone: ---

Wrong DTIO arguments with -fdefault-integer-8

It seems that gfortran miscompiles the following simple program when
`-fdefault-integer-8` compiler option is used:

module types

type dtype
contains
procedure :: write_formatted
generic, public :: write(formatted) => write_formatted
end type

contains

subroutine write_formatted (this, unit, iotype, v_list, iostat, iomsg)

class(dtype), intent(in):: this
integer,  intent(in):: unit, v_list(:)
character(*), intent(in):: iotype
integer,  intent(out)   :: iostat
character(*), intent(inout) :: iomsg

iostat = 0

print *, 'v_list', v_list

end subroutine write_formatted

end module types


program p

use types, only: dtype

type(dtype) :: data
integer :: u

open (file = 'output.txt', newunit = u, form = 'formatted')
write (u, '(dt(1,2,3))') data
close (u)

end program p

The derived type `dtype` should be given integers 1,2,3 in the v_list parameter
of the `write(formatted)` subroutine, which only echoes them out for feedback.
This works with Intel compilers regardless of the default integer type.
However, the output is wrong if I combine gfortran `-fdefault-integer-8`. The
behaviour is the same with the current git version as well as with GCC release
11.3, so the problem has been around for some time.

$ /opt/gcc-git/bin/gfortran --version | head -n 1
GNU Fortran (GCC) 13.0.1 20230205 (experimental)
$ /opt/gcc-git/bin/gfortran main.f90 
$ ./a.out 
 v_list   1   2   3
$ /opt/gcc-git/bin/gfortran -fdefault-integer-8 main.f90 
$ ./a.out 
 v_list   858993459330

$ gfortran-11 --version | head -n 1
GNU Fortran (SUSE Linux) 11.3.1 20221024 [revision
bd0c76a2329e7fe6d6612c2259647bbb67f5866a]
$ gfortran-11 -fdefault-integer-8 main.f90 
$ ./a.out 
 v_list   858993459330

$ ifx --version | head -n 1
ifx (IFORT) 2023.0.0 20221201
$ ifx -i8 main.f90 
$ ./a.out 
 v_list 1 2 3

$ ifort --version | head -n 1
ifort (IFORT) 2021.8.0 20221119
$ ifort -i8 main.f90 
$ ./a.out 
 v_list 1 2 3

It looks as if the subroutine was actually getting pointers to 4-byte integers
regardless of the switch, because the large value pritned first is actually
composition of the missing 2 and 1:

8589934593 ~ 0010
0001
   ~ 2 1

[Bug tree-optimization/108677] wrong vectorization (when copy constructor is present?)

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

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

--- Comment #2 from Andrew Pinski  ---
Is the confusing part is the fmaddsub instruction?

*PING* [PATCH] Fortran: prevent redundant integer division truncation warnings [PR108592]

[Harald Anlauf via Gcc-patches]

Early gentle ping.

Am 30.01.23 um 22:55 schrieb Harald Anlauf via Gcc-patches:

Dear Fortranners,

the subject says it all: in some cases we emit redundant integer division
truncation warnings (2 or 4), where just one would have been sufficient.
This is solved by using gfc_warning instead of gfc_warning_now.

The testcase uses a suggestion by Andrew to verify that we get the
desired warning exactly once.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

Re: [PATCH] c++: equivalence of non-dependent calls [PR107461]

[Jason Merrill via Gcc-patches]

On 2/5/23 09:57, Patrick Palka wrote:

On Sat, 4 Feb 2023, Jason Merrill wrote:


On 2/4/23 20:41, Jason Merrill wrote:

On 2/4/23 20:08, Patrick Palka wrote:

On Sat, 4 Feb 2023, Jason Merrill wrote:


On 2/4/23 15:31, Patrick Palka wrote:

After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of
FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependentness of a CALL_EXPR before treating the callee as a dependent
name, which manifests as us incorrectly accepting the first two
testcases below and rejecting the third:

    * In the first testcase, cp_tree_equal incorrectly returns true for
  the two non-dependent CALL_EXPRs f(0) and f(0) (whose
CALL_EXPR_FN
  are different FUNCTION_DECLs) and so we treat #2 as a
redeclaration
  of #1.

    * Same issue in the second testcase, for f() and f().

    * In the third testcase, cp_tree_equal incorrectly returns true for
  f() and f() which causes us to conflate the
two
  dependent specializations A()(U()))> and
  A()(U()))>, leading to a bogus error.

This patch fixes this by making called_fns_equal treat two callees as
dependent names only if the CALL_EXPRs in question are dependent.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for
trunk/12?  Patch generated with -w to ignore noisy whitespace changes.

 PR c++/107461

gcc/cp/ChangeLog:

 * pt.cc (iterative_hash_template_arg) : Treat
 the callee as a dependent name only if the CALL_EXPR is
 dependent.
 * tree.cc (called_fns_equal): Take two CALL_EXPRs instead of
 CALL_EXPR_FNs thereof.  As above.
 (cp_tree_equal) : Adjust call to called_fns_equal.

gcc/testsuite/ChangeLog:

 * g++.dg/cpp0x/overload5.C: New test.
 * g++.dg/cpp0x/overload5a.C: New test.
 * g++.dg/cpp0x/overload6.C: New test.
---
    gcc/cp/pt.cc    |  1 +
    gcc/cp/tree.cc  | 33
++---
    gcc/testsuite/g++.dg/cpp0x/overload5.C  | 12 +
    gcc/testsuite/g++.dg/cpp0x/overload5a.C | 10 
    gcc/testsuite/g++.dg/cpp0x/overload6.C  | 16 
    5 files changed, 58 insertions(+), 14 deletions(-)
    create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload5.C
    create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload5a.C
    create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload6.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 255332dc0c1..c9360240cd2 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -1841,6 +1841,7 @@ iterative_hash_template_arg (tree arg, hashval_t
val)
    case CALL_EXPR:
  {
    tree fn = CALL_EXPR_FN (arg);
+    if (TREE_TYPE (arg) == NULL_TREE)


How about changing dependent_name to take the CALL_EXPR rather than the
CALL_EXPR_FN?  That would mean some changes to write_expression to move
the
dependent_name handling into the CALL_EXPR handling, but that doesn't
seem
like a bad thing.  Other callers seem like a trivial change.


Indeed changing dependent_name seems best, but I'm worried about such a
refactoring to write_expression causing unintended mangling changes at
this stage.  Because it seems the CALL_EXPR case of write_expression
isn't the user of the dependent_name branch of write_expression, at
least according to the following patch which causes us to ICE on
mangle{37,57,58,76}.C:


Yeah, I tried the same thing.  Maybe for GCC 13 better to add a new function
rather than change the current one.


Sounds good, like so?  Only regtested so far.  Full bootstrap and
regtest running on x86_64-pc-linux-gnu.

-- >8 --

Subject: [PATCH] c++: equivalence of non-dependent calls [PR107461]

After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependentness of a CALL_EXPR before treating a FUNCTION_DECL callee as a
dependent name, which manifests as us incorrectly accepting the first
two testcases below and rejecting the third:

  * In the first testcase, cp_tree_equal incorrectly returns true for
the two non-dependent CALL_EXPRs f(0) and f(0) (whose CALL_EXPR_FN
are different FUNCTION_DECLs) and so we treat #2 as a redeclaration
of #1.

  * Same issue in the second testcase, for f() and f().

  * In the third testcase, cp_tree_equal incorrectly returns true for
f() and f() which causes us to conflate the two
dependent specializations A()(U()))> and
A()(U()))>, leading to a bogus error.

This patch fixes this by making called_fns_equal treat two callees as
dependent names only if the overall CALL_EXPRs are dependent, via a new
convenience function call_expr_dependent_name that is like dependent_name
but also checks dependence of the overall CALL_EXPR.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?  Patch generated with -w 

[Bug fortran/108609] New test case gfortran.dg/pr108527.f90 in r13-5479-g22afa4947584c7 ICEs

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

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

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

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

commit r12-9107-g1e60e9124543fd002f3e6dad8172cff8aa1b24b3
Author: Harald Anlauf 
Date:   Wed Feb 1 21:01:32 2023 +0100

Fortran: error recovery on invalid array section [PR108609]

The testcase for PR108527 uncovered a latent issue with invalid array
sections that resulted in different paths being taken on different
architectures.  Detect the invalid array declaration for a clean recovery.

gcc/fortran/ChangeLog:

PR fortran/108609
* expr.cc (find_array_section): Add check to prevent interpreting
an
mpz non-integer constant as an integer.

gcc/testsuite/ChangeLog:

PR fortran/108609
* gfortran.dg/pr108527.f90: Adjust test pattern.

(cherry picked from commit 88a2a09dd4529107e7ef7a6e7ce43acf96457173)

[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:511928102dc9fa3f9c377e01f9bfb605b4995a61

commit r12-9106-g511928102dc9fa3f9c377e01f9bfb605b4995a61
Author: Harald Anlauf 
Date:   Tue Jan 24 22:36:25 2023 +0100

Fortran: fix ICE in compare_bound_int [PR108527]

gcc/fortran/ChangeLog:

PR fortran/108527
* resolve.cc (compare_bound_int): Expression to compare must be of
type INTEGER.
(compare_bound_mpz_t): Likewise.
(check_dimension): Fix comment on checks applied to array section
and clean up associated logic.

gcc/testsuite/ChangeLog:

PR fortran/108527
* gfortran.dg/pr108527.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit 22afa4947584c701633a79fd8750c9ceeaa96711)

[Bug tree-optimization/108677] wrong vectorization (when copy constructor is present?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|wrong-code  |missed-optimization

--- Comment #1 from Andrew Pinski  ---
>gcc vectorize the loop even if a dependency is present...[1]

What dependency? TrigArr cannot point to tp.

Also it is just doing just doing SLP, the vectorization is fine here even.
It is only doing basic block form.


IR:

  _2 = jp_31 + 4294967295;
  _3 = (long unsigned int) _2;
  _4 = _3 * 16;
  _5 = TrigArr.0_1 + _4;
  vect__22.19_48 = MEM  [(double *)_5];
  vect__22.23_43 = VEC_PERM_EXPR ;
  vect__20.15_54 = MEM  [(double *)tp_14(D)];
  vect__20.16_53 = VEC_PERM_EXPR ;
  vect__20.27_38 = VEC_PERM_EXPR ;
  vect__27.28_37 = vect__20.27_38 * vect__22.23_43;
  vect__57.29_36 = .VEC_FMADDSUB (vect__20.16_53, vect__22.19_48,
vect__27.28_37);
  _7 = (long unsigned int) jp_31;
  _8 = _7 * 16;
  _9 = TrigArr.0_1 + _8;
  MEM  [(double *)_9] = vect__57.29_36;

_5 is [jp-1], _9 is [jp]

This looks fine to me.

As not doing SLP without the copy constructor, it seems like the IR changes and
forced the load from tp_14 outside of the loop which caused SLP not do to the
load there ...

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Brecht Sanders  
---
I would love to give it a go if only I knew where to add the support.

I actually got a Windows on ARM device hoping I could figure it out, bit it
looks I will need tome help.

The "Unknown tune used in --with-tune=generic" error is where I'm currently
stuck, and I couldn't figure out in which file(s) I need to address this.

[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |13.0
 CC||marxin at gcc dot gnu.org
Summary|ice in modify_call, at  |[13 Regression] ice in
   |ipa-param-manipulation.cc:6 |modify_call, at
   |56  |ipa-param-manipulation.cc:6
   ||56
  Component|c   |ipa

[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|13.0|10.5

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/108529] [10/11/12 Regression] ICE in transformational_result, at fortran/simplify.cc:478

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/108529] [10/11/12 Regression] ICE in transformational_result, at fortran/simplify.cc:478

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11198-gb66a0f2fecb4dc1ac5960ff5d630ab8f672b4106
Author: Harald Anlauf 
Date:   Tue Jan 24 21:39:43 2023 +0100

Fortran: ICE in transformational_result [PR108529]

gcc/fortran/ChangeLog:

PR fortran/108529
* simplify.c (simplify_transformation): Do not try to simplify
transformational intrinsic when the ARRAY argument has a NULL
shape.

gcc/testsuite/ChangeLog:

PR fortran/108529
* gfortran.dg/pr108529.f90: New test.

(cherry picked from commit 6c96382eed96a9285611f2e3e2e59557094172b8)

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11197-gb523b58690c84b04cc9695d2d652611beb6f28ca
Author: Harald Anlauf 
Date:   Thu Jul 14 22:24:55 2022 +0200

Fortran: error recovery for bad initializers of implied-shape arrays
[PR106209]

gcc/fortran/ChangeLog:

PR fortran/106209
* decl.c (add_init_expr_to_sym): Handle bad initializers for
implied-shape arrays.

gcc/testsuite/ChangeLog:

PR fortran/106209
* gfortran.dg/pr106209.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit 748f8a8b145dde59c7b63aa68b5a59515b7efc49)

[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:068fce9743ec9f3181c189cb8d03a982ca30eb7e

commit r10-11194-g068fce9743ec9f3181c189cb8d03a982ca30eb7e
Author: Harald Anlauf 
Date:   Mon Jan 16 21:30:56 2023 +0100

Fortran: fix ICE in get_expr_storage_size [PR108421]

gcc/fortran/ChangeLog:

PR fortran/108421
* interface.c (get_expr_storage_size): Check that we actually have
an integer value before trying to extract it with mpz_get_si.

gcc/testsuite/ChangeLog:

PR fortran/108421
* gfortran.dg/pr108421.f90: New test.

(cherry picked from commit a75760374ee54768e5fd6a27080698bfbbd041ab)

[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11196-gd4bb7751af090736fb4a3bd7278d7094f35e02e4
Author: Harald Anlauf 
Date:   Mon Jan 23 21:19:03 2023 +0100

Fortran: avoid ICE on invalid array subscript triplets [PR108501]

gcc/fortran/ChangeLog:

PR fortran/108501
* interface.c (get_expr_storage_size): Check array subscript
triplets
that we actually have integer values before trying to extract with
mpz_get_si.

gcc/testsuite/ChangeLog:

PR fortran/108501
* gfortran.dg/pr108501.f90: New test.

(cherry picked from commit 771d793df1622a476e1cf8d05f0a6aee350fa56b)

[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295

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

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

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

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

commit r10-11195-gc67d76171e87d3ce364400684a654712047058b1
Author: Harald Anlauf 
Date:   Mon Jan 23 22:13:44 2023 +0100

Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]

gcc/fortran/ChangeLog:

PR fortran/108502
* dependency.c (gfc_check_dependency): Prevent NULL pointer
dereference while recursively checking expressions.

gcc/testsuite/ChangeLog:

PR fortran/108502
* gfortran.dg/pr108502.f90: New test.

(cherry picked from commit 51767f31878a95161142254dca7119b409699670)

[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11193-gb14dcf0c99fab065e11ec87984475580b649edeb
Author: Harald Anlauf 
Date:   Mon Jan 16 21:41:09 2023 +0100

Fortran: fix ICE in check_charlen_present [PR108420]

gcc/fortran/ChangeLog:

PR fortran/108420
* iresolve.c (check_charlen_present): Preserve character length if
there is no array constructor.

gcc/testsuite/ChangeLog:

PR fortran/108420
* gfortran.dg/pr108420.f90: New test.

(cherry picked from commit e6669c0a50ed8aee9e5997d61e6271668d149218)

[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:841e585ad936624f2d080512a9f6244b49e71969

commit r10-11192-g841e585ad936624f2d080512a9f6244b49e71969
Author: Harald Anlauf 
Date:   Sat Jan 28 17:59:23 2023 +0100

Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]

gcc/fortran/ChangeLog:

PR fortran/108453
* match.c (gfc_match_common): A USE associated name shall not
appear
in a COMMON block (F2018:C8121).

gcc/testsuite/ChangeLog:

PR fortran/108453
* gfortran.dg/common_27.f90: New test.

(cherry picked from commit aba9ff8f30d4245294ea2583de1dc28f1c7ccf7b)

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

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

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

--- Comment #1 from Andrew Pinski  ---
I have not seen anyone step up to patch GCC for aarch64-mingw yet.
Most aarch64 developers don't use Windows at all. There is some support being
worked on for aarch64 darwin (Mac OS) though.

[pushed] doc: Remove note on PW32

[Gerald Pfeifer]

Indeed looking at http://pw32.sourceforge.net indicates this has gone the 
way of the dodo.

Pushed.

Gerald


gcc/ChangeLog:

* doc/install.texi (Specific): Remove PW32.
---
 gcc/doc/install.texi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index b1861a6a437..8ef5c1414da 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -5182,9 +5182,6 @@ support the Interix subsystem.  See above.
 
 Old target names including *-*-winnt and *-*-windowsnt are no longer used.
 
-PW32 (i386-pc-pw32) support was never completed, and the project seems to
-be inactive.  See @uref{http://pw32.sourceforge.net/} for more information.
-
 UWIN support has been removed due to a lack of maintenance.
 
 @html
-- 
2.39.1

[pushed] wwwdocs: mirrors: Remove ftp.uvsq.fr mirror

[Gerald Pfeifer]

ftp.uvsq.fr has been unreachable for an extensive period of time
(tested from different networks).

Thank you for your service in the past, ftpma...@uvsq.fr!

Gerald
---
 htdocs/mirrors.html | 1 -
 1 file changed, 1 deletion(-)

diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html
index 963fc7c3..b49aa76c 100644
--- a/htdocs/mirrors.html
+++ b/htdocs/mirrors.html
@@ -19,7 +19,6 @@ mirrors.  The following sites mirror the gcc.gnu.org 
download site
 
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/;>ftp.lip6.fr, thanks to 
ftpma...@lip6.fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/;>ftp.irisa.fr, thanks 
to ftpma...@irisa.fr
-France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/;>ftp.uvsq.fr, 
thanks to ftpma...@uvsq.fr
 Germany, Berlin: https://ftp.fu-berlin.de/unix/languages/gcc/;>ftp.fu-berlin.de, 
thanks to f...@fu-berlin.de
 Germany: https://ftp.gwdg.de/pub/misc/gcc/;>ftp.gwdg.de, 
thanks to f...@gwdg.de
 Germany: https://ftp.mpi-inf.mpg.de/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/;>mpi-sb.mpg.de,
 thanks to ftpad...@mpi-sb.mpg.de
-- 
2.39.1

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87334
 Target||Aarch64-mingw

Re: libquadmath fix for 94756 and 87204

[NightStrike via Gcc-patches]

Jakub, ping

On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> hello,
>
> could someone look at the patch attached please?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610392.html
>

[Bug c/108679] New: ice in modify_call, at ipa-param-manipulation.cc:656

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108679
   Summary: ice in modify_call, at ipa-param-manipulation.cc:656
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

struct S1 {
  signed f0;
};
struct S2 {
  struct S1 f2;
  short f8;
} g_18;
g_732, func_6_l_17;
static *func_12();
static func_6(struct S2 p_7) { func_12(func_6_l_17, p_7.f2, g_18, 0); }
*func_12(int, struct S1 p_14) {
  safe_lshift_func_int16_t_s_u();
  safe_unary_minus_func_uint64_t_u();
  g_732 = safe_mul_func_uint8_t_u_u(0, p_14);
}
main() {
  struct S2 l_10 = {3};
  func_6(l_10);
}

compiled by recent gcc, does this:

$ /home/dcb36/gcc/results/bin/gcc -w -O2 -ftrivial-auto-var-init=zero bug881.c 
during IPA pass: inline
bug881.c: In function ‘main’:
bug881.c:18:3: internal compiler error: in modify_call, at
ipa-param-manipulation.cc:656
   18 |   func_6(l_10);
  |   ^~~~
0xb64d40 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
../../trunk.d1/gcc/ipa-param-manipulation.cc:656

The bug first seems to occur sometime between g:d0a3d55ae4a2656f
and g:1530a9b1f45a7ceb

[no subject]

[George Clapps via Gcc]

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

[Alejandro Colomar via Gcc]

Formatted version:

BUGS
   sockaddr_storage was designed back when strict aliasing wasn’t a  prob‐
   lem.  Back then, one would define a variable of that type, and then ac‐
   cess it as any of the other sockaddr_* types, depending on the value of
   the  first  member.   This is Undefined Behavior.  However, there is no
   way to use these APIs without invoking Unedfined  Behavior,  either  in
   the  user  program  or  in libc, so it is still recommended to use this
   method.  The only correct way to use  different  types  in  an  API  is
   through  a  union.   However, that union must be implemented in the li‐
   brary, since the type must be shared between the library and user code,
   so libc should be fixed by implementing sockaddr_storage as a union.
--

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

[Alejandro Colomar via Gcc]

As discussed before, and Bastien and I seem to agree, ideally we should
define the following types:

struct sockaddr_storage {
union {
struct {
sa_family_t  ss_family;
};
struct sockaddr_in   sin;
struct sockaddr_in6  sin6;
struct sockaddr_un   sun;
// ...
};
};

struct [[deprecated]] sockaddr {
sa_family_t  sa_family;
};

union [[gnu::transparent_union]] sockaddr_ptr {
struct sockaddr_storage  *ss;
struct sockaddr  *sa;
};

And then we could define APIs like:

int bind(int sockfd, const union sockaddr_ptr *addr, socklen_t len);

Link: 

Link: 

Cc: GCC 
Cc: glibc 
Cc: Bastien Roucariès 
Cc: Stefan Puiu 
Cc: Igor Sysoev 
Cc: Rich Felker 
Cc: Andrew Clayton 
Cc: Richard Biener 
Cc: Zack Weinberg 
Cc: Florian Weimer 
Cc: Joseph Myers 
Cc: Jakub Jelinek 
Cc: Eric Blake 
Signed-off-by: Alejandro Colomar 
---
 man3type/sockaddr.3type | 20 
 1 file changed, 20 insertions(+)

diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type
index 319a5e552..239e836fc 100644
--- a/man3type/sockaddr.3type
+++ b/man3type/sockaddr.3type
@@ -120,6 +120,26 @@ .SH NOTES
 .I 
 and
 .IR  .
+.SH BUGS
+.I sockaddr_storage
+was designed back when strict aliasing wasn't a problem.
+Back then,
+one would define a variable of that type,
+and then access it as any of the other
+.IR sockaddr_ *
+types,
+depending on the value of the first member.
+This is Undefined Behavior.
+However, there is no way to use these APIs without invoking Unedfined Behavior,
+either in the user program or in libc,
+so it is still recommended to use this method.
+The only correct way to use different types in an API is through a union.
+However,
+that union must be implemented in the library,
+since the type must be shared between the library and user code,
+so libc should be fixed by implementing
+.I sockaddr_storage
+as a union.
 .SH SEE ALSO
 .BR accept (2),
 .BR bind (2),
-- 
2.39.1

Re: [PATCH] c++: equivalence of non-dependent calls [PR107461]

[Patrick Palka via Gcc-patches]

On Sat, 4 Feb 2023, Jason Merrill wrote:

> On 2/4/23 20:41, Jason Merrill wrote:
> > On 2/4/23 20:08, Patrick Palka wrote:
> > > On Sat, 4 Feb 2023, Jason Merrill wrote:
> > > 
> > > > On 2/4/23 15:31, Patrick Palka wrote:
> > > > > After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
> > > > > CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of
> > > > > FUNCTION_DECL.
> > > > > This innocent change revealed that cp_tree_equal doesn't first check
> > > > > dependentness of a CALL_EXPR before treating the callee as a dependent
> > > > > name, which manifests as us incorrectly accepting the first two
> > > > > testcases below and rejecting the third:
> > > > > 
> > > > >    * In the first testcase, cp_tree_equal incorrectly returns true for
> > > > >  the two non-dependent CALL_EXPRs f(0) and f(0) (whose
> > > > > CALL_EXPR_FN
> > > > >  are different FUNCTION_DECLs) and so we treat #2 as a
> > > > > redeclaration
> > > > >  of #1.
> > > > > 
> > > > >    * Same issue in the second testcase, for f() and f().
> > > > > 
> > > > >    * In the third testcase, cp_tree_equal incorrectly returns true for
> > > > >  f() and f() which causes us to conflate the
> > > > > two
> > > > >  dependent specializations A()(U()))> and
> > > > >  A()(U()))>, leading to a bogus error.
> > > > > 
> > > > > This patch fixes this by making called_fns_equal treat two callees as
> > > > > dependent names only if the CALL_EXPRs in question are dependent.
> > > > > 
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > > for
> > > > > trunk/12?  Patch generated with -w to ignore noisy whitespace changes.
> > > > > 
> > > > > PR c++/107461
> > > > > 
> > > > > gcc/cp/ChangeLog:
> > > > > 
> > > > > * pt.cc (iterative_hash_template_arg) : Treat
> > > > > the callee as a dependent name only if the CALL_EXPR is
> > > > > dependent.
> > > > > * tree.cc (called_fns_equal): Take two CALL_EXPRs instead of
> > > > > CALL_EXPR_FNs thereof.  As above.
> > > > > (cp_tree_equal) : Adjust call to called_fns_equal.
> > > > > 
> > > > > gcc/testsuite/ChangeLog:
> > > > > 
> > > > > * g++.dg/cpp0x/overload5.C: New test.
> > > > > * g++.dg/cpp0x/overload5a.C: New test.
> > > > > * g++.dg/cpp0x/overload6.C: New test.
> > > > > ---
> > > > >    gcc/cp/pt.cc    |  1 +
> > > > >    gcc/cp/tree.cc  | 33
> > > > > ++---
> > > > >    gcc/testsuite/g++.dg/cpp0x/overload5.C  | 12 +
> > > > >    gcc/testsuite/g++.dg/cpp0x/overload5a.C | 10 
> > > > >    gcc/testsuite/g++.dg/cpp0x/overload6.C  | 16 
> > > > >    5 files changed, 58 insertions(+), 14 deletions(-)
> > > > >    create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload5.C
> > > > >    create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload5a.C
> > > > >    create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload6.C
> > > > > 
> > > > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > > > > index 255332dc0c1..c9360240cd2 100644
> > > > > --- a/gcc/cp/pt.cc
> > > > > +++ b/gcc/cp/pt.cc
> > > > > @@ -1841,6 +1841,7 @@ iterative_hash_template_arg (tree arg, hashval_t
> > > > > val)
> > > > >    case CALL_EXPR:
> > > > >  {
> > > > >    tree fn = CALL_EXPR_FN (arg);
> > > > > +    if (TREE_TYPE (arg) == NULL_TREE)
> > > > 
> > > > How about changing dependent_name to take the CALL_EXPR rather than the
> > > > CALL_EXPR_FN?  That would mean some changes to write_expression to move
> > > > the
> > > > dependent_name handling into the CALL_EXPR handling, but that doesn't
> > > > seem
> > > > like a bad thing.  Other callers seem like a trivial change.
> > > 
> > > Indeed changing dependent_name seems best, but I'm worried about such a
> > > refactoring to write_expression causing unintended mangling changes at
> > > this stage.  Because it seems the CALL_EXPR case of write_expression
> > > isn't the user of the dependent_name branch of write_expression, at
> > > least according to the following patch which causes us to ICE on
> > > mangle{37,57,58,76}.C:
> > 
> > Yeah, I tried the same thing.  Maybe for GCC 13 better to add a new function
> > rather than change the current one.

Sounds good, like so?  Only regtested so far.  Full bootstrap and
regtest running on x86_64-pc-linux-gnu.

-- >8 --

Subject: [PATCH] c++: equivalence of non-dependent calls [PR107461]

After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependentness of a CALL_EXPR before treating a FUNCTION_DECL callee as a
dependent name, which manifests as us incorrectly accepting the first
two testcases below and rejecting the third:

 * In the first testcase, cp_tree_equal incorrectly returns true for
   the two non-dependent CALL_EXPRs f(0) and f(0) (whose 

[Bug c/108678] New: Windows on ARM64 platform target aarch64-w64-mingw32

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 108678
   Summary: Windows on ARM64 platform target aarch64-w64-mingw32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

Are there plans to support Windows (using MinGW-w64) on ARM64?

The triplet for this platform should be: aarch64-w64-mingw32

I'm trying to build natively on a Windows on ARM device (bootstrapping from
LLVM/CLang).

Since binutils 2.40 there some support for aarch64 COFF/PE format, and I
already built a working binutils with the following supported targets:

ld --help|sed -n "s/^.*supported targets: //p"
pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386
elf32-iamcu pdb elf64-little elf64-big elf32-little elf32-big pe-bigobj-i386
pe-aarch64-little pei-aarch64-little srec symbolsrec verilog tekhex binary ihex
plugin

So it looks like pe-aarch64-little and pei-aarch64-little are listed.

I'm don't know if a pe-bigobj-aarch64-little is needed or if it will be
supported in the future.

My first attempt to get gcc (I tried with source tarball 12.2.0) to configure
was changing the following line in gcc/config.gcc:

i[34567]86-*-mingw* | x86_64-*-mingw*)

to:

i[34567]86-*-mingw* | x86_64-*-mingw* | aarch64-*-mingw*)

but then I get the following error:

Unknown tune used in --with-tune=generic

What needs to be changed to get past that?

[Bug tree-optimization/108677] New: wrong vectorization (when copy constructor is present?)

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

Bug ID: 108677
   Summary: wrong vectorization (when copy constructor is
present?)
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

in this real life code

#include

struct trig_pair {
   double CosPhi;
   double SinPhi;

   trig_pair() : CosPhi(1.), SinPhi(0.) {}
   trig_pair(const trig_pair ) : CosPhi(tp.CosPhi), SinPhi(tp.SinPhi) {}
   trig_pair(const double C, const double S) : CosPhi(C), SinPhi(S) {}
   trig_pair(const double phi) : CosPhi(cos(phi)), SinPhi(sin(phi)) {}

   //Return trig_pair fo angle increased by angle of tp.
   trig_pair Add(const trig_pair ) {
  return trig_pair(this->CosPhi*tp.CosPhi - this->SinPhi*tp.SinPhi,
   this->SinPhi*tp.CosPhi + this->CosPhi*tp.SinPhi);
   }
};

trig_pair *TrigArr;

void FillTrigArr(trig_pair tp, unsigned MaxM)
{
//Fill TrigArr with trig_pair(jp*phi)
   if (!TrigArr) return;;
   TrigArr[1] = tp;
   for (unsigned jp = 2; jp <= MaxM; ++jp) TrigArr[jp] = TrigArr[jp-1].Add(tp);
}


gcc vectorize the loop even if a dependency is present...[1]
It will not if I comment out the copy contructor...[2]


[1]
https://godbolt.org/z/vhPeh35n5

[2]
https://godbolt.org/z/YPjdYdqG8

[Bug c++/108676] template parameters are misprinted in function signature

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ivan Sorokin  ---
I added a broken link to godbolt, here is a valid one:
https://godbolt.org/z/EE5eezW1r

[Bug c++/108676] New: GCC prints function signature incorrectly

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 108676
   Summary: GCC prints function signature incorrectly
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider this code:

template 
struct X
{};

template 
X f();

template 
X g();

int main()
{
g();
}

On GCC 12.2 it gives this error message:

:13:12: error: no matching function for call to 'g()'
   13 | g();
  | ~~~^~
:9:7: note: candidate: 'template X g()'
9 | X g();
  |   ^

Please note that the return type of 'g' is printed incorrectly. It should say
'X' instead of 'X'.

https://godbolt.org/z/EeWoo16M

Re: _Optional: a type qualifier to indicate pointer nullability

[Jonathan Wakely via Gcc]

On Sun, 5 Feb 2023, 08:07 Christopher Bazley,  wrote:

>
>
> On Sat, 4 Feb 2023 at 23:53, Jonathan Wakely 
> wrote:
>
>>
>>
>> On Sat, 4 Feb 2023, 21:23 Christopher Bazley,  wrote:
>>
>>>
>>>
>>> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely 
>>> wrote:
>>>

 On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, 
 wrote:

>
> Does the lack of support for Clang's nullability qualifiers in GCC
> indicate
> a greater likelihood for my proposed feature to be accepted into GCC?


 No, I don't think so. I think it would be better to support the same
 qualifiers as Clang, not diverge in this way.

>>>
>>> Clang’s _Nullable qualifier is broken and pretty useless (even according
>>> to the code owner), so good luck with that.
>>>
>>
>> But marking pointer arguments as non-null is already supported in GCC
>> (with an attribute on the function, not the argument). Supporting a nonnull
>> attribute on individual arguments seems useful to me. Far more than marking
>> pointers as maybe-null, which is already true for all pointers.
>>
>
> Sorry, but I get the feeling that you didn’t read my article. If you could
> spare the time, it would help you to understand where I’m coming from.
>

I read it. All. Even though it's very long. And the summary post. And I
skimmed the WG14 proposal when that was sent to WG14. And the LLVM
discourse thread. I just don't agree with your position on it.

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Björn Schäpers]

Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:

On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
 wrote:



From: Ian Lance Taylor 
Date: Tue, 24 Jan 2023 09:58:10 -0800
Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org

I'd rather that the patch look like the appended.  Can someone with a
Windows system test to see what that builds and passes the tests?


ENOPATCH


Gah.

Ian

That seems to be my original patch, right? That one I have tested (and 
am actually using) on x86 and x64 windows.

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Björn Schäpers]

Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:

On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
 wrote:



From: Ian Lance Taylor 
Date: Tue, 24 Jan 2023 09:58:10 -0800
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org

I'd rather that the patch look like the appended.  Can someone with a
Windows system test to see what that builds and passes the tests?


ENOPATCH


Gah.

Ian

That seems to be my original patch, right? That one I have tested (and 
am actually using) on x86 and x64 windows.

Re: _Optional: a type qualifier to indicate pointer nullability

[Christopher Bazley via Gcc]

On Sat, 4 Feb 2023 at 23:53, Jonathan Wakely  wrote:

>
>
> On Sat, 4 Feb 2023, 21:23 Christopher Bazley,  wrote:
>
>>
>>
>> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely 
>> wrote:
>>
>>>
>>> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, 
>>> wrote:
>>>

 Does the lack of support for Clang's nullability qualifiers in GCC
 indicate
 a greater likelihood for my proposed feature to be accepted into GCC?
>>>
>>>
>>> No, I don't think so. I think it would be better to support the same
>>> qualifiers as Clang, not diverge in this way.
>>>
>>
>> Clang’s _Nullable qualifier is broken and pretty useless (even according
>> to the code owner), so good luck with that.
>>
>
> But marking pointer arguments as non-null is already supported in GCC
> (with an attribute on the function, not the argument). Supporting a nonnull
> attribute on individual arguments seems useful to me. Far more than marking
> pointers as maybe-null, which is already true for all pointers.
>

Sorry, but I get the feeling that you didn’t read my article. If you could
spare the time, it would help you to understand where I’m coming from.
Saying “it’s already true that all pointers can be null [therefore there’s
no need for ‘_Optional’ in the type system]” is as facile as saying “it’s
already true that all values in Python can be None”.

I’d sooner trust Guido van Rossum on this question than Bjarne Stroustrup,
since the former actually *likes* C and uses it, whereas the latter
describes C as a perverse mess (and certainly doesn’t use it).
-- 
Christopher Bazley