[Bug target/97194] optimize vector element set/extract at variable position

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> So for set with T == int and N == 32 we could generate
> 
> vmovd   %edi, %xmm1
> vpbroadcastd%xmm1, %ymm1
> vpcmpeqd.LC0(%rip), %ymm1, %ymm2
> vpblendvb   %ymm2, %ymm1, %ymm0, %ymm0
> ret
> 
> .LC0:
> .long   0
> .long   1
> .long   2
> .long   3
> .long   4
> .long   5
> .long   6
> .long   7
> 
> aka, with GCC generic vectors
> 
> V setg (V v, int idx, T val)
> {
>   V valv = (V){idx, idx, idx, idx, idx, idx, idx, idx};
>   V mask = ((V){0, 1, 2, 3, 4, 5, 6, 7} == valv);
>   v = (v & ~mask) | (valv & mask);
>   return v;
> }

Botched this up, corrected is

V setg (V v, int idx, T val)
{
  V idxv = (V){idx, idx, idx, idx, idx, idx, idx, idx};
  V valv = (V){val, val, val, val, val, val, val, val};
  V mask = ((V){0, 1, 2, 3, 4, 5, 6, 7} == idxv);
  v = (v & ~mask) | (valv & mask);
  return v;
}

which produces

vmovd   %edi, %xmm1
vmovd   %esi, %xmm2
vpbroadcastd%xmm1, %ymm1
vpbroadcastd%xmm2, %ymm2
vpcmpeqd.LC0(%rip), %ymm1, %ymm1
vpblendvb   %ymm1, %ymm2, %ymm0, %ymm0

with AVX2, so one more vmovd/vpbroadcastd (as expected).  With -mavx512vl
this even becomes

vpbroadcastd%edi, %ymm1
vpcmpd  $0, .LC0(%rip), %ymm1, %k1
vpbroadcastd%esi, %ymm0{%k1}

for the extract case we really need to compute a variable permute mask
which looks harder and possibly more expensive than the spill/load,
so the set case looks more important to tackle (tackling it will still
eventually improve initial RTL generation by avoiding stack assignments
for locals)

> There's ongoing patch iteration on the ml adding variable index vec_set
> expanders for powerpc (and the related middle-end changes).  The question
> is whether optabs can try many things or the target should have the choice
> (probably better).
> 
> Eventually there's a more efficient way to generate {0, 1, 2, 3...}.

[Bug c++/97198] New: __is_constructible(int[], int) should return true

[kariya_mitsuru at hotmail dot com via Gcc-bugs]

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

Bug ID: 97198
   Summary: __is_constructible(int[], int) should return true
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com
  Target Milestone: ---

The sample code below returns 0 if it is compiled by GCC HEAD with c++2a mode
but I think that it should return 1.

 sample code 
int main()
{
return __is_constructible(int[], int);
}
 sample code 
cf. https://wandbox.org/permlink/nFQtqfxDNJPZRhZt


The C++20 DIS 20.15.4.3 Type properties[meta.unary.prop] p.8 says,

The predicate condition for a template specialization is_constructible shall be satisfied if and only if the following variable definition
would be well-formed for some invented variable t:

T t(declval()...);

...

cf. https://timsong-cpp.github.io/cppwp/n4861/meta#unary.prop-8


If T = int[] and Args = int, it is well-formed.

 sample code 
int main()
{
using T = int[];
T t(42);
}
 sample code 
cf. https://wandbox.org/permlink/2MhF1PNUbgq7mNAC

So, I think that __is_constructible(int[], int) should return true even though
int[] is imcomplete type. (unless it is a defect of the C++20 DIS)


Related PR:

PR94149 __is_constructible doesn't know about C++20 parenthesized init for
arrays
PR90532 [8/9/10 Regression] is_constructible_v and
is_default_constructible_v should agree

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Hongtao.liu  ---
> Still I don't understand why compiler does not compare the cost of full loop
> body after combining to the cost before combining and does not come to
> conclusion that combining increased the cost.

As Richard says, GCC does not model CPU pipelines in such detail.

[Bug bootstrap/97183] zstd build failure for gcc 10 on Ubuntu 16.04

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

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

--- Comment #3 from Jim Wilson  ---
I installed Ubuntu 16.04 on an old laptop so I can directly reproduce the build
failure.

Checking for the zstd version looks like the easier patch.

Checking for specific macros and functions might be better, but what do we do
with the info?  I'm not familiar with zstd or the lto-compress.c code, and it
doesn't look like we can easily change it to not use certain macros/functions
when they don't exist.  Checking for half a dozen macros/functions and
disabling all of the code if one or more is missing seems silly.  Though
looking at this, as Kito pointed out, it appears that
ZSTD_getFrameContentSize() is the most recently added function that we are
using, so maybe we only need to check for that one.  That was added in version
1.3.0.  Or we can check for the 1.3.0 version which seems simpler.  I do know
that version 1.3.3 of zstd works as this is what Ubuntu 18.04 has.  I haven't
tried the versions 1.3.[012].

