[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #33 from Martin Liška  ---
> Tested today's gcc against firefox-86 in lto+pgo mode. Built fine. Thank you!

I thank you. You tested various attempts I proposed :)

[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-03-06

--- Comment #1 from Martin Liška  ---
Please provide the mentioned tarball and what compiler options are used for the
SPEC run?

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Seems the latest change resulted in various inline asms with "=m" constraint to
fall through into return false rather than decompose_address.
The problem to me seems to be that constraint is "=m" (and generally, it is the
whole constraint string, rather than some particular constraint in it),
and lookup_constraint looks up only a particular constraint (say "m") etc.
So it only returns something other than CONSTRAINT__UNKNOWN if it is an input
operand rather than output (because that necessarily starts with = or +) and
doesn't have any other modifiers etc. in it and it has a single variant or the
first variant is the one that is considered.
There are other spots that do the same though, e.g. simplify_operand_subreg:
  || ((get_constraint_type (lookup_constraint
(curr_static_id->operand[nop].constraint))
   != CT_SPECIAL_MEMORY)
While e.g. process_alt_operands walks the whole constraint string and handles
everything in there.

I'm afraid I must be missing something important.

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Last reconfirmed||2021-03-06
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668

[nilsgladitz at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Nils Gladitz  ---
Not sure if this is helpful at all but I think I ran into the same issue and
reduced it to the following which is slightly shorter but also keeps the
standard C++ includes intact (manually reintroduced them after reduction):

#include 
#include 

struct a {
  a();
};

struct task {
  struct promise_type {
std::suspend_always initial_suspend();
std::suspend_always final_suspend() noexcept;
void unhandled_exception();
task get_return_object();
  };

  std::suspend_always c(a);

  a bar(std::initializer_list);

 task e() {
co_await c(bar({a{}}));
  }
};

[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668

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

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

--- Comment #5 from Iain Sandoe  ---
thanks for the reports (I have some idea about where the issue is coming from,
but not fixed yet).

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Alexander Lelyakin  changed:

   What|Removed |Added

 CC||alexander.lelyakin@googlema
   ||il.com

--- Comment #1 from Alexander Lelyakin  ---
Just want to express my current understanding of situation.

Here:

https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html#C_002b_002b-Modules

is stated:
"The Standard Library is not provided as importable header units. If you want
to import such units, you must explicitly build them first. If you do not do
this with care, you may have multiple declarations, which the module machinery
must merge—compiler resource usage can be affected by how you partition header
files into header units."


Any header file in "/usr[/local]/include/c++/11[.0.1]" can be precompiled as a
header module like:

g++ -std=c++20 -fmodules-ts -x c++-system-header iostream

And can be successfully used as:

import ;

int main()
{
  std::cout<<"Hello\n";
  return 0;
}

g++ -std=c++20 -fmodules-ts test.c++


However if you will compile more than one header into the same 'gcm.cache'
directory, you will receive various compiler errors depending of order of
compilation of headers.

Currently there is no way to compile all headers. Longest sequence i have seen
so far was 35 headers, shortest - just 2.

This meta bug will accumulate bug reports discovered during attempts to
precompile system headers.

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

--- Comment #2 from Jakub Jelinek  ---
I see the function is called before selecting a particular alternative, so
perhaps it means to care only about constraints like "X" and "" and not say
that mixed with other constraints etc.
But, shouldn't the code at least skip the =, +, &, % and whitespace from the
start?  What about other modifiers (the various disparage slightly etc. chars)?
And only consider as empty constraint if after those skips constraint is ""?
Not really sure if ",,," constraint is valid...
And, regarding of Eric's change to handle "X" that way, does that really apply
just to MEM and not SUBREG of MEM too?

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

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

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

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

https://gcc.gnu.org/g:84185598dc7470bad4e7f8c22b64e3c944efb670

commit r11-7542-g84185598dc7470bad4e7f8c22b64e3c944efb670
Author: Jakub Jelinek 
Date:   Sat Mar 6 11:11:30 2021 +0100

libstdc++: Improve std::rot[lr] [PR99396]

As can be seen on:

unsigned char f1 (unsigned char x, int y) { return std::rotl (x, y); }
unsigned char f2 (unsigned char x, int y) { return std::rotr (x, y); }
unsigned short f3 (unsigned short x, int y) { return std::rotl (x, y); }
unsigned short f4 (unsigned short x, int y) { return std::rotr (x, y); }
unsigned int f5 (unsigned int x, int y) { return std::rotl (x, y); }
unsigned int f6 (unsigned int x, int y) { return std::rotr (x, y); }
unsigned long int f7 (unsigned long int x, int y) { return std::rotl (x,
y); }
unsigned long int f8 (unsigned long int x, int y) { return std::rotr (x,
y); }
unsigned long long int f9 (unsigned long long int x, int y) { return
std::rotl (x, y); }
unsigned long long int f10 (unsigned long long int x, int y) { return
std::rotr (x, y); }
//unsigned __int128 f11 (unsigned __int128 x, int y) { return std::rotl (x,
y); }
//unsigned __int128 f12 (unsigned __int128 x, int y) { return std::rotr (x,
y); }

constexpr auto a = std::rotl (1234U, 0);
constexpr auto b = std::rotl (1234U, 5);
constexpr auto c = std::rotl (1234U, -5);
constexpr auto d = std::rotl (1234U, -__INT_MAX__ - 1);
the current  definitions of std::__rot[lr] aren't pattern recognized
as rotates, they are too long/complex for that, starting with signed
modulo,
special case for 0 and different cases for positive and negative.

For types with power of two bits the following patch adds definitions that
the compiler can pattern recognize and turn e.g. on x86_64 into
ro[lr][bwlq]
instructions.  For weirdo types like unsigned __int20 etc. it keeps the
current definitions.

2021-03-06  Jakub Jelinek  

PR libstdc++/99396
* include/std/bit (__rotl, __rotr): Add optimized variants for
power of
two _Nd which the compiler can pattern match the rotates.

[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/99405] Rotate with mask not optimized on x86 for QI/HImode rotates

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
Bug 99405 depends on bug 99396, which changed state.

Bug 99396 Summary: std::rotl and std::rotr Does not convert into ROTATE on the 
gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396

   What|Removed |Added

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

