[Bug c++/103968] [11/12 Regression] ICE and segfault when instantiating template with lvalue ref argument and nested template type

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/102123] [11/12 Regression] Internal Compiler Error occurs during template deduction in use with templates as template parameters

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/102045] [11/12 regression] constructor is not being instantiated

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #5 from Jason Merrill  ---
*** Bug 102654 has been marked as a duplicate of this bug. ***

[Bug c++/102654] [11/12 Regression] undefined reference to `std::variant::variant(std::string_view&&)'

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Dup.

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

[Bug go/104832] gccgo / libgo Reproducibility Problem

[toolybird at tuta dot io via Gcc-bugs]

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

--- Comment #7 from Toolybird  ---
I just stumbled across this openSUSE bug report which may or may not be
related:

https://bugzilla.opensuse.org/show_bug.cgi?id=1188621

Interesting that it mentions filesystem readdir which I hadn't considered as a
possible factor. For the record, I'm building on ext4.

[Bug c++/103943] [11/12 Regression] ICE building qualified name inside class with variadic CTAD

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

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

Jason Merrill  changed:

   What|Removed |Added

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

Re: [PATCH RFC] Fix ICE due to shared BLOCK node in coroutine generation [PR103328]

[Jason Merrill via Gcc-patches]

On 3/17/22 07:37, Benno Evers via Gcc-patches wrote:

The coroutine transformation moves the original function body into a
newly created actor function, but the block of the
`current_binding_level` still points into the original function,
causing the block to be shared between the two functions if it is
subsequently used. This may cause havoc later on, as subsequent
compiler passes for one function will also implicitly modify the
other. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328#c19 for
a more detailed writeup.

This patch fixes the issue locally, but I'm not familiar with the GCC
code base so I'm not sure if this is the right way to go about it or
if there's a cleaner way to reset the current binding level. If this
is the way to go I'm happy to extend the patch with a testcase and
changelog entry.


Please do, it looks like a good fix to me.  Iain, does it make sense to 
you as well?



---
  gcc/cp/coroutines.cc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index b1bfdc767a4..eb5f80f499b 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4541,6 +4541,8 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
*destroyer)
BLOCK_VARS (top_block) = BIND_EXPR_VARS (ramp_bind);
BLOCK_SUBBLOCKS (top_block) = NULL_TREE;

+  current_binding_level->blocks = top_block;
+
/* The decl_expr for the coro frame pointer, initialize to zero so that we
   can pass it to the IFN_CO_FRAME (since there's no way to pass a type,
   directly apparently).  This avoids a "used uninitialized" warning.  */

[Bug c++/102045] [11/12 regression] constructor is not being instantiated

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/100282] local class in lambda in pack expansion

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #6 from Jason Merrill  ---
*** Bug 103428 has been marked as a duplicate of this bug. ***

[Bug c++/103428] [11/12 Regression] Parameter packs not expanded with local struct in lambda

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Local classes in lambdas in pack expansions that depend on parameter packs have
never worked properly; giving an error is better than accepting it and doing
the wrong thing.

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

[Bug c++/104847] [11/12 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/96780] debuginfo for std::move and std::forward isn't useful

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

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

--- Comment #17 from Jason Merrill  ---
*** Bug 104719 has been marked as a duplicate of this bug. ***

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Target Milestone|--- |12.0
 Status|NEW |RESOLVED

--- Comment #13 from Jason Merrill  ---
I believe the primary concern of this PR is resolved by Patrick's patch for
PR96780; you can now use -ffold-simple-inlines to avoid calls to std::move at
-O0.  Please open separate PRs for individual standard library abstraction
penalty issues.

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

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

[peter at cordes dot ca via Gcc-bugs]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #14 from Peter Cordes  ---
This bug is mis-categorized; it's not a sanitizer bug, it's a bug in the
implementation _mm_load_ss / sd.

It currently derefs the  `float const*` arg directly, which is not
strict-aliasing or alignment safe.  alignof(float) is 4, but Intel's
documentation for this API still says "mem_addr does not need to be aligned on
any particular boundary."

_mm_load_ss (float const *__P)
{
  return _mm_set_ss (*__P);
}


As discussed on PR99754 _mm_load_si32(const void*) *is* strict-aliasing and
alignment safe.  But it only existed recently, and GCC11's implementation of it
is buggy (shuffling the element to the wrong place).  Before that, one safe way
to do a 32-bit SIMD load is with _mm_load_ss and _mm_castps_si128.  Or it was
supposed to be safe, but isn't!!

Clang uses a packed may_alias struct containing a float to get a safe load
done.  Another way would be casting the pointer to

typdef float aliasing_unaligned_f32 __attribute__((aligned(1),may_alias));

This is similar to what we do with __m32_u for use in aliasing-safe integer
load/store, except we define that as int with
vector_size(4),may_alias,aligned(1) for some reason.  Perhaps influenced by
__m64_u which is a vector of 2 ints.

MSVC is like gcc -fno-strict-aliasing, so however it handles intrinsics,
they're always aliasing-safe.

I'm not 100% sure about what ICC formally guarantees, but in practice it
doesn't move aliasing short*  stores across a _mm_load_ss( (float*)pshort )
load.
https://godbolt.org/z/6s76v71xz  I didn't test with _mm_store_ss aliasing with
short loads, only vice versa.

So GCC is the odd one out, out of the major 4 compilers that support Intel's
intrinsics API.  All our narrow load/store intrinsics should be strict-aliasing
and alignment safe, regardless of what pointer type they accept.

Intel's early design of taking float* and double* instead of void* could be
considered poor design.  Their naming with just load/store instead of
_mm_loadu_ss / storeu is also poor design, clearly motivated by the asm
differences rather than an actual intrinsic API difference.

In x86 asm, loads/stores narrower than 16 bytes never require alignment (unless
the AC bit is set in EFLAGS).  Assuming Intel modeled their intrinsics API
after their asm, then it makes sense to have load and loadu for ps and si128,
but only load/store with an implied lack of alignment for intrinsics that wrap
instructions like movlps / movhps / movss / movsd, and movd / movq, which do
narrower memory accesses.

That of course *doesn't* make sense in C terms, where it's always potentially a
problem to dereference misaligned pointers to narrow objects, even when
compiling for x86-64:
https://stackoverflow.com/questions/47510783/why-does-unaligned-access-to-mmaped-memory-sometimes-segfault-on-amd64
has an example and links some others, showing that compilers *don't* define the
behaviour of deref of misaligned pointers.

I'm pretty certain that Intel always intended their narrow load/store
intrinsics to not have any alignment requirements, like the asm instructions
that wrap them, but weren't thinking in C terms when naming them.  And were
sloppily in their choices of which ones to provide until decades later, since
it seems they thought that _mm_cvtsi32_si128(*x) was sufficient for a movd
load.  (Only the case on a compiler without strict-aliasing or alignment, since
the deref happens on the user's plain int*).

Anyway, hopefully this refutes the argument that _mm_load_sd should be aligned
because of the name, and clarifies what Intel might have been thinking when
naming these.

[Bug tree-optimization/104987] [12 Regression] Recent change causing vrp13.c regressions on several targets

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

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

--- Comment #7 from Jeffrey A. Law  ---
Highly confident this is a simulator bug for the v850.  I hiaven't looked at
iq2000-elf yet, but I wouldn't be surprised if that turns out to be something
similar.

[Bug c++/102538] [11 Regression] Wrong narrowing conversion checking for initializer with union

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
And 11.3.

[Bug c++/103299] [11 Regression] accessing incorrect storage for designated init of anonymous union at constexpr context

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 11.3

[Bug c++/101767] [11 Regression] Aggregate initialization fails for struct that has both unnamed struct and union fields

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 11.3

[Bug c++/102740] [11 Regression] Data member not found in struct inside an unnamed union

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixend for 11.3 as well.

[Bug c++/59950] [9/10 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] Bogus  |[9/10 Regression] Bogus
   |diagnostic "taking address  |diagnostic "taking address
   |of temporary" taking|of temporary" taking
   |address of trivial no-op|address of trivial no-op
   |assignment to temporary |assignment to temporary
   |with empty class|with empty class

--- Comment #9 from Jason Merrill  ---
And 11.3

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.5 |12.0

--- Comment #22 from Jason Merrill  ---
Fixed for 12, not backporting.

[Bug target/99754] [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly

[peter at cordes dot ca via Gcc-bugs]

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

--- Comment #6 from Peter Cordes  ---
Looks good to me, thanks for taking care of this quickly, hopefully we can get
this backported to the GCC11 series to limit the damage for people using these
newish intrinsics.  I'd love to recommend them for general use, except for this
GCC problem where some distros have already shipped GCC versions that compile
without error but in a 100% broken way.

Portable ways to do narrow alignment/aliasing-safe SIMD loads were sorely
lacking; there aren't good effective workarounds for this, especially for
16-bit loads.  (I still don't know how to portably / safely write code that
will compile to a memory-source PMOVZXBQ across all compilers; Intel's
intrinsics API is rather lacking in some areas and relies on compilers folding
loads into memory source operands.)


> So, isn't that a bug in the intrinsic guide instead?

Yes, __m128i _mm_loadu_si16 only really makes sense with SSE2 for PINSRW.  Even
movzx into an integer reg and then MOVD xmm, eax requires SSE2.  With only SSE1
you'd have to movzx / dword store to stack / MOVSS reload.

SSE1 makes *some* sense for _mm_loadu_si32 since it can be implemented with a
single MOVSS if MOVD isn't available.

But we already have SSE1 __m128 _mm_load_ss(const float *) for that.

Except GCC's implementation of _mm_load_ss isn't alignment and strict-aliasing
safe; it derefs the actual float *__P as _mm_set_ss (*__P).  Which I think is a
bug, although I'm not clear what semantics Intel intended for that intrinsic. 
Clang implements it as alignment/aliasing safe with a packed may_alias struct
containing a float.  MSVC always behaves like -fno-strict-aliasing, and I
*think* ICC does, too.

Perhaps best to follow the crowd and make all narrow load/store intrinsics
alignment and aliasing safe, unless that causes code-gen regressions; users can
_mm_set_ss( *ptr ) themselves if they want that to tell the compiler that's its
a normal C float object.

Was going to report this, but PR84508 is still open and already covers the
relevant ss and sd intrinsics.  That points out that Intel specifically
documents it as not requiring alignment, not mentioning aliasing.



Speaking of bouncing through a GP-integer reg, GCC unfortunately does that; it
seems to incorrectly think PINSRW xmm, mem, 0 requires -msse4.1, unlike with a
GP register source.  Reported as PR105066 along with related missed
optimizations about folding into a memory source operand for pmovzx/sx.

But that's unrelated to correctness; this bug can be closed unless we're
keeping it open until it's fixed in the GCC11 current stable series.

[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

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

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

--- Comment #11 from Jason Merrill  ---
(In reply to Patrick Palka from comment #10)
> That'd work for finish_call_expr and build_new_method call since they're
> given the original arguments, but other callers e.g. build_new_op never see
> the original arguments, so we wouldn't be able to do fold_non_dependent_expr
> from there IIUC.  For build_new_op in particular, we'd have to instead
> fold_non_dependent_expr from _its_ callers, the build_x_* class of
> functions, I think..

Agreed.  Or possibly reorganize them to share the non-dep handling between them
better.

[Bug target/105066] New: GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg

[peter at cordes dot ca via Gcc-bugs]

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

Bug ID: 105066
   Summary: GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not
SSE2?  _mm_loadu_si16 bounces through integer reg
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

PR99754 fixed the wrong-code for _mm_loadu_si16, but the resulting asm is not
efficient without -msse4.1 (as part of -march= most things).  It seems GCC
thinks that pinsrw / pextrw with a memory operand requires SSE4.1, like
pinsr/extr for b/d/q operand-size.  But actually 16-bit insr/extr only needs
SSE2

(We're also not efficiently folding it into a memory source operand for
PMOVZXBQ, see below)

https://godbolt.org/z/dYchb6hec shows GCC trunk 12.0.1 20220321

__m128i load16(void *p){
return _mm_loadu_si16( p );
}


load16(void*): # no options, or -march=core2 or -mssse3
movzwl  (%rdi), %eax
pxor%xmm1, %xmm1
pinsrw  $0, %eax, %xmm1   # should be MOVD %eax, or PINSRW mem
movdqa  %xmm1, %xmm0
ret

vs. 

load16(void*):  # -msse4.1
pxor%xmm1, %xmm1
pinsrw  $0, (%rdi), %xmm1
movdqa  %xmm1, %xmm0
ret


The second version is actually 100% fine with SSE2:
https://www.felixcloutier.com/x86/pinsrw shows that there's only a single
opcode for PINSRW xmm, r32/m16, imm8 and it requires SSE2; reg vs. mem source
is just a matter of the modr/m byte.

The same problem exists for _mm_storeu_si16 not using pextrw to memory (which
is also SSE2), instead bouncing through EAX.  (Insanely still PEXTRW instead of
MOVD).



There is a choice of strategy here, but pinsrw/extrw between eax and xmm0 is
clearly sub-optimal everywhere.  Once we factor out the dumb register
allocation that wastes a movdqa, the interesting options are:

movzwl  (%rdi), %eax  # 1 uop on everything
movd%eax, %xmm0   # 1 uop on everything

vs.

pxor%xmm0, %xmm0# 1 uop for the front-end, eliminated on Intel
pinsrw  $0, (%rdi), %xmm0   # 2 uops  (load + shuffle/merge)


Similarly for extract,

pextrw  $0, %xmm0, (%rdi)   # 2 uops on most

vs.

movd%xmm0, %eax # 1 uop, only 1/clock even on Ice Lake
movw%ax, (%rdi) # 1 uop

On Bulldozer-family, bouncing through an integer reg adds a lot of latency vs.
loading straight into the SIMD unit.  (2 integer cores share a SIMD/FP unit, so
movd between XMM and GP-integer is higher latency than most.)  So that would
definitely favour pinsrw/pextrw with memory.

On Ice Lake, pextrw to mem is 2/clock throughput: the SIMD shuffle can run on
p1/p5.  But MOVD r,v is still p0 only, and MOVD v,r is still p5 only.  So that
also favours pinsrw/pextrw with memory, despite the extra front-end uop for
pxor-zeroing the destination on load.

Of course, if _mm_storeu_si16 is used on a temporary that's later reloaded,
being able to optimize to a movd (and optionally movzx) is very good.  Similar
for _mm_loadu_si16 on a value we have in an integer reg, especially if we know
it's already zero-extended to 32-bit for just a movd, we'd like to be able to
do that.

---

It's also essential that these loads fold efficiently into memory source
operands for PMOVZX; pmovzxbq is one of the major use-cases for a 16-bit load.

That may be a separate bug, IDK

https://godbolt.org/z/3a9T55n3q shows _mm_cvtepu8_epi32(_mm_loadu_si32(p)) does
fold a 32-bit memory source operand nicely to pmovzxbd (%rdi), %xmm0 which can
micro-fuse into a single uop on Intel CPUs (for the 128-bit destination
version, not YMM), but disaster with 16-bit loads:

__m128i pmovzxbq(void *p){
return _mm_cvtepu8_epi64(_mm_loadu_si16(p));
}

pmovzxbq(void*):  # -O3 -msse4.1 -mtune=haswell
pxor%xmm0, %xmm0  # 1 uop
pinsrw  $0, (%rdi), %xmm0 # 2 uops, one for shuffle port
pmovzxbq%xmm0, %xmm0  # 1 uop for the same shuffle port
ret

(_mm_cvtepu8_epi64 requires SSE4.1 so there's no interaction with the
-mno-sse4.1 implementation of the load.)

[Bug c++/102869] [11/12 Regression] Expansion pattern 'std::integer_sequence' contains no parameter packs

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

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

Jason Merrill  changed:

   What|Removed |Added

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

gcc-11-20220326 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 856efb41a873adf2b3e9332cc296c64f6adff240

You'll find:

 gcc-11-20220326.tar.xz   Complete GCC

  SHA256=495a856322cf2b03ac9af5dd7d99d53088089f2f6aedce0c5d7f3a9287b31aea
  SHA1=387bf19afb095b8e0e429f086aefeae3ff57a4f9

Diffs from 11-20220319 are available in the diffs/ subdirectory.

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

[Bug middle-end/103770] [11 Regression] ICE related to VLA

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||niget.tom at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 105065 has been marked as a duplicate of this bug. ***

[Bug middle-end/105065] Internal compiler error (segfault) when calling a function with a sized array parameter returning a type bigger than 16 bytes

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
An exact dup of bug 103770.

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

[Bug c/105065] New: Internal compiler error (segfault) when calling a function with a sized array parameter returning a type bigger than 16 bytes

[niget.tom at gmail dot com via Gcc-bugs]

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

Bug ID: 105065
   Summary: Internal compiler error (segfault) when calling a
function with a sized array parameter returning a type
bigger than 16 bytes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niget.tom at gmail dot com
  Target Milestone: ---

The following code:


# 0 "main.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "main.c"
typedef struct
{
char filler[17];
} big_struct;

big_struct dummy(int size, char array[size]);

int main()
{
dummy(0, 0);
}


Gives the following error when built normally (`gcc main.c`):

during RTL pass: expand
/tmp/gccbug/main.c: In function ‘main’:
/tmp/gccbug/main.c:10:5: internal compiler error: Segmentation fault
   10 | dummy(0, 0); // arguments don't matter
  | ^~~
0xa563ed crash_signal
../../src/gcc/toplev.c:327
0x7f3d8de5651f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x1134db4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1274
0x1134db4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1260
0x1129e96 get_size_range(tree_node*, tree_node**, int)
../../src/gcc/calls.c:1401
0x1129e96 maybe_warn_rdwr_sizes
../../src/gcc/calls.c:2034
0x1129e96 initialize_argument_information
../../src/gcc/calls.c:2626
0x1129e96 expand_call(tree_node*, rtx_def*, int)
../../src/gcc/calls.c:4010
0x105339e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11287
0x10ad851 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../src/gcc/expr.c:8519
0x10ad851 expand_expr
../../src/gcc/expr.h:282
0x10ad851 expand_call_stmt
../../src/gcc/cfgexpand.c:2840
0x10ad851 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3871
0x10ad851 expand_gimple_stmt
../../src/gcc/cfgexpand.c:4035
0x1077e48 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:6077
0x1077e48 execute
../../src/gcc/cfgexpand.c:6761


`big_struct` can be pretty much anything as long as it's strictly bigger than
16 bytes. The types of `size` and `array` do not matter, as long as `array` is
sized with `size`.

The parameters given to `dummy` do not matter (I used 0 and 0 here, but a real
size and array trigger the crash too).

`dummy` must not have an implementation in the same compilation unit as its
call site (it can be implemented in a separate file).

Technical details:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)

[Bug libstdc++/59769] please add ios_base::__noreplace

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

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

--- Comment #8 from Jonathan Wakely  ---
... by LEWG and LWG. It still has to pass at plenary to get into the draft.

[Bug libstdc++/59769] please add ios_base::__noreplace

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

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

--- Comment #7 from Jonathan Wakely  ---
Approved for C++23

[Bug c++/84918] Better handling of "std::cout >> 42;"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.5 |---

[Bug c++/89883] Excessive candidates for ambiguous overload in error message

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-03-26
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Clang just says:

am.C:13:6: error: use of overloaded operator '<<' is ambiguous (with operand
types 'std::ostream' (aka 'basic_ostream') and 'Foo')
  os << Bar;
  ~~ ^  ~~~
am.C:8:14: note: candidate function
std::ostream operator<<( std::ostream& os, Foo );
 ^
am.C:9:14: note: candidate function
std::ostream operator<<( std::ostream& os, Foo const& );
 ^
1 error generated.

[Bug c++/105050] error: expression '' is not a constant expression

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

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

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

[Bug c++/105064] requires crashes gcc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-03-26
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs (as requested when entering a new bug)

Remove mysterious '-# Defining these options here in addition to common.opt is necessary' command-line option (was: [PATCH v2 1/2] add -Wuse-after-free)

[Thomas Schwinge]

Hi!

On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches 
 wrote:
> On 1/11/22 15:40, Jason Merrill wrote:
>> On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
>>> [default setting of the option]

>> Let's put =2 in -Wall for now.

> I've adjusted [...] and pushed r12-6605 [...]

Pushed to master branch commit 43911ddd18b97d8ebd17d2959f36efa539d359b7
"Remove mysterious '-# Defining these options here in addition to
common.opt is necessary' command-line option", see attached.  ;'-)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 43911ddd18b97d8ebd17d2959f36efa539d359b7 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 24 Mar 2022 22:34:30 +0100
Subject: [PATCH] Remove mysterious '-# Defining these options here in addition
 to common.opt is necessary' command-line option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Before:

$ [...]/gcc '-# Defining these options here in addition to common.opt is necessary' -S -x c /dev/null && echo MYSTERIOUS
MYSTERIOUS

After:

$ [...]/gcc '-# Defining these options here in addition to common.opt is necessary' -S -x c /dev/null && echo MYSTERIOUS
gcc: error: unrecognized command-line option ‘-# Defining these options here in addition to common.opt is necessary’

This commit changes:

--- [...]/build-gcc/gcc/optionlist	2022-03-24 22:12:07.936746648 +0100
+++ [...]/build-gcc/gcc/optionlist	2022-03-24 22:30:06.976737341 +0100
@@ -1,4 +1,3 @@
-# Defining these options here in addition to common.opt is necessary# in order for the default -Wall setting of -Wuse-after-free=2 to take# effect.
 ###Driver
 -all-warningsAda AdaWhy AdaSCIL Alias(Wall)
 -all-warningsC ObjC C++ ObjC++ Warning Alias(Wall)
[...]

--- [...]/build-gcc/gcc/options.cc	2022-03-24 22:12:09.548727738 +0100
+++ [...]/build-gcc/gcc/options.cc	2022-03-24 22:30:08.904727249 +0100
@@ -3222,15 +3222,6 @@
 const struct cl_option cl_options[] =
 {
  /* [0] = */ {
-"-# Defining these options here in addition to common.opt is necessary",
-"# effect.",
-NULL,
-NULL,
-NULL, NULL, N_OPTS, N_OPTS, 68, /* .neg_idx = */ -1,
-0,
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-(unsigned short) -1, 0, CLVC_INTEGER, 0, -1, -1 },
- /* [1] = */ {
 "-###",
 NULL,
 NULL,
[...]

..., and re-numbers all following options.

--- [...]/build-gcc/gcc/options.h	2022-03-21 23:24:25.894226828 +0100
+++ [...]/build-gcc/gcc/options.h	2022-03-24 22:30:07.288735708 +0100
@@ -9753,2118 +9753,2117 @@

 enum opt_code
 {
-  OPT___Defining_these_options_here_in_addition_to_common_opt_is_necessary = 0,/* -# Defining these options here in addition to common.opt is necessary */
[...]

..., and likewise re-numbers all following options.

Clean-up for commit 671a283636de75f7ed638ee6b01ed2d44361b8b6
"Add -Wuse-after-free [PR80532]".

	gcc/c-family/
	* c.opt: Properly quote comment.
---
 gcc/c-family/c.opt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 9a4828ebe37..790d47caf0a 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1377,9 +1377,9 @@ Wunused-const-variable=
 C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_unused_const_variable) Warning LangEnabledBy(C ObjC,Wunused-variable, 1, 0) IntegerRange(0, 2)
 Warn when a const variable is unused.
 
-# Defining these options here in addition to common.opt is necessary
-# in order for the default -Wall setting of -Wuse-after-free=2 to take
-# effect.
+; Defining these options here in addition to common.opt is necessary
+; in order for the default -Wall setting of -Wuse-after-free=2 to take
+; effect.
 
 Wuse-after-free
 LangEnabledBy(C ObjC C++ LTO ObjC++)
-- 
2.35.1

[Bug target/105052] Incorrect constraint on SSSE3 split patterns with MMX operands

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.4
 Resolution|--- |FIXED

--- Comment #4 from H.J. Lu  ---
Fixed GCC 12, GCC 11.3 and GCC 10.4.

[Bug testsuite/105055] pr95483-1.c makes incorrect assumption of SSE2 being enabled.

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |11.3

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 12 and GCC 11.3.

[Bug target/105058] Incorrect register constraint in KL patterns

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.3

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 12 and GCC 11.3.

[Bug target/105052] Incorrect constraint on SSSE3 split patterns with MMX operands

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

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

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

https://gcc.gnu.org/g:40e7524ada2f09ec80d8083b9608a10ed516d8fe

commit r10-10514-g40e7524ada2f09ec80d8083b9608a10ed516d8fe
Author: H.J. Lu 
Date:   Thu Mar 24 21:41:12 2022 -0700

x86: Use x constraint on SSSE3 patterns with MMX operands

Since PHADDW/PHADDD/PHADDSW/PHSUBW/PHSUBD/PHSUBSW/PSIGNB/PSIGNW/PSIGND
have no AVX512 version, replace the "Yv" register constraint with the
"x" register constraint.

PR target/105052
* config/i386/sse.md (ssse3_phwv4hi3):
Replace "Yv" with "x".
(ssse3_phdv2si3): Likewise.
(ssse3_psign3): Likewise.

(cherry picked from commit 99591cf43fc1da0fb72b3da02ba937ba30bd2bf2)

[Bug testsuite/105055] pr95483-1.c makes incorrect assumption of SSE2 being enabled.

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

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

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

https://gcc.gnu.org/g:856efb41a873adf2b3e9332cc296c64f6adff240

commit r11-9696-g856efb41a873adf2b3e9332cc296c64f6adff240
Author: H.J. Lu 
Date:   Fri Mar 25 13:53:34 2022 -0700

x86: Use -msse2 on gcc.target/i386/pr95483-1.c

Replace -msse with -msse2 since  requires SSE2.

PR testsuite/105055
* gcc.target/i386/pr95483-1.c: Replace -msse with -msse2.

(cherry picked from commit bdd7b679e8497c07e25726f6ab6429e4c4d429c7)

[Bug target/105058] Incorrect register constraint in KL patterns

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

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

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

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

commit r11-9695-gf0ed5f0763933de8287b3e01aa7fd3efdd77d485
Author: H.J. Lu 
Date:   Fri Mar 25 10:48:16 2022 -0700

x86: Use x constraint on KL patterns

Since KL instructions have no AVX512 version, replace the "v" register
constraint with the "x" register constraint.

PR target/105058
* config/i386/sse.md (loadiwkey): Replace "v" with "x".
(aesu8): Likewise.

(cherry picked from commit ede5f5224d55b84b9f186b288164df9c06fd85e7)

[Bug target/105052] Incorrect constraint on SSSE3 split patterns with MMX operands

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

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

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

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

commit r11-9694-gee25401b10a1ca6157c0a02f49f47e7b253af123
Author: H.J. Lu 
Date:   Thu Mar 24 21:41:12 2022 -0700

x86: Use x constraint on SSSE3 patterns with MMX operands

Since PHADDW/PHADDD/PHADDSW/PHSUBW/PHSUBD/PHSUBSW/PSIGNB/PSIGNW/PSIGND
have no AVX512 version, replace the "Yv" register constraint with the
"x" register constraint.

PR target/105052
* config/i386/sse.md (ssse3_phwv4hi3):
Replace "Yv" with "x".
(ssse3_phdv2si3): Likewise.
(ssse3_psign3): Likewise.

(cherry picked from commit 99591cf43fc1da0fb72b3da02ba937ba30bd2bf2)

RE: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons.

[Roger Sayle]

Hi Aldy,
The proposed frange implementation looks cool.  The one technical tweak is
that if x is not NaN and not +Inf/-Inf, then x*0.0 is [-0.0,0.0].  It's because 
this
result is a range and not a constant that it can’t normally be constant folded,
unless it appears in a context where the sign of zero isn't important (such as
a comparison).

I suspect that frange needs pos_zero_p, neg_zero_p and any_zero_p instead
of just zero_p (and variants r.set_zero) to capture the subtleties.

Cheers,
Roger
--

> -Original Message-
> From: Aldy Hernandez 
> Sent: 21 March 2022 05:56
> To: Jeff Law 
> Cc: Andrew MacLeod ; Roger Sayle
> ; Richard Biener
> ; GCC Patches 
> Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP
> comparisons.
> 
> On Fri, Mar 18, 2022 at 7:33 PM Aldy Hernandez  wrote:
> 
> > > > Consider the following interesting example:
> > > >
> > > > int foo(int x, double y) {
> > > >  return (x * 0.0) < y;
> > > > }
> > > >
> > > > Although we know that x (when converted to double) can't be
> > > > NaN or Inf, we still worry that for negative values of x that
> > > > (x * 0.0) may be -0.0 and so perform the multiplication at
> > > > run-time. But in this case, the result of the comparison (-0.0
> > > > < y) will be exactly the same as (+0.0 < y) for any y, hence
> > > > the above may be safely constant folded to "0.0 <
> > >  y"
> > > > avoiding the multiplication at run-time.
> 
> Ok, once the "frange" infrastructure is in place, it's actually trivial.  See 
> attached
> patch and tests.  We can do everything with small range-op entries and evrp /
> ranger will handle everything else.
> 
> Roger, I believe this is what you described:
> 
> +// { dg-do compile }
> +// { dg-options "-O2 -fno-tree-forwprop -fno-thread-jumps
> -fdump-tree-evrp -fdump-tree-optimized" }
> +
> +extern void link_error ();
> +
> +int foo(int x, double y)
> +{
> +  return (x * 0.0) < y;
> +}
> +
> +// The multiply should be gone by *vrp time.
> +// { dg-final { scan-tree-dump-not " \\* " "evrp" } }
> +
> +// Ultimately, there sound be no references to "x".
> +// { dg-final { scan-tree-dump-not "x_" "optimized" } }
> 
> With the attached patch (and pending patches), we keep track that a cast from
> int to float is guaranteed to not be NaN, which allows us to fold x*0.0 into 
> 0.0,
> and DCE to remove x altogether.  Also, as the other tests show, we are able to
> resolve __builtin_isnan's for the operations implemented.  It should be
> straightforward for someone with floating point foo to extend this to all
> operations.
> 
> Aldy

[Bug middle-end/104885] ICE in compiling new test case g++.dg/other/pr84964.C after r12-7607-ga717376e99fb33

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:41d1f11f5f693a2a06c65c9467a28dfeb02aed85

commit r12-7833-g41d1f11f5f693a2a06c65c9467a28dfeb02aed85
Author: Roger Sayle 
Date:   Sat Mar 26 08:10:27 2022 -1000

PR middle-end/104885: Fix ICE with large stack frame on powerpc64.

My recent testcase for PR c++/84964.C stress tests the middle-end by
attempting to pass a UINT_MAX sized structure on the stack.  Although
my fix to PR84964 avoids the ICE after sorry on x86_64 and similar
targets, a related issue still exists on powerpc64 (and similar
ACCUMULATE_OUTGOING_ARGS/ARGS_GROW_DOWNWARD targets) which don't
issue a "sorry, unimplemented" message, but instead ICE elsewhere.

After attempting several alternate fixes, the simplest solution is
to just defensively check in mark_stack_region_used that the upper
bound of the region lies within the allocated stack_usage_map
array, which is of size highest_outgoing_arg_in_use.  When this isn't
the case, the code now follows the same path as for variable sized
regions, and uses stack_usage_watermark rather than a map.

2022-03-26  Roger Sayle  

gcc/ChangeLog
PR middle-end/104885
* calls.cc (mark_stack_region_used): Check that the region
is within the allocated size of stack_usage_map.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

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

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:41d1f11f5f693a2a06c65c9467a28dfeb02aed85

commit r12-7833-g41d1f11f5f693a2a06c65c9467a28dfeb02aed85
Author: Roger Sayle 
Date:   Sat Mar 26 08:10:27 2022 -1000

PR middle-end/104885: Fix ICE with large stack frame on powerpc64.

My recent testcase for PR c++/84964.C stress tests the middle-end by
attempting to pass a UINT_MAX sized structure on the stack.  Although
my fix to PR84964 avoids the ICE after sorry on x86_64 and similar
targets, a related issue still exists on powerpc64 (and similar
ACCUMULATE_OUTGOING_ARGS/ARGS_GROW_DOWNWARD targets) which don't
issue a "sorry, unimplemented" message, but instead ICE elsewhere.

After attempting several alternate fixes, the simplest solution is
to just defensively check in mark_stack_region_used that the upper
bound of the region lies within the allocated stack_usage_map
array, which is of size highest_outgoing_arg_in_use.  When this isn't
the case, the code now follows the same path as for variable sized
regions, and uses stack_usage_watermark rather than a map.

2022-03-26  Roger Sayle  

gcc/ChangeLog
PR middle-end/104885
* calls.cc (mark_stack_region_used): Check that the region
is within the allocated size of stack_usage_map.

[Bug tree-optimization/104987] [12 Regression] Recent change causing vrp13.c regressions on several targets

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

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

--- Comment #6 from Jeffrey A. Law  ---
For the v850 at least, I'm starting to think this is a simulator bug.  In
particular the simulator code doesn't look safe on a 64bit host for a signed
input to the MUL instruction.

[Bug rtl-optimization/103775] [12 Regression] Assembler messages: Warning: unpredictable transfer with writeback -- `ldrb w0,[x0,16]!'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug c++/105064] New: requires crashes gcc