[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible

[bugdal at aerifal dot cx via Gcc-bugs]

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

--- Comment #7 from Rich Felker  ---
Indeed, the direct clock_gettime syscall stuff is just unnecessary on any
modern system, certainly any time64 one. I read the patch briefly and I don't
see anywhere it would break anything, but it also wouldn't produce a useful
Y2038-ready configuration, so I don't think it makes sense. Configure or
source-level assertions should just ensure that, if time_t is larger than long
and there's a distinct time64 syscall, the direct syscall is never used.

[Bug tree-optimization/97188] [11 Regression] ICE in c_tree_printer at c/c-objc-common.c:314 since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554784.html

[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible

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

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

--- Comment #6 from Jonathan Wakely  ---
On second thoughts, we probably don't need to worry about
SYS_clock_gettime_time64. We only use SYS_clock_gettime syscalls on old glibc
systems where clock_gettime is in librt not libc, and those systems aren't
going to get updated with the time64 version.

[Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex

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

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

--- Comment #5 from Jim Wilson  ---
I see that a riscv64-linux libgomp.so has mutex calls and no obvious futex
calls.  Though I find it a little curious that futex support isn't
auto-detected.  There is already config/futex.m4 to detect futex support, and
libstdc++ is using it.  So yes, we are missing riscv*-linux futex support in
libgomp.

[Bug tree-optimization/97190] [11 Regression] ICE in get_location_from_adhoc_loc at libcpp/line-map.c:257 since r11-2928-gd14c547abd484d35

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Martin Sebor  ---
I can't reproduce the ICE with today's top of trunk.  It looks like a duplicate
of pr97175 that I fixed yesterday.

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

[Bug middle-end/97175] [11 Regression] ICE in maybe_warn_for_bound, at builtins.c:3483 since r11-2928-gd14c547abd484d35

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

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

--- Comment #8 from Martin Sebor  ---
*** Bug 97190 has been marked as a duplicate of this bug. ***

[Bug gcov-profile/97193] .gcno files are not written to same directory as the object file

[mario at klebsch dot de via Gcc-bugs]

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

--- Comment #3 from Mario Klebsch  ---
If it was a desired change, what were the reasons for this change?

This change breaks my makefiles. I am cross compiling for several different
targets possibly using a different version of gcc for each target. The build is
always performed in the source directory, writing the object files to different
directories for each target.

Now, the .gcno files of different build are all in the same directory. The
clean target of the makefile leaves these files around and they are not
archived as build products. They have horribly long file names littering my
source directory. These long file names make ls output unreadable.

I am sure, there was a good reason for this change, but for me it does not feel
like a good idea. :-(

Is there an option to select a different directory for these .gcno-files?

73, Mario

[Bug c++/94485] Inter-dependency between { tree-sra, ABI, inlining, loop-unrolling } leads to mis-optimization

[dimitri.gorokhovik at free dot fr via Gcc-bugs]

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

--- Comment #8 from Dimitri Gorokhovik  ---
I was able to reduce same code (see the attached file bug-6.cpp).

-- when compiled correctly, running it produces the following (expected)
output:

cube: ({ 0, 0, 0 }, { 1, 1, 1 }) 
cube: ({ 0, 0, 1 }, { 1, 1, 2 }) 
cube: ({ 0, 0, 2 }, { 1, 1, 3 }) 
cube: ({ 0, 1, 0 }, { 1, 2, 1 }) 
cube: ({ 0, 1, 1 }, { 1, 2, 2 }) 
cube: ({ 0, 1, 2 }, { 1, 2, 3 }) 
cube: ({ 0, 2, 0 }, { 1, 3, 1 }) 
cube: ({ 0, 2, 1 }, { 1, 3, 2 }) 
cube: ({ 0, 2, 2 }, { 1, 3, 3 }) 
cube: ({ 1, 0, 0 }, { 2, 1, 1 }) 
cube: ({ 1, 0, 1 }, { 2, 1, 2 }) 
cube: ({ 1, 0, 2 }, { 2, 1, 3 }) 
cube: ({ 1, 1, 0 }, { 2, 2, 1 }) 
cube: ({ 1, 1, 1 }, { 2, 2, 2 }) 
cube: ({ 1, 1, 2 }, { 2, 2, 3 }) 
cube: ({ 1, 2, 0 }, { 2, 3, 1 }) 
cube: ({ 1, 2, 1 }, { 2, 3, 2 }) 
cube: ({ 1, 2, 2 }, { 2, 3, 3 }) 
cube: ({ 2, 0, 0 }, { 3, 1, 1 }) 
cube: ({ 2, 0, 1 }, { 3, 1, 2 }) 
cube: ({ 2, 0, 2 }, { 3, 1, 3 }) 
cube: ({ 2, 1, 0 }, { 3, 2, 1 }) 
cube: ({ 2, 1, 1 }, { 3, 2, 2 }) 
cube: ({ 2, 1, 2 }, { 3, 2, 3 }) 
cube: ({ 2, 2, 0 }, { 3, 3, 1 }) 
cube: ({ 2, 2, 1 }, { 3, 3, 2 }) 
cube: ({ 2, 2, 2 }, { 3, 3, 3 }) 
count = 27

-- when compiled incorrectly, it prints out:

count = 0

Tested with build g++ (GCC) 11.0.0 20200924 (experimental).


In order to compile and run:

g++ -std=c++17 -O3 -o bug-6 bug-6.cpp && ./bug-6

This builds for implicit '-m64' (x86_64) and produces invalid output. 

To get valid output, compile with either of the following:
-m32
-O0 (instead of -O3)
-fno-tree-sra
one of: -DFIX_0, -DFIX_1, -DFIX_2, -DFIX_3, -DFIX_4 


>From my limited understanding of tree dumps, here is what roughly happens:

-- the routine 'begin()', line 183, returns 'struct iterator' by value. The
latter has the size of 14 bytes so returned "in registers". Forcing it to be
returned via memory ==> issue goes away. (Methods to force: make bigger than 16
bytes, make some fields volatile, use -m32). Note also that, when the routine
is evaluated as constexpr (in static_assert), the issue is not reproduced.

-- all called routines (pretty much) are inlined inside one call, to
'count_them ()'. Prevent the inlining of the routine 'can_be_incremented ()'
==>  issue goes away. (Methods to prevent: define FIX_1.)

-- SRA replaces several fields of the 'struct iterator' (line 150), most
importantly 'idx_' (line 153). Disable SRA ==> issue goes away (-fno-tree-sra
or  -O0). 

This replacement by tree-SRA somehow doesn't propagate the writes to the
replacement vars of idx_to the original parts of the structure living "in the
return registers".  When the return value lives in memory, the writes are
propagated correctly.

The compiler then eliminates the loop in 'can_be_incremented' and evaluates the
call to that routine to 'false' (line 163). Forcibly keeping the loop (-DFIX_2)
or replacing it by non-loop code (-DFIX_0) ==> issue goes away.

[Bug c++/97059] C++20: compound requirement uses inconsistent return type (adds ref)

[dimitri.gorokhovik at free dot fr via Gcc-bugs]

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

--- Comment #2 from Dimitri Gorokhovik  ---
(In reply to Dimitri Gorokhovik from comment #1)
> I was able to reduce same code (attached file bug-6.cpp).

Please disregard the comment #1 -- posted to wrong bug.

[Bug c++/97059] C++20: compound requirement uses inconsistent return type (adds ref)

[dimitri.gorokhovik at free dot fr via Gcc-bugs]

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

--- Comment #1 from Dimitri Gorokhovik  ---
I was able to reduce same code (attached file bug-6.cpp).

-- when compiled correctly, running it produces the following (expected)
output:

cube: ({ 0, 0, 0 }, { 1, 1, 1 }) 
cube: ({ 0, 0, 1 }, { 1, 1, 2 }) 
cube: ({ 0, 0, 2 }, { 1, 1, 3 }) 
cube: ({ 0, 1, 0 }, { 1, 2, 1 }) 
cube: ({ 0, 1, 1 }, { 1, 2, 2 }) 
cube: ({ 0, 1, 2 }, { 1, 2, 3 }) 
cube: ({ 0, 2, 0 }, { 1, 3, 1 }) 
cube: ({ 0, 2, 1 }, { 1, 3, 2 }) 
cube: ({ 0, 2, 2 }, { 1, 3, 3 }) 
cube: ({ 1, 0, 0 }, { 2, 1, 1 }) 
cube: ({ 1, 0, 1 }, { 2, 1, 2 }) 
cube: ({ 1, 0, 2 }, { 2, 1, 3 }) 
cube: ({ 1, 1, 0 }, { 2, 2, 1 }) 
cube: ({ 1, 1, 1 }, { 2, 2, 2 }) 
cube: ({ 1, 1, 2 }, { 2, 2, 3 }) 
cube: ({ 1, 2, 0 }, { 2, 3, 1 }) 
cube: ({ 1, 2, 1 }, { 2, 3, 2 }) 
cube: ({ 1, 2, 2 }, { 2, 3, 3 }) 
cube: ({ 2, 0, 0 }, { 3, 1, 1 }) 
cube: ({ 2, 0, 1 }, { 3, 1, 2 }) 
cube: ({ 2, 0, 2 }, { 3, 1, 3 }) 
cube: ({ 2, 1, 0 }, { 3, 2, 1 }) 
cube: ({ 2, 1, 1 }, { 3, 2, 2 }) 
cube: ({ 2, 1, 2 }, { 3, 2, 3 }) 
cube: ({ 2, 2, 0 }, { 3, 3, 1 }) 
cube: ({ 2, 2, 1 }, { 3, 3, 2 }) 
cube: ({ 2, 2, 2 }, { 3, 3, 3 }) 
count = 27

-- when compiled incorrectly, it prints out:

count = 0

Tested with build g++ (GCC) 11.0.0 20200924 (experimental).


In order to compile and run:

g++ -std=c++17 -O3 -o bug-6 bug-6.cpp && ./bug-6

This builds for implicit '-m64' (x86_64) and produces invalid output. 

To get valid output, compile with either of the following:
-m32
-O0 (instead of -O3)
-fno-tree-sra
one of -DFIX_0 to -DFIX_4 


>From my limited understanding of tree dumps, here is what roughly happens:

-- the routine 'begin()', line 183, returns 'struct iterator' by value. The
latter has the size of 14 bytes so returned "in registers". Forcing it to be
returned via memory ==> issue goes away. (Methods to force: make bigger than 16
bytes, make volatile, use -m32). Note also that, when the routine is evaluated
as constexpr (in static_assert), the issue is not reproduced.

-- all called routines are inlined inside one call, to 'count_them'. Prevent
the inlining of the routine 'can_be_incremented ()' ==>  issue goes away.
(Methods to prevent: define FIX_1.)

-- SRA replaces several fields of the 'struct iterator' (line 150), notably,
'idx_' (line 153). Disable SRA ==> issue goes away (-fno-tree-sra or use -O0). 

This replacement by tree-SRA somehow doesn't propagate the writes to idx_, from
the replacement vars to the original part of the structure which lives "in the
return registers".  When the return value lives in memory, the writes are
propagated correctly.

The compiler then eliminates the loop in 'can_be_incremented' and evaluates the
call to that routine by 'false' (line 163). Forcibly keeping the loop (-DFIX_2)
or replacing it by non-loop code (-DFIX_0) ==> issue goes away.

[Bug c++/94485] [10.0.1, c++2a] g++ optimizes away necessary code, accepts arbitrary inline asm

[dimitri.gorokhovik at free dot fr via Gcc-bugs]

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

Dimitri Gorokhovik  changed:

   What|Removed |Added

  Attachment #48194|0   |1
is obsolete||

--- Comment #7 from Dimitri Gorokhovik  ---
Created attachment 49268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49268&action=edit
Testcase demonstrating the issue.

A more reduced testcase demonstrating the issue.

[Bug c++/97177] [11 Regression] ICE in dependent_type_p, at cp/pt.c:26475 since r11-3192-ge9fdb9a73249f95f

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Nathan Sidwell  ---
I think my fix for pr97171 fixed this too.  Adding the testcase though.

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

[Bug c++/97171] [11 Regression] ICE in symtab_node::get_for_asmname at gcc/symtab.c:1023 since r11-3192-ge9fdb9a73249f95f

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #5 from Nathan Sidwell  ---
*** Bug 97177 has been marked as a duplicate of this bug. ***

[Bug analyzer/97115] Support for pre-main ctors in -fanalyzer

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

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

--- Comment #1 from David Malcolm  ---
"Static Initialization Order Fiasco"
  https://en.cppreference.com/w/cpp/language/siof
  https://isocpp.org/wiki/faq/ctors#static-init-order

[Bug c++/97177] [11 Regression] ICE in dependent_type_p, at cp/pt.c:26475 since r11-3192-ge9fdb9a73249f95f

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
well, we're at least collecting interesting test cases :)

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-3442-gc1fc9f6e10e646f01194c8f150affbc1cfbc404a
Author: Antony Polukhin 
Date:   Thu Sep 24 18:51:37 2020 +0100

libstdc++: assert that type traits are not misused with incomplete types
[PR 71579]

libstdc++-v3/ChangeLog:

PR libstdc++/71579
* include/std/type_traits (invoke_result, is_invocable)
(is_invocable_r, is_nothrow_invocable, is_nothrow_invocable_r):
Add static_asserts to make sure that the arguments of the type
traits are not misused with incomplete types.
* testsuite/20_util/invoke_result/incomplete_args_neg.cc: New test.
* testsuite/20_util/is_invocable/incomplete_args_neg.cc: New test.
* testsuite/20_util/is_invocable/incomplete_neg.cc: New test.
* testsuite/20_util/is_nothrow_invocable/incomplete_args_neg.cc:
New test.
* testsuite/20_util/is_nothrow_invocable/incomplete_neg.cc: Check
for error on incomplete type usage in trait.

[Bug c++/86883] Unexpected error: expansion pattern '' contains no argument packs

[vopl at bk dot ru via Gcc-bugs]

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

vopl at bk dot ru changed:

   What|Removed |Added

 CC||vopl at bk dot ru

--- Comment #3 from vopl at bk dot ru ---
Probably caused by the same

$ cat test.cpp 
template struct Outer
{
template
struct Inner
{
static bool Member;
};
};

template
template
bool Outer::Inner::Member;

$ g++-10.2.0 test.cpp 
test.cpp:12:34: error: expansion pattern ‘Values0’ contains no parameter packs
   12 | bool Outer::Inner::Member;
  |  ^
test.cpp:12:6: error: too many template-parameter-lists
   12 | bool Outer::Inner::Member;
  |  ^~~

[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 11, GCC 10.3, GCC 9.4 and GCC 8.5.

[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:97c34eb5f57bb1d37f3feddefefa5f553bcea9fc

commit r8-10533-g97c34eb5f57bb1d37f3feddefefa5f553bcea9fc
Author: H.J. Lu 
Date:   Mon Sep 14 08:52:27 2020 -0700

rtl_data: Add sp_is_clobbered_by_asm

Add sp_is_clobbered_by_asm to rtl_data to inform backends that the stack
pointer is clobbered by asm statement.

gcc/

PR target/97032
* cfgexpand.c (expand_asm_stmt): Set sp_is_clobbered_by_asm to
true if the stack pointer is clobbered by asm statement.
* emit-rtl.h (rtl_data): Add sp_is_clobbered_by_asm.
* config/i386/i386.c (ix86_get_drap_rtx): Set need_drap to true
if the stack pointer is clobbered by asm statement.

gcc/testsuite/

PR target/97032
* gcc.target/i386/pr97032.c: New test.

(cherry picked from commit 453a20c65722719b9e2d84339f215e7ec87692dc)

[Bug tree-optimization/97188] [11 Regression] ICE in c_tree_printer at c/c-objc-common.c:314 since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Created attachment 49267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49267&action=edit
Proposed fix

Rich, does this work for musl?

As glibc hasn't updated its userspace timespec yet I have no way to test
whether this fixes the problem, because I don't have the problem.

Is inspecting __USE_TIME_BITS64 allowed with musl? The current proposal at 
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#API_design says users
can check if that's defined, although usually the __USE_xxx macros are not
meant for public consumption.

[Bug preprocessor/91412] Unexpectedly correct raw string literal

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

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

Nathan Sidwell  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
libcpp/lex.c (lex_raw_string)

  after_backslash:
if (note->type == ' ')
  /* GNU backslash whitespace newline extension.  FIXME
 could be any sequence of non-vertical space.  When we
 can properly restore any such sequence, we should
 mark this note as handled so _cpp_process_line_notes
 doesn't warn.  */
  accum.append (pfile, UC" ", 1);

[Bug middle-end/97175] [11 Regression] ICE in maybe_warn_for_bound, at builtins.c:3483 since r11-2928-gd14c547abd484d35

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---

Interesting.

$ fgrep DECL_SOURCE_LOCATION `find trunk/gcc -name \*.c -print | fgrep -v
/testsuite/` | wc -l
1002
$ fgrep EXPR_LOCATION `find trunk/gcc -name \*.c -print | fgrep -v /testsuite/`
| wc -l
588

So almost 1,600 edits to change every use of DECL_SOURCE_LOCATION and
EXPR_LOCATION to anything else.

So it looks like some of these awful macros are a lot of work to change.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[p.padavala at camlintechnologies dot com via Gcc-bugs]

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

Prasannanjaneyulu  changed:

   What|Removed |Added

 CC||p.padavala@camlintechnologi
   ||es.com

--- Comment #43 from Prasannanjaneyulu  ---
Looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 is similar. But
We could still see this issue on GCC 5.4.0 on ubuntu 16.04.12 with Gcov 5.4.0
and lcov 1.2. Is it something can't be fixed for lower GCC versions or is there
any possible workaround?

[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:3bec35d813cc706b3334bd0b0edbd51869b0f725

commit r9-8937-g3bec35d813cc706b3334bd0b0edbd51869b0f725
Author: H.J. Lu 
Date:   Mon Sep 14 08:52:27 2020 -0700

rtl_data: Add sp_is_clobbered_by_asm

Add sp_is_clobbered_by_asm to rtl_data to inform backends that the stack
pointer is clobbered by asm statement.

gcc/

PR target/97032
* cfgexpand.c (asm_clobber_reg_kind): Set sp_is_clobbered_by_asm
to true if the stack pointer is clobbered by asm statement.
* emit-rtl.h (rtl_data): Add sp_is_clobbered_by_asm.
* config/i386/i386.c (ix86_get_drap_rtx): Set need_drap to true
if the stack pointer is clobbered by asm statement.

gcc/testsuite/

PR target/97032
* gcc.target/i386/pr97032.c: New test.

(cherry picked from commit 453a20c65722719b9e2d84339f215e7ec87692dc)

[Bug middle-end/97175] [11 Regression] ICE in maybe_warn_for_bound, at builtins.c:3483 since r11-2928-gd14c547abd484d35

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

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

--- Comment #6 from Martin Sebor  ---
It definitely would be a step in the right direction.  But I'm not sure how
feasible it is to turn any of these tests into compile-time.  They often test
different bits in different structures.  For example, the location macros:

(gdb) info macro DECL_SOURCE_LOCATION
Defined at /src/gcc/master/gcc/tree.h:2437
  included at /src/gcc/master/gcc/builtins.c:30
#define DECL_SOURCE_LOCATION(NODE) (DECL_MINIMAL_CHECK
(NODE)->decl_minimal.locus)
(gdb) info macro EXPR_LOCATION
Defined at /src/gcc/master/gcc/tree.h:1176
  included at /src/gcc/master/gcc/builtins.c:30
#define EXPR_LOCATION(NODE) (CAN_HAVE_LOCATION_P ((NODE)) ? (NODE)->exp.locus :
UNKNOWN_LOCATION)

In GCC, everything is an instance of tree_node (pointed-to by the NODE argument
above), a union of a bunch of different data structures that represent the most
common elements of a program (like a declaration, a type, a constant, etc.). 
Except for a small common subset of leading members the structures have a
different layout, with the same thing (such as a location) sometimes being
represented by different sets of bits.  So decl_minimal.locus is at a different
offset from the beginning of tree_node than exp.locus.  Some of these bits may
even be beyond the end of the union (in sort of a "flexible array member.") 
The only way to tell what is what and where things are is to query bits in the
same position (typically the tree_code enum).

I suspect changing this basic structure would amount to essentially rewriting
the whole compiler.  What might be doable with much less effort, though, is
replacing all (or at least some of) these awful macros with more general inline
functions.  The location macros could be replaced (or supplanted) with:

  inline location_t get_location (cons_tree t)
  {
if (DECL_P (t))
  return DECL_SOURCE_LOCATION (t);
if (EXPR_P (t && EXPR_HAS_LOCATION (t))
  return EXPR_LOCATION (t);
return UNKNOWN_LOCATION;
  }

Some might argue that the function too should abort if t is neither a DECL nor
EXPR.  Others might object that using the function instead of either macro is
wasteful when the caller "knows" that they're working with one or the other. 
But it might be worth at least proposing it.

[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

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

commit r10-8796-gf0baed1fb6cd6ed7c7a3dce1f555d3f72b1575a5
Author: H.J. Lu 
Date:   Mon Sep 14 08:52:27 2020 -0700

rtl_data: Add sp_is_clobbered_by_asm

Add sp_is_clobbered_by_asm to rtl_data to inform backends that the stack
pointer is clobbered by asm statement.

gcc/

PR target/97032
* cfgexpand.c (asm_clobber_reg_kind): Set sp_is_clobbered_by_asm
to true if the stack pointer is clobbered by asm statement.
* emit-rtl.h (rtl_data): Add sp_is_clobbered_by_asm.
* config/i386/i386.c (ix86_get_drap_rtx): Set need_drap to true
if the stack pointer is clobbered by asm statement.

gcc/testsuite/

PR target/97032
* gcc.target/i386/pr97032.c: New test.

(cherry picked from commit 453a20c65722719b9e2d84339f215e7ec87692dc)

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

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

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

--- Comment #41 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:

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

commit r8-10532-ga8ec9cc2241f4e0c387e78f23bae0100c74de6a8
Author: Kyrylo Tkachov 
Date:   Tue Sep 3 08:40:30 2019 +

Add support for __jcvt intrinsic

This patch implements the __jcvt ACLE intrinsic [1] that maps down to the
FJCVTZS [2] instruction from Armv8.3-a.
No fancy mode iterators or nothing. Just a single builtin, UNSPEC and
define_insn and the associate plumbing.
This patch also defines __ARM_FEATURE_JCVT to indicate when the intrinsic
is available.

[1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics
[2]
https://developer.arm.com/docs/ddi0596/latest/simd-and-floating-point-instructions-alphabetic-order/fjcvtzs-floating-point-javascript-convert-to-signed-fixed-point-rounding-toward-zero

gcc/
PR target/71233
* config/aarch64/aarch64.md (UNSPEC_FJCVTZS): Define.
(aarch64_fjcvtzs): New define_insn.
* config/aarch64/aarch64.h (TARGET_JSCVT): Define.
* config/aarch64/aarch64-builtins.c (aarch64_builtins):
Add AARCH64_JSCVT.
(aarch64_init_builtins): Initialize __builtin_aarch64_jcvtzs.
(aarch64_expand_builtin): Handle AARCH64_JSCVT.
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_JCVT where appropriate.
* config/aarch64/arm_acle.h (__jcvt): Define.
* doc/sourcebuild.texi (aarch64_fjcvtzs_hw) Document new
target supports option.

gcc/testsuite/
PR target/71233
* gcc.target/aarch64/acle/jcvt_1.c: New test.
* gcc.target/aarch64/acle/jcvt_2.c: New testcase.
* lib/target-supports.exp
(check_effective_target_aarch64_fjcvtzs_hw): Add new check for
FJCVTZS hw.

Co-Authored-By: Andrea Corallo  

(cherry picked from commit e1d5d19ec4f84b67ac693fef5b2add7dc9cf056d)
(cherry picked from commit 2c62952f8160bdc8d4111edb34a4bc75096c1e05)
(cherry picked from commit d2b86e14c14020f3e119ab8f462e2a91bd7d46e5)
(cherry picked from commit 58ae77d3ba70a2b9ccc90a90f3f82cf46239d5f1)

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

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

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

--- Comment #40 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:

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

commit r9-8936-g6f06be1769d45359940c60517f9d55bedd3cb1f4
Author: Kyrylo Tkachov 
Date:   Tue Sep 3 08:40:30 2019 +

Add support for __jcvt intrinsic

This patch implements the __jcvt ACLE intrinsic [1] that maps down to the
FJCVTZS [2] instruction from Armv8.3-a.
No fancy mode iterators or nothing. Just a single builtin, UNSPEC and
define_insn and the associate plumbing.
This patch also defines __ARM_FEATURE_JCVT to indicate when the intrinsic
is available.

[1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics
[2]
https://developer.arm.com/docs/ddi0596/latest/simd-and-floating-point-instructions-alphabetic-order/fjcvtzs-floating-point-javascript-convert-to-signed-fixed-point-rounding-toward-zero

gcc/
PR target/71233
* config/aarch64/aarch64.md (UNSPEC_FJCVTZS): Define.
(aarch64_fjcvtzs): New define_insn.
* config/aarch64/aarch64.h (TARGET_JSCVT): Define.
* config/aarch64/aarch64-builtins.c (aarch64_builtins):
Add AARCH64_JSCVT.
(aarch64_init_builtins): Initialize __builtin_aarch64_jcvtzs.
(aarch64_expand_builtin): Handle AARCH64_JSCVT.
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_JCVT where appropriate.
* config/aarch64/arm_acle.h (__jcvt): Define.
* doc/sourcebuild.texi (aarch64_fjcvtzs_hw) Document new
target supports option.

gcc/testsuite/
PR target/71233
* gcc.target/aarch64/acle/jcvt_1.c: New test.
* gcc.target/aarch64/acle/jcvt_2.c: New testcase.
* lib/target-supports.exp
(check_effective_target_aarch64_fjcvtzs_hw): Add new check for
FJCVTZS hw.

Co-Authored-By: Andrea Corallo  

(cherry picked from commit e1d5d19ec4f84b67ac693fef5b2add7dc9cf056d)
(cherry picked from commit 2c62952f8160bdc8d4111edb34a4bc75096c1e05)
(cherry picked from commit d2b86e14c14020f3e119ab8f462e2a91bd7d46e5)

[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.

[p.padavala at camlintechnologies dot com via Gcc-bugs]

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

Prasannanjaneyulu  changed:

   What|Removed |Added

 CC||p.padavala@camlintechnologi
   ||es.com

--- Comment #16 from Prasannanjaneyulu  ---
I still see this problem in GCC 5.4.0. I am on ubuntu 16.04.12 with lcov
version 1.12 and gcov version is 5.4.0.

This is how it is compiling:

g++ -std=c++14 -DHAVE_CONFIG_H -I. -I..  -fprofile-arcs -ftest-coverage
-DGITVERSION=\"2.2.4-2-gc134167-dirty\" -O2 -Wall -Wextra -pedantic
-I/usr/local/include/ -L/usr/local/lib/ -MT Helper-abc.o -MD -MP -MF
.deps/Helper-abc.Tpo -c -o Helper-abc.o `test -f 'abc.cpp' || echo './'`abc.cpp


With branch coverage enabled the lcov call is freezing

lcov --rc lcov_branch_coverage=1 --directory $PWD --capture --output-file
tests_coverage.info

Only the .gcda file generated for abc.cpp is freezing rest it is ok. I am
literally desparate for some workaround. It's been a long standing ticket not
seen any workaround or fix.

[Bug c++/97197] New: With -O2, Incorrect -Werror=maybe-uninitialized thrown, leads to 'target_mem_ref' and 'dump_expr' in message

[davidfink314 at gmail dot com via Gcc-bugs]

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

Bug ID: 97197
   Summary: With -O2, Incorrect -Werror=maybe-uninitialized
thrown, leads to 'target_mem_ref' and
'dump_expr' in message
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidfink314 at gmail dot com
  Target Milestone: ---

Bug looks like it was introduced in gcc 7
reproduces in gcc trunk



Output:

x86-64 gcc (trunk)
-O2 -Werror=maybe-uninitialized
1

x86-64 gcc (trunk) - cached
In copy constructor 'Normal::Normal(const Normal&)',
inlined from 'Combo::Combo(const Combo&)' at :21:8,
inlined from 'void Y::f()' at :36:24:
:18:35: error: ''target_mem_ref' not supported by dump_expr' may be used uninitialized [-Werror=maybe-uninitialized]
   18 | Normal(Normal const& o) : p(o.p /* warning here for no good reason
*/) { }
  | ~~^
: In member function 'void Y::f()':
:36:16: note: 'combo' declared here
   36 | for (Combo combo : comboList) { /* implicit copy required to
reproduce bug */
  |^
cc1plus: some warnings being treated as errors
Compiler returned: 1



Input:

https://godbolt.org/z/b73cY8

-O2 -Werror=maybe-uninitialized

#include 

struct Weirdo {
// nonstandard copy constructor
bool data{false}; // initializer here required to reproduce bug
Weirdo() = default;
Weirdo(const Weirdo& o) {
// data should still be set to false via {} above and not being listed
// original code had this in the assignment operator, and the copy
constructor called the assignment operator.
if (this != &o) { // pointer check required to reproduce bug
data = o.data;
}
}
};

struct Normal {
bool p{false};
Normal() = default;
Normal(Normal const& o) : p(o.p /* warning here for no good reason */) { }
};

struct Combo {
Combo() : v(), q() {}
void g();

Weirdo v;
Normal q;
};

struct Y {
void f();

std::vector comboList;
};

void Y::f() {
for (Combo combo : comboList) { /* implicit copy required to reproduce bug
*/
combo.v.data && (combo.g(), false);
}
}

[Bug c/97196] Difference in output between no optimization and -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Jakub Jelinek  ---
Invalid testcase, b is uninitialized before use.

[Bug c/97196] Difference in output between no optimization and -O2

[m.bartelsman.mejia at student dot rug.nl via Gcc-bugs]

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

--- Comment #2 from Miguel  ---
Trigger seems to be line 22, in the loop guard. If I change `while (x != 0)` to
`while (x)` the program then behaves properly regardless of optimization level.

[Bug c/97196] Difference in output between no optimization and -O2

[m.bartelsman.mejia at student dot rug.nl via Gcc-bugs]

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

Miguel  changed:

   What|Removed |Added

Summary|Difference in output|Difference in output
   |between no optimization and |between no optimization and
   |-O2, triggered by a |-O2
   |variable wrapped in |
   |parentheses in the RHS of   |
   |the assignment operator |

--- Comment #1 from Miguel  ---
The bug seems to be caused by line

[Bug c/97196] New: Difference in output between no optimization and -O2, triggered by a variable wrapped in parentheses in the RHS of the assignment operator

[m.bartelsman.mejia at student dot rug.nl via Gcc-bugs]

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

Bug ID: 97196
   Summary: Difference in output between no optimization and -O2,
triggered by a variable wrapped in parentheses in the
RHS of the assignment operator
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.bartelsman.mejia at student dot rug.nl
  Target Milestone: ---

Created attachment 49266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49266&action=edit
Source and preprocessed files

GCC version:
9.3.0

System:
Ubuntu 20.04.1 LTS on WSL2 on Win10 x86_64, and at least one other,
unknown, system.

GCC Options:
gcc -std=c99 -pedantic -Wall -o a.out *.c
gcc -std=c99 -pedantic -Wall -o a.out *.c -O2

How to reproduce:
On both versions run:
$ a.out
$ 2000

Non -O2 will yield `2002 3`, while -O2 will yield `2002 0`

Compiler output:
Only on -O2 version:

palindromicSums.c: In function ‘main’:
palindromicSums.c:34:3: warning: ignoring return value of ‘scanf’, declared
with attribute warn_unused_result [-Wunused-result]
   34 |   scanf("%d", &n);
  |   ^~~

[Bug target/97194] optimize vector element set/extract at variable position

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> Eventually there's a more efficient way to generate {0, 1, 2, 3...}.

vpmovzx* could be at least used to only have a single
byte vector {0, ... 255 } in memory for all cases including V256QI.
Maybe also a separately useful constant pool optimization ...

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return ok in some cases.

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

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

--- Comment #13 from Jonathan Wakely  ---
Thanks!

[Bug target/97194] optimize vector element set/extract at variable position

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

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

--- Comment #2 from Richard Biener  ---
So for set with T == int and N == 32 we could generate

vmovd   %edi, %xmm1
vpbroadcastd%xmm1, %ymm1
vpcmpeqd.LC0(%rip), %ymm1, %ymm2
vpblendvb   %ymm2, %ymm1, %ymm0, %ymm0
ret

.LC0:
.long   0
.long   1
.long   2
.long   3
.long   4
.long   5
.long   6
.long   7

aka, with GCC generic vectors

V setg (V v, int idx, T val)
{
  V valv = (V){idx, idx, idx, idx, idx, idx, idx, idx};
  V mask = ((V){0, 1, 2, 3, 4, 5, 6, 7} == valv);
  v = (v & ~mask) | (valv & mask);
  return v;
}


There's ongoing patch iteration on the ml adding variable index vec_set
expanders for powerpc (and the related middle-end changes).  The question
is whether optabs can try many things or the target should have the choice
(probably better).

Eventually there's a more efficient way to generate {0, 1, 2, 3...}.

[Bug c++/97195] New: construct_at on a union member is not a constant expression

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 97195
   Summary: construct_at on a union member is not a constant
expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

In trying to test adding more constexpr support to std::optional:

#include 

union S {
int i;
};

constexpr int f() {
S s;
std::construct_at(&s.i, 0);
return 0;
}

constexpr int z = f();

gcc rejects with:

:13:20:   in 'constexpr' expansion of 'f()'
:9:22:   in 'constexpr' expansion of 'std::construct_at((&
s.S::i), 0)'
:13:21: error: '(void*)(& s.S::i)' is not a constant expression
   13 | constexpr int z = f();
  | ^

But this should be fine.

[Bug target/97194] optimize vector element set/extract at variable position

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*
 CC||hjl.tools at gmail dot com
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Note I googled quite a bit but didn't find sth for the 'set' case.

[Bug target/97194] New: optimize vector element set/extract at variable position

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

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

Bug ID: 97194
   Summary: optimize vector element set/extract at variable
position
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

#define N 32
typedef int T;
typedef T V __attribute__((vector_size(N)));
V set (V v, int idx, T val)
{
  v[idx] = val;
  return v;
}
T get (V v, int idx)
{
  return v[idx];
}

generates with -mavx2

set:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movslq  %edi, %rdi
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
vmovdqa %ymm0, -32(%rsp)
movl%esi, -32(%rsp,%rdi,4)
vmovdqa -32(%rsp), %ymm0
^^^ store forwarding fail
leave
.cfi_def_cfa 7, 8
ret

get:
.LFB1:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movslq  %edi, %rdi
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
vmovdqa %ymm0, -32(%rsp)
movl-32(%rsp,%rdi,4), %eax
leave
.cfi_def_cfa 7, 8
ret

maybe not too bad.

Vary N and T to cover all types and vector sizes.

It should be possible to do the 'get' case via variable permutes
and the 'set' case via a splat of the value and a blend using
a mask generated from 'idx'.

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return ok in some cases.

[dmjpp at hotmail dot com via Gcc-bugs]

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

--- Comment #12 from Dimitrij Mijoski  ---
Hello Jonathan. I posted a patch for this bug which I hope you'll find it
useful once you start working on this.
https://gcc.gnu.org/pipermail/libstdc++/2020-September/051073.html

[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #5 from Alan Modra  ---
Fixed everywhere we support power10

[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alan Modra :

https://gcc.gnu.org/g:71c83e108de7b54f604eeebefbc9e97672310ca7

commit r10-8795-g71c83e108de7b54f604eeebefbc9e97672310ca7
Author: Alan Modra 
Date:   Fri Sep 18 23:21:05 2020 +0930

[RS6000] Power10 libffi fixes

Power10 pc-relative code doesn't use or preserve r2 as a TOC pointer.
That means calling between pc-relative and TOC using code can't be
done without intervening linker stubs, and a call from TOC code to
pc-relative code must have a nop after the bl in order to restore r2.

Now the PowerPC libffi assembly code doesn't use r2 except for the
implicit use when making calls back to C, ffi_closure_helper_LINUX64
and ffi_prep_args64.  So changing the assembly to interoperate with
pc-relative code without stubs is easily done.

PR target/97166
* src/powerpc/linux64.S (ffi_call_LINUX64): Don't emit global
entry when __PCREL__.  Call using @notoc.  Add nops.
* src/powerpc/linux64_closure.S (ffi_closure_LINUX64): Likewise.
(ffi_go_closure_linux64): Likewise.

(cherry picked from commit 08cd8d5929eac84b27788d8483fd75ab7ad13129)
(cherry picked from commit fff56af6421a1a3e357bcaad99f2ea084d72a7a8)

[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alan Modra :

https://gcc.gnu.org/g:8f4b43c00feed11a6cedd4c40baa3cdcf687b3a1

commit r10-8794-g8f4b43c00feed11a6cedd4c40baa3cdcf687b3a1
Author: Alan Modra 
Date:   Wed Sep 23 20:15:39 2020 +0930

[RS6000] Built-in __PCREL__ define

Useful in assembly to know details of power10 function calls.

PR target/97166
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros):
Conditionally define __PCREL__.

(cherry picked from commit 677b9150f54a0483d3de1182ac40717b7c4431a5)

[Bug debug/91610] fvar-tracking degrades -O0 debug info

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

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

--- Comment #2 from Jakub Jelinek  ---
Yeah, for -O0 we'd need a special mode of -fvar-tracking that would only track
the register vars or vars before they have their memory slot initialized.

[Bug debug/91610] fvar-tracking degrades -O0 debug info

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
   Severity|normal  |enhancement
   Keywords|wrong-debug |

--- Comment #1 from Eric Botcazou  ---
-fvar-tracking was not designed to work at -O0 so reclassifying.

[Bug c++/97186] [11 Regression] ICE: Segmentation fault (in maybe_instantiate_noexcept)

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed 2e66e53b1ef

if you think the code should be accepted without error please file a separate
defect.

[Bug c++/97186] [11 Regression] ICE: Segmentation fault (in maybe_instantiate_noexcept)

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:2e66e53b1efb98f5cf6b0a123990c1ca999affd7

commit r11-3436-g2e66e53b1efb98f5cf6b0a123990c1ca999affd7
Author: Nathan Sidwell 
Date:   Thu Sep 24 06:17:00 2020 -0700

c++: local-decls are never member fns [PR97186]

This fixes an ICE in noexcept instantiation.  It was presuming
functions always have template_info, but that changed with my
DECL_LOCAL_DECL_P changes.  Fortunately DECL_LOCAL_DECL_P fns are
never member fns, so we don't need to go fishing out a this pointer.

Also I realized I'd misnamed local10.C, so renaming it local-fn3.C,
and while there adding the effective-target lto that David E pointed
out was missing.

PR c++/97186
gcc/cp/
* pt.c (maybe_instantiate_noexcept): Local externs are never
member fns.
gcc/testsuite/
* g++.dg/template/local10.C: Rename ...
* g++.dg/template/local-fn3.C: .. here.  Require lto.
* g++.dg/template/local-fn4.C: New.

[Bug gcov-profile/97193] .gcno files are not written to same directory as the object file

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Last reconfirmed||2020-09-24

--- Comment #2 from Martin Liška  ---
Mine.

[Bug gcov-profile/97193] .gcno files are not written to same directory as the object file

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Richard Biener  ---
I think that was a desired change and thus is expected which makes it a
documentation bug.  Martin?

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #13 from Michael_S  ---
(In reply to Hongtao.liu from comment #11)
> (In reply to Michael_S from comment #10)
> > (In reply to Hongtao.liu from comment #9)
> > > (In reply to Michael_S from comment #8)
> > > > What are values of gcc "loop" cost of the relevant instructions now?
> > > > 1. AVX256 Load
> > > > 2. FMA3 ymm,ymm,ymm
> > > > 3. AVX256 Regmove
> > > > 4. FMA3 mem,ymm,ymm
> > > 
> > > For skylake, outside of register allocation.
> > > 
> > > they are
> > > 1. AVX256 Load   10
> > > 2. FMA3 ymm,ymm,ymm --- 16
> > > 3. AVX256 Regmove  --- 2
> > > 4. FMA3 mem,ymm,ymm --- 32
> > > 
> > > In RA, no direct cost for fma instrcutions, but we can disparage memory
> > > alternative in FMA instructions， but again, it may hurt performance in 
> > > some
> > > cases.
> > > 
> > > 1. AVX256 Load   10
> > > 3. AVX256 Regmove  --- 2
> > > 
> > > BTW: we have done a lot of experiments with different cost models and no
> > > significant performance impact on SPEC2017.
> > 
> > Thank you.
> > With relative costs like these gcc should generate 'FMA3 mem,ymm,ymm' only
> > in conditions of heavy registers pressure. So, why it generates it in my
> > loop, where registers pressure in the innermost loop is light and even in
> > the next outer level the pressure isn't heavy?
> > What am I missing?
> 
> the actual transformation gcc did is
> 
> vmovuxx (mem1), %ymmA pass_combine 
> vmovuxx (mem), %ymmD > vmovuxx   (mem1), %ymmA
> vfmadd213 %ymmD,%ymmC,%ymmAvfmadd213 (mem),%ymmC,%ymmA
> 
> then RA works like
> RA
> vmovuxx (mem1), %ymmA  >  %vmovaps %ymmB, %ymmA
> vfmadd213 (mem),%ymmC,%ymmA   vfmadd213 (mem),%ymmC,%ymmA
> 
> it "look like" but actually not this one.
> 
>  vmovuxx  (mem), %ymmA
>  vfnmadd231xx %ymmB, %ymmC, %ymmA
> transformed to
>  vmovaxx  %ymmB, %ymmA
>  vfnmadd213xx (mem), %ymmC, %ymmA
> 
> ymmB is allocate for (mem1) not (mem)

Thank you.
Now compiler's reasoning is starting to make more sense.
Still I don't understand why compiler does not compare the cost of full loop
body after combining to the cost before combining and does not come to
conclusion that combining increased the cost.

[Bug c++/97186] [11 Regression] ICE: Segmentation fault (in maybe_instantiate_noexcept)

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

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

--- Comment #2 from Nathan Sidwell  ---
The error abount conversion failure, if it is a bug, is unrelated to the ICE. 
I say 'if', because I think there have been changes in regards to whether
functions decay to pointers which can be implicitly converted to bool in
constant exprs.  Not digging into that right now though.

[Bug gcov-profile/97193] New: .gcno files are not written to same directory as the object file

[mario at klebsch dot de via Gcc-bugs]

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

Bug ID: 97193
   Summary: .gcno files are not written to same directory as the
object file
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario at klebsch dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

According to https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html, the .gcno
files should be written to the same directory as the object files.

> The .gcno files are placed in the same directory as the object file.

This seems to work with gcc 8.3.0 but does not work with gcc 9.3.0:

+ echo Toolchain 1
Toolchain 1
+ find . -name '*.gcno' -exec rm '{}' +
+ find . -name '*.o' -exec rm '{}' +
+ find . -name '*.gcno' -o -name '*.o'
+ toolchain1/bin/powerpc-603e-linux-gnu-gcc --version
powerpc-603e-linux-gnu-gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ toolchain1/bin/powerpc-603e-linux-gnu-gcc -fprofile-arcs -ftest-coverage
-fprofile-dir=/tmp/coverage -c foo.c -o build/foo.o
+ find . -name '*.gcno' -o -name '*.o'
./build/foo.o
./build/foo.gcno
  ^
same directory as expected

+ echo Toolchain 2
Toolchain 2
+ find . -name '*.gcno' -exec rm '{}' +
+ find . -name '*.o' -exec rm '{}' +
+ find . -name '*.gcno' -o -name '*.o'
+ toolchain2/bin/powerpc-603e-linux-gnu-gcc --version
powerpc-603e-linux-gnu-gcc (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ toolchain2/bin/powerpc-603e-linux-gnu-gcc -fprofile-arcs -ftest-coverage
-fprofile-dir=/tmp/coverage -c foo.c -o build/foo.o
+ find . -name '*.gcno' -o -name '*.o'
./#tmp#gcc-bug#build#foo.gcno
./build/foo.o
^^^
Different directories, not as excpected. :-(

+ echo Natove compiler
Natove compiler
+ find . -name '*.gcno' -exec rm '{}' +
+ find . -name '*.o' -exec rm '{}' +
+ find . -name '*.gcno' -o -name '*.o'
+ gcc --version
gcc (Gentoo 9.3.0-r1 p3) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ gcc -fprofile-arcs -ftest-coverage -fprofile-dir=/tmp/coverage -c foo.c -o
build/foo.o
+ find . -name '*.gcno' -o -name '*.o'
./#tmp#gcc-bug#build#foo.gcno
./build/foo.o
^^^
Different directories, not as excpected. :-(

[Bug c++/97186] [11 Regression] ICE: Segmentation fault (in maybe_instantiate_noexcept)

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug target/97192] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:133 with -O -ftracer -mavx512vl

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
Sorry for the dup. I used gcc built this morning, and I didn't find PR97085,
since it was closed in the meantime.

[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

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

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

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

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

commit r11-3431-ga8d5c28233f95e3474ee8cbc4d341cbb43ab7bb6
Author: Richard Biener 
Date:   Thu Sep 24 13:27:49 2020 +0200

target/97192 - new testcase for fixed PR

This adds another testcase for the PR97085 fix.

2020-09-24  Richard Biener  

PR tree-optimization/97085
* gcc.dg/pr97192.c: New testcase.

[Bug target/97192] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:133 with -O -ftracer -mavx512vl

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Looks like the same case as for PR97085 for aarch64:

-  _19 = VEC_COND_EXPR <_18, { -1, -1, -1, -1, -1, -1, -1, -1 }, { 0, 0, 0, 0,
0, 0, 0, 0 }>;
-  _20 = {a.2_2, a.2_2, a.2_2, a.2_2, a.2_2, a.2_2, a.2_2, a.2_2};
-  _21 = _19 == _20;
+  _21 = VEC_COND_EXPR <_18, { 0, 0, 0, 0, 0, 0, 0, 0 }, { -1, -1, -1, -1, -1,
-1, -1, -1 }>;
   _22 = VEC_COND_EXPR <_21, { -1, -1, -1, -1, -1, -1, -1, -1 }, { 0, 0, 0, 0,
0, 0, 0, 0 }>;

so we compute the VEC_COND_EXPR mask using a VEC_COND_EXPR.  And it's indeed
fixed by the fix for said PR.  I will add the testcase.

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

[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #10 from Richard Biener  ---
*** Bug 97192 has been marked as a duplicate of this bug. ***

[Bug target/97192] New: [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:133 with -O -ftracer -mavx512vl

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 97192
   Summary: [11 Regression] ICE: in gimple_expand_vec_cond_expr,
at gimple-isel.cc:133 with -O -ftracer -mavx512vl
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 49265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49265&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -ftracer -mavx512vl testcase.c 
during GIMPLE pass: isel
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:133
7 | foo (void)
  | ^~~
0x7679cf gimple_expand_vec_cond_expr
/repo/gcc-trunk/gcc/gimple-isel.cc:133
0x122787c gimple_expand_vec_cond_exprs
/repo/gcc-trunk/gcc/gimple-isel.cc:179
0x122787c execute
/repo/gcc-trunk/gcc/gimple-isel.cc:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-3421-20200924150219-gfff56af6421-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-3421-20200924150219-gfff56af6421-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200924 (experimental) (GCC)

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-3430-ge86a02f87d8a11480c1421ef2dd71b8b5f43d938
Author: Paul Thomas 
Date:   Thu Sep 24 11:52:30 2020 +0100

This patch fixes PR96495 - frees result components outside loop.

2020-24-09  Paul Thomas  

gcc/fortran
PR fortran/96495
* trans-expr.c (gfc_conv_procedure_call): Take the deallocation
of allocatable result components of a scalar result outside the
scalarization loop. Find and use the stored result.

gcc/testsuite/
PR fortran/96495
* gfortran.dg/alloc_comp_result_2.f90 : New test.

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Hongtao.liu  ---
Correct AVX256 load cost outside of register allocation and vectorizer

> they are
> 1. AVX256 Load   16
> 2. FMA3 ymm,ymm,ymm --- 16
> 3. AVX256 Regmove  --- 2
> 4. FMA3 mem,ymm,ymm --- 32

That's why pass_combine would combine *avx256 load* and *FMA3 ymm,ymm,ymm* to
*FMA3 mem,ymm,ymm*

[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
   Priority|P3  |P1
 CC||jamborm at gcc dot gnu.org

--- Comment #13 from Martin Liška  ---
Thank you Sergei for the reduced test-case. What happens:

(gdb) p ie->caller->debug()
ai/1 (ai) @0x7772b168
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
  previous sharing asm name: 8
  References: table/5 (addr) ap/4 (addr) (speculative) ag/0 (addr)
(speculative) 
  Referring: 
  Function ai/1 is inline copy in h/3
  Availability: local
  Profile id: 1923518911
  Function flags: count:4 (precise) first_run:4 body local hot
  Called by: h/3 (inlined) (4 (precise),1.00 per call) 
  Calls: ag/7 (speculative) (inlined) (2 (adjusted),0.50 per call) ap/4
(speculative) (2 (adjusted),0.50 per call) PyErr_Format/6 (0 (precise),0.00 per
call) 
   Indirect call(speculative) (0 (adjusted),0.00 per call)  of param:1 (vptr
maybe changed) Num speculative call targets: 2

We first enqueu the edge ai/1 -> ap/4 and then ipa_make_edge_direct_to_target
is called for the Indirect call (with speculative=false) and we end up:

(gdb) p ie->caller->debug()
ai/1 (ai) @0x7772b168
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
  previous sharing asm name: 8
  References: table/5 (addr) 
  Referring: 
  Function ai/1 is inline copy in h/3
  Availability: local
  Profile id: 1923518911
  Function flags: count:4 (precise) first_run:4 body local hot
  Called by: h/3 (inlined) (4 (precise),1.00 per call) 
  Calls: ap/4 (4 (adjusted),1.00 per call) PyErr_Format/6 (0 (precise),0.00 per
call) 

and we add the edge again to the heap in ipa-prop:
  3830new_edges->safe_push (new_direct_edge);

and we ICE due to that. I tried not to add the edge in case
new_direct_edge->aux is NULL, but a sanity check in inliner fails:

during IPA pass: inline
parsermodule.c:35:1: internal compiler error: in estimate_calls_size_and_time,
at ipa-fnsummary.c:3328
   35 | int ap(entry *j) { return ai(j, ag, 14, 4); }
  | ^~~

So I guess a profile masage is needed. Leaving to Martin as he's more familiar
with IPA PROP. Something similar to ipa-prop.c:3309-3316?

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

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

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

--- Comment #38 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:

https://gcc.gnu.org/g:11e0e5fa724f9f6f979abe537d6485850abfe4d9

commit r8-10530-g11e0e5fa724f9f6f979abe537d6485850abfe4d9
Author: Tamar Christina 
Date:   Mon May 21 10:33:30 2018 +

Add missing AArch64 NEON instrinctics for Armv8.2-a to Armv8.4-a

This patch adds the missing neon intrinsics for all 128 bit vector Integer
modes for the
three-way XOR and negate and xor instructions for Arm8.2-a to Armv8.4-a.

gcc/
PR target/71233
* config/aarch64/aarch64-simd.md (aarch64_eor3qv8hi): Change to
eor3q4.
(aarch64_bcaxqv8hi): Change to bcaxq4.
* config/aarch64/aarch64-simd-builtins.def (veor3q_u8, veor3q_u32,
veor3q_u64, veor3q_s8, veor3q_s16, veor3q_s32, veor3q_s64,
vbcaxq_u8,
vbcaxq_u32, vbcaxq_u64, vbcaxq_s8, vbcaxq_s16, vbcaxq_s32,
vbcaxq_s64): New.
* config/aarch64/arm_neon.h: Likewise.
* config/aarch64/iterators.md (VQ_I): New.

gcc/testsuite/
PR target/71233
* gcc.target/aarch64/sha3.h (veor3q_u8, veor3q_u32,
veor3q_u64, veor3q_s8, veor3q_s16, veor3q_s32, veor3q_s64,
vbcaxq_u8,
vbcaxq_u32, vbcaxq_u64, vbcaxq_s8, vbcaxq_s16, vbcaxq_s32,
vbcaxq_s64): New.
* gcc.target/aarch64/sha3_1.c: Likewise.
* gcc.target/aarch64/sha3_2.c: Likewise.
* gcc.target/aarch64/sha3_3.c: Likewise.

(cherry picked from commit d21052ebd7ac9d545a26dde3229c57f872c1d5f3)

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

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

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

--- Comment #39 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:

https://gcc.gnu.org/g:7409639ab568d0d4babcc17370816a2ddd112b72

commit r8-10531-g7409639ab568d0d4babcc17370816a2ddd112b72
Author: Tamar Christina 
Date:   Mon Feb 25 17:46:16 2019 +

AArch64: Update Armv8.4-a's FP16 FML intrinsics

This patch updates the Armv8.4-a FP16 FML intrinsics's suffixes from u32 to
f16
to be more consistent with the naming convention for intrinsics.

The specifications for these intrinsics have not been published yet so we
do
not need to maintain the old names.

The patch was created with the following script:

grep -lIE "(vfml[as].+)_u32" -r gcc/ | grep -iEv ".+Changelog.*" \
  | xargs sed -i -E -e "s/(vfml[as].+)_u32/\1_f16/g"

gcc/
PR target/71233
* config/aarch64/arm_neon.h (vfmlal_low_u32, vfmlsl_low_u32,
vfmlalq_low_u32, vfmlslq_low_u32, vfmlal_high_u32, vfmlsl_high_u32,
vfmlalq_high_u32, vfmlslq_high_u32, vfmlal_lane_low_u32,
vfmlsl_lane_low_u32, vfmlal_laneq_low_u32, vfmlsl_laneq_low_u32,
vfmlalq_lane_low_u32, vfmlslq_lane_low_u32, vfmlalq_laneq_low_u32,
vfmlslq_laneq_low_u32, vfmlal_lane_high_u32, vfmlsl_lane_high_u32,
vfmlal_laneq_high_u32, vfmlsl_laneq_high_u32,
vfmlalq_lane_high_u32,
vfmlslq_lane_high_u32, vfmlalq_laneq_high_u32,
vfmlslq_laneq_high_u32):
Rename ...
(vfmlal_low_f16, vfmlsl_low_f16, vfmlalq_low_f16, vfmlslq_low_f16,
vfmlal_high_f16, vfmlsl_high_f16, vfmlalq_high_f16,
vfmlslq_high_f16,
vfmlal_lane_low_f16, vfmlsl_lane_low_f16, vfmlal_laneq_low_f16,
vfmlsl_laneq_low_f16, vfmlalq_lane_low_f16, vfmlslq_lane_low_f16,
vfmlalq_laneq_low_f16, vfmlslq_laneq_low_f16, vfmlal_lane_high_f16,
vfmlsl_lane_high_f16, vfmlal_laneq_high_f16, vfmlsl_laneq_high_f16,
vfmlalq_lane_high_f16, vfmlslq_lane_high_f16,
vfmlalq_laneq_high_f16,
vfmlslq_laneq_high_f16): ... To this.

gcc/testsuite/
PR target/71233
* gcc.target/aarch64/fp16_fmul_high.h (test_vfmlal_high_u32,
test_vfmlalq_high_u32, test_vfmlsl_high_u32,
test_vfmlslq_high_u32):
Rename ...
(test_vfmlal_high_f16, test_vfmlalq_high_f16, test_vfmlsl_high_f16,
test_vfmlslq_high_f16): ... To this.
* gcc.target/aarch64/fp16_fmul_lane_high.h
(test_vfmlal_lane_high_u32,
tets_vfmlsl_lane_high_u32, test_vfmlal_laneq_high_u32,
test_vfmlsl_laneq_high_u32, test_vfmlalq_lane_high_u32,
test_vfmlslq_lane_high_u32, test_vfmlalq_laneq_high_u32,
test_vfmlslq_laneq_high_u32): Rename ...
(test_vfmlal_lane_high_f16, tets_vfmlsl_lane_high_f16,
test_vfmlal_laneq_high_f16, test_vfmlsl_laneq_high_f16,
test_vfmlalq_lane_high_f16, test_vfmlslq_lane_high_f16,
test_vfmlalq_laneq_high_f16, test_vfmlslq_laneq_high_f16): ... To
this.
* gcc.target/aarch64/fp16_fmul_lane_low.h
(test_vfmlal_lane_low_u32,
test_vfmlsl_lane_low_u32, test_vfmlal_laneq_low_u32,
test_vfmlsl_laneq_low_u32, test_vfmlalq_lane_low_u32,
test_vfmlslq_lane_low_u32, test_vfmlalq_laneq_low_u32,
test_vfmlslq_laneq_low_u32): Rename ...
(test_vfmlal_lane_low_f16, test_vfmlsl_lane_low_f16,
test_vfmlal_laneq_low_f16, test_vfmlsl_laneq_low_f16,
test_vfmlalq_lane_low_f16, test_vfmlslq_lane_low_f16,
test_vfmlalq_laneq_low_f16, test_vfmlslq_laneq_low_f16): ... To
this.
* gcc.target/aarch64/fp16_fmul_low.h (test_vfmlal_low_u32,
test_vfmlalq_low_u32, test_vfmlsl_low_u32, test_vfmlslq_low_u32):
Rename ...
(test_vfmlal_low_f16, test_vfmlalq_low_f16, test_vfmlsl_low_f16,
test_vfmlslq_low_f16): ... To This.
* lib/target-supports.exp
(check_effective_target_arm_fp16fml_neon_ok_nocache): Update test.

(cherry picked from commit 9d04c986b6faed878dbcc86d2f9392a721a3936e)

[Bug ipa/97181] Inlining of leaf case in recursion

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #3 from Jan Hubicka  ---
> and then inline btsum.0.  Notice how the possibility of level < 0 is left
> untouched ... [I think there are no unsigned types in fortran]
> 
> That said, I don't think IPA-CP/VRP do this kind of "evolution analysis"
> on parameters [in the recursion case]?

ipa-cp does this kind of analysis for the recursive clonning (for
exchange). I would hope that it could handle case like this evnetually
too.

Re: [Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[Andrea Corallo]

"iains at gcc dot gnu.org via Gcc-bugs"  writes:
[...]
> unfortunately, I've not been able to test since you applied this - currently
> bootstrap is broken on aarch64-darwin for reasons outside our control (new
> security provisions stopping the gcc/build/gen* programs from running).  If it
> could stay open for a few more days, while we try to find a fix for that - (or
> close it and we can reopen if needed).

Sure no rush, thanks for testing it!

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #8 from Andrea Corallo  ---
"iains at gcc dot gnu.org via Gcc-bugs"  writes:
[...]
> unfortunately, I've not been able to test since you applied this - currently
> bootstrap is broken on aarch64-darwin for reasons outside our control (new
> security provisions stopping the gcc/build/gen* programs from running).  If it
> could stay open for a few more days, while we try to find a fix for that - (or
> close it and we can reopen if needed).

Sure no rush, thanks for testing it!

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

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

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Andrea Corallo from comment #6)
> I believe f5e73de00e9c853ce65333efada7409b0d00f758 should have fixed
> this.
> 
> Okay to close?

unfortunately, I've not been able to test since you applied this - currently
bootstrap is broken on aarch64-darwin for reasons outside our control (new
security provisions stopping the gcc/build/gen* programs from running).  If it
could stay open for a few more days, while we try to find a fix for that - (or
close it and we can reopen if needed).

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Hongtao.liu  ---
(In reply to Michael_S from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > (In reply to Michael_S from comment #8)
> > > What are values of gcc "loop" cost of the relevant instructions now?
> > > 1. AVX256 Load
> > > 2. FMA3 ymm,ymm,ymm
> > > 3. AVX256 Regmove
> > > 4. FMA3 mem,ymm,ymm
> > 
> > For skylake, outside of register allocation.
> > 
> > they are
> > 1. AVX256 Load   10
> > 2. FMA3 ymm,ymm,ymm --- 16
> > 3. AVX256 Regmove  --- 2
> > 4. FMA3 mem,ymm,ymm --- 32
> > 
> > In RA, no direct cost for fma instrcutions, but we can disparage memory
> > alternative in FMA instructions， but again, it may hurt performance in some
> > cases.
> > 
> > 1. AVX256 Load   10
> > 3. AVX256 Regmove  --- 2
> > 
> > BTW: we have done a lot of experiments with different cost models and no
> > significant performance impact on SPEC2017.
> 
> Thank you.
> With relative costs like these gcc should generate 'FMA3 mem,ymm,ymm' only
> in conditions of heavy registers pressure. So, why it generates it in my
> loop, where registers pressure in the innermost loop is light and even in
> the next outer level the pressure isn't heavy?
> What am I missing?

the actual transformation gcc did is

vmovuxx (mem1), %ymmA pass_combine 
vmovuxx (mem), %ymmD > vmovuxx   (mem1), %ymmA
vfmadd213 %ymmD,%ymmC,%ymmAvfmadd213 (mem),%ymmC,%ymmA

then RA works like
RA
vmovuxx (mem1), %ymmA  >  %vmovaps %ymmB, %ymmA
vfmadd213 (mem),%ymmC,%ymmA   vfmadd213 (mem),%ymmC,%ymmA

it "look like" but actually not this one.

 vmovuxx  (mem), %ymmA
 vfnmadd231xx %ymmB, %ymmC, %ymmA
transformed to
 vmovaxx  %ymmB, %ymmA
 vfnmadd213xx (mem), %ymmC, %ymmA

ymmB is allocate for (mem1) not (mem)

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #6 from Andrea Corallo  ---
I believe f5e73de00e9c853ce65333efada7409b0d00f758 should have fixed
this.

Okay to close?

Thanks

  Andrea

Re: [Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[Andrea Corallo]

I believe f5e73de00e9c853ce65333efada7409b0d00f758 should have fixed
this.

Okay to close?

Thanks

  Andrea

[Bug ada/96488] Long time failures of gnat.dg/unchecked_convert5.adb and gnat.dg/unchecked_convert6.adb

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-24
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
The test can pass only on big-endian targets so needs to be killed here.

[Bug target/97107] libgo fails to build for power10

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Target|powerpc*|powerpc64*-*
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #3 from Alan Modra  ---
This one isn't needed on gcc-10 for powerpc64 since the patch enabling tail
calls isn't on the branch (yet).  It isn't needed for ppc32 either, since
-fsplit-stack isn't supported on ppc32.

[Bug tree-optimization/97190] [11 Regression] ICE in get_location_from_adhoc_loc at libcpp/line-map.c:257 since r11-2928-gd14c547abd484d35

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

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

Richard Biener  changed:

   What|Removed |Added

Version|10.0|11.0
   Target Milestone|--- |11.0

[Bug c++/97191] ICE In expand_expr_real_1, at expr.c:10234

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-09-24
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.1, 11.0

--- Comment #1 from Richard Biener  ---
Confirmed.

10238 gcc_assert (!exp
10239 || SCOPE_FILE_SCOPE_P (context)
10240 || context == current_function_decl
10241 || TREE_STATIC (exp)
10242 || DECL_EXTERNAL (exp)
(gdb) l
10243 /* ??? C++ creates functions that are not
TREE_STATIC.  */
10244 || TREE_CODE (exp) == FUNCTION_DECL);
(gdb) p exp
$1 = 
(gdb) p current_function_decl 
$2 = 
(gdb) p exp->decl_minimal.context 
$3 = 

but the underlying reason may be a stale VLA reference due to a missing
DECL_EXPR.

[Bug target/96528] [11 Regression] vector comparisons on ARM

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug target/96528] [11 Regression] vector comparisons on ARM

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

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

Richard Biener  changed:

   What|Removed |Added

   Severity|enhancement |normal
 CC||rearnsha at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Hmm, I configured exactly as in the description but I do not manage to get nice
code even when veclower sees

  _1 = a_5(D) == { 5, 5, 5, 5 };
  _2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
  _3 = b_6(D) == { 7, 7, 7, 7 };
  _4 = VEC_COND_EXPR <_3, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
  _7 = _2 | _4;
  return _7;

I guess I'm missing magic compiler options (as usual with arm...).

Besides 'fixing' the arm backend we can either ISEL the compares as
.VCOND, adjust them in veclower to supported VEC_COND_EXPRs
(need to adjust veclower anyway to not generate the awkward code).

I'll note that the arm backend in its vcond* neon patterns seems to
emit two instructions, a mask generating one and a selecting one
where the mask generating one isn't exposed to the middle-end
(that would be vec_cmp* patterns).

So for the specific case of arm neon I agree the best fix would be
to the target.  It might be possible to copy the aarch64 patterns here.

[Bug c++/97191] New: ICE In expand_expr_real_1, at expr.c:10234

[tangyixuan at mail dot dlut.edu.cn via Gcc-bugs]

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

Bug ID: 97191
   Summary: ICE In expand_expr_real_1, at expr.c:10234
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, the following code crashes GCC.

$ cat s.cpp

struct A { 
  A (); 
  A ( const A &); 
  A ( int );
}; 
A :: A (){
  int a =0; 
  A b [a][0];
} 

$ g++ -c s.cpp

during RTL pass: expand
s.cpp: In constructor ‘A::A()’:
s.cpp:8:12: internal compiler error: in expand_expr_real_1, at expr.c:10234
8 |   A b [a][0];
  |^
0x606834 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-11-20200906/gcc/expr.c:10234
0x97e6a1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-11-20200906/gcc/expr.c:8480
0x97e6a1 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc-11-20200906/gcc/expr.c:5858
0x97fcd1 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-11-20200906/gcc/expr.c:5594
0x8742f8 expand_gimple_stmt_1
../../gcc-11-20200906/gcc/cfgexpand.c:3749
0x8742f8 expand_gimple_stmt
../../gcc-11-20200906/gcc/cfgexpand.c:3847
0x87a39e expand_gimple_basic_block
../../gcc-11-20200906/gcc/cfgexpand.c:5888
0x87a39e execute
../../gcc-11-20200906/gcc/cfgexpand.c:6572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Michael_S  ---
(In reply to Hongtao.liu from comment #9)
> (In reply to Michael_S from comment #8)
> > What are values of gcc "loop" cost of the relevant instructions now?
> > 1. AVX256 Load
> > 2. FMA3 ymm,ymm,ymm
> > 3. AVX256 Regmove
> > 4. FMA3 mem,ymm,ymm
> 
> For skylake, outside of register allocation.
> 
> they are
> 1. AVX256 Load   10
> 2. FMA3 ymm,ymm,ymm --- 16
> 3. AVX256 Regmove  --- 2
> 4. FMA3 mem,ymm,ymm --- 32
> 
> In RA, no direct cost for fma instrcutions, but we can disparage memory
> alternative in FMA instructions， but again, it may hurt performance in some
> cases.
> 
> 1. AVX256 Load   10
> 3. AVX256 Regmove  --- 2
> 
> BTW: we have done a lot of experiments with different cost models and no
> significant performance impact on SPEC2017.

Thank you.
With relative costs like these gcc should generate 'FMA3 mem,ymm,ymm' only in
conditions of heavy registers pressure. So, why it generates it in my loop,
where registers pressure in the innermost loop is light and even in the next
outer level the pressure isn't heavy?
What am I missing?

[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

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

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

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

https://gcc.gnu.org/g:10843f8303509fcba880c6c05c08e4b4ccd24f36

commit r11-3426-g10843f8303509fcba880c6c05c08e4b4ccd24f36
Author: Richard Biener 
Date:   Thu Sep 24 10:14:33 2020 +0200

tree-optimization/97085 - fold some trivial bool vector ?:

The following aovids the ICE in the testcase by doing some additional
simplification of VEC_COND_EXPRs for VECTOR_BOOLEAN_TYPE_P which
we don't really expect, esp. when they are not classical vectors,
thus AVX512 or SVE masks.

2020-09-24  Richard Biener  

PR tree-optimization/97085
* match.pd (mask ? { false,..} : { true, ..} -> ~mask): New.

* gcc.dg/vect/pr97085.c: New testcase.

[Bug gcov-profile/96534] keep gcov intermediate format

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

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

--- Comment #6 from Martin Liška  ---
(In reply to xlwu from comment #5)
> A bug found in the JSON format:
> 
> in the lines.count and functions.execute_count fields, when the number is
> extremely large , it will be shown as something like:  8.12123199e+08 , even
> become a minus number , like -8.1332322e+08 . this is not a legal JSON
> format , when I try to unmarshel in golang , it just crash, I believe other
> language will crash too

That should be fixed in r10-4051-g076222782e4558e0bd22711c6fdcc0faf0882daf and
part of GCC 10.x release. Can you please verify that?

> 
> another question is:  in our environment , the gcda and gcno files are not
> under same dir

How that happens?

> , to run the gcov , I had to copy them into a temp dir , is
> it possible to provide options to give the gcda and gcno path in command
> line?

Right now, it's not possible. Can you please experiment with -o option?

[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
   Last reconfirmed||2020-09-24
 CC||amodra at gmail dot com
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Alan Modra  ---
Oops didn't put the PR number in the commit.  Fixed on master with commit
08cd8d5929 and followup commit fff56af642.  These two will give a working
power10 libffi even without commit 677b9150f5, the patch adding a built-in
__PCREL__ define but you'll get some linker stubs to call between pc-rel and
toc code.

[Bug bootstrap/97183] zstd build failure for gcc 10 on Ubuntu 16.04

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-09-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, can you please suggest a patch Jim?

[Bug c++/97187] [11 Regression] ICE: tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19782

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started to ICE with r11-423-gcda6396a1b6e6bba, before that it was rejected
with:

$ g++-10 pr97187.C -c -fno-exceptions
pr97187.C: In instantiation of ‘DI zl() [with DI = ]’:
pr97187.C:15:30:   required from here
pr97187.C:7:57: error: exception handling disabled, use ‘-fexceptions’ to
enable
7 |   auto au = [] () -> DI { return *new auto (true ? yp : throw); };
  | ^

[Bug c++/97186] [11 Regression] ICE: Segmentation fault (in maybe_instantiate_noexcept)

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started to ICE with r11-3192-ge9fdb9a73249f95f, before that it was rejected:

g++-10 pr97186.C -c
pr97186.C: In instantiation of ‘void hk() [with GG = int]’:
pr97186.C:9:8:   required from ‘static void no::tg() [with GG = int]’
pr97186.C:16:18:   required from here
pr97186.C:7:5: error: conversion from ‘void (*)()’ to ‘bool’ in a converted
constant expression
7 | hk () noexcept (tg);
  | ^~
pr97186.C:7:5: error: could not convert ‘no::tg’ from ‘void()’ to ‘bool’

[Bug tree-optimization/97190] [11 Regression] ICE in get_location_from_adhoc_loc at libcpp/line-map.c:257 since r11-2928-gd14c547abd484d35

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-24
 Ever confirmed|0   |1
  Known to work||10.2.0
  Known to fail||11.0

[Bug tree-optimization/97190] New: [11 Regression] ICE in get_location_from_adhoc_loc at libcpp/line-map.c:257 since r11-2928-gd14c547abd484d35

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

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

Bug ID: 97190
   Summary: [11 Regression] ICE in get_location_from_adhoc_loc at
libcpp/line-map.c:257 since r11-2928-gd14c547abd484d35
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The following ICEs:

$ cat strncat.c
#include 
#include 

test1(char *to, int to_size, char from) { strncat(to, from, 2); }
main() {
  size_t to_size = 0;
  char *to = malloc(to_size);
  char from;
  test1(to, to_size, from);
}

$ gcc strncat.c -c -O1
strncat.c:4:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
4 | test1(char *to, int to_size, char from) { strncat(to, from, 2); }
  | ^
strncat.c: In function ‘test1’:
strncat.c:4:55: warning: passing argument 2 of ‘strncat’ makes pointer from
integer without a cast [-Wint-conversion]
4 | test1(char *to, int to_size, char from) { strncat(to, from, 2); }
  |   ^~~~
  |   |
  |   char
In file included from strncat.c:1:
/usr/include/string.h:133:71: note: expected ‘const char * restrict’ but
argument is of type ‘char’
  133 | extern char *strncat (char *__restrict __dest, const char *__restrict
__src,
  |   
~~~^
strncat.c: At top level:
strncat.c:5:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
5 | main() {
  | ^~~~
In function ‘test1’,
inlined from ‘main’ at strncat.c:9:3:
strncat.c:4:43: warning: ‘strncat’ specified bound 2 exceeds destination size 0
[-Wstringop-overflow=]
4 | test1(char *to, int to_size, char from) { strncat(to, from, 2); }
  |   ^~~~

during RTL pass: expand
strncat.c: In function ‘main’:
strncat.c:4:43: internal compiler error: Segmentation fault
0xb1b95f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/toplev.c:329
0x776a652f ???
   
/usr/src/debug/glibc-2.31-6.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x14c3a67 get_location_from_adhoc_loc(line_maps const*, unsigned int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/libcpp/line-map.c:257
0x14c3a67 linemap_resolve_location(line_maps*, unsigned int,
location_resolution_kind, line_map_ordinary const**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/libcpp/line-map.c:1540
0x149afa9 diagnostic_report_current_module(diagnostic_context*, unsigned int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/diagnostic.c:683
0xb64481 diagnostic_report_current_function(diagnostic_context*,
diagnostic_info*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/tree-diagnostic.c:39
0xb644c0 default_tree_diagnostic_starter
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/tree-diagnostic.c:48
0x149a1f6 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/diagnostic.c:1206
0x149c6c7 diagnostic_impl
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/diagnostic.c:1355
0x149c6c7 inform(unsigned int, char const*, ...)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/diagnostic.c:1434
0x7226db maybe_warn_for_bound
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/builtins.c:3483
0x725f28 maybe_warn_for_bound
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/builtins.c:3361
0x725f28 check_access(tree_node*, tree_node*, tree_node*, tree_node*,
tree_node*, access_mode, access_data const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/builtins.c:4071
0x7295cf expand_builtin_strncat
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/builtins.c:5284
0x72c136 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/builtins.c:8665
0x849652 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/expr.c:11243
0x74b73e expand_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/expr.h:282
0x74b73e expand_call_stmt
  

[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Marc Glisse from comment #6)
> (In reply to Richard Biener from comment #5)
> > (In reply to Marc Glisse from comment #4)
> > > I would be happy with a revert of that patch, if the ARM backend gets 
> > > fixed,
> > > but indeed a missed optimization should not cause an ICE.
> > 
> > Not sure what the ARM backend issue is.
> 
> PR 96528
> 
> > Well, VEC_COND_EXPR (as some other VEC_ tree codes) are special in that
> > we are (try to...) be careful to only synthesize ones supported "directly"
> > by the target.
> 
> After vector lowering, yes. But before that, the front-end can produce
> vec_cond_expr for vector types that are not supported. Ah, you probably
> meant synthesize them from optimization passes, ok.

Yeah.  I'm also not sure whether the user can synthesize VEC_COND_EXPR
for say AVX512 vector masks - you cannot even declare those "vector types",
instead the intrinsic header uses

typedef unsigned char  __mmask8;
typedef unsigned short __mmask16;

maybe for SVE this is different, but the SVE header is "hidden" ;)

/* NOTE: This implementation of arm_sve.h is intentionally short.  It does
   not define the SVE types and intrinsic functions directly in C and C++
   code, but instead uses the following pragma to tell GCC to insert the
   necessary type and function definitions itself.  The net effect is the
   same, and the file is a complete implementation of arm_sve.h.  */
#pragma GCC aarch64 "arm_sve.h"

> > For the mask vectors (VECTOR_BOOLEAN_TYPE_P, in the
> > AVX512/SVE case) I don't think the targets support ?: natively but they
> > have bitwise instructions for this case.  That means we could 'simply'
> > expand mask x ? y : z as (y & x) | (z & ~x) I guess [requires x and y,z
> > to be of the same type of course].  I wondered whether we ever
> > need to translate between, say, vector and vector
> > where lowering ?: this way would require '[un]packing' one of the vectors.
> 
> I still need to go back to the introduction of those types to understand why
> vector exists at all...
> 
> > True, unless you go to bitwise ops.  For scalar flag ? bool_a : bool_b
> > ?: isn't the natural representation either - at least I'm not aware
> > of any pattern transforming (a & b) | (c & ~b) to b ? a : c for
> > precision one integer types ;)
> 
> There are PRs asking for this transformation (and for transformations that
> this one would enable).

heh ;)

[Bug tree-optimization/97189] [11 Regression] ICE in attr_access::array_as_string at gcc/attribs.c:2276 since r11-3303-g6450f07388f9fe57

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-24
  Known to work||10.2.0
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
  Known to fail||11.0

[Bug tree-optimization/97189] New: [11 Regression] ICE in attr_access::array_as_string at gcc/attribs.c:2276 since r11-3303-g6450f07388f9fe57

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

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

Bug ID: 97189
   Summary: [11 Regression] ICE in attr_access::array_as_string at
gcc/attribs.c:2276 since r11-3303-g6450f07388f9fe57
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat attr.c
#define RW(...) __attribute__((access(read_write, __VA_ARGS__)))
RW(2, 3) void f1(int n, int[n], int);
RW(2) void f2(int, int[*], int);
RW(2, 3) void f2(int, int[], int);

$ gcc attr.c -c
attr.c:2:22: warning: attribute ‘access (read_write, 2, 3)’ positional argument
2 conflicts with previous designation by argument 3 [-Wattributes]
2 | RW(2, 3) void f1(int n, int[n], int);
  |  ^
attr.c:2:22: note: designating the bound of variable length array argument 2
attr.c:4:1: internal compiler error: Segmentation fault
4 | RW(2, 3) void f2(int, int[], int);
  | ^~
0xd9e6ff crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:329
0x7788652f ???
   
/usr/src/debug/glibc-2.31-6.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7e3304 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3298
0x7e3304 attr_access::array_as_string[abi:cxx11](tree_node*) const
/home/marxin/Programming/gcc/gcc/attribs.c:2276
0x8e96fe warn_parm_array_mismatch(unsigned int, tree_node*, tree_node*)
/home/marxin/Programming/gcc/gcc/c-family/c-warn.c:3424
0x85c5dc c_parser_declaration_or_fndef
/home/marxin/Programming/gcc/gcc/c/c-parser.c:2346
0x865383 c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1777
0x865e81 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1650
0x865e81 c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:21821
0x8c054d c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97188] [11 Regression] ICE in c_tree_printer at c/c-objc-common.c:314 since r11-3303-g6450f07388f9fe57

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||10.2.0
  Known to fail||11.0
   Last reconfirmed||2020-09-24

[Bug tree-optimization/97188] New: [11 Regression] ICE in c_tree_printer at c/c-objc-common.c:314 since r11-3303-g6450f07388f9fe57

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

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

Bug ID: 97188
   Summary: [11 Regression] ICE in c_tree_printer at
c/c-objc-common.c:314 since r11-3303-g6450f07388f9fe57
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The following ICEs:

$ void function(short width, int[][width]);
void test() { function(1, 0); }

$ gcc vla.c -Wnonnull -c

during RTL pass: expand
In function ‘test’:
Segmentation fault
2 | void test() { function(1, 0); }
  |   ^~
0xd9e6ff crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:329
0x7788652f ???
   
/usr/src/debug/glibc-2.31-6.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x8336e0 c_tree_printer
/home/marxin/Programming/gcc/gcc/c/c-objc-common.c:314
0x8336e0 c_tree_printer
/home/marxin/Programming/gcc/gcc/c/c-objc-common.c:254
0x188dccc pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1475
0x1871bbe diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1205
0x1874238 diagnostic_impl
/home/marxin/Programming/gcc/gcc/diagnostic.c:1355
0x1874238 warning_at(unsigned int, int, char const*, ...)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1492
0x927455 maybe_warn_rdwr_sizes
/home/marxin/Programming/gcc/gcc/calls.c:2038
0x928ad6 initialize_argument_information
/home/marxin/Programming/gcc/gcc/calls.c:2531
0x928ad6 expand_call(tree_node*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/calls.c:3926
0xa5ea2a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11246
0x940259 expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:282
0x940259 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2703
0x940259 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3686
0x940259 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3851
0x94560a expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5892
0x9470b6 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6576
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

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

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

--- Comment #6 from Marc Glisse  ---
(In reply to Richard Biener from comment #5)
> (In reply to Marc Glisse from comment #4)
> > I would be happy with a revert of that patch, if the ARM backend gets fixed,
> > but indeed a missed optimization should not cause an ICE.
> 
> Not sure what the ARM backend issue is.

PR 96528

> Well, VEC_COND_EXPR (as some other VEC_ tree codes) are special in that
> we are (try to...) be careful to only synthesize ones supported "directly"
> by the target.

After vector lowering, yes. But before that, the front-end can produce
vec_cond_expr for vector types that are not supported. Ah, you probably meant
synthesize them from optimization passes, ok.

> For the mask vectors (VECTOR_BOOLEAN_TYPE_P, in the
> AVX512/SVE case) I don't think the targets support ?: natively but they
> have bitwise instructions for this case.  That means we could 'simply'
> expand mask x ? y : z as (y & x) | (z & ~x) I guess [requires x and y,z
> to be of the same type of course].  I wondered whether we ever
> need to translate between, say, vector and vector
> where lowering ?: this way would require '[un]packing' one of the vectors.

I still need to go back to the introduction of those types to understand why
vector exists at all...

> True, unless you go to bitwise ops.  For scalar flag ? bool_a : bool_b
> ?: isn't the natural representation either - at least I'm not aware
> of any pattern transforming (a & b) | (c & ~b) to b ? a : c for
> precision one integer types ;)

There are PRs asking for this transformation (and for transformations that this
one would enable).

[Bug c++/97187] [11 Regression] ICE: tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19782

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0