[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288

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

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

--- Comment #15 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566366.html

[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833

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

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

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

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

commit r10-9419-ged8fede89a705b031d3123c502717d7bc8b29320
Author: Tobias Burnus 
Date:   Fri Mar 5 11:41:44 2021 +0100

OpenACC: C/C++ - fix async parsing [PR99137]

gcc/c/ChangeLog:

PR c/99137
* c-parser.c (c_parser_oacc_clause_async): Reject comma
expressions.

gcc/cp/ChangeLog:

PR c/99137
* parser.c (cp_parser_oacc_clause_async): Reject comma expressions.

gcc/testsuite/ChangeLog:

PR c/99137
* c-c++-common/goacc/asyncwait-1.c: Update dg-error; add
additional test.

(cherry picked from commit 6ddedd3efa3fe482f76a4037521a06b3ac9f2a8b)

[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:47a0284fe7d4c996cc054c13e196ee3983025fb3

commit r9-9270-g47a0284fe7d4c996cc054c13e196ee3983025fb3
Author: Tobias Burnus 
Date:   Fri Mar 5 11:41:44 2021 +0100

OpenACC: C/C++ - fix async parsing [PR99137]

gcc/c/ChangeLog:

PR c/99137
* c-parser.c (c_parser_oacc_clause_async): Reject comma
expressions.

gcc/cp/ChangeLog:

PR c/99137
* parser.c (cp_parser_oacc_clause_async): Reject comma expressions.

gcc/testsuite/ChangeLog:

PR c/99137
* c-c++-common/goacc/asyncwait-1.c: Update dg-error; add
additional test.

(cherry picked from commit 6ddedd3efa3fe482f76a4037521a06b3ac9f2a8b)

[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  ---
FIXED on mainline (GCC 11), GCC 10 and GCC 9.

Thanks for the report!

As mentioned in the patch review at
  https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566298.html
the issue was discussed in a OpenACC spec meeting (Issue 354) and it was agreed
but not yet voted on to use the OpenMP wording (valid assignment-expression).

When writing that patch, I tried to find likewise issues with other clauses.
Unless I missed one in 'gcc' or 'g++', it seems as if only 'async' was
affected.

[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #26 from David Binderman  ---
Quite interestingly, this ice can also be made with C testsuite file
./gcc.dg/pr99122-3.c at -O2

It seems to have been iceing since before 20210214.

[Bug c++/99429] New: ICE for bool return from <=>

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

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

Bug ID: 99429
   Summary: ICE for bool return from <=>
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

Created attachment 50315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50315&action=edit
std::strong_ordering and incorrect duration code

When erronously declaring <=> to return bool, g++ crashes:

> g++ -c -std=c++20 chrono.cc
chrono.cc: In instantiation of ‘class duration<1>’:
chrono.cc:44:42:   required from here
chrono.cc:38:20: internal compiler error: Segmentation fault
   38 | constexpr bool operator<=> (const duration& d) const = default;
  |^~~~

[Bug c++/99429] ICE for bool return from <=>

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

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

Mike Sharov  changed:

   What|Removed |Added

  Attachment #50315|0   |1
is obsolete||

--- Comment #1 from Mike Sharov  ---
Created attachment 50316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50316&action=edit
incorrect duration

[Bug gcov-profile/99406] [11 regression] MAP_ANONYMOUS undeclared in libgcov.h

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

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

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

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

commit r11-7543-g73a9216b8a47889234c94e3aaec193391ee6604d
Author: Jakub Jelinek 
Date:   Sat Mar 6 16:22:27 2021 +0100

libgcov: Fix build on Darwin [PR99406]

As reported, bootstrap currently fails on older Darwin because
MAP_ANONYMOUS
is not defined.

The following is what gcc/system.h does, so I think it should work for
libgcov.

2021-03-06  Jakub Jelinek  

PR gcov-profile/99406
* libgcov.h (MAP_FAILED, MAP_ANONYMOUS): If HAVE_SYS_MMAN_H is
defined, define these macros if not defined already.

[Bug gcov-profile/99406] [11 regression] MAP_ANONYMOUS undeclared in libgcov.h

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/96330] Constexpr variables cannot be used in the template context.

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11.  Thanks for the bug report!

[Bug c++/99365] [11 Regression] ICE on partial specialization with constrained placeholder NTTP

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed.

[Bug libstdc++/99430] New: std::filesystem::path: UNC device paths with \\?\… not supported properly

[moritz at bunkus dot org via Gcc-bugs]

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

Bug ID: 99430
   Summary: std::filesystem::path: UNC device paths with \\?\… not
supported properly
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz at bunkus dot org
  Target Milestone: ---

Created attachment 50317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50317&action=edit
test case highlighting the issue

Paths such as \\?\C:\WINDOWS or \\?\UNC\LOCALHOST\c$\WINDOWS don't work
properly with std::filesystem::path (e.g. exists() & is_directory() return
false).

According to Microsoft's documentation those are valid.[1]

The corresponding variants starting with \\.\ seem to fare better (safe for the
root name & absolute issues, but I've filed 99333 for that already).

boost::filesystem works fine with all of these paths.

The attached sample program outputs the following, showing how Boost's & std's
implementation differ:

-
std::filesystem::path for \\?\C:\WINDOWS
  is_aboslute 0
  has_root_path 1
  has_root_name 0
  exists 0
  is_directory 0
boost::filesystem::path for \\?\C:\WINDOWS
  is_aboslute 1
  has_root_path 1
  has_root_name 1
  exists 1
  is_directory 1
std::filesystem::path for \\?\UNC\localhost\c$\WINDOWS
  is_aboslute 0
  has_root_path 1
  has_root_name 0
  exists 0
  is_directory 0
boost::filesystem::path for \\?\UNC\localhost\c$\WINDOWS
  is_aboslute 1
  has_root_path 1
  has_root_name 1
  exists 1
  is_directory 1
std::filesystem::path for \\.\C:\WINDOWS
  is_aboslute 0
  has_root_path 1
  has_root_name 0
  exists 1
  is_directory 1
boost::filesystem::path for \\.\C:\WINDOWS
  is_aboslute 1
  has_root_path 1
  has_root_name 1
  exists 1
  is_directory 1
std::filesystem::path for \\.\UNC\localhost\c$\WINDOWS
  is_aboslute 0
  has_root_path 1
  has_root_name 0
  exists 1
  is_directory 1
boost::filesystem::path for \\.\UNC\localhost\c$\WINDOWS
  is_aboslute 1
  has_root_path 1
  has_root_name 1
  exists 1
  is_directory 1
-

gcc mingw 10.2.0 from MXE (cross-compiling from Linux to Windows), Boost 1.74.0

[1] https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats

[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
Created attachment 50318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50318&action=edit
tar ball to repeat the failure

[Bug c/99431] New: Return value of __builtin_memset() incorrect if partially optimized away

[jonathon.reinhart at gmail dot com via Gcc-bugs]

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

Bug ID: 99431
   Summary: Return value of __builtin_memset() incorrect if
partially optimized away
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathon.reinhart at gmail dot com
  Target Milestone: ---

Created attachment 50319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50319&action=edit
Minimal example

Please see attached code or https://godbolt.org/z/oTMhsd.

If the address of a struct object is passed to __builtin_memset(), and some
leading fields are assigned elsewhere in the function, GCC may effectively
adjust the portion of the object written to by the memset(), to eliminate
redundant writes. However, the return value of memset(), which should always
match the first argument, is also (incorrectly) adjusted, leading to an invalid
result.

Specifically, this happens with -Os. I attempted to narrow this down to a
specific set of optimizations by testing everything listed in the output of
this command, but that was insufficient to reproduce the problem:

  gcc -Q -Os --help=optimizers

I found it interesting, although not surprising, that adding this between the
__builtin_memset() call and the "other" assignments caused the problem to go
away: 

__asm__("" :::"memory");

GCC versions tested:
  10.2 OK
  10.1 OK
  9.3  Broken
  8.3  Broken
  7.3  Broken
  7.2  Broke
  7.1  Broken
  6.3  OK

[Bug libfortran/99218] [8/9/10/11 Regression] matmul on temporary array accesses invalid memory (segfault)

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

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

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

https://gcc.gnu.org/g:4fbef612ca1adb71c90eab0d6a682ec6af5b7c93

commit r10-9420-g4fbef612ca1adb71c90eab0d6a682ec6af5b7c93
Author: Harald Anlauf 
Date:   Fri Mar 5 20:57:54 2021 +0100

PR libfortran/99218 - matmul on temporary array accesses invalid memory

Do not invoke tuned rank-2 times rank-2 matmul if rank(b) == 1.

libgfortran/ChangeLog:

PR libfortran/99218
* m4/matmul_internal.m4: Invoke tuned matmul only for rank(b)>1.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Likewise.
* generated/matmul_c4.c: Likewise.
* generated/matmul_c8.c: Likewise.
* generated/matmul_i1.c: Likewise.
* generated/matmul_i16.c: Likewise.
* generated/matmul_i2.c: Likewise.
* generated/matmul_i4.c: Likewise.
* generated/matmul_i8.c: Likewise.
* generated/matmul_r10.c: Likewise.
* generated/matmul_r16.c: Likewise.
* generated/matmul_r4.c: Likewise.
* generated/matmul_r8.c: Likewise.
* generated/matmulavx128_c10.c: Likewise.
* generated/matmulavx128_c16.c: Likewise.
* generated/matmulavx128_c4.c: Likewise.
* generated/matmulavx128_c8.c: Likewise.
* generated/matmulavx128_i1.c: Likewise.
* generated/matmulavx128_i16.c: Likewise.
* generated/matmulavx128_i2.c: Likewise.
* generated/matmulavx128_i4.c: Likewise.
* generated/matmulavx128_i8.c: Likewise.
* generated/matmulavx128_r10.c: Likewise.
* generated/matmulavx128_r16.c: Likewise.
* generated/matmulavx128_r4.c: Likewise.
* generated/matmulavx128_r8.c: Likewise.

gcc/testsuite/ChangeLog:

PR libfortran/99218
* gfortran.dg/matmul_21.f90: New test.

(cherry picked from commit b1bee29167df6b0fbc9a4c8d06e2acbf3367af47)

[Bug c++/99429] [10/11 Regression] ICE for bool return from <=>

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE for bool return from|[10/11 Regression] ICE for
   |<=> |bool return from <=>
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2021-03-06

--- Comment #2 from Jakub Jelinek  ---
Started to ICE with r10-4397-gb7689b962dd6536bbb2567bfdec52e35109af7ab

[Bug c++/99429] [10/11 Regression] ICE for bool return from <=>

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

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

--- Comment #3 from Jakub Jelinek  ---
Slightly reduced:
namespace std {
struct strong_ordering {
  int _v;
  constexpr strong_ordering (int v) :_v(v) {}
  constexpr operator int (void) const { return _v; }
  static const strong_ordering less;
  static const strong_ordering equal;
  static const strong_ordering greater;
};
constexpr strong_ordering strong_ordering::less = -1;
constexpr strong_ordering strong_ordering::equal = 0;
constexpr strong_ordering strong_ordering::greater = 1;
}

template 
struct duration {
  static constexpr const long period = N;
  constexpr duration (void) = default;
  constexpr duration (const duration& d) = default;
  constexpr bool operator== (const duration& d) const = default;
  constexpr bool operator<=> (const duration& d) const = default;
  long _d;
};

using nanoseconds = duration<1>;
using microseconds = duration;

[Bug c/99431] Return value of __builtin_memset() incorrect if partially optimized away

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
On the trunk started with r7-5965-g7c9560a578a06125cb30458a26605f91feb29b0d
and got fixed with r10-7140-g349ab34dc64a10fe0b1eda66d13b62862878b73e

[Bug c/99431] Return value of __builtin_memset() incorrect if partially optimized away

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
So dup.

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

[Bug tree-optimization/94130] [8 Regression] Unintended result with optimization option when assigning two structures, memset and 0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jonathon.reinhart at gmail dot 
com

--- Comment #14 from Jakub Jelinek  ---
*** Bug 99431 has been marked as a duplicate of this bug. ***

[Bug c/99431] Return value of __builtin_memset() incorrect if partially optimized away

[jonathon.reinhart at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jonathon Reinhart  ---
Yep, that's it. I figured there had to be a dup, but couldn't find it. Thanks
Jakub.

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from David Binderman  ---
I also see this when compiling linux kernel 5.12-rc2.

net/netfilter/utils.c: In function ‘nf_checksum’:
net/netfilter/utils.c:139:1: error: unrecognizable insn:
  139 | }
  | ^
(insn 120 466 414 12 (parallel [
(set (reg:SI 0 ax [orig:200 sum ] [200])
(asm_operands:SI ("  addl %1, %0
  adcl %2, %0
  adcl %3, %0
  adcl $0, %0
") ("=r") 0 [
(mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [301 %sfp+-8 S4 A64])
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) [301 %sfp+-16 S8
A64])
(const_int 12 [0xc])) [1 MEM[(const struct
iphdr *)_19].saddr+0 S4 A32])
(reg:SI 1 dx [203])
(reg:SI 0 ax [orig:200 sum ] [200])
]
 [
(asm_input:SI ("g")
./arch/x86/include/asm/checksum_64.h:91)
(asm_input:SI ("g")
./arch/x86/include/asm/checksum_64.h:91)
(asm_input:SI ("g")
./arch/x86/include/asm/checksum_64.h:91)
(asm_input:SI ("0")
./arch/x86/include/asm/checksum_64.h:91)
]
 [] ./arch/x86/include/asm/checksum_64.h:91))
(clobber (reg:CC 17 flags))
]) "./arch/x86/include/asm/checksum_64.h":91:2 -1
 (nil))

[Bug target/99432] New: ICE in extract_constrain_insn, at recog.c:2670 when building libgcc for i686

[italolmm2018 at outlook dot com via Gcc-bugs]

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

Bug ID: 99432
   Summary: ICE in extract_constrain_insn, at recog.c:2670 when
building libgcc for i686
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: italolmm2018 at outlook dot com
  Target Milestone: ---

gcc version 11.0.1 20210306 (experimental), configured with: ../configure
--target=i686-elf --prefix=/home/italo/chos/toolchain/kernel/x86/out
--enable-languages=c,c++ --enable-lto --disable-multilib --without-headers
--disable-nls --disable-werror

Command Line:
/home/italo/chos/toolchain/build/gcc/build/./gcc/xgcc
-B/home/italo/chos/toolchain/build/gcc/build/./gcc/
-B/home/italo/chos/toolchain/kernel/x86/out/i686-elf/bin/
-B/home/italo/chos/toolchain/kernel/x86/out/i686-elf/lib/ -isystem
/home/italo/chos/toolchain/kernel/x86/out/i686-elf/include -isystem
/home/italo/chos/toolchain/kernel/x86/out/i686-elf/sys-include-g -O2 -O2 
-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem
./include  -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -fpic -I. -I. -I../.././gcc -I../../../libgcc
-I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include 
-DHAVE_CC_TLS  -Wno-missing-prototypes -Wno-type-limits -o divtf3.o -MT
divtf3.o -MD -MP -MF divtf3.dep  -c ../../../libgcc/soft-fp/divtf3.c
-fvisibility=hidden -DHIDE_EXPORTS

Command Output:
../../../libgcc/soft-fp/divtf3.c: In function '__divtf3':
../../../libgcc/soft-fp/divtf3.c:51:1: error: unrecognizable insn:
   51 | }
  | ^
(insn 1199 3373 3715 79 (parallel [
(set (reg:SI 5 di [623])
(asm_operands:SI ("sub{l} {%11,%3|%3,%11}
sbb{l} {%9,%2|%2,%9}
sbb{l} {%7,%1|%1,%7}
sbb{l} {%5,%0|%0,%5}") ("=r") 0 [
(reg:SI 5 di [623])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -80 [0xffb0])) [5
A_f[2]+0 S4 A64])
(reg:SI 1 dx [624])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [5
A_f[1]+0 S4 A32])
(reg:SI 4 si [625])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -88 [0xffa8])) [5
A_f[0]+0 S4 A128])
(reg:SI 0 ax [626])
(mem:SI (plus:SI (plus:SI (mult:SI (mem/c:SI (plus:SI
(reg/f:SI 6 bp)
(const_int -112
[0xff90])) [10 %sfp+-88 S4 A32])
(const_int 4 [0x4]))
(reg/f:SI 6 bp))
(const_int -40 [0xffd8])) [5
MEM[(unsigned int *)_7]+0 S4 A32])
]
 [
(asm_input:SI ("0")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("g")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("1")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("g")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("2")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("g")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("3")
../../../libgcc/soft-fp/divtf3.c:46)
(asm_input:SI ("g")
../../../libgcc/soft-fp/divtf3.c:46)
]
 [] ../../../libgcc/soft-fp/divtf3.c:46))