[janezz55 at gmail dot com via Gcc-bugs]

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

Bug ID: 105064
   Summary: requires crashes gcc
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janezz55 at gmail dot com
  Target Milestone: ---

another gcc crash:
g++ -std=c++20 -Ofast loopdemo.cpp -o s

In file included from loopdemo.cpp:3:
loop.hpp:168:45: internal compiler error: Segmentation fault
  168 | requires(std::is_integral_v);
  | ^
0xe4c988 internal_error(char const*, ...)
???:0
0xf778a4 duplicate_decls(tree_node*, tree_node*, bool, bool)
???:0
0xf82c3b pushdecl_namespace_level(tree_node*, bool)
???:0
0x10ecbfe push_template_decl(tree_node*, bool)
???:0
0x159b601 do_friend(tree_node*, tree_node*, tree_node*, tree_node*,
overload_flags, bool)
???:0
0x1001717 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x105cc75 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
???:0
0x14e7873 c_parse_file()
???:0
0x14c9d9e c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

source code is here:
https://github.com/user1095108/cr/blob/master/loopdemo.cpp

clang++ compiles the code without issue.

Re: [PATCH] fortran: Fix up initializers of param(0) PARAMETERs [PR103691]

[Richard Biener via Gcc-patches]

> Am 26.03.2022 um 12:28 schrieb Thomas Koenig :
> 
> On 25.03.22 12:34, Jakub Jelinek via Fortran wrote:
>> What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i;
>> }, is that applying the side-effects 11 times or once ?
> 
> For side effects during the evaluation of expression, Fortran has a
> clear "if you depend on it, it's your fault" rule.  In F 2018, it says
> 
> 10.1.7  Evaluation of operands
> 
> 1 It is not necessary for a processor to evaluate all of the operands of
> an expression, or to evaluate entirely each operand, if the value of the
> expression can be determined otherwise.
> 
> Also, the semantics of
> 
> a(a:b) = expr
> 
> say that the expression on the LHS is evaluated only once before
> assignment.  So, anything that looks like that should be translated
> to
> 
> tmp = ++i;
> [0..10] = tmp;

