[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #16 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #11)
> This is a regression (as in we don't want such a call in that case for
> performance reasons and in the past we didn't emit it).

Yes, just note it regresses 531.deepsjeng_r by 2% for -O2 -march=x86-64 since
below function.

typedef unsigned long long BITBOARD;
int PopCount (BITBOARD b) {
int c = 0;

while (b) {
b &= b - 1;
c++;
}

return c;
}

popcnt is supported by x86-64_v2.

[Bug gcov-profile/105282] [11/12 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

--- Comment #2 from Sergei Trofimovich  ---
Proposed the fix as
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg283031.html

[Bug c/105283] New: Ternary operator and precedence warning

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 105283
   Summary: Ternary operator and precedence warning
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

extern int g( int);

void f( int a, int b)
{
if (a & 0x03 == 3)
g( 1);

if (a + (b > 10) ? g( 1) : g( 2))
g( 10);
}

gcc finds the first problem, but not the second:

$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -Wparentheses
-Wint-in-bool-context apr15b.cc
apr15b.cc: In function ‘void f(int, int)’:
apr15b.cc:6:22: warning: suggest parentheses around comparison in operand of
‘&’ [-Wparentheses]
6 | if (a & 0x03 == 3)
  | ~^~~~
$ 

Here is recent clang on the same code:

$ /home/dcb/llvm/results/bin/clang -c -Wall   apr15b.cc
apr15b.cc:6:8: warning: & has lower precedence than ==; == will be evaluated
first [-Wparentheses]
if (a & 0x03 == 3)
  ^~~
apr15b.cc:6:8: note: place parentheses around the '==' expression to silence
this warning
if (a & 0x03 == 3)
  ^
()
apr15b.cc:6:8: note: place parentheses around the & expression to evaluate it
first
if (a & 0x03 == 3)
  ^
(   )
apr15b.cc:9:19: warning: operator '?:' has lower precedence than '+'; '+' will
be evaluated first [-Wparentheses]
if (a + (b > 10) ? g( 1) : g( 2))
 ^
apr15b.cc:9:19: note: place parentheses around the '+' expression to silence
this warning
if (a + (b > 10) ? g( 1) : g( 2))
 ^
(   )
apr15b.cc:9:19: note: place parentheses around the '?:' expression to evaluate
it first
if (a + (b > 10) ? g( 1) : g( 2))
 ^
(   )
2 warnings generated.
$ 

Please note I only had to use -Wall on clang to get the second warning
and the warning message itself is IMHO more descriptive.

[Bug c++/105284] New: missing syncstream and spanstream forward decl. in

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 105284
   Summary: missing syncstream and spanstream forward decl. in

   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

according to https://wg21.link/iosfwd.syn's  sypnosis:

The followings are declared (forward declaration only) which are added in C++20
and C++23:

* class template std::basic_spanbuf
* typedef std:spanbuf
* typedef std::wspanbuf
* class template std::basic_ispanstream
* typedef std::ispanstream
* typedef std::wispanstream
* class template std::basic_ospanstream
* typedef std::ospanstream
* typedef std::wospanstream
* class template std::basic_spanstream
* typedef std::spanstream
* typedef std::wspanstream
* class template std::basic_syncbuf
* typedef std::syncbuf
* typedef std::wsyncbuf
* class template std::basic_osyncstream
* typedef std::osyncstream
* typedef std::wosyncstream

However, they are currently not added in the current header  of
libstdc++

[Bug analyzer/105285] New: False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[avarab at gmail dot com via Gcc-bugs]

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

Bug ID: 105285
   Summary: False positive with -Wanalyzer-null-dereference in
git.git's reftable/reader.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: avarab at gmail dot com
  Target Milestone: ---

Created attachment 52813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52813&action=edit
gcc -E of reftable/reader.c

I didn't have time to come up with a nice isolated test case this time for
$subject, sorry, but (maybe this is easier):

git clone https://github.com/git/git/
cd git
make CC=gcc CFLAGS=-fanalyzer reftable/reader.o

Or alternatively the gcc -E output that's attached, but most informative is the
patch I'll attach to git.git to work around this (as the code was pretty
nonsensical anyway).

Why do I think it's a false positive? It's code that's basically doing:

  struct x = { 0 }; /* "foo" member is NULL */
  if (x >= 0)
  return 0; /* early abort */
  [...]
  if (x >= 0)
  return 1; /* we don't init "x.foo" */
  x.foo

I.e. the analyzer thinks you can go through these two and for "x >= 0" to be
true the first time, and false the next, or the other way around.

In this case the types didn't have "const" on them, but to make sure these
*really* weren't being changed I added that in all the relevant places, but it
still complained. The warning was:

reftable/reader.c: In function ‘extract_block_size’:
reftable/reader.c:274:20: warning: dereference of NULL ‘data’ [CWE-476]
[-Wanalyzer-null-dereference]
  274 | *typ = data[0];
  |^~~

Also, for the GCC 11.2 I have locally (I tested the warning on near-trunk GCC
12.0) I got two different warnings from -fanalyzer, so this seems to be an area
that's seen active changes recently...

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[avarab at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ævar Arnfjörð Bjarmason  ---
Created attachment 52814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52814&action=edit
A patch to git.git that works around the -fanalyzer false positive

A fix to git.git to work around the analyzer false positive, this diff on top
shows an annotated path through the program it thinks we'd take. 24 and 28
can't be true/false false/true, only false/false true/true.

diff --git a/reftable/reader.c b/reftable/reader.c
index ea66771165f..d3a4639d6ca 100644
--- a/reftable/reader.c
+++ b/reftable/reader.c
@@ -61,6 +61,9 @@ static int reader_get_block(struct reftable_block *dest,
uint32_t sz, const uint64_t off,
const uint64_t r_size)
 {
+   if (off >= r_size) /* (28) following ‘true’ branch (when ‘off >=
r_size’)... */
+   return 0;
+
if (off + sz > r_size) {
sz = r_size - off;
}
@@ -288,13 +291,14 @@ int reader_init_block_reader(struct reftable_reader *r,
struct block_reader *br,
uint32_t header_off = next_off ? 0 : header_size(r->version);
int32_t block_size = 0;

-   if (next_off >= r_size)
+   if (next_off >= r_size) /* (24) following ‘false’ branch (when
‘next_off < r_size’)... */
return 1;

err = reader_get_block(&block, &r->source, next_off, guess_block_size,
r_size);
-   if (err < 0)
+   if (err < 0) /* (31) following ‘false’ branch (when ‘err >= 0’)... */
goto done;

+   /* We'll supposedly deference NULL block.data[0] here ... */ 
block_size = extract_block_size(block.data, &block_typ, next_off,
r->version);
if (block_size < 0) {

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[avarab at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ævar Arnfjörð Bjarmason  ---
This code also errors under -Werror=analyzer-too-complex, including in some
adjacent code, so perhaps the analyzer gave up?

gcc-bugs@gcc.gnu.org

[avarab at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Ævar Arnfjörð Bjarmason  ---
Thanks a lot, I can confirm that this fixes the issue in builtin/merge-file.c
in git.git.

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #9 from Mikael Pettersson  ---
Can this be closed now? I cannot reproduce the abort at -O2 for the original
test case with current gcc-10/11 branch snapshots (but I can with snapshots
from March).

[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

[lili.cui at intel dot com via Gcc-bugs]

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

--- Comment #9 from cuilili  ---
Really appreciate for your reply, I debugged SRA pass with the small testcase
and found that SRA dose not handle this situation.

SRA cannot split callee's first parameter for "Do not decompose non-BLKmode
parameters in a way that would create a BLKmode parameter. Especially for
pass-by-reference (hence, pointer type parameters), it's not worth it."

Before inline:
For caller 
store-1 :   128 bits store of struct "a" (it is an implicit store during IPA
pass, the store can only be found after a certain pass.)
For callee
load-1 :128 bits load of struct "a" for operation "c->a=(*a)"
store-2:128 bits store of struct "c->a" for operation "c->a=(*a)" 
load-2 :4 * 32 bits load for c->a.f1, c->a.f2, c->a.f3 and c->a.f4.
(because the store-2 using vector register to store, we cannot use the register
directly here.) 

After inline:
For caller
None.
For callee
store-2 :  128 bits store of struct c->a for operation "c->a=(*a)"


int callee (struct A *a, struct C *c)
{
  c->a=(*a);   
  if ((c->b + 7) & 17)
{
  c->a.f1 = c->a.f2 + c->a.f3;
  c->a.f2 = c->a.f2 - c->a.f3;
  c->a.f3 = c->a.f2 + c->a.f3;
  c->a.f4 = c->a.f2 - c->a.f3;
  c->b = c->a.f2 + c->a.f4;
  return 0;
}
  return 1;
}

int caller (int d, struct C *c)
{
  struct A a;
  a.f1 = 1 + d;
  a.f2 = 2;
  a.f3 = 12 + d;
  a.f4 = 68 + d;
  if (d > 0)
return callee (&a, c);
  else
return 1;
}
-
In 538.imagic_r（c_ray also has the similar code）, if we inline the hot
function, the redundant store and load structure's size is 256 bits (4 elements
of size 64 bits), which can eliminates one 256-bit store, one 256-bit load, and
four 64-bit loads.
can I do it like this? Computes the total size of all callee arguments that can
eliminate redundant loads and stores. Thanks!

[Bug jit/105286] New: Struct initializers do not work with function pointers

[marc--- via Gcc-bugs]

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

Bug ID: 105286
   Summary: Struct initializers do not work with function pointers
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: m...@nieper-wisskirchen.de
  Target Milestone: ---

Created attachment 52815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52815&action=edit
Sample C source demonstrating the issue

Please consider the attached C file repro.c.

$ gcc -lgccjit repro.c && ./a.out
libgccjit.so: error: gcc_jit_context_new_struct_constructor: value and field
not the same unqualified type, at index 0 (struct struct.func: void (*)
())(value type: void (*) ())
libgccjit.so: error: gcc_jit_global_set_initializer_rvalue: NULL init_rvalue
gcc_jit_result_release: NULL result

The second error is caused by the first, which is the one I am reporting here.

[Bug analyzer/105287] New: [12 Regression] ICE in get_region_for_local, at analyzer/region.cc:874

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105287
   Summary: [12 Regression] ICE in get_region_for_local, at
analyzer/region.cc:874
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 52816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52816&action=edit
Testcase

g++ 12.0.1 20220410 snapshot (g:54c5e064cc3dc3c9b3dff12b6d48dc3efd482b07) ICEs
when compiling the attached testcase, reduced from
gcc/testsuite/g++.dg/coroutines/torture/co-await-18-if-cond.C, w/ -std=c++20
-fanalyzer:

% g++-12.0.1 -std=c++20 -fanalyzer -c refdaee6.C
during IPA pass: analyzer
refdaee6.C:35:73: internal compiler error: in get_region_for_local, at
analyzer/region.cc:874
   35 | coro1 my_coro() { co_await BoolAwaiter(true) && co_await IntAwaiter(1);
}
  |
^
0x89b2d6 ana::frame_region::get_region_for_local(ana::region_model_manager*,
tree_node*, ana::region_model_context const*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/region.cc:874
0x157c5e9 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/region-model.cc:2138
0x157c5e9 ana::region_model::get_lvalue(tree_node*, ana::region_model_context*)
const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/region-model.cc:2149
0x15b8915 fully_overwrites_p
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:840
0x15b8915
ana::state_purge_per_decl::process_point_backwards(ana::function_point const&,
auto_vec*, hash_set >*, ana::state_purge_map const&,
ana::region_model const&)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:928
0x15b8fae ana::state_purge_per_decl::process_worklists(ana::state_purge_map
const&, ana::region_model_manager*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:742
0x15bb1f1 ana::state_purge_map::state_purge_map(ana::supergraph const&,
ana::region_model_manager*, ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:262
0x155f824 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/engine.cc:5728
0x156047e ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/engine.cc:5851
0x154f108 execute
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/analyzer-pass.cc:87

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

[esgergn at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from Esger Abbink  ---
Cherry picking
https://github.com/gcc-mirror/gcc/commit/cde87638bf5cf6aafffb590986b6a890da0ba06c
on top of releases-9.4.0 allowed me to apply the patch to get a patched gcc9.4
supporting -fprofile-prefix-map and that leads to the same (desired) behavior
as described in the previous comment for patched gcc11, plus gcovr is now able
to produce coverage reports.

However, all is still not well, because ccache does not know the
-fprofile-prefix-map option and therefore marks files compiled with it as
uncacheable.. :(

[Bug libstdc++/105281] status of constexpr and for c++23

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

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

--- Comment #1 from Jonathan Wakely  ---
Those changes in  have been present since GCC 4.6, so they predate the
C++23 changes by *many* years. Nobody has yet verified how closely it conforms
to the new C++23 spec.

[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-15
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #9 from Michael_S  ---
(In reply to Michael_S from comment #4)
> If you want quick fix for immediate shipment then you can take that:
> 
> #include 
> #include 
> 
> __float128 quick_and_dirty_sqrtq(__float128 x)
> {
>   if (isnanq(x))
> return x;
> 
>   if (x==0)
> return x;
> 
>   if (x < 0)
> return nanq("");
> 
>   if (isinfq(x))
> return x;
> 
>   int xExp;
>   x = frexpq(x, &xExp);
>   if (xExp & 1)
> x *= 2.0; // x in [0.5:2.0)
> 
>   __float128 r = (__float128)(1.0/sqrt((double)x)); // r=rsqrt(x) estimate
> (53 bits)
>   r *= 1.5 - r*r*x*0.5; // NR iteration improves precision of r to 105.4 bit
> 
>   __float128 y  = x*r;  // y=sqrt(x) estimate (105.4 bits)
> 
>   // extended-precision NR iteration
>   __float128 yH = (double)y;
>   __float128 yL = y - yH;
> 
>   __float128 deltaX = x - yH*yH;
>   deltaX -= yH*yL*2;
>   deltaX -= yL*yL;
>   y += deltaX*r*0.5; // improve precision of y to ~210.2 bits. Not enough
> for perfect rounding, but not too bad
> 
>   return ldexpq(y, xExp >> 1);
> }
> 
> It is very slow, even slower than what you have now, which by itself is
> quite astonishingly slow.
> It is also not sufficiently precise for correct rounding in all cases.
> But, at least, the worst error is something like (0.5+2**-98) ULP, so you are
> unlikely to be ever caught by black box type of testing.
> It's biggest advantage is extreme portability.
> Should run on all platforms where double==IEEE binary64 and __float128 ==
> IEEE binary128.
> 
> May be, few days later I'll have better variant for "good" 64-bit platforms
> i.e. for those where we have __int128.
> It would be 15-25 times faster than the variant above and rounding would be
> mathematically correct rather than just "impossible to be caught" like above.
> But it would not run everywhere.
> Also, I want to give it away under MIT or BSD license, rather than under GPL.

Here.

#include 
#include 
#include 

static __inline uint64_t umulx64(uint64_t mult1, uint64_t mult2, int rshift)
{
  return (uint64_t)(((unsigned __int128)mult1 * mult2)>>rshift);
}

static __inline uint64_t umulh64(uint64_t mult1, uint64_t mult2)
{
  return umulx64(mult1, mult2, 64);
}

static __inline __float128 ret__float128(uint64_t wordH, uint64_t wordL) {
  unsigned __int128 res_u128 = ((unsigned __int128)wordH << 64) | wordL;
  __float128 result;
  memcpy(&result, &res_u128, sizeof(result)); // hopefully __int128 and
__float128 have the endianness
  return result;
}

__float128 slow_and_clean_sqrtq(__float128 src)
{
  typedef unsigned __int128 __uint128;
  const uint64_t SIGN_BIT   = (uint64_t)1  << 63;
  const uint64_t MANT_H_MSK = (uint64_t)-1 >> 16;
  const uint64_t nNAN_MSW = (uint64_t)0x8 << 44; // -NaN

  __uint128 src_u128;
  memcpy(&src_u128, &src, sizeof(src_u128));
  uint64_t mshalf = (uint64_t)(src_u128 >> 64); // MS half
  uint64_t mantL  = (uint64_t)(src_u128);   // LS half

  // parse MS half of source
  unsigned exp   = mshalf >> 48;
  uint64_t mantH = mshalf & MANT_H_MSK;
  unsigned expx = exp + 0x3FFF;
  if (exp - 1 >= 0x7FFF-1) { // special cases: exp = 0, exp=max_exp or sign=1
if (exp > 0x7fff) {  // negative
  if (exp==0x) { // NaN or -Inf
if ((mantH | mantL)==0) // -Inf
  mshalf = nNAN_MSW;
return ret__float128(mshalf, mantL); // in case of NaN the leave number
intact
  }
  if (mshalf==SIGN_BIT && mantL==0) // -0
return ret__float128(mshalf, mantL); // in case of -0 leave the number
intact
  // normal or sub-normal
  mantL = 0;
  mshalf = nNAN_MSW;
  return ret__float128(mshalf, mantL);
}
// non-negative
if (exp == 0x7fff) // NaN or -Inf
  return ret__float128(mshalf, mantL); // in case of positive NaN or Inf
leave the number intact

// exp==0 : zero or subnormal
if ((mantH | mantL)==0) // +0
  return ret__float128(mshalf, mantL); // in case of +0 leave the number
intact

// positive subnormal
// normalize
if (mantH == 0) {
  expx -= 48;
  int lz = __builtin_clzll(mantL);
  expx -= lz;
  mantL <<= lz + 1;
  mantH = mantL >> 16;
  mantL = mantL << 48;
} else {
  int lz = __builtin_clzll(mantH)-16;
  expx -= lz;
  mantH = (mantH << (lz+1)) | mantL >> (63-lz);
  mantL = mantL << (lz + 1);
}
mantH &= MANT_H_MSK;
  }

  // Normal case
  int e = expx & 1; // e= LS bit of exponent

  const uint64_t BIT_30 = (uint64_t)1 << 30;
  static const uint8_t rsqrt_tab[64] = { // floor(1/sqrt(1+i/32)*512) - 256
   252, 248, 244, 240,237, 233, 230, 226,
   223, 220, 216, 213,210, 207, 204, 201,
   199, 196, 193, 190,188, 185, 183, 180,
   178, 175, 173, 171,168, 166, 164, 162,
   159, 157, 155, 153,151, 149, 147, 145,
   143, 141, 139, 138,136, 134, 132, 131,
   129, 127, 125, 124,122, 121, 119, 117,
   116, 114, 113, 111,110, 108, 107, 106,
 };

  // Look for approximate value of rs

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

[esgergn at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from Esger Abbink  ---
After patching ccache 4.5.1 to understand -fprofile-prefix-map it does cache .o
and .gcno:

$ ccache -z -C

$ cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_DEBUG=
CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache
/usr/bin/g++-9.4p --coverage
-fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=.
-fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. -c
/home/esger/src/application/coverage_test/dir1/source/main.cpp

$ ccache -s
Summary:
  Hits:   0 /1 (0.00 %)
Direct:   0 /1 (0.00 %)
Preprocessed: 0 /1 (0.00 %)
  Misses: 1
Direct:   1
Preprocessed: 1
Primary storage:
  Hits:   0 /2 (0.00 %)
  Misses: 2
  Cache size (GB): 0.00 / 5.00 (0.00 %)
  Cleanups:   4

$ cd /home/esger/src/application/coverage_test/dir2/source/ && CCACHE_DEBUG=
CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir2 ccache
/usr/bin/g++-9.4p --coverage
-fprofile-prefix-map=/home/esger/src/application/coverage_test/dir2=.
-fdebug-prefix-map=/home/esger/src/application/coverage_test/dir2=. -c
/home/esger/src/application/coverage_test/dir2/source/main.cpp

$ ccache -s
Summary:
  Hits:   1 /2 (50.00 %)
Direct:   1 /2 (50.00 %)
Preprocessed: 0 /1 (0.00 %)
  Misses: 1
Direct:   1
Preprocessed: 1
Primary storage:
  Hits:   2 /4 (50.00 %)
  Misses: 2
  Cache size (GB): 0.00 / 5.00 (0.00 %)
  Cleanups:   4

Using the cached .o/.gcno also generates a gcda in the correct location:

$ cd /home/esger/src/application/coverage_test/dir2/source/ && CCACHE_DEBUG=
CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir2 ccache
/usr/bin/g++-9.4p --coverage
-fprofile-prefix-map=/home/esger/src/application/coverage_test/dir2=.
-fdebug-prefix-map=/home/esger/src/application/coverage_test/dir2=. main.o -o
../bin/a.out

$ cd /home/esger/src/application/coverage_test/dir2 && ./bin/a.out

$ ls source/
main.cpp  main.gcda  main.gcno  main.o

$ gcovr --html coverage.html .
[ coverage report OK ]



Though the gcno of source still contains a wrong CWD:

$ gcov-dump-9.4p source/main.gcno |more
main.gcno:note:magic `gcno':version `A94*'
main.gcno:stamp 761679940
main.gcno:cwd: /home/esger/src/application/coverage_test/dir1/source
main.gcno:  0100:  20:FUNCTION ident=1826217343,
lineno_checksum=0x36a9d8e5, cfg_checksum=0xc0bbb23e, `_GLOBAL__sub_I__Z5funcAi'
main.cpp:21:1-21:1, artificial
main.gcno:0141:   1:BLOCKS 4 blocks
main.gcno:0143:   3:ARCS 1 arcs
main.gcno:0143:   5:ARCS 2 arcs
main.gcno:0143:   3:ARCS 1 arcs
main.gcno:0145:   9:LINES
main.gcno:0145:   9:LINES
...


Not sure though what (negative) impact that will/could have?

[Bug analyzer/105287] [12 Regression] ICE in get_region_for_local, at analyzer/region.cc:874

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-04-15
 CC||iains at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Confirmed; it's an assertion failing in
ana::frame_region::get_region_for_local, due to a variable having NULL for its
DECL_CONTEXT:

(gdb) list
869 case SSA_NAME:
870   {
871 if (tree var = SSA_NAME_VAR (expr))
872   {
873 if (DECL_P (var))
874   gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
875   }

This is probably benign if assertions are disabled (perhaps the analyzer is
being more fussy than the rest of the middle-end?)

(gdb) call debug_tree(var)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea665b28 precision:1 min  max 
pointer_to_this >
unsigned QI ../../src/gcc/testsuite/g++.dg/analyzer/pr105287.C:35:73 size
 unit-size 
align:8 warn_if_not_align:0>
(gdb) p var.decl_minimal.context 
$2 = 


The var_decl is "cond_var" created here in the C++ FE:

#4  0x00b30ec2 in flatten_await_stmt (n=0x317b9b0,
promoted=0x7fffcc40, temps_used=0x7fffcc70, replace_in=)
at ../../src/gcc/cp/coroutines.cc:2792
2792  tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
cond_type);
(gdb) list
2787  /* If the condition contains an await expression, then we
need to
2788 set that first and use a separate var.  */
2789  if (cp_walk_tree (&cond, find_any_await, &found, NULL))
2790{
2791  tree cond_type = TREE_TYPE (cond);
2792  tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
cond_type);
2793  DECL_ARTIFICIAL (cond_var) = true;
2794  layout_decl (cond_var, 0);
2795  gcc_checking_assert (!TYPE_NEEDS_CONSTRUCTING
(cond_type));
2796  cond = build2 (INIT_EXPR, cond_type, cond_var, cond);
2797  var_nest_node *ins
2798= new var_nest_node (cond_var, cond, n->prev, n);
2799  COND_EXPR_COND (n->init) = cond_var;
2800  flatten_await_stmt (ins, promoted, temps_used, NULL);
2801}

Iain: shouldn't the DECL_CONTEXT be being set on var_decls created here?

[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X caused by r0-109856

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
Created attachment 52817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52817&action=edit
fix

Here's a fix, but I'm going to hold it for stage 1, probably backport for 12.2
etc.

[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X caused by r0-109856

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #3 from David Malcolm  ---
Thanks for filing this bug; I can reproduce it with the initial attachment;
it's unclear to me yet what's going on.

[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to David Malcolm from comment #1)
> Confirmed; it's an assertion failing in
> ana::frame_region::get_region_for_local, due to a variable having NULL for
> its DECL_CONTEXT:
> 
> (gdb) list
> 869   case SSA_NAME:
> 870 {
> 871   if (tree var = SSA_NAME_VAR (expr))
> 872 {
> 873   if (DECL_P (var))
> 874 gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
> 875 }
> 
> This is probably benign if assertions are disabled (perhaps the analyzer is
> being more fussy than the rest of the middle-end?)
> 
> (gdb) call debug_tree(var)
>   type  type_6 QI
> size 
> unit-size 
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fffea665b28 precision:1 min  max
> 
> pointer_to_this >
> unsigned QI ../../src/gcc/testsuite/g++.dg/analyzer/pr105287.C:35:73
> size  unit-size 
> align:8 warn_if_not_align:0>
> (gdb) p var.decl_minimal.context 
> $2 = 
> 
> 
> The var_decl is "cond_var" created here in the C++ FE:
> 
> #4  0x00b30ec2 in flatten_await_stmt (n=0x317b9b0,
> promoted=0x7fffcc40, temps_used=0x7fffcc70, replace_in= out>)
> at ../../src/gcc/cp/coroutines.cc:2792
> 2792tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
> cond_type);
> (gdb) list
> 2787/* If the condition contains an await expression, then we 
> need to
> 2788   set that first and use a separate var.  */
> 2789if (cp_walk_tree (&cond, find_any_await, &found, NULL))
> 2790  {
> 2791tree cond_type = TREE_TYPE (cond);
> 2792tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
> cond_type);
> 2793DECL_ARTIFICIAL (cond_var) = true;
> 2794layout_decl (cond_var, 0);
> 2795gcc_checking_assert (!TYPE_NEEDS_CONSTRUCTING 
> (cond_type));
> 2796cond = build2 (INIT_EXPR, cond_type, cond_var, cond);
> 2797var_nest_node *ins
> 2798  = new var_nest_node (cond_var, cond, n->prev, n);
> 2799COND_EXPR_COND (n->init) = cond_var;
> 2800flatten_await_stmt (ins, promoted, temps_used, NULL);
> 2801  }
> 
> Iain: shouldn't the DECL_CONTEXT be being set on var_decls created here?

I'd expect so; does build_lang_decl() not add them to the current context? [I
didn't look at the code, and memory might be faulty there].  If it doesn't then
I need to take a pass through and add the appropriate one.

[Bug c++/105268] type/value mismatch when using variadic concept

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r12-8176-gccae4443c8322d9d82a19a1e7c689413a122a478
Author: Marek Polacek 
Date:   Thu Apr 14 13:48:15 2022 -0400

c++: wrong error with variadic concept [PR105268]

Here we issue a wrong error for the

  template>> void g();

line in the testcase.  I surmise that's because we mistakenly parse
C_many as a placeholder-type-specifier, and things go wrong from
there.  We are in a default argument so we should reject parsing
C_many
as a placeholder-type-specifier, which would mean creating a new parameter.
We want C_many to be a concept-id instead.

It's interesting to see why the same problem didn't occur for C_one.
In that case, cp_parser_placeholder_type_specifier ->
finish_type_constraints
-> build_type_constraint -> build_concept_check -> build_standard_check ->
coerce_template_parms fails the parse here:

 8916   nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
 8917   if ((nargs - variadic_args_p > nparms && !variadic_p)
 8918   || (nargs < nparms - variadic_p
 8919   && require_all_args
 8920   && !variadic_args_p
 8921   && (!use_default_args
 8922   || (TREE_VEC_ELT (parms, nargs) != error_mark_node
 8923   && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
 8924 {
 8925 bad_nargs:
 ...
 8943   return error_mark_node;

because nargs is 2 (the targs are ) while nparms is
1 (for the one 'typename' in the tparam list of C_one).  But for
C_many variadic_p is true so we don't return error_mark_node but
.

This patch does not issue any error for the !tentative case because
I didn't figure out how to trigger that.  So it adds an assert instead.

PR c++/105268

gcc/cp/ChangeLog:

* parser.cc (cp_parser_placeholder_type_specifier): Return
error_mark_node when trying to build up a constrained parameter in
a default argument.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/variadic6.C: New test.

[Bug c++/105268] type/value mismatch when using variadic concept

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 12.

[Bug c++/101500] [C++17] [DR2311] gcc accepts the code with extra curly braces

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] gcc |[C++17] [DR2311] gcc
   |accepts the code with extra |accepts the code with extra
   |curly braces|curly braces
 Status|NEW |SUSPENDED
URL||wg21.link/cwg2311

--- Comment #2 from Jason Merrill  ---
This seems like an instance of issue 2311: with C++17 mandatory copy elision,
do we really want an actual call to the move constructor in this case?  The
testcase is rejected in C++14 mode, as expected.

The standard says that we try to call a constructor, initializing the argument
with {A{}}.  So we in turn look for an A constructor to initialize the
argument, initializing its argument from A{}.  Under 2311, does this result in
still an rvalue?  And the enclosing constructor call, still the same rvalue?

This seems parallel to

const A a = A(A(A()));

which is also accepted by clang in C++17 mode.

Perhaps we want to raise the priority of issue 2311.

[Bug jit/105279] Using libgccjit produces a null pointer access in GCC's tree-optimization code

[marc--- via Gcc-bugs]

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

--- Comment #1 from Marc Nieper-Wißkirchen  ---
The internal compiler error also seems to go away if I remove the pointer
subtraction around line 1833 in reproducer.c.  Maybe this is the real problem
because I am not subtracting pointers the way I should do in libgccjit (but
still, it shouldn't crash).  But if this is not the way to do it, is there
another way to achieve pointer subtraction (besides bitcasting the pointers to
integers)?

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

[i at rvalue dot moe via Gcc-bugs]

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

--- Comment #15 from rvalue  ---
Hi, Kito:

I've tried these patches and found that it doesn't work with isa-spec
20190608/20191213.

Release 11.2.0 with following patches applied: 9871d39f752b, f41871dfdbd9,
f049717d8d50, 330aff0a9f7b, fa21fcfb6758

Verbose output:

$ cat > test.c
int main(){
asm volatile("fence.i" ::: "memory");
}
$ gcc test.c -o test -v -march=rv64gc -misa-spec=20191213
Using built-in specs.
COLLECT_GCC=/usr/sbin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--disable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--enable-link-serialization=1 gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-march=rv64gc' '-misa-spec=20191213'
'-mabi=lp64d' '-march=rv64imafdc'
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/cc1 -quiet -v test.c -quiet
-dumpbase test.c -dumpbase-ext .c -march=rv64gc -misa-spec=20191213 -mabi=lp64d
-march=rv64imafdc -version -o /tmp/ccQTUxnc.s
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/../../../../riscv64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include
 /usr/local/include
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7a7a4553dc5ab0b4f8fc26761070a0ed
COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-march=rv64gc' '-misa-spec=20191213'
'-mabi=lp64d' '-march=rv64imafdc'
 as -v --traditional-format -fpic -march=rv64gc -march=rv64imafdc -mabi=lp64d
-misa-spec=20191213 -o /tmp/cc2my6Or.o /tmp/ccQTUxnc.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
test.c: Assembler messages:
test.c:2: Error: unrecognized opcode `fence.i'

[Bug libstdc++/104858] ranges::minmax double dereferences first

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

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

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

https://gcc.gnu.org/g:7e76cef873342a66408c126abceaf7dbddd3f477

commit r12-8178-g7e76cef873342a66408c126abceaf7dbddd3f477
Author: Patrick Palka 
Date:   Fri Apr 15 14:41:14 2022 -0400

libstdc++: Avoid double-deref of __first in ranges::minmax [PR104858]

PR libstdc++/104858

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing
__first twice at the start.
* testsuite/25_algorithms/minmax/constrained.cc (test06): New test.

[Bug libstdc++/104858] ranges::minmax double dereferences first

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #10 from Jan Hubicka  ---
Fixed.

[Bug c/100545] ICE with -g: in gen_typedef_die with mode attribute and aligned attribute

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

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

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 target/105288] New: AVX/AVX512 casts should the "v" constraint

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

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

Bug ID: 105288
   Summary: AVX/AVX512 casts should the "v" constraint
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
Target: x86-64

There are

(define_insn_and_split "avx__"
  [(set (match_operand:AVX256MODE2P 0 "nonimmediate_operand" "=x,m")
(vec_concat:AVX256MODE2P
  (match_operand: 1 "nonimmediate_operand" "xm,x")
  (unspec: [(const_int 0)] UNSPEC_CAST)))]
  "TARGET_AVX && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

where the "x" constraint should be "v".

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

[esgergn at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from Esger Abbink  ---
Building a real project with the patched gcc9.4 and ccache 4.5.1 (replacing
-fprofile-dir with -fprofile-prefix-map=${CMAKE_SOURCE_DIR}=.) it looks ok at
first sight:

- 100% cache hits for the second compilation in a different directory
- gcda created next to .o & .gcda for both first and second
compilations/directories

However when running the unittests binaries there are quite a number of gcov
warnings:

[==] 2807 tests from 297 test suites ran. (272928 ms total)
[  PASSED  ] 2807 tests.

libgcov profiling error:
:overwriting an existing profile data with a different timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:
:overwriting an existing profile data with a different timestamp
libgcov profiling error::overwriting an existing profile data with a different
timestamp
libgcov profiling error::overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:&:overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:':overwriting an existing profile data with a different
timestamp
profiling::Cannot open
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error::overwriting an existing profile data with a different
timestamp
...
[this continues for quite a number of lines]

Note that these warnings are produced both for the directory where compilation
really took place as for the directory where .o & .gcno were taken from the
cache.

Since the gcda files are created next to the .o * .gcno there should not be any
name clashes (for identical names the path would still be different). So I am
not sure what is happening here? Unfortunately, the warning lines do not
include any information about which file is being written or which file is
clashing.



Still, gcovr is able to produce a coverage report with information that looks
sane, but there are differences with the gcc7.5 reports. I would assume because
of the above warnings. 

The coverage report for the second compilation (using cached .o & .gcno) is for
all intents and purposes the same as the one for the first compilation. The
difference being 2 lines and 2 branches on totals of 17515 and 14727.

[Bug c++/105289] New: ICE on partial specialization

[michsteinb at gmail dot com via Gcc-bugs]

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

Bug ID: 105289
   Summary: ICE on partial specialization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michsteinb at gmail dot com
  Target Milestone: ---

Created attachment 52818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52818&action=edit
Self-contained reproduction of the ICE, compile with -std=c++20

arm-none-eabi-g++ 11.2 crashes on attached self-contained code with following
prompt on win64:
```
PS H:\projects\install\arm-embedded-gcc\11.2-2022.02\bin>
.\arm-none-eabi-g++.exe -save-temps -std=c++20 -c repro.cxx
repro.cxx:14:8: internal compiler error: Segmentation fault
   14 | struct push_front_vlist, Arg>
  |^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

The 10.x release cycle compilers accepted this code, so does clang, so this is
a regression introduced with 11.0.

Further checks on godbolt showed the same behaviour on all 11.x compilers I
tried.

The problem stems from the primary template using a meta-function of its first
parameter as type for its second. If I do not constrain the type of Arg, the
crash disappears.

[Bug target/105288] AVX/AVX512 casts should use the "v" constraint

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongyu Wang  ---
I think should be these 2?

(define_insn_and_split "avx512f__"
  [(set (match_operand:AVX512MODE2P 0 "nonimmediate_operand" "=x,m")
(vec_concat:AVX512MODE2P
  (vec_concat:
(match_operand: 1 "nonimmediate_operand" "xm,x")
(unspec: [(const_int 0)] UNSPEC_CAST))
  (unspec: [(const_int 0)] UNSPEC_CAST)))]
  "TARGET_AVX512F && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

(define_insn_and_split "avx512f__256"
  [(set (match_operand:AVX512MODE2P 0 "nonimmediate_operand" "=x,m")
(vec_concat:AVX512MODE2P
  (match_operand: 1 "nonimmediate_operand" "xm,x")
  (unspec: [(const_int 0)] UNSPEC_CAST)))]
  "TARGET_AVX512F && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

The AVX insn shouldn't have constraints "v"

[Bug c++/105290] New: "Purely syntactic" disambiguation but GCC applies semantic rules for constant expressions

[hstong at ca dot ibm.com via Gcc-bugs]

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

Bug ID: 105290
   Summary: "Purely syntactic" disambiguation but GCC applies
semantic rules for constant expressions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

As far as parsing is concerned, a _constant-expression_ is just a
_conditional-expression_. There is no statement that a _constant-expression_
has to be semantically a constant expression to be parsed as one.

Every use of _constant-expression_ in the grammar is associated with a
case-specific (semantic) statement that applies the semantic constant
expression requirements.

It looks like GCC applies the semantic rules for constant expressions while
performing vexing parse disambiguation, which the standard says is "purely
syntactic".

Compiler Explorer link: https://godbolt.org/z/Ms38PPsqh

### SOURCE (``):
typedef int *Ptr;
int idx(unsigned *) { return 0; }
constexpr int idx(short *) { return 1; }
void zip(void **p) {
  int val(Ptr (*p)[idx((short *)0)]); // constant expression in array
declarator
  val(nullptr);
}
void zap(void **p) {
  int val(Ptr(*p)[idx((unsigned *)0)]); // non-constant expression in subscript
expression?!
  val(nullptr);
}


### ACTUAL OUTPUT:
: In function 'void zap(void**)':
:10:6: error: 'val' cannot be used as a function


### EXPECTED OUTPUT:
(Clean compile)


### COMPILER INVOCATION:
g++ -fsyntax-only -Wno-vexing-parse -xc++ -


### COMPILER VERSION INFO (`g++ -v`):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220415 (experimental) (GCC)

[Bug c++/105290] "Purely syntactic" disambiguation but GCC applies semantic rules for constant expressions

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

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

--- Comment #1 from Andrew Pinski  ---
There is another bug related to how array types are messed up when it comes to
parsing. I suspect this is a dup of that one.