(set (reg:SI 1 dx [624])
(asm_operands:SI ("sub{l} {%11,%3|%3,%11}
sbb{l} {%9,%2|%2,%9}
sbb{l} {%7,%1|%1,%7}
sbb{l} {%5,%0|%0,%5}") ("=&r") 1 [
(reg:SI 5 di [623])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -80 [0xffb0])) [5
A_f[2]+0 S4 A64])
(reg:SI 1 dx [624])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [5
A_f[1]+0 S4 A32])
(reg:SI 4 si [625])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -88 [0xffa8])) [5
A_f[0]+0 S4 A128])
(reg:SI 0 ax [626])
(mem:SI (plus:SI (plus:SI (mult:SI (mem/c:

[Bug c++/99433] New: custom friend pipe-operator| conflicts with range adaptor?

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

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

Bug ID: 99433
   Summary: custom friend pipe-operator| conflicts with range
adaptor?
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hello gcc-team,

the following code does not compile with gcc-11 any more, but did with gcc-10.

```c++
#include 
#include 
template 
struct deep {
underlying_adaptor_t adaptor;

template 
friend auto operator|(range_t &range, deep const &me)
{
return me.adaptor(range[0]);
}
};
inline auto const complement = deep{std::views::transform([](auto const nucl) {
return nucl + ' '; })};
std::vector> foo{};
auto v = foo | complement;
```

https://godbolt.org/z/9oEj9T

Thank you!

[Bug tree-optimization/99434] New: std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 99434
   Summary: std::bit_cast generates more instructions than
__builtin_bit_cast and memcpy with -march=native
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://godbolt.org/z/5KWM8Y
struct u64x2_t
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
std::uint64_t high,low;
#else
std::uint64_t low,high;
#endif
};
u64x2_t umul5(std::uint64_t a,std::uint64_t b) noexcept
{
return std::bit_cast(static_cast<__uint128_t>(a)*b);
}

u64x2_t umul_builtin(std::uint64_t a,std::uint64_t b) noexcept
{
return __builtin_bit_cast(u64x2_t,static_cast<__uint128_t>(a)*b);
}

assembly:
umul5(unsigned long, unsigned long):
movq%rdi, %rdx
mulx%rsi, %rdx, %rcx
movq%rdx, %rax
movq%rcx, %rdx
ret
umul_builtin(unsigned long, unsigned long):
movq%rdi, %rdx
mulx%rsi, %rax, %rdx
ret

There is another issue:

std::uint64_t umul128(std::uint64_t a,std::uint64_t b,std::uint64_t& high)
noexcept
{
__uint128_t res{static_cast<__uint128_t>(a)*b};
high=static_cast(res>>64);
return static_cast(res);
}
I cannot do this since this generates more instructions than using memcpy to
pun types.

clang does not have this issue and all cases are dealt with correctly.

[Bug target/99435] New: avr: incorrect I/O address ranges for some cores

[gcc at nothien dot uber.space via Gcc-bugs]

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

Bug ID: 99435
   Summary: avr: incorrect I/O address ranges for some cores
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at nothien dot uber.space
  Target Milestone: ---

The `io' and `io_low' attributes incorrectly report out-of-range addresses when
compiling for the ATmega32u4 (-mmcu=atmega32u4), on all GCC versions.

In particular, on this core, the 'low' I/O address space (within which the
instructions sbi, cbi, sbis, sbic, etc. can be used, in addition to memory
reads/writes) is from 0x20 to 0x5F (inclusive; 64 bytes), and the 'high' I/O
address space (which can only be accessed only using memory reads/writes) is
from 0x60 to 0xFF (inclusive; 160 bytes).

The datasheet for the ATmega32u4 (and the ATmega16u4), which discusses these
ranges (see section 5), can be found at
.

Compiling, for example, the following (with `avr-gcc -Wall -Wextra -Wpedantic
-Werror -mmcu=atmega32u4`):

volatile uint8_t io_pllcsr __attribute__((io_low (0x49)));

will fail with the error: "‘io_low’ attribute address out of range", although
this is a perfectly valid low I/O address on this platform.

This error occurs because currently GCC assumes that the low I/O address space
is from 0x20 to 0x3F and that the high I/O address space is from 0x40 to 0x5F. 
These limits are hardcoded into the `low_io_address_operand',
`high_io_address_operand', and `io_address_operand' predicates, defined at
`gcc/config/avr/predicates.md'.

This should be corrected by moving these values into the avr_arch structure,
where they can be varied by platform.  I will send in a patch for this shortly.

[Bug target/99432] ICE in extract_constrain_insn, at recog.c:2670 when building libgcc for i686

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||99422

--- Comment #1 from Andrew Pinski  ---
This is most likely a dup of bug 99422.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
[Bug 99422] [11 Regression] ICE in extract_constrain_insn building glibc
pthread_create

[Bug c++/99436] New: ICE in get_cxx_dialect_name, at cp/name-lookup.c:6955 when using modules on C++23

[italolmm2018 at outlook dot com via Gcc-bugs]

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

Bug ID: 99436
   Summary: ICE in get_cxx_dialect_name, at cp/name-lookup.c:6955
when using modules on C++23
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: italolmm2018 at outlook dot com
  Target Milestone: ---

ICE when trying to 'export module' under C++23/C++2B:

gcc version 11.0.1 20210306 (experimental), configured with: ../configure
--target=i686-elf --prefix=/home/italo/chos/toolchain/kernel/x86/out
--enable-languages=c,c++ --enable-lto --disable-multilib --without-headers
--disable-nls --disable-werror

Command line and output:

$ x86_64-elf-g++ -std=c++2b -fmodules-ts -c test.cxx
test.cxx:1:8: internal compiler error: in get_cxx_dialect_name, at
cp/name-lookup.c:6955
1 | export module test;
  |^~
0x67dca0 get_cxx_dialect_name(cxx_dialect)
../../gcc/cp/name-lookup.c:6955
0x680a49 get_cxx_dialect_name(cxx_dialect)
../../gcc/tree.h:3353
0x9e1056 module_state_config::get_dialect()
../../gcc/cp/module.cc:14443
0x9f7a74 module_state_config::module_state_config()
../../gcc/cp/module.cc:14416
0x9f7a74 module_state::write(elf_out*, cpp_reader*)
../../gcc/cp/module.cc:17663
0x9f8caf finish_module_processing(cpp_reader*)
../../gcc/cp/module.cc:19875
0x98cf4b c_parse_final_cleanups()
../../gcc/cp/decl2.c:5175
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.

The contents of the test.cxx file are just 'export module test;', and it builds
normally when using -std=c++20.

[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Target||x86_64
   Keywords||missed-optimization, ra
  Component|tree-optimization   |target

--- Comment #1 from Andrew Pinski  ---
This is just a register allocation issue dealing with mulx and TImode.

If mulq was used instead (that is without -march=native), all of the functions
are done correctly.

[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
(In reply to Andrew Pinski from comment #1)
> This is just a register allocation issue dealing with mulx and TImode.
> 
> If mulq was used instead (that is without -march=native), all of the
> functions are done correctly.

I do not think so. I think GCC generally did things like this wrong. I have
even found out how to produce different wrong results deterministically.

For example like this
https://godbolt.org/z/PbobYG

Any time it deals with things like >>32 or >>64, it produces a slower result.
This even compiles without -march=native.

While clang generates exactly the same assembly which means my result is
correct. GCC does things for this wrong.

It looks like we need more optimizations on trees for these patterns.

[Bug middle-end/98689] [11 Regression] FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O1 execution test

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

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

--- Comment #3 from John David Anglin  ---
Created attachment 50320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50320&action=edit
.s diff to gcc10 .s

The following code is wrong in gcc-11:

-   ldw 12(%r3),%r28
+   ldw 12(%r3),%r5
+   copy %r5,%r28
bl foo,%r2
ldo 64(%r3),%r4
-   stw %r28,0(%r4)
+   stw %r5,0(%r4)

In gcc-10, the return value from foo is stored in 0(%r4).

[Bug c++/99287] std::source_location::function_name breaks constexpr

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

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

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

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

commit r11-7546-gd1bba463bd0d5692b7fa58ee37a61a55b2517456
Author: Patrick Palka 
Date:   Sat Mar 6 17:09:07 2021 -0500

c++: Fix constexpr evaluation of pre-increment when !lval [PR99287]

Here, during cxx_eval_increment_expression (with lval=false) of
++__first where __first is &"mystr"[0], we correctly update __first
to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
&"mystr"[1].  This unreduced return value inhibits other pointer
arithmetic folding during later constexpr evaluation, which ultimately
causes the constexpr evaluation to fail.

It turns out the simplification of &"mystr"[0] + 1 to &"mystr"[1]
is performed by cxx_fold_pointer_plus_expression, not by fold_build2.
So we perform this simplification during constexpr evaluation of
the temporary MODIFY_EXPR (during which we assign to __first the
simplified value), but then we return 'mod' which has only been folded
via fold_build2 and hasn't gone through cxx_fold_pointer_plus_expression.

This patch fixes this by updating 'mod' with the result of the
MODIFY_EXPR evaluation appropriately, so that it captures any additional
folding of the expression when !lval.  We now need to be wary of this
evaluation failing and returning e.g. the MODIFY_EXPR or NULL_TREE; it
seems checking *non_constant_p should cover our bases here and is
generally prudent.

gcc/cp/ChangeLog:

PR c++/99287
* constexpr.c (cxx_eval_increment_expression): Pass lval when
evaluating the MODIFY_EXPR, and update 'mod' with the result of
this evaluation.  Check *non_constant_p afterwards.  For prefix
ops, just return 'mod'.

gcc/testsuite/ChangeLog:

PR c++/99287
* g++.dg/cpp2a/constexpr-99287.C: New test.

Co-authored-by: Jakub Jelinek 

[Bug c++/99287] std::source_location::function_name breaks constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Fixed for GCC 11.  Thanks for the bug report!

[Bug c/99295] [9/10 Regression] documentation on __attribute__((malloc)) is wrong

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #6 from Roland Illig  ---
Thank you for updating the documentation. It reads really nice now and explains
everything I would need or like to know when I stumble upon this function
attribute.

[Bug target/99434] std::bit_cast generates more instructions than __builtin_bit_cast and memcpy with -march=native

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to cqwrteur from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This is just a register allocation issue dealing with mulx and TImode.
> > 
> > If mulq was used instead (that is without -march=native), all of the
> > functions are done correctly.
> 
> I do not think so. I think GCC generally did things like this wrong. I have
> even found out how to produce different wrong results deterministically.
> 
> For example like this
> https://godbolt.org/z/PbobYG
> 
> Any time it deals with things like >>32 or >>64, it produces a slower result.
> This even compiles without -march=native.

This is still a register allocation issue, this time dealing with DImode on
32bit. GCC has a known issue with register allocation when dealing with values
stored into two registers.  See PR 21150, PR 43644, PR 50339, etc.

[Bug sanitizer/99418] sanitizer checks for accessing multidimentional VLA-array

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ivan Sorokin  ---
Here is the reduced example. It doesn't SIGSEGV, but it doesn't report any
sanitizer errors either:

$ g++ -g -fsanitize=bounds 3.cpp
$ cat 3.cpp
#include 

void escape(int& a)
{}

void test(size_t n, size_t m)
{
int mas[n][m];
escape(mas[n - 1][m]);
}

int main()
{
test(4, 3);
}

Surprisingly if I replace taking a reference with writing to the array it will
show an error.

[Bug target/99437] New: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'

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

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

Bug ID: 99437
   Summary: Error: immediate value out of range 1 to 8 at operand
3 -- `shrn v1.8b,v1.8h,15'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

Created attachment 50321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50321&action=edit
test case

gcc 11 fails to build openCV for aarch64 due to an assembler error on attached
sample program.

% arch64-yoe-linux-g++ -c a.cpp -O

/tmp/ccxRnB71.s: Assembler messages:
/tmp/ccxRnB71.s:113: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,15'
/tmp/ccxRnB71.s:249: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,14'
/tmp/ccxRnB71.s:385: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,13'
/tmp/ccxRnB71.s:521: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,12'
/tmp/ccxRnB71.s:657: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,11'
/tmp/ccxRnB71.s:793: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,10'
/tmp/ccxRnB71.s:929: Error: immediate value out of range 1 to 8 at operand 3 --
`shrn v1.8b,v1.8h,9'

[Bug target/99437] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'

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

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

--- Comment #1 from Khem Raj  ---
the version of gcc in use is

gcc version 11.0.1 20210306 (experimental) (GCC)

[Bug target/99437] [11 Regression] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Error: immediate value out  |[11 Regression] Error:
   |of range 1 to 8 at operand  |immediate value out of
   |3 -- `shrn v1.8b,v1.8h,15'  |range 1 to 8 at operand 3
   ||-- `shrn v1.8b,v1.8h,15'
   Target Milestone|--- |11.0
   Keywords||assemble-failure
   Host|x86_64  |

--- Comment #2 from Andrew Pinski  ---
//(insn 148 147 149 (set (reg:V16QI 33 v1 [orig:153 _101 ] [153])
//(vec_concat:V16QI (truncate:V8QI (lshiftrt:V8HI (reg:V8HI 33 v1
[orig:165 _113 ] [165])
//(const_vector:V8HI [
//(const_int 15 [0xf]) repeated x8
//])))
//(const_vector:V8QI [
//(const_int 0 [0]) repeated x8
//])))
"/mnt/b/yoe/master/build/tmp/work/cortexa57-yoe-linux/opencv/4.5.1-r0/recipe-sysroot-native/usr/lib/aarch64-yoe-linux/gcc/aarch64-yoe-linux/11.0.1/include/arm_neon.h":6548:53
1917 {aarch64_shrnv8hi_insn_le}
// (nil))
shrnv1.8b, v1.8h, 15// 148  [c=4 l=4] 
aarch64_shrnv8hi_insn_le

Confirmed, reducing 

[Bug c/99420] New warning -Warray-parameter

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Keywords||diagnostic

--- Comment #1 from Eric Gallager  ---
I'm pretty sure Martin Sebor added this warning; cc-ing him...

[Bug target/99437] [11 Regression] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
Trying 144, 146 -> 148:
  144: r159:V8HI=r165:V8HI 0>>const_vector
  REG_DEAD r165:V8HI
  146: r155:V8QI=trunc(r159:V8HI)
  REG_DEAD r159:V8HI
  148: r153:V16QI=vec_concat(r155:V8QI,const_vector)
  REG_DEAD r155:V8QI
Successfully matched this instruction:
(set (reg:V16QI 153 [ _101 ])
(vec_concat:V16QI (truncate:V8QI (lshiftrt:V8HI (reg:V8HI 165 [ _113 ])
(const_vector:V8HI [
(const_int 15 [0xf]) repeated x8
])))
(const_vector:V8QI [
(const_int 0 [0]) repeated x8
])))

I have not reduced it yet but the above shows where the problem is introduced
inside combine.  I think the constrants/predicates for aarch64_shrnv8hi_insn_le
on the const_vect (shift) are incorrect.

[Bug bootstrap/99438] New: [11 regression] libgcc/soft-fp/divtf3.c:51:1: error: unrecognizable insn

[gerald at pfeifer dot com via Gcc-bugs]

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

Bug ID: 99438
   Summary: [11 regression] libgcc/soft-fp/divtf3.c:51:1: error:
unrecognizable insn
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---
Target: i586-unknown-freebsd12.2

This is a regression that entered the tree in the last 24 (plus a few
maybe hours):

/scratch/tmp/gerald/GCC-HEAD/libgcc/soft-fp/divtf3.c: In function '__divtf3':
/scratch/tmp/gerald/GCC-HEAD/libgcc/soft-fp/divtf3.c:51:1: error: unrecognizabl
e insn:
   51 | }
  | ^
(insn 1185 3357 3676 80 (parallel [
(set (reg:SI 5 di [621])
(asm_operands:SI ("sub{l} {%11,%3|%3,%11}
sbb{l} {%9,%2|%2,%9}
sbb{l} {%7,%1|%1,%7}
sbb{l} {%5,%0|%0,%5}") ("=r") 0 [
(reg:SI 5 di [621])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -80 [0xffb0])) [5 A_f[2]
+0 S4 A64])
(reg:SI 1 dx [622])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [5 A_f[1]
+0 S4 A32])
(reg:SI 0 ax [623])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)


The invocation is


/scratch/tmp/gerald/OBJ-0306-1540/./gcc/xgcc -B/scratch/tmp/gerald/OBJ-0306-154
0/./gcc/ -B/home/gerald/gcc-ref11-i386/i586-unknown-freebsd12.2/bin/ -B/home/ge
rald/gcc-ref11-i386/i586-unknown-freebsd12.2/lib/ -isystem /home/gerald/gcc-ref
11-i386/i586-unknown-freebsd12.2/include -isystem /home/gerald/gcc-ref11-i386/i
586-unknown-freebsd12.2/sys-include   -fno-checking -g -O2 -O2  -g -O2 -DIN_GCC
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wo
ld-style-definition  -isystem ./include  -fpic -pthread -g -DIN_LIBGCC2 -fbuild
ing-libgcc -fno-stack-protector  -fpic -pthread -I. -I. -I../.././gcc -I/scratc
h/tmp/gerald/GCC-HEAD/libgcc -I/scratch/tmp/gerald/GCC-HEAD/libgcc/. -I/scratch
/tmp/gerald/GCC-HEAD/libgcc/../gcc -I/scratch/tmp/gerald/GCC-HEAD/libgcc/../inc
lude  -DHAVE_CC_TLS  -o _gcov_merge_add.o -MT _gcov_merge_add.o -MD -MP -MF _gc
ov_merge_add.dep -DL_gcov_merge_add -c /scratch/tmp/gerald/GCC-HEAD/libgcc/libg
cov-merge.c

[Bug target/98792] Fail to use SHRN instructions for narrowing shift on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-07
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Confirmed.


(insn 17 16 18 3 (set (reg:V8HI 109 [ vect__3.8 ])
(vec_concat:V8HI (truncate:V4HI (reg:V4SI 105 [ vect__2.7 ]))
(truncate:V4HI (reg:V4SI 107 [ vect__2.7 ] "t9.c":9:16 1942
{vec_pack_trunc_v4si}
 (expr_list:REG_DEAD (reg:V4SI 107 [ vect__2.7 ])
(expr_list:REG_DEAD (reg:V4SI 105 [ vect__2.7 ])
(nil
(insn 18 17 19 3 (set (mem:V8HI (post_inc:DI (reg:DI 92 [ ivtmp.16 ])) [2 MEM
 [(short unsigned int *)_7]+0 S16 A128])
(reg:V8HI 109 [ vect__3.8 ])) "t9.c":9:16 1161 {*aarch64_simd_movv8hi}
 (expr_list:REG_DEAD (reg:V8HI 109 [ vect__3.8 ])
(expr_list:REG_INC (reg:DI 92 [ ivtmp.16 ])
(nil
Part of the problem is the above. 
So this might need to be done at the gimple level such that we don't do the
vec_concat in the first place 
That is if we had the RTL for:
ushrv1.4s, v1.4s, 3
ushrv0.4s, v0.4s, 3
xtn v2.4h, v1.4s
xtn v3.8h, v0.4s
str d3, d2, [x1], 16
I think combine would have done its job.

[Bug target/99312] __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-07
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Confirmed, Naveen posted the patch already.

[Bug middle-end/99370] calling a virtual function in insufficient space silently folded to __builtin_unreachable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-07

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug target/99432] ICE in extract_constrain_insn, at recog.c:2670 when building libgcc for i686

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup in the end.

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

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||italolmm2018 at outlook dot com

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

[Bug bootstrap/99438] [11 regression] libgcc/soft-fp/divtf3.c:51:1: error: unrecognizable insn

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 99422.

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

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

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

[Bug middle-end/98865] Missed transform of (a >> 63) * b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-07
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug libstdc++/99439] New: use_facet> (l); get() API with kMonthDayYearFormat = L"%m/%d/%Y" should allow missing leading zero

[lewis at sophists dot com via Gcc-bugs]

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

Bug ID: 99439
   Summary: use_facet> (l); get() API with
kMonthDayYearFormat = L"%m/%d/%Y" should allow missing
leading zero
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lewis at sophists dot com
  Target Milestone: ---

This code fails to compile (viewable on onlinegcc compiler link
https://onlinegdb.com/rkloG0-7O)

---

#include 
#include 
#include 
#include 

using namespace std;


auto getPCTMRequiresLeadingZeroBug = [] () {
static constexpr wstring_view kMonthDayYearFormat = L"%m/%d/%Y"sv;

std::locale  l = locale::classic ();
const time_get& tmget = use_facet> (l);
ios::iostate state = ios::goodbit;
wistringstream   iss (L"11/1/2002");
istreambuf_iterator itbegin (iss); // beginning of iss
istreambuf_iterator itend; // end-of-stream
tm   resultTM{};
auto i = tmget.get (itbegin, itend, iss, state,
&resultTM, kMonthDayYearFormat.data (), kMonthDayYearFormat.data () +
kMonthDayYearFormat.length ());
#if qCompilerAndStdLib_locale_time_get_PCTM_RequiresLeadingZero_Buggy
assert ((state & ios::badbit) or (state & ios::failbit));
#else
assert (not((state & ios::badbit) or (state & ios::failbit)));
#endif
};


int main()
{
getPCTMRequiresLeadingZeroBug();
printf("Hello World");

return 0;
}
---

The reason this APPEARS to be a bug is the docs:

https://en.cppreference.com/w/cpp/locale/time_get/get
say 
parses the month as a decimal number (range [01,12]), leading zeroes permitted
but not required

meaning leading zero CAN be there in month, but not it says NOT REQUIRED.

11/1/2004 fails to parse, but 11/01/2004 works (but the leading zero should be
optional).

[Bug debug/95431] inconsistent behaviors at -O2

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

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

--- Comment #2 from Andrew Pinski  ---
Looks correct at the gimple level:
  [t.c:6:3] # DEBUG BEGIN_STMT
  [t.c:6:16] one.0_1 ={v} one;
  [t.c:6:16] _2 = (char) one.0_1;
  [t.c:6:8] a1[0] = _2;
  [t.c:6:8] MEM  [(char *)&a1 + 1B] = 770;
  [t.c:6:8] a1[3] = 4;

  [t.c:7:3] # DEBUG BEGIN_STMT
  [t.c:7:8] a2[0] = 1;
  [t.c:7:19] one.1_3 ={v} one;
  [t.c:7:19] _4 = (unsigned char) one.1_3;
  [t.c:7:19] _5 = _4 * 2;
  [t.c:7:19] _6 = (char) _5;
  [t.c:7:8] a2[1] = _6;
  [t.c:7:8] MEM  [(char *)&a2 + 2B] = 1027;

  [t.c:8:3] # DEBUG BEGIN_STMT
  [t.c:8:31] one.2_7 ={v} one;
  [t.c:8:31] _8 = one.2_7 + 5;
  [t.c:8:13] _9 = (long unsigned int) _8;
  [t.c:8:13] res_19 = memcmp ([t.c:8:21] &a1, [t.c:8:25] &a2, _9);
  [t.c:8:13] # DEBUG res => res_19
  [t.c:9:3] # DEBUG BEGIN_STMT

Assembly:
.loc 1 6 3 view .LVU1
.loc 1 5 12 is_stmt 0 view .LVU2
subq$24, %rsp
.cfi_def_cfa_offset 32
.loc 1 6 16 view .LVU3
movlone(%rip), %eax
.loc 1 7 8 view .LVU4
movl$1027, %edx
movw%dx, 14(%rsp)
.loc 1 8 13 view .LVU5
leaq12(%rsp), %rsi
leaq8(%rsp), %rdi
.loc 1 6 16 view .LVU6
movb%al, 8(%rsp)
.loc 1 6 8 view .LVU7
movl$770, %eax
movw%ax, 9(%rsp)
.loc 1 7 19 view .LVU8
movlone(%rip), %eax
.loc 1 8 31 view .LVU9
movlone(%rip), %edx
.loc 1 6 8 view .LVU10
movb$4, 11(%rsp)
.loc 1 7 3 is_stmt 1 view .LVU11
.loc 1 8 3 view .LVU12
.loc 1 7 19 is_stmt 0 view .LVU13
addl%eax, %eax
.loc 1 7 8 view .LVU14
movb$1, 12(%rsp)
.loc 1 8 31 view .LVU15
addl$5, %edx
.loc 1 7 19 view .LVU16
movb%al, 13(%rsp)
.loc 1 8 13 view .LVU17
movslq  %edx, %rdx


This could be a gdb issue because what GCC produces look correct.

[Bug debug/95432] inconsistent behaviors at -O2

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

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

--- Comment #2 from Andrew Pinski  ---
Assembly:
.loc 1 12 3 is_stmt 1 view .LVU12
.loc 1 10 8 is_stmt 0 view .LVU13
movaps  %xmm0, (%rsp)
.loc 1 11 8 view .LVU14
movaps  %xmm0, 32(%rsp)
.loc 1 12 13 view .LVU15
callfoo
.LVL1:
.loc 1 13 13 view .LVU16
leaq32(%rsp), %rdi
.loc 1 12 13 view .LVU17
movl%eax, %edx
.LVL2:
.loc 1 13 3 is_stmt 1 view .LVU18
.loc 1 13 13 is_stmt 0 view .LVU19
callfoo
.LVL3:
.loc 1 14 3 is_stmt 1 view .LVU20
.loc 1 14 6 is_stmt 0 view .LVU21

Looks correct to me, both call foo have the correct line on them.  I think this
is another GDB issue, most likely how dwarf3 and is_stmt is handled just like
95431 even.

[Bug rtl-optimization/95405] Unnecessary stores with std::optional

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-07
  Component|tree-optimization   |rtl-optimization
 Target||x86_64-linux-gnu
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
On aarch64 we do the correct thing:
_Z3barv:
stp x29, x30, [sp, -32]!
mov x29, sp
bl  _Z3foov
tst w1, 255
cselx0, x0, xzr, ne
ldp x29, x30, [sp], 32
ret

So this is most likely an issue with how x86_64 implements stuff.

Confirmed for x86_64 though.

[Bug gcov-profile/99440] New: [GCOV] Wrong coverage with callsite

[dz1933028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 99440
   Summary: [GCOV] Wrong coverage with callsite
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dz1933028 at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

$ cat test.c
#include 

extern void abort(void);

int v1 = 8;
long int v2 = 3;
void *v3 = (void *)&v2;
struct A {
  char c[16];
} v4 = {"foo"};
long double v5 = 40;
char seen[20];
int cnt;

__attribute__((noinline)) int foo1(int x, int y, ...) {
  return x;
}

__attribute__((noinline)) int foo2(int x, int y, ...) {
  return x + 8;
}

__attribute__((noinline)) int foo3(void) { return 6; }

extern inline __attribute__((always_inline, gnu_inline)) int bar(int x, ...) {
  if (x < 10)
return foo1(x, foo3(), 5, __builtin_va_arg_pack());
  return foo2(x, foo3() + 4, __builtin_va_arg_pack());
}

int main(void) {
  if (bar(0, ++v1, v4, &v4, v2++) != 0)
abort();
  if (bar(1, ++v5, 8, v3) != 1)
abort();
  if (bar(2) != 2)
abort();
  if (bar(v1 + 2) != 19)
abort();
  if (bar(v1 + 3, v5--, v4, v4, v3, 16LL) != 20)
abort();
  return 0;
}


$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:75.00% of 20
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include 
-:2:
-:3:extern void abort(void);
-:4:
-:5:int v1 = 8;
-:6:long int v2 = 3;
-:7:void *v3 = (void *)&v2;
-:8:struct A {
-:9:  char c[16];
-:   10:} v4 = {"foo"};
-:   11:long double v5 = 40;
-:   12:char seen[20];
-:   13:int cnt;
-:   14:
3:   15:__attribute__((noinline)) int foo1(int x, int y, ...) {
3:   16:  return x;
-:   17:}
-:   18:
2:   19:__attribute__((noinline)) int foo2(int x, int y, ...) {
2:   20:  return x + 8;
-:   21:}
-:   22:
5:   23:__attribute__((noinline)) int foo3(void) { return 6; }
-:   24:
-:   25:extern inline __attribute__((always_inline, gnu_inline)) int
bar(int x, ...) {
1:   26:  if (x < 10)
   3*:   27:return foo1(x, foo3(), 5, __builtin_va_arg_pack());
   2*:   28:  return foo2(x, foo3() + 4, __builtin_va_arg_pack());
-:   29:}
-:   30:
1:   31:int main(void) {
2:   32:  if (bar(0, ++v1, v4, &v4, v2++) != 0)
#:   33:abort();
2:   34:  if (bar(1, ++v5, 8, v3) != 1)
#:   35:abort();
1:   36:  if (bar(2) != 2)
#:   37:abort();
2:   38:  if (bar(v1 + 2) != 19)
#:   39:abort();
2:   40:  if (bar(v1 + 3, v5--, v4, v4, v3, 16LL) != 20)
#:   41:abort();
1:   42:  return 0;
-:   43:}

The coverage of line #32,#34,#38 and #40 should be 1 like line #36

[Bug sanitizer/99418] sanitizer checks for accessing multidimentional VLA-array

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ivan Sorokin  ---
It looks like this is related to ignore_off_by_one parameter of
ubsan_instrument_bounds.

As can be seen in gimple the problematic .UBSAN_BOUNDS checks against array
size plus 1.