Note I was not trying to question middle-end semantic here but gfortran se_expr 
(?) one. Is there a Fortan input where Jakob’s patch would cause a side-effect 
to be dropped and is that valid?

Richard.

> 
> 

Re: [PATCH] middle-end/100786 - constant folding from incompatible alias

[FX via Gcc-patches]

Hi Richard,

The patch for PR100786 introduced a testcase that systematically fails on 
darwin:

FAIL: gcc.dg/torture/pr100786.c   -O0  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O2 -flto -flto-partition=none  (test for 
excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -Os  (test for excess errors)

see https://gcc.gnu.org/pipermail/gcc-testresults/2022-March/757882.html

because

pr100786.c:4:12: error: only weak aliases are supported in this configuration
4 | extern int b __attribute__((alias("a")));
  |^
pr100786.c:8:15: error: only weak aliases are supported in this configuration
8 | extern double b2 __attribute__((alias("a2")));
  |   ^~


FX

[Bug gcov-profile/105063] New: [GCOV] Ability to map .gcda paths

[vit9696 at protonmail dot com via Gcc-bugs]

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

Bug ID: 105063
   Summary: [GCOV] Ability to map .gcda paths
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vit9696 at protonmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When compiling code with `-fprofile-arcs` gcc encodes .gcda file path relative
to object file. In some cases this is infeasible, as the compilation directory
may have extra long prefix, which is not practical to store on embedded
targets.

To avoid this issue we would like to replace this prefix with a custom value.
Currently there are 3 options in GCC, which allow one to do coverage file
mapping:

* -fprofile-dir
* -fprofile-prefix-map
* -fprofile-prefix-path

We assumed that at least one of them should do what we need, yet it is not
true:

* Normal gives /app/output.gcda (https://godbolt.org/z/jaj6vhnd5)
* -fprofile-dir=/test gives /test//app/output.gcda
(https://godbolt.org/z/8h7brYE84)
* -fprofile-prefix-map=/app=/test gives /app/output.gcda
(https://godbolt.org/z/c9TxeMPzM)
* -fprofile-prefix-path=/test -fprofile-generate=/app give
/app//app/output.gcda (https://godbolt.org/z/bh7esxPcK)

I see two routes to solve this issue:

1. One of the existing options is fixed to do this. E.g.
-fprofile-prefix-map=/app=/test could result in /test/output.gcda.
2. A new option is introduced to map gcda files.

The relevant code is in coverage.cc:coverage_init
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/coverage.cc;h=8ece5db680e614f8225d9e8407dd89bd27020b4d;hb=refs/heads/master#l1253).

[Bug rtl-optimization/103775] [12 Regression] Assembler messages: Warning: unpredictable transfer with writeback -- `ldrb w0,[x0,16]!'

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

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

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

https://gcc.gnu.org/g:6459e6537632bc06e04e6011ca7fb6488f0e8e7d

commit r12-7832-g6459e6537632bc06e04e6011ca7fb6488f0e8e7d
Author: Jakub Jelinek 
Date:   Sat Mar 26 16:21:36 2022 +0100

ecog: Return 1 from insn_invalid_p if REG_INC reg overlaps some stored reg
[PR103775]

The following testcase ICEs on aarch64-linux with -g and
assembles with a warning otherwise, because it emits
ldrb w0,[x0,16]!
instruction which sets the x0 register multiple times.
Due to disabled DCE (from -Og) we end up before REE with:
(insn 12 39 13 2 (set (reg:SI 1 x1 [orig:93 _2 ] [93])
(zero_extend:SI (mem/c:QI (pre_modify:DI (reg/f:DI 0 x0 [114])
(plus:DI (reg/f:DI 0 x0 [114])
(const_int 16 [0x10]))) [1 u128_1+0 S1 A128])))
"pr103775.c":5:35 117 {*zero_extendqisi2_aarch64}
 (expr_list:REG_INC (reg/f:DI 0 x0 [114])
(nil)))
(insn 13 12 14 2 (set (reg:DI 0 x0 [orig:112 _2 ] [112])
(zero_extend:DI (reg:SI 1 x1 [orig:93 _2 ] [93])))
"pr103775.c":5:16 111 {*zero_extendsidi2_aarch64}
 (nil))
which is valid but not exactly efficient as x0 is dead after the
insn that auto-increments it.  REE turns it into:
(insn 12 39 44 2 (set (reg:DI 0 x0)
(zero_extend:DI (mem/c:QI (pre_modify:DI (reg/f:DI 0 x0 [114])
(plus:DI (reg/f:DI 0 x0 [114])
(const_int 16 [0x10]))) [1 u128_1+0 S1 A128])))
"pr103775.c":5:35 119 {*zero_extendqidi2_aarch64}
 (expr_list:REG_INC (reg/f:DI 0 x0 [114])
(nil)))
(insn 44 12 14 2 (set (reg:DI 1 x1)
(reg:DI 0 x0)) "pr103775.c":5:35 -1
 (nil))
which is invalid because it sets x0 multiple times, one
in SET_DEST of the PATTERN and once in PRE_MODIFY.
As perhaps other passes than REE might suffer from it, IMHO it is better
to reject this during change validation.

2022-03-26  Jakub Jelinek  

PR rtl-optimization/103775
* recog.cc (check_invalid_inc_dec): New function.
(insn_invalid_p): Return 1 if REG_INC operand overlaps
any stored REGs.

* gcc.dg/pr103775.c: New test.

[Bug c++/103455] [9/10/11 Regression] internal compiler error: in dependent_type_p since r9-713-gd9338471b91bbe6e1

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression]
   |internal compiler error: in |internal compiler error: in
   |dependent_type_p since  |dependent_type_p since
   |r9-713-gd9338471b91bbe6e1   |r9-713-gd9338471b91bbe6e1

--- Comment #11 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug c++/105050] error: expression '' is not a constant expression

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

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

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

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

commit r12-7831-gff465bd8a0f0f96a00d3067018442917b194b7af
Author: Patrick Palka 
Date:   Sat Mar 26 10:20:18 2022 -0400

c++: diagnosing if-stmt with non-constant branches [PR105050]

When an if-stmt is determined to be non-constant because both of its
branches are non-constant, we issue a somewhat generic error which,
since the error also points to the 'if' token, misleadingly suggests
the condition is at fault:

  constexpr-105050.C:8:3: error: expression ââ is not a
constant expression
  8 |   if (p != q && *p < 0)
|   ^~

This patch clarifies the error message to instead read:

  constexpr-105050.C:8:3: error: neither branch of âifâ is a constant
expression
  8 |   if (p != q && *p < 0)
|   ^~

PR c++/105050

gcc/cp/ChangeLog:

* constexpr.cc (potential_constant_expression_1) :
Clarify error message when a if-stmt is non-constant because its
branches are non-constant.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-105050.C: New test.

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p since r9-713-gd9338471b91bbe6e1

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

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

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

https://gcc.gnu.org/g:04f19580e8dbdbc7366d0f5fd068aa0cecafdc9d

commit r12-7830-g04f19580e8dbdbc7366d0f5fd068aa0cecafdc9d
Author: Patrick Palka 
Date:   Sat Mar 26 10:20:16 2022 -0400

c++: ICE when building builtin operator->* set [PR103455]

Here when constructing the builtin operator->* candidate set according
to the available conversion functions for the operand types, we end up
considering a candidate with C1=T (through B's dependent conversion
function) and C2=F, during which we crash from DERIVED_FROM_P because
dependent_type_p sees a TEMPLATE_TYPE_PARM outside of a template
context.

Sidestepping the question of whether we should be considering such a
dependent conversion function here in the first place, it seems futile
to test DERIVED_FROM_P for anything other than an actual class type, so
this patch fixes this ICE by simply guarding the DERIVED_FROM_P test
with CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P.

PR c++/103455

gcc/cp/ChangeLog:

* call.cc (add_builtin_candidate) : Test
CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/overload/builtin6.C: New test.

[Bug target/105058] Incorrect register constraint in KL patterns

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r12-7829-gede5f5224d55b84b9f186b288164df9c06fd85e7
Author: H.J. Lu 
Date:   Fri Mar 25 10:48:16 2022 -0700

x86: Use x constraint on KL patterns

Since KL instructions have no AVX512 version, replace the "v" register
constraint with the "x" register constraint.

PR target/105058
* config/i386/sse.md (loadiwkey): Replace "v" with "x".
(aesu8): Likewise.

[Bug target/105052] Incorrect constraint on SSSE3 split patterns with MMX operands

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:99591cf43fc1da0fb72b3da02ba937ba30bd2bf2

commit r12-7828-g99591cf43fc1da0fb72b3da02ba937ba30bd2bf2
Author: H.J. Lu 
Date:   Thu Mar 24 21:41:12 2022 -0700

x86: Use x constraint on SSSE3 patterns with MMX operands

Since PHADDW/PHADDD/PHADDSW/PHSUBW/PHSUBD/PHSUBSW/PSIGNB/PSIGNW/PSIGND
have no AVX512 version, replace the "Yv" register constraint with the
"x" register constraint.

PR target/105052
* config/i386/sse.md (ssse3_phwv4hi3):
Replace "Yv" with "x".
(ssse3_phdv2si3): Likewise.
(ssse3_psign3): Likewise.

[Bug tree-optimization/105062] New: Suboptimal vectorization for reduction with several elements

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

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

Bug ID: 105062
   Summary: Suboptimal vectorization for reduction with several
elements
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

The testcase is essentially the same as in PR105053, but here this is about
performance, not correctness.

#include 
#include 
#include 
#include 
#include 
#include 

int main(){
  const long n = 1;
  std::vector> vec;
  vec.reserve(n);
  std::random_device rd;
  std::default_random_engine re(rd());
  std::uniform_int_distribution rand_int;
  std::uniform_real_distribution rand_dbl;
  for(int i=0;i(vec[i]),std::get<1>(vec[i])));
volatile int noopt0 = sup;
  }
#else
  {
int sup = 0;
for(int i=0;i(vec[i])),std::get<1>(vec[i]));
volatile int noopt1 = sup;
  }
#endif
  auto finish = std::chrono::system_clock::now();
  std::cout << std::chrono::duration_cast(finish -
start).count() << '\n';
}


I compile with -O3 -march=skylake (originally noticed with -march=native on a
i7-10875H CPU).

The second loop runs in about 60ms, while the first (compiling with -DSLOW)
runs in 80ms. The generated asm also looks very different. For the fast code,
the core loop is

.L64:
vmovdqu (%rax), %ymm3
addq$64, %rax
vpunpckldq  -32(%rax), %ymm3, %ymm0
vpermd  %ymm0, %ymm2, %ymm0
vpmaxsd %ymm0, %ymm1, %ymm1
cmpq%rdx, %rax
jne .L64

which looks nice and compact (well, I think we could do without the vpermd, but
it is already great). Now for the slow code, we have

.L64:
vmovdqu (%rax), %ymm0
vmovdqu 32(%rax), %ymm10
vmovdqu 64(%rax), %ymm2
vmovdqu 96(%rax), %ymm9
vpermd  %ymm10, %ymm6, %ymm8
vpermd  %ymm0, %ymm7, %ymm1
vpblendd$240, %ymm8, %ymm1, %ymm1
vpermd  %ymm9, %ymm6, %ymm11
vpermd  %ymm2, %ymm7, %ymm8
vpermd  %ymm0, %ymm4, %ymm0
vpermd  %ymm10, %ymm3, %ymm10
vpermd  %ymm2, %ymm4, %ymm2
vpermd  %ymm9, %ymm3, %ymm9
vpblendd$240, %ymm11, %ymm8, %ymm8
vpblendd$240, %ymm10, %ymm0, %ymm0
vpblendd$240, %ymm9, %ymm2, %ymm2
vpermd  %ymm1, %ymm4, %ymm1
vpermd  %ymm8, %ymm3, %ymm8
vpermd  %ymm0, %ymm4, %ymm0
vpermd  %ymm2, %ymm3, %ymm2
vpblendd$240, %ymm8, %ymm1, %ymm1
vpblendd$240, %ymm2, %ymm0, %ymm0
vpmaxsd %ymm0, %ymm1, %ymm1
subq$-128, %rax
vpmaxsd %ymm1, %ymm5, %ymm5
cmpq%rdx, %rax
jne .L64

It is unrolled once more than the fast code and contains an excessive amount of
shuffling. If I understand correctly, it vectorizes a reduction with MAX_EXPR
on "sup" but does not consider the operation max(get<0>,get<1>) as being part
of this reduction, so it generates code that would make sense if I used 2
different operations like

  sup=std::max(sup,std::get<0>(vec[i])+std::get<1>(vec[i]))

instead of both being the same MAX_EXPR. Maybe, when we discover a reduction,
we could check if the elements are themselves computed with the same operation
as the reduction and in that case try to make it a "bigger" reduction?

[Bug analyzer/105057] [12 Regression] ICE: in get_or_create_cluster, at analyzer/store.cc:2658 with -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

Sorry for the breakage, and thanks again for filing this bug.

[committed] analyzer: fix ICE on memset of untracked region [PR105057]

[David Malcolm via Gcc-patches]

In r12-7809-g5f6197d7c197f9d2b7fb2e1a19dac39a023755e8 I added an
optimization to avoid tracking the state of certain memory regions
in the store.

Unfortunately, I didn't cover every way in which
store::get_or_create_cluster can be called for a base region, leading
to assertion failure ICEs in -fanalyzer on certain function calls
with certain params.

I've worked through all uses of store::get_or_create_cluster and found
four places where the assertion could fire.

This patch fixes them, and adds regression tests where possible.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7827-g8c8993c75309901e03418eba1d6239b9a39a43b7.

gcc/analyzer/ChangeLog:
PR analyzer/105057
* store.cc (binding_cluster::make_unknown_relative_to): Reject
attempts to create a cluster for untracked base regions.
(store::set_value): Likewise.
(store::fill_region): Likewise.
(store::mark_region_as_unknown): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/105057
* gcc.dg/analyzer/fread-2.c: New test, as a regression test for
ICE in store::set_value on untracked base region.
* gcc.dg/analyzer/memset-2.c: Likewise, for ICE in
store::fill_region.
* gcc.dg/analyzer/strcpy-2.c: Likewise, for ICE in
store::mark_region_as_unknown.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/store.cc| 17 ++---
 gcc/testsuite/gcc.dg/analyzer/fread-2.c  | 31 
 gcc/testsuite/gcc.dg/analyzer/memset-2.c | 27 +
 gcc/testsuite/gcc.dg/analyzer/strcpy-2.c | 27 +
 4 files changed, 98 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/fread-2.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/memset-2.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/strcpy-2.c

diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index 62733b9777f..9aa7d690b04 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -1823,7 +1823,8 @@ binding_cluster::make_unknown_relative_to (const 
binding_cluster *other,
{
  const region *base_reg
= region_sval->get_pointee ()->get_base_region ();
- if (!base_reg->symbolic_for_unknown_ptr_p ())
+ if (base_reg->tracked_p ()
+ && !base_reg->symbolic_for_unknown_ptr_p ())
{
  binding_cluster *c = out_store->get_or_create_cluster (base_reg);
  c->mark_as_escaped ();
@@ -2384,11 +2385,17 @@ store::set_value (store_manager *mgr, const region 
*lhs_reg,
  mark_as_escaped (ptr_base_reg);
}
 }
-  else
+  else if (lhs_base_reg->tracked_p ())
 {
   lhs_cluster = get_or_create_cluster (lhs_base_reg);
   lhs_cluster->bind (mgr, lhs_reg, rhs_sval);
 }
+  else
+{
+  /* Reject attempting to bind values into an untracked region;
+merely invalidate values below.  */
+  lhs_cluster = NULL;
+}
 
   /* Bindings to a cluster can affect other clusters if a symbolic
  base region is involved.
@@ -2564,7 +2571,8 @@ void
 store::fill_region (store_manager *mgr, const region *reg, const svalue *sval)
 {
   const region *base_reg = reg->get_base_region ();
-  if (base_reg->symbolic_for_unknown_ptr_p ())
+  if (base_reg->symbolic_for_unknown_ptr_p ()
+  || !base_reg->tracked_p ())
 return;
   binding_cluster *cluster = get_or_create_cluster (base_reg);
   cluster->fill_region (mgr, reg, sval);
@@ -2587,7 +2595,8 @@ store::mark_region_as_unknown (store_manager *mgr, const 
region *reg,
   uncertainty_t *uncertainty)
 {
   const region *base_reg = reg->get_base_region ();
-  if (base_reg->symbolic_for_unknown_ptr_p ())
+  if (base_reg->symbolic_for_unknown_ptr_p ()
+  || !base_reg->tracked_p ())
 return;
   binding_cluster *cluster = get_or_create_cluster (base_reg);
   cluster->mark_region_as_unknown (mgr, reg, uncertainty);
diff --git a/gcc/testsuite/gcc.dg/analyzer/fread-2.c 
b/gcc/testsuite/gcc.dg/analyzer/fread-2.c
new file mode 100644
index 000..02a5e31cec6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/fread-2.c
@@ -0,0 +1,31 @@
+/* { dg-additional-options "-fdump-analyzer-untracked" } */
+
+#include "analyzer-decls.h"
+
+struct S
+{
+  int i;
+};
+
+typedef __SIZE_TYPE__ size_t;
+
+extern size_t fread (void *, size_t, size_t, void *);
+
+/* fread of a static struct that never gets used.  */
+
+void
+test_1 (void *fp)
+{
+  static struct S s; /* { dg-warning "track 's': no" } */
+  fread (, sizeof (s), 1, fp);
+}
+
+/* fread of a static struct that later gets used.  */
+
+int
+test_2 (void *fp)
+{
+  static struct S s; /* { dg-warning "track 's': yes" } */
+  fread (, sizeof (s), 1, fp);
+  return s.i;
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/memset-2.c 
b/gcc/testsuite/gcc.dg/analyzer/memset-2.c
new file mode 100644
index 000..de7c973b1fd
--- /dev/null
+++ 

[Bug analyzer/105057] [12 Regression] ICE: in get_or_create_cluster, at analyzer/store.cc:2658 with -fanalyzer

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

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

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

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

commit r12-7827-g8c8993c75309901e03418eba1d6239b9a39a43b7
Author: David Malcolm 
Date:   Fri Mar 25 16:50:51 2022 -0400

analyzer: fix ICE on memset of untracked region [PR105057]

In r12-7809-g5f6197d7c197f9d2b7fb2e1a19dac39a023755e8 I added an
optimization to avoid tracking the state of certain memory regions
in the store.

Unfortunately, I didn't cover every way in which
store::get_or_create_cluster can be called for a base region, leading
to assertion failure ICEs in -fanalyzer on certain function calls
with certain params.

I've worked through all uses of store::get_or_create_cluster and found
four places where the assertion could fire.

This patch fixes them, and adds regression tests where possible.

gcc/analyzer/ChangeLog:
PR analyzer/105057
* store.cc (binding_cluster::make_unknown_relative_to): Reject
attempts to create a cluster for untracked base regions.
(store::set_value): Likewise.
(store::fill_region): Likewise.
(store::mark_region_as_unknown): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/105057
* gcc.dg/analyzer/fread-2.c: New test, as a regression test for
ICE in store::set_value on untracked base region.
* gcc.dg/analyzer/memset-2.c: Likewise, for ICE in
store::fill_region.
* gcc.dg/analyzer/strcpy-2.c: Likewise, for ICE in
store::mark_region_as_unknown.

Signed-off-by: David Malcolm 

https://vm.tiktok.com/ZMLuVs9oV/Be anonymous, ever wanted to send a text message anonymously for free

[Paul Small via Gcc]

Learn how to send an sms text message anonymously using Termux right now
hit the link to start : https://vm.tiktok.com/ZMLuVs9oV/

Thank me later 

Kind regards

Dave Hackwell
Prod team leader

Re: [PATCH] fortran: Fix up initializers of param(0) PARAMETERs [PR103691]

[Thomas Koenig via Gcc-patches]

On 25.03.22 12:34, Jakub Jelinek via Fortran wrote:

What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i;
}, is that applying the side-effects 11 times or once ?


For side effects during the evaluation of expression, Fortran has a
clear "if you depend on it, it's your fault" rule.  In F 2018, it says

10.1.7  Evaluation of operands

1 It is not necessary for a processor to evaluate all of the operands of
an expression, or to evaluate entirely each operand, if the value of the
expression can be determined otherwise.

Also, the semantics of

a(a:b) = expr

say that the expression on the LHS is evaluated only once before
assignment.  So, anything that looks like that should be translated
to

tmp = ++i;
[0..10] = tmp;

[Bug c++/105061] [9/10 Regression] [c++2a+] anonymous bitfield templated offset rejected

[wjwray at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Will Wray  ---
Hmm, the accepted simplified version ^^^ with typename parameter removed
is then rejected if 'unsigned' is replaced with 'uint32_t' from 

#include 
template 
struct uint_offset_bitfield { uint32_t : offset, field : width; };
|  ^
| error: found ':' in nested-name-specifier, expected '::'
|  ::
| error: invalid use of '::'

(and "error: invalid use of '::'" is just wrong - no use of '::' at all)

[Bug c++/105061] New: [9/10 Regression] [c++2a+] anonymous bitfield templated offset rejected

[wjwray at gmail dot com via Gcc-bugs]

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

Bug ID: 105061
   Summary: [9/10 Regression] [c++2a+] anonymous bitfield
templated offset rejected
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

A very specific regression: https://godbolt.org/z/dWxnvd93j

template 
struct offset_bitfield { alloc_unit : offset, field : width; };

 accepted forever  with -std=c++17-
 accepted in  9.4  with -std=c++2a
 rejected in 10.1+ with -std=c++20+
(accepted in Clang & MSVC, any std)

My guess as to the cause: the c++20 change to allow bitfield initializers.

template 
struct offset_bitfield { alloc_unit : offset, field : width; };
//  ^   ^
// error: found ':' in nested-name-specifier, expected '::'
// error: expected unqualified-id before ',' token

The template is accepted if the typename parameter is removed:

template 
struct uint_offset_bitfield { unsigned : offset, field : width; };

[Bug c++/55357] -Wshadow warns about lambda function parameters matching variables in outer scope

[jcl at nvidia dot com via Gcc-bugs]

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

JC Liang  changed:

   What|Removed |Added

 CC||jcl at nvidia dot com

--- Comment #4 from JC Liang  ---
Could we reevaluate this case? I think it's not necessary to warning about
lambda parameters shadowing local vars in outer scope, because it's simply
won't compile.
MSVC's default-on policy C4457 doesn't have this issue. Our project is cross
platform so we really want to have parity in different compiler for this
warning.

[Bug target/105058] Incorrect register constraint in KL patterns

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
cat test.c

 #include 

 unsigned int ctrl;
 __m128i k1, k2, k3;

 void
 test_keylocker_11 (void)
 {
   register __m128i k4 __asm ("xmm16") = k2;
  asm volatile ("" : "+v" (k4));
  _mm_loadiwkey (ctrl, k1, k4, k3);
 }

gcc -O2 -march=skylake-avx512 -mkl -c


/tmp/ccy9VHP9.s: Assembler messages:
/tmp/ccy9VHP9.s:13: Error: unsupported instruction `loadiwkey'

Re: [PATCH] x86: Use x constraint on KL patterns

[Hongtao Liu via Gcc-patches]

On Sat, Mar 26, 2022 at 10:05 AM Hongyu Wang via Gcc-patches
 wrote:
>
> > > Is it possible to create a test case that gas would throw an error for
> > > invalid operands?
> >
> > You can use -ffix-xmmN to disable XMM0-15.
>
> I mean can we create an intrinsic test for this PR that produces xmm16-31?
> And the -ffix-xmmN is an option for assembler or compiler? I didn't
> find it in document.
Can be reproduced by below testcase.
 #include 

 unsigned int ctrl;
 __m128i k1, k2, k3;

 void
 test_keylocker_11 (void)
 {
   register __m128i k4 __asm ("xmm16") = k2;
  asm volatile ("" : "+v" (k4));
  _mm_loadiwkey (ctrl, k1, k4, k3);
}

/tmp/ccy9VHP9.s: Assembler messages:
/tmp/ccy9VHP9.s:13: Error: unsupported instruction `loadiwkey'

>
> H.J. Lu  于2022年3月26日周六 09:22写道：
> >
> > On Fri, Mar 25, 2022 at 6:08 PM Hongyu Wang  wrote:
> > >
> > > Is it possible to create a test case that gas would throw an error for
> > > invalid operands?
> >
> > You can use -ffix-xmmN to disable XMM0-15.
> >
> > > H.J. Lu via Gcc-patches  于2022年3月26日周六 04:50写道：
> > > >
> > > > Since KL instructions have no AVX512 version, replace the "v" register
> > > > constraint with the "x" register constraint.
> > > >
> > > > PR target/105058
> > > > * config/i386/sse.md (loadiwkey): Replace "v" with "x".
> > > > (aesu8): Likewise.
> > > > ---
> > > >  gcc/config/i386/sse.md | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> > > > index 29802d00ce6..33bd2c4768a 100644
> > > > --- a/gcc/config/i386/sse.md
> > > > +++ b/gcc/config/i386/sse.md
> > > > @@ -28364,8 +28364,8 @@ (define_insn "avx512f_dpbf16ps__mask"
> > > >
> > > >  ;; KEYLOCKER
> > > >  (define_insn "loadiwkey"
> > > > -  [(unspec_volatile:V2DI [(match_operand:V2DI 0 "register_operand" "v")
> > > > - (match_operand:V2DI 1 "register_operand" "v")
> > > > +  [(unspec_volatile:V2DI [(match_operand:V2DI 0 "register_operand" "x")
> > > > + (match_operand:V2DI 1 "register_operand" "x")
> > > >   (match_operand:V2DI 2 "register_operand" "Yz")
> > > >   (match_operand:SI   3 "register_operand" "a")]
> > > >  UNSPECV_LOADIWKEY)
> > > > @@ -28498,7 +28498,7 @@ (define_int_attr aesklvariant
> > > > (UNSPECV_AESENC256KLU8 "enc256kl")])
> > > >
> > > >  (define_insn "aesu8"
> > > > -  [(set (match_operand:V2DI 0 "register_operand" "=v")
> > > > +  [(set (match_operand:V2DI 0 "register_operand" "=x")
> > > > (unspec_volatile:V2DI [(match_operand:V2DI 1 "register_operand" 
> > > > "0")
> > > >(match_operand:BLK   2 "memory_operand" 
> > > > "m")]
> > > >   AESDECENCKL))
> > > > --
> > > > 2.35.1
> > > >
> >
> >
> >
> > --
> > H.J.



-- 
BR,
Hongtao

Re: [PATCH] x86: Use x constraint on SSSE3 patterns with MMX operands

[Hongtao Liu via Gcc-patches]

On Sat, Mar 26, 2022 at 1:27 AM H.J. Lu via Gcc-patches
 wrote:
>
> Since PHADDW/PHADDD/PHADDSW/PHSUBW/PHSUBD/PHSUBSW/PSIGNB/PSIGNW/PSIGND
> have no AVX512 version, replace the "Yv" register constraint with the
> "x" register constraint.
LGTM, please backport to GCC10/GCC11 branch.
>
> PR target/105052
> * config/i386/sse.md (ssse3_phwv4hi3):
> Replace "Yv" with "x".
> (ssse3_phdv2si3): Likewise.
> (ssse3_psign3): Likewise.
> ---
>  gcc/config/i386/sse.md | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 6f7af2f21d6..aae29cd462f 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -20112,12 +20112,12 @@ (define_insn "ssse3_phwv8hi3"
> (set_attr "mode" "TI")])
>
>  (define_insn_and_split "ssse3_phwv4hi3"
> -  [(set (match_operand:V4HI 0 "register_operand" "=y,x,Yv")
> +  [(set (match_operand:V4HI 0 "register_operand" "=y,x,x")
> (ssse3_plusminus:V4HI
>   (vec_select:V4HI
> (vec_concat:V8HI
> - (match_operand:V4HI 1 "register_operand" "0,0,Yv")
> - (match_operand:V4HI 2 "register_mmxmem_operand" "ym,x,Yv"))
> + (match_operand:V4HI 1 "register_operand" "0,0,x")
> + (match_operand:V4HI 2 "register_mmxmem_operand" "ym,x,x"))
> (parallel
>   [(const_int 0) (const_int 2) (const_int 4) (const_int 6)]))
>   (vec_select:V4HI
> @@ -20199,12 +20199,12 @@ (define_insn "ssse3_phdv4si3"
> (set_attr "mode" "TI")])
>
>  (define_insn_and_split "ssse3_phdv2si3"
> -  [(set (match_operand:V2SI 0 "register_operand" "=y,x,Yv")
> +  [(set (match_operand:V2SI 0 "register_operand" "=y,x,x")
> (plusminus:V2SI
>   (vec_select:V2SI
> (vec_concat:V4SI
> - (match_operand:V2SI 1 "register_operand" "0,0,Yv")
> - (match_operand:V2SI 2 "register_mmxmem_operand" "ym,x,Yv"))
> + (match_operand:V2SI 1 "register_operand" "0,0,x")
> + (match_operand:V2SI 2 "register_mmxmem_operand" "ym,x,x"))
> (parallel [(const_int 0) (const_int 2)]))
>   (vec_select:V2SI
> (vec_concat:V4SI (match_dup 1) (match_dup 2))
> @@ -20702,10 +20702,10 @@ (define_insn "_psign3"
> (set_attr "mode" "")])
>
>  (define_insn "ssse3_psign3"
> -  [(set (match_operand:MMXMODEI 0 "register_operand" "=y,x,Yv")
> +  [(set (match_operand:MMXMODEI 0 "register_operand" "=y,x,x")
> (unspec:MMXMODEI
> - [(match_operand:MMXMODEI 1 "register_operand" "0,0,Yv")
> -  (match_operand:MMXMODEI 2 "register_mmxmem_operand" "ym,x,Yv")]
> + [(match_operand:MMXMODEI 1 "register_operand" "0,0,x")
> +  (match_operand:MMXMODEI 2 "register_mmxmem_operand" "ym,x,x")]
>   UNSPEC_PSIGN))]
>"(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
>"@
> --
> 2.35.1
>


-- 
BR,
Hongtao

Re: [PATCH] x86: Use x constraint on KL patterns

[Hongtao Liu via Gcc-patches]

On Sat, Mar 26, 2022 at 4:50 AM H.J. Lu via Gcc-patches
 wrote:
>
> Since KL instructions have no AVX512 version, replace the "v" register
> constraint with the "x" register constraint.
>
> PR target/105058
> * config/i386/sse.md (loadiwkey): Replace "v" with "x".
> (aesu8): Likewise.
LGTM, please backport to GCC11.
> ---
>  gcc/config/i386/sse.md | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 29802d00ce6..33bd2c4768a 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -28364,8 +28364,8 @@ (define_insn "avx512f_dpbf16ps__mask"
>
>  ;; KEYLOCKER
>  (define_insn "loadiwkey"
> -  [(unspec_volatile:V2DI [(match_operand:V2DI 0 "register_operand" "v")
> - (match_operand:V2DI 1 "register_operand" "v")
> +  [(unspec_volatile:V2DI [(match_operand:V2DI 0 "register_operand" "x")
> + (match_operand:V2DI 1 "register_operand" "x")
>   (match_operand:V2DI 2 "register_operand" "Yz")
>   (match_operand:SI   3 "register_operand" "a")]
>  UNSPECV_LOADIWKEY)
> @@ -28498,7 +28498,7 @@ (define_int_attr aesklvariant
> (UNSPECV_AESENC256KLU8 "enc256kl")])
>
>  (define_insn "aesu8"
> -  [(set (match_operand:V2DI 0 "register_operand" "=v")
> +  [(set (match_operand:V2DI 0 "register_operand" "=x")
> (unspec_volatile:V2DI [(match_operand:V2DI 1 "register_operand" "0")
>(match_operand:BLK   2 "memory_operand" "m")]
>   AESDECENCKL))
> --
> 2.35.1
>


-- 
BR,
Hongtao

[Bug c++/105060] New: [10/11] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:14879 with keep-inline-functions

[lutztonineubert at gmail dot com via Gcc-bugs]

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

Bug ID: 105060
   Summary: [10/11] ICE with consteval function: internal compiler
error: in cp_gimplify_expr, at cp/cp-gimplify.c:14879
with keep-inline-functions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lutztonineubert at gmail dot com
  Target Milestone: ---

Compiled with g++ 10/11 and -fkeep-inline-functions -std=c++20. Doesn't seem to
happen with current trunk.

ERROR:

: In constructor 'consteval
basic_format_string::basic_format_string(const S&) [with S = char [1];
Args = {char, }]':
:19:5: internal compiler error: in gimplify_expr, at gimplify.c:14879
   19 | if (!check()) {
  | ^~
0x1786229 internal_error(char const*, ...)
???:0
0x678608 fancy_abort(char const*, int, char const*)
???:0
0xab0f92 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab1068 gimplify_stmt(tree_node**, gimple**)
???:0
0xaaebb2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab1068 gimplify_stmt(tree_node**, gimple**)
???:0
0xab212b gimplify_body(tree_node*, bool)
???:0
0xab259f gimplify_function_tree(tree_node*)
???:0
0x943cf7 cgraph_node::analyze()
???:0
0x94707d symbol_table::finalize_compilation_unit()
???:0

CODE:

template 
struct type_identity {
  using type = T;
};

template 
using type_identity_t = typename type_identity::type;

constexpr int check() {
  return {};
}

template 
class basic_format_string {
 public:
  template 
  consteval basic_format_string(const S& s) {
if (!check()) {
}
  }
};

template 
using format_string = basic_format_string...>;

template 
void test(format_string format_str, const Args&... args) {}

enum { Blue };

void g() {
  test("", Blue);
}



See: https://gcc.godbolt.org/z/M7v96YPn1