[Bug tree-optimization/101009] [12 Regression] wrong code with "-O3 -fno-tree-sra"

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

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

--- Comment #7 from Richard Biener  ---
So interestingly we do compute a distance vector of zero but we fail to add it,
instead we end up returning true from build_classic_dist_vector_1 without
setting *init_b to true (the access fns are not POLYNOMIAL_CHREC but are
equal).  Then in build_classic_dist_vector we skip

  /* Save the distance vector if we initialized one.  */
  if (init_b)
..

and run into

  /* There is a distance of 1 on all the outer loops: Example:
 there is a dependence of distance 1 on loop_1 for the array A.

 | loop_1
 |   A[5] = ...
 | endloop
  */
  add_outer_distances (ddr, dist_v,
   lambda_vector_first_nz (dist_v,
   DDR_NB_LOOPS (ddr), 0));

which ends up pushing a distance vector (1) as "outer distance".  But in
the skipped if () case we'd only ever do that if DDR_NB_LOOPS > 1.

Both

@@ -5435,7 +5437,7 @@ build_classic_dist_vector (struct
data_dependence_relation
 *ddr,
save_dist_v (ddr, save_v);
}
 }
-  else
+  else if (DDR_NB_LOOPS (ddr) > 1)
 {
   /* There is a distance of 1 on all the outer loops: Example:
 there is a dependence of distance 1 on loop_1 for the array A.

and

@@ -5121,6 +5121,8 @@ build_classic_dist_vector_1 (struct
data_dependence_relati
on *ddr,
  non_affine_dependence_relation (ddr);
  return false;
}
+  else
+   *init_b = true;
 }

   return true;

fix the miscompilation.  For the first patch we end up with no distance
vector in ddr->dist_vects and for the second with a single { 0 } distance
vector.  IMHO the second looks more correct to me but maybe it is intended
that non-affine but constant indexes do not get a distance vector.

Anybody with some insights here?

[Bug tree-optimization/101009] [10/11/12 Regression] wrong code with "-O3 -fno-tree-sra"

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12 Regression] wrong code  |[10/11/12 Regression] wrong
   |with "-O3 -fno-tree-sra"|code with "-O3
   ||-fno-tree-sra"
   Target Milestone|12.0|10.4
  Known to work||9.4.0

--- Comment #8 from Richard Biener  ---
With -O2 -fno-tree-sra -fno-tree-pre -ftree-loop-distribution even GCC 10
miscompiles the code.  For dg-torture:

/* { dg-do run } */
/* { dg-additional-options "-fno-tree-sra -fno-tree-pre
-ftree-loop-distribution" } */

struct a {
  unsigned b;
  unsigned c;
} e, *f = &e;
int d = 1;
int main() {
  for (; d; d--) {
struct a g[] = {{2, 1}, {2, 1}};
*f = g[1];
  }
  if (e.c != 1)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/97770] [ICELAKE]suboptimal vectorization for vpopcntw/b/q

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

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

--- Comment #20 from Richard Biener  ---
(In reply to H.J. Lu from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> > 
> > That's going to work I guess but it will pessimize general optimization
> > which no longer know this is computing popcount (not sure if the old
> > version exposed that fact).
> 
> Do we have testcase for that?

Sth like

int
foo  (unsigned long long a)
{
  return _mm_popcnt_u64 (a) == 0;
}

basically anything that triggers a simplification of POPCOUNT as implemented
in match.pd (there are quite some).  But no, I don't think we have any
of those using the x86 intrinsics in the testsuite.

Guest article pitch

[Lisa Smith via Gcc-bugs]

Hello

Do you currently accept guest posts on - lttng.org?

I’d be happy to provide you with a high-quality article related to the tech or 
eCommerce niche.

Let me know the requirements.
Lisa Smith
Don't want emails from us anymore? Reply to this email with the word 
"UNSUBSCRIBE" in the subject line.

[Bug tree-optimization/101009] [10/11/12 Regression] wrong code with "-O3 -fno-tree-sra"

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> @@ -5435,7 +5437,7 @@ build_classic_dist_vector (struct
> data_dependence_relation
>  *ddr,
> save_dist_v (ddr, save_v);
> }
>  }
> -  else
> +  else if (DDR_NB_LOOPS (ddr) > 1)
>  {
>/* There is a distance of 1 on all the outer loops: Example:
>  there is a dependence of distance 1 on loop_1 for the array A.

I suppose this one would re-introduce the problem when we add an outer loop
(and include that in dependence analysis).  So I'm testing the other one now.

[Bug target/101021] PSHUFB is emitted instead of PSHUFD, PSHUFLW and PSHUFHW with -msse4

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-11
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Uroš Bizjak  ---
Created attachment 50982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50982&action=edit
Proposed patch

Effectively one liner patch with:

+  /* Try to avoid variable permutation instruction.  */
+  if (canonicalize_vector_int_perm (d, &nd) && expand_vec_perm_1 (&nd))
+return false;

in a strategic place.

Survives:

GCC_TEST_RUN_EXPENSIVE=1 make check-gcc RUNTESTFLAGS='--target_board=unix/-mavx
dg-torture.exp=vshuf*.c'

[Bug c++/100897] Symmetric transfer does not prevent stack-overflow for C++20 coroutines

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94794,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95137

--- Comment #1 from Iain Sandoe  ---
for symmetric transfer to work without stack overflow, it relies on an indirect
tailcall.

For some GCC targets indirect tail-calls are not available without some
additional support (see PR94794).

I tried to reproduce this (with a test case I use regularly for this) on a
target that normally completes symmetric transfers successfully when the
optimisation level is > 1. (x86_64, darwin).

The fail also occurs with my regular test case with -fsanitize=address - so, it
seems that the inclusion of the address sanitiser is preventing or interfering
with the tailcall.  Note that there are also other known issues with coroutines
and the sanitizers (PR95137).

[Bug testsuite/101020] [12 regression] Several test case failures after r12-1316

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.2

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Priority|P3  |P2
  Known to fail||11.1.0, 12.0
   Last reconfirmed||2021-06-11
   Target Milestone|--- |11.2
 Ever confirmed|0   |1
Version|unknown |12.0
Summary|wrong code at -O3 on|[11/12 Regression] wrong
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Confirmed.  -fno-tree-vectorize fixes it, but in the end it seems to be
store motion that moves the vector stores across the stores in the if (!g)
block.  Thus -fno-tree-loop-im also fixes it.

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from Uroš Bizjak  ---
CC added.

[Bug tree-optimization/101026] New: [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

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

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

Bug ID: 101026
   Summary: [12 Regression] ICE Segmentation fault since
r12-1329-gce670e4faafb296d
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat ice.f
  SUBROUTINE PASSB4 (CC,CH)
  DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
 DO 103 I=2,IDO,2
TI4 = CC0-CC(I,4,K)
CI4 = TI1-TI4
CH(I-1,K,4) = CI4
CH(I,K,4) = CI4
  103CONTINUE
  END

$ gcc ice.f -Ofast -c -frounding-math 
during GIMPLE pass: vect
ice.f:1:23:

1 |   SUBROUTINE PASSB4 (CC,CH)
  |   ^
internal compiler error: Segmentation fault
0xf15eda crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0x11d40e2 vect_optimize_slp(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3626
0x11b4f3e vect_analyze_loop_2
/home/marxin/Programming/gcc/gcc/tree-vect-loop.c:2332
0x11b51fa vect_analyze_loop(loop*, vec_info_shared*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.c:2986
0x11e6615 try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1009
0x11e704e vectorize_loops()
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1243
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #2 from Roger Sayle  ---
Isn't the variable "a" uninitialized in this code.  If "a" happens to have the
value zero, the code works fine; but if "a" is non-zero, the value of "h"
changes value in calls to k() and the program aborts?

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #2 from Richard Biener  ---
Shorter IL testcase:

int a[10];
int b, d, g;
volatile char c;
short e;
volatile int f;
int main()
{
  for (; d <= 9; d++) {
  b = e = 0;
  for (; e < 4; e++)
a[e] = 4;
  for (; b <= 3; b++)
if (g)
  f = 0;
else
  a[b] = c;
  }
  if (a[1] != 0)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started in between r11-4120-g94fd05f1f76faca9 and r11-4127-g35f258f4bbba7fa0, I
can't build the commit in between.

[Bug c++/101027] New: Short-circuit behavior not respected with co_await in while head

[alois1--- via Gcc-bugs]

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

Bug ID: 101027
   Summary: Short-circuit behavior not respected with co_await in
while head
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alo...@gmx-topmail.de
  Target Milestone: ---

Created attachment 50983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50983&action=edit
Reduced preprocessed code

GCC miscompiles the following C++ program:

$ cat test.cpp
#include 

struct task
{
struct promise_type
{
task get_return_object() { return
{std::coroutine_handle::from_promise(*this)}; }
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() {}
void return_void() {}
};

bool await_ready() { return true; }
void await_suspend(std::coroutine_handle<>) {}
bool await_resume() { return true; }

std::coroutine_handle m_handle;
};

extern "C" void exit(int status);

task should_not_execute()
{
exit(1);
co_return;
}

task main_task()
{
while (false && co_await should_not_execute());
}

int main()
{
main_task();
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb]
(SUSE Linux) 

$ g++ -std=c++20 test.cpp; ./a.out; echo $?
1

Expected output would be 0, as the && operator should short-circuit, and
should_not_execute therefore should never be started (in particular, the call
to exit should not be reached).

Interestingly, the unexpected behavior only happens in a while head, in an if
head or assignment to a variable the short-circuit behavior seems to be
respected.

For convenience, I have attached a manually reduced version of the preprocessed
code that I have confirmed to exhibit the same behavior.

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #4 from Martin Liška  ---
So started with r11-4123-g128f43cf679e51564202b41f23fae4146347f93d.

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #5 from Richard Biener  ---
The issue is with sm_seq_valid_bb which when processing store sequences from
multiple branches of the CFG performs merging in a way that drops refs
that still need to be considered for dependence queries.  Notably

  /* Incrementally merge seqs into first_edge_seq.  */
  for (unsigned int i = 0; i < min_len; ++i) 
{
  /* ???  We can more intelligently merge when we face
different
 order by additional sinking operations in one sequence.
 For now we simply mark them as to be processed by the
 not order-preserving SM code.  */
  if (first_edge_seq[i].first != edge_seq[i].first)
{
  if (first_edge_seq[i].second == sm_ord)
bitmap_set_bit (refs_not_supported,
first_edge_seq[i].first); 
  if (edge_seq[i].second == sm_ord)
bitmap_set_bit (refs_not_supported, edge_seq[i].first);
  first_edge_seq[i].second = sm_other;
  first_edge_seq[i].from = NULL_TREE;

we re matching f ={v} 0 against a[3] = ...;, marking 'f' as not supported for
store-motion and to be dependence checked against all stores in the sequence.
But we simply forget about a[3] = ... which we'd need to insert somehow into
the sequence for dependence checking purposes similar to how we handle

  /* Any excess elements become sm_other since they are now
 coonditionally executed.  */
  if (first_edge_seq.length () > edge_seq.length ())
{ 

(but even that code looks suspicious).  What we'd need to verify is that
we can push the ref down in 'edge_seq' (but not actually do that) and then
append it like the late loop (but we need to disambiguate against the
stores in first_edge_seq as well).

The code is quite complex and as it handles dependence queries incrementally
it's also fragile...

[Bug tree-optimization/101009] [10/11/12 Regression] wrong code with "-O3 -fno-tree-sra"

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #8)
> With -O2 -fno-tree-sra -fno-tree-pre -ftree-loop-distribution even GCC 10
> miscompiles the code.  For dg-torture:

That started with r10-141-g051ef623d6e332a6199bbf4e6c66e53925cac825

[Bug tree-optimization/101009] [10/11/12 Regression] wrong code with "-O3 -fno-tree-sra"

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

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

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

https://gcc.gnu.org/g:336c41dbcb21740f8964021e157bc69ca547059b

commit r12-1381-g336c41dbcb21740f8964021e157bc69ca547059b
Author: Richard Biener 
Date:   Fri Jun 11 09:33:58 2021 +0200

middle-end/101009 - fix distance vector recording

This fixes recording of distance vectors in case the DDR has just
constant equal indexes.  In that case we expect distance vectors
with zero distances to be recorded which is what was done when
any distance was computed for affine indexes.

2021-06-11  Richard Biener  

PR middle-end/101009
* tree-data-ref.c (build_classic_dist_vector_1): Make sure
to set *init_b to true when we encounter a constant equal
index pair.
(compute_affine_dependence): Also dump the actual DR_REF.

* gcc.dg/torture/pr101009.c: New testcase.

[Bug tree-optimization/101009] [10/11 Regression] wrong code with "-O3 -fno-tree-sra"

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
   |code with "-O3  |code with "-O3
   |-fno-tree-sra"  |-fno-tree-sra"

--- Comment #12 from Richard Biener  ---
Fixed on trunk sofar - the underlying issue is latent everywhere and not really
a regression.

[Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org
 Status|ASSIGNED|NEW

--- Comment #6 from Richard Biener  ---
Not working on this at the moment.

[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r12-1383-g8bf728aecc4fea46b4490e950b9ae229f90597b0
Author: Martin Liska 
Date:   Tue Jun 1 15:13:18 2021 +0200

Introduce -Wcoverage-invalid-line-number

PR gcov-profile/100788

gcc/ChangeLog:

* common.opt: Add new option.
* coverage.c (coverage_begin_function): Emit warning instead on
the internal compiler error.
* doc/invoke.texi: Document the option.
* toplev.c (process_options): Enable it by default.

gcc/testsuite/ChangeLog:

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

[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||12.0

--- Comment #14 from Martin Liška  ---
Fixed on master so far.

[Bug target/79185] [8 Regression] register allocation in the addition of two 128/9 bit ints

[drraph at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Raphael C  ---
Tested in gcc 11.1 with -O2

ai(__int128, __int128):
mov r9, rdi
mov rax, rdx
mov r8, rsi
mov rdx, rcx
add rax, r9
adc rdx, r8
ret


This looks like two more mov's than needed but I may be wrong.

By contrast clang gives

ai(__int128, __int128):  
mov rax, rdi
add rax, rdx
adc rsi, rcx
mov rdx, rsi
ret

[Bug tree-optimization/79201] missed optimization: sinking doesn't handle calls, swap PRE and sinking

[drraph at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Raphael C  ---
I can confirm you now get

f:
mov eax, 1
ret

with gcc 8 onwards.

[Bug tree-optimization/101026] [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-11
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug target/101021] PSHUFB is emitted instead of PSHUFD, PSHUFLW and PSHUFHW with -msse4

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-1384-g1fa991d1d74cb1ce96c48ede70ae0be7a9683ce3
Author: Uros Bizjak 
Date:   Fri Jun 11 12:31:42 2021 +0200

i386: Try to avoid variable permutation instruction [PR101021]

Some permutations can be implemented without costly PSHUFB instruction,
e.g.:

{ 8,9,10,11,12,13,14,15, 0,1,2,3,4,5,6,7 } with PALIGNR,

{ 0,1,2,3, 4,5,6,7, 4,5,6,7, 12,13,14,15 } with PSHUFD,

{ 0,1, 2,3, 2,3, 6,7, 8,9,10,11,12,13,14,15 } with PSHUFLW and

{ 0,1,2,3,4,5,6,7, 8,9, 10,11, 10,11, 14,15 } with PSHUFHW.

All these instructions have constant shuffle control mask and do not
need to load shuffle mask from a memory to a temporary XMM register.

2021-06-11  Uroš Bizjak  

gcc/
PR target/101021
* config/i386/i386-expand.c (expand_vec_perm_pshufb): Return
false if the permutation can be implemented with constant
permutation instruction in wider mode.
(canonicalize_vector_int_perm): Move above expand_vec_perm_pshufb.
Handle V8QImode and V4HImode.

gcc/testsuite/

PR target/101021
* gcc.target/i386/pr101021-1.c: New test.
* gcc.target/i386/pr101021-2.c: Ditto.

[Bug c++/100897] Symmetric transfer does not prevent stack-overflow for C++20 coroutines

[l.v.merzljak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Leonard von Merzljak  ---
(In reply to Iain Sandoe from comment #1)
> for symmetric transfer to work without stack overflow, it relies on an
> indirect tailcall.
> 
> For some GCC targets indirect tail-calls are not available without some
> additional support (see PR94794).
> 
> I tried to reproduce this (with a test case I use regularly for this) on a
> target that normally completes symmetric transfers successfully when the
> optimisation level is > 1. (x86_64, darwin).
> 
> The fail also occurs with my regular test case with -fsanitize=address - so,
> it seems that the inclusion of the address sanitiser is preventing or
> interfering with the tailcall.  Note that there are also other known issues
> with coroutines and the sanitizers (PR95137).

Thank you for your comment. I tried it out and can confirm that I don't get a
stack-overflow anymore if I omit -fsanitize=address and use an optimization
level > 1. If the issues with coroutines and sanitizers are already known, then
this bug report can be marked as resolved.
Of course, it would be nice if the stack-overflow would not occur even when
using an optimization level <= 1, but this probably does not qualify as a bug.

[Bug target/101021] PSHUFB is emitted instead of PSHUFD, PSHUFLW and PSHUFHW with -msse4

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug tree-optimization/101028] New: [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

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

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

Bug ID: 101028
   Summary: [12 Regression] SLP compile-time hog since
r12-1329-gce670e4faafb296d
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following is causing hog (reduced from imagick SPEC benchmark):

$ cat 1.i
void ConvertImageCommand();
void MagickCommandGenesis();
void MogrifyImages();
void TracePath();

typedef struct {
  double x, y;
} PointInfo;

typedef struct {
  PointInfo point;
} PrimitiveInfo;

int TraceBezier_alpha, TraceBezier_i;
double TraceBezier_weight;
PointInfo *TraceBezier_points;
PrimitiveInfo *TraceBezier_primitive_info;
void DrawImage() { TracePath(); }

void TracePath() {
  double *coefficients;
  PointInfo point;
  long j;
  for (; TraceBezier_i; TraceBezier_i++) {
point.x = point.y = TraceBezier_alpha = 1.0;
j = 0;
for (; j < 4; j++) {
  point.x += TraceBezier_alpha * coefficients[j] *
 TraceBezier_primitive_info->point.x;
  point.y += TraceBezier_alpha * TraceBezier_primitive_info->point.y;
  TraceBezier_alpha *= TraceBezier_weight;
  TraceBezier_primitive_info++;
}
TraceBezier_points[TraceBezier_i] = point;
TraceBezier_weight += 1.0;
  }
}

void ConvertMain() { MagickCommandGenesis(ConvertImageCommand); }
void ConvertImageCommand() { MogrifyImages(); }
void MogrifyImages() { DrawImage(); }

int main() { return ConvertMain; }

$ gcc 1.i -flto=auto -Ofast  -shared -fPIC
...

likely never finishes :)

[Bug tree-optimization/101028] [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
   Priority|P3  |P1
 Blocks||26163


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug target/101007] [12 Regression] ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2

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

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

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

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

commit r12-1385-ga984da88a35b42f444d1f9eeba77aa520b950d35
Author: Jakub Jelinek 
Date:   Fri Jun 11 12:58:22 2021 +0200

i386: Fix up *vec_concat_0_1 [PR101007]

On Fri, Apr 23, 2021 at 12:53:58PM +0800, Hongtao Liu via Gcc-patches
wrote:
> -(define_insn "*vec_concatv4si_0"
> -  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
> - (vec_concat:V4SI
> -   (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
> -   (match_operand:V2SI 2 "const0_operand"   " C,C")))]
> +(define_insn "*vec_concat_0"
> +  [(set (match_operand:VI124_128 0 "register_operand"   "=v,x")
> + (vec_concat:VI124_128
> +   (match_operand: 1 "nonimmediate_operand"
"vm,?!*y")
> +   (match_operand: 2 "const0_operand"   "
C,C")))]
>"TARGET_SSE2"
>"@
> %vmovq\t{%1, %0|%0, %1}
> @@ -22154,6 +22157,24 @@ (define_insn "avx_vec_concat"
> (set_attr "prefix" "maybe_evex")
> (set_attr "mode" "")])
>
> +(define_insn_and_split "*vec_concat_0"
> +  [(set (match_operand:V 0 "register_operand")
> + (vec_select:V
> +   (vec_concat:
> + (match_operand:V 1 "nonimmediate_operand")
> + (match_operand:V 2 "const0_operand"))
> +   (match_parallel 3 "movq_parallel"
> + [(match_operand 4 "const_int_operand")])))]
> +  "ix86_pre_reload_split ()"
> +  "#"
> +  "&& 1"
> +  [(set (match_dup 0)
> + (vec_concat:V (match_dup 1) (match_dup 5)))]
> +{
> +  operands[1] = gen_lowpart (mode, operands[1]);
> +  operands[5] = CONST0_RTX (mode);
> +})

This regressed the following testcase with -msse -mno-sse2.
The define_insn_and_split splits the permutation into *vec_concat_0
or *vec_concatv2di_0 insns which both have TARGET_SSE2 in their
conditions (for the former you can see it above), but the
define_insn_and_split matches always when the V mode's condition do,
which for V16QI/V8HI/V4SI/V2DI/V4SF modes is always (well, when those
modes are valid, which is TARGET_SSE).

2021-06-11  Jakub Jelinek  

PR target/101007
* config/i386/sse.md (*vec_concat_0_1): Require TARGET_SSE2.

* gcc.target/i386/sse-pr101007.c: New test.

[Bug rtl-optimization/101008] ICE: in native_encode_rtx, at simplify-rtx.c:6594 with -O -g

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

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

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

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

commit r12-1386-g4bdcdd8fa8d7659e5a19a930cf2f0332127f8a46
Author: Jakub Jelinek 
Date:   Fri Jun 11 12:59:43 2021 +0200

simplify-rtx: Fix up simplify_logical_relational_operation for vector IOR
[PR101008]

simplify_relational_operation callees typically return just const0_rtx
or const_true_rtx and then simplify_relational_operation attempts to fix
that up if the comparison result has vector mode, or floating mode,
or punt if it has scalar mode and vector mode operands (it doesn't know how
exactly to deal with the scalar masks).
But, simplify_logical_relational_operation has a special case, where
it attempts to fold (x < y) | (x >= y) etc. and if it determines it is
always true, it just returns const_true_rtx, without doing the dances that
simplify_relational_operation does.
That results in an ICE on the following testcase, where such folding
happens
during expansion (of debug stmts into DEBUG_INSNs) and we ICE because
all of sudden a VOIDmode rtx appears where it expects a vector (V4SImode)
rtx.

The following patch fixes that by moving the adjustement into a separate
helper routine and using it from both simplify_relational_operation and
simplify_logical_relational_operation.

2021-06-11  Jakub Jelinek  

PR rtl-optimization/101008
* simplify-rtx.c (relational_result): New function.
(simplify_logical_relational_operation,
simplify_relational_operation): Use it.

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

[Bug c++/100897] Symmetric transfer does not prevent stack-overflow for C++20 coroutines

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Leonard von Merzljak from comment #2)
> (In reply to Iain Sandoe from comment #1)

> Thank you for your comment. I tried it out and can confirm that I don't get
> a stack-overflow anymore if I omit -fsanitize=address and use an
> optimization level > 1.

So that's a workaround (on platforms that support indirect tail calls at all).

> If the issues with coroutines and sanitizers are
> already known, then this bug report can be marked as resolved.

For the present, I will leave this open - until (at least) there's a chance to
confirm the hypothesis and determine if the problems are the same ones as
mentioned in other PRs.

> Of course, it would be nice if the stack-overflow would not occur even when
> using an optimization level <= 1, but this probably does not qualify as a
> bug.

Note that the inability to support indirect tail calls is not usually a failing
in GCC - but that some platform ABIs cannot support it (e.g. because they
require initialisation of some per DSO data).

For platforms that support indirect tail calls, it is actually feasible to
support the symmetric transfer at O0 (at least as per my local testing) - the
front end can demand a tailcall "for correctness".  The issue is that
coroutines are not a target-specific implementation, and therefore demanding
the tailcall will cause compile fails on targets that cannot support it.

Of course, one can argue that the code will *probably* fail on those targets if
there is arbitrary recursion needed - but it was decided to not to make this
demand until a solution is found to supporting continuations on all target.

JFTR, my outline sketch for this would be to allocate some area in the
coroutine frame that is reserved for target-specific continuation support, and
then to use a builtin to implement the continuation rather than relying on the
indirect tailcall mechanism.

[Bug tree-optimization/101026] [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

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

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

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

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

commit r12-1387-gfbd8a8041292f2ec2c22be43c8d3e74b37b2bc88
Author: Richard Biener 
Date:   Fri Jun 11 13:33:17 2021 +0200

tree-optimization/101026 - fix SLP re-association

Since we cannot yet encode the operation in the SLP node itself
but need a representative stmt require an existing one for now
to avoid the need to build a fake GIMPLE stmt.

2021-06-11  Richard Biener  

PR tree-optimization/101026
* tree-vect-slp.c (vect_build_slp_tree_2): Make sure we
have a representative for the associated chain nodes.

* gfortran.dg/pr101026.f: New testcase.

[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/101024] Missed min expression at phiopt1

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

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

--- Comment #2 from Andrew Pinski  ---
I have a start but there are a few patterns that need to be moved.
An example is from gcc.dg/tree-ssa/pr66726-4.c:
#define SAT(x) (x < 0 ? 0 : (x > 255 ? 255 : x))

void
foo (unsigned char *p, int i)
{
  *p = SAT (i);
}

[Bug c++/101029] New: unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[jim.w.walker at gmail dot com via Gcc-bugs]

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

Bug ID: 101029
   Summary: unexpected error: non-constant condition for static
assertion in gcc 10/11, but not 9 (clang also fine)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim.w.walker at gmail dot com
  Target Milestone: ---

Created attachment 50984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50984&action=edit
Output from -save-temps

A recent change to use unity builds in a product
(https://github.com/couchbase/kv_engine) I work on produced a build failure
which only occurred on our gcc 10.2 builder, it was fine on clang based builds. 

Further debugging of the issue revealed it appears to build fine on gcc 9. This
investigation also revealed I could make an unrelated code change preceding the
use of a templated type, and the code would then compile (details of this are
below). So far my conclusion is that this is an issue in gcc.

When compiled on gcc 10.2 the following error is seen.

/opt/gcc-10.2.0/include/c++/10.2.0/type_traits: In instantiation of ‘struct
std::is_default_constructible’:
/opt/gcc-10.2.0/include/c++/10.2.0/type_traits:143:12:   required from ‘struct
std::__and_,
std::is_default_constructible,
std::__not_,
std::__is_implicitly_default_constructible > > >’
/opt/gcc-10.2.0/include/c++/10.2.0/bits/stl_pair.h:244:59:   required by
substitution of ‘template,
std::is_default_constructible<_U2>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
 > constexpr std::pair::pair() [with _U1 = const
char; _U2 = char; typename
std::enable_if,
std::is_default_constructible<_U2>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
 = ]’
tlm/deps/folly.exploded/include/folly/AtomicHashArray-inl.h:63:19:   required
from here
/opt/gcc-10.2.0/include/c++/10.2.0/type_traits:918:52: error: non-constant
condition for static assertion
  918 |  
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
  |
~~~^~~~

The complete gcc command used (this generated the attached file):

/opt/gcc-10.2.0/bin/g++
-DDESTINATION_ROOT=\"/mnt/Code/couchbase/docker/install\" -DEP_USE_ROCKSDB=1
-DFMT_LOCALE -DGLOG_NO_ABBREVIATED_SEVERITIES -DGOOGLE_GLOG_DLL_DECL=""
-DHAVE_BREAKPAD -DHAVE_JEMALLOC -DHAVE_JEMALLOC_SDALLOCX
-DLIBCOUCHSTORE_NO_VISIBILITY
-DMEMCACHED_VERSION=\"5c9636b6d00bf1f53f1302b7d76eee3ba9c0cd0d\"
-DOBJECT_ROOT=\"/home/couchbase/couchbase/kv_engine\"
-DPRODUCT_VERSION=\"0.0.0-\"
-DSOURCE_ROOT=\"/mnt/Code/couchbase/docker/kv_engine\" -DSPDLOG_COMPILED_LIB
-DSPDLOG_FMT_EXTERNAL -DSPDLOG_LEVEL_NAMES="{\"TRACE\", \"DEBUG\", \"INFO\",
\"WARNING\", \"ERROR\", \"CRITICAL\", \"OFF\"}" -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS -D__EXTENSIONS__=1
-D__STDC_FORMAT_MACROS -Dgsl_CONFIG_CONTRACT_VIOLATION_THROWS
-Itlm/deps/prometheus-cpp.exploded/include -Ikv_engine/engines/ep
-Icouchstore/include -I/mnt/Code/couchbase/docker/couchstore/include
-I/mnt/Code/couchbase/docker/kv_engine/include
-I/mnt/Code/couchbase/docker/kv_engine/tracing
-I/mnt/Code/couchbase/docker/kv_engine/utilities
-I/mnt/Code/couchbase/docker/kv_engine
-I/mnt/Code/couchbase/docker/platform/external
-I/mnt/Code/couchbase/docker/platform/include
-Itlm/deps/flatbuffers.exploded/include -Itlm/deps/snappy.exploded/include
-Ikv_engine/engines/ep/src
-I/mnt/Code/couchbase/docker/kv_engine/engines/ep/src
-I/mnt/Code/couchbase/docker/kv_engine/engines/ep
-I/mnt/Code/couchbase/docker/install/include -Ikv_engine/include
-Iplatform/include
-I/mnt/Code/couchbase/docker/kv_engine/engines/ep/tools/couchfile_upgrade
-I/mnt/Code/couchbase/docker/third_party/spdlog/include -isystem
/mnt/Code/couchbase/docker/third_party/HdrHistogram_c/src -isystem
/mnt/Code/couchbase/docker/phosphor/include -isystem
tlm/deps/boost.exploded/include -isystem tlm/deps/json.exploded/include
-isystem /mnt/Code/couchbase/docker/third_party/gsl-lite/include -isystem
tlm/deps/libevent.exploded/include -isystem tlm/deps/openssl.exploded/include
-isystem tlm/deps/jemalloc.exploded/include -isystem
tlm/deps/rocksdb.exploded/include -isystem
/mnt/Code/couchbase/docker/third_party/googletest/googletest/include -isystem
/mnt/Code/couchbase/docker/third_party/googletest/googlemock/include -isystem
tlm/deps/folly.exploded/include -isystem
tlm/deps/double-conversion.exploded/include -isystem
tlm/deps/glog.exploded/include -isystem tlm/deps/fmt.exploded/include -isystem
tlm/deps/zlib.exploded/include -isystem
/home/couchbase/couchbase/tlm/deps/breakpad.exploded/include/breakpad
-fvisibility=hidden -pthread -pedantic -Wall -Wredundant-decls
-Werror=missing-braces -fno-strict-aliasing -Werror=switch -g -fPIC
-ftls-model=initial-exec -st

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[jim.w.walker at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jim Walker  ---
Adding version output:

/opt/gcc-10.2.0/bin/g++ --version
g++ (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks

[Bug target/101007] [12 Regression] ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed, although perhaps desirable to backport (except for the testcase).

[Bug rtl-optimization/101008] ICE: in native_encode_rtx, at simplify-rtx.c:6594 with -O -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed, again except for the testcase might be desirable to backport.

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, reducing that right now..

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jim Walker from comment #0)
> /opt/gcc-10.2.0/include/c++/10.2.0/type_traits:918:52: error: non-constant
> condition for static assertion
>   918 |  
> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),

This assertion was added for gcc 10, which is why you don't see it with gcc 9.

[Bug c++/101030] New: gcc internal error with Wconversion

[chrishair85 at gmail dot com via Gcc-bugs]

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

Bug ID: 101030
   Summary: gcc internal error with Wconversion
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrishair85 at gmail dot com
  Target Milestone: ---

template 
struct jj {
int ii[N ?: 1];
};

int main() {
jj<2> kk;
}

g++ -Wconversion dies with
version 8 to 11

changing template to template makes it work

Regards

:4:18: internal compiler error: Segmentation fault
4 | int ii[N ?: 1];
  |  ^
0x1780bf9 internal_error(char const*, ...)
???:0
0x6d96a9 cp_convert_and_check(tree_node*, tree_node*, int)
???:0
0x6f2dc8 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x707dd4 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
???:0
0x7c0cab c_parse_file()
???:0
0x892aa2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

Rgds

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
 Status|UNCONFIRMED |WAITING

--- Comment #2 from H.J. Lu  ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 50981 [details]
> auto-reduced testcase (from OpenTTD sources)
> 
> Compiler output:
> $ x86_64-pc-linux-gnu-g++ -O2 -mtune=opteron -mstackrealign
> --param=hot-bb-frequency-fraction=1 testcase.C -S
> 
> The offending code is:
> .L8:
>   pushq   %rbp
>   .cfi_def_cfa_offset 16
>   .cfi_offset 6, -16
>   movq%rsp, %rbp
>   .cfi_def_cfa_register 6
>   movq%r12, -8(%rbp)
>   pushq   %rax
> 
> the "push" overwrites r12 stored just one instruction above; when returning:
>   movq-8(%rbp), %r12
>   xorl%eax, %eax
>   leave
>   .cfi_def_cfa 7, 8
>   ret
> 
> the wrong data is restored to r12
> 
> I wasn't able yet to generate an executable testcase, but I can try to if
> needed. (it shouldn't be that hard, just r12 needs to be used by the caller
> during the call)

Please create a run-time testcase.

[Bug tree-optimization/101028] [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

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

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

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

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

commit r12-1388-gb9ec5ebb605936684e95b8dcc12e43ba7d8f2cb4
Author: Richard Biener 
Date:   Fri Jun 11 13:36:26 2021 +0200

tree-optimization/101028 - fix endless SLP reassoc discovery

This fixes a missing clearing of mismatched lanes from the
fatal fail path in SLP reassoc discovery in the most conservative
way.

2021-06-11  Richard Biener  

PR tree-optimization/101028
* tree-vect-slp.c (vect_build_slp_tree_2): When SLP
reassoc discovery fails fatally, mark appropriate lanes
in matches[] so.

* gcc.dg/pr101028.c: New testcase.

[Bug tree-optimization/101028] [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 101028 Summary: [12 Regression] SLP compile-time hog since 
r12-1329-gce670e4faafb296d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101028

   What|Removed |Added

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

[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r7-4021-g574284e9c49687d8.

[Bug tree-optimization/101026] [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/100948] [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Likely started with r8-3365-gb89a63b916340ef2.

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Here it is:

// PR target/101023
// { dg-do run }
// { dg-options "-O2 -mtune=opteron -mstackrealign
--param=hot-bb-frequency-fraction=1" }

struct S {
  __attribute__((noipa)) int m1 ();
  __attribute__((noipa)) void m2 ();
};
struct T {
  __attribute__((noipa)) virtual S m3 ();
};
struct U : T {
  int u;
  __attribute__((noipa)) U (int);
};
int *a;
S *b;
int c;

int
S::m1 ()
{
  return 0;
}

void
S::m2 ()
{
}

S
T::m3 ()
{
  return S ();
}

U::U (int) : u (4)
{
}

__attribute__((noipa)) int
foo ()
{
  if (a)
return 0;
  U d(c);
  S *e = b;
  e->m2 ();
  return e->m1();
}

int
main ()
{
  register int r12 __asm ("r12") = 1;
  register int rax __asm ("rax") = 2;
  asm volatile ("" : "+r" (r12), "+r" (rax));
  foo ();
  asm volatile ("" : "+r" (r12));
  if (r12 != 1)
__builtin_abort ();
}

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

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

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

--- Comment #4 from Jakub Jelinek  ---
// { dg-do run { target lp64 } }
(or ! ia32 if you want).

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #5 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #3)
> Here it is:
> 

Thank you, I probably wouldn't be able to get back to this until next week.

[Bug testsuite/101020] [12 regression] Several test case failures after r12-1316

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

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-11
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from David Edelsohn  ---
I already have a patch for the first part of this.  This should test dg-require
target int128 and float128, not lp64.

[Bug tree-optimization/101031] New: wrong code at -O2 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

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

Bug ID: 101031
   Summary: wrong code at -O2 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It appears to be a recent regression.


$ gcc-trunk -v
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210611 (experimental) [master revision
336c41dbcb2:00da4bcb67d:36943c6bdd3d3b535b24872bbd802d91ef0c6299] (GCC)


$ gcc-trunk abc.c ; ./a.out
0

$ gcc-trunk -O2 abc.c ; ./a.out
1


$ cat abc.c
int a;
char b, e;
static char *c = &b;
static long d;
void f(void);
void h() {
  int g = 0;
  for (; g < 2; ++g) {
d = *c;
*c = 1;
b = 0;
  }
  f();
}
void f() {
  if (d++)
c = &e;
  for (; a;)
;
}
int main() {
  h();
  printf("%d\n", b);
}

[Bug tree-optimization/101031] wrong code at -O2 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

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

Qirun Zhang  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #1 from Qirun Zhang  ---
My bisection points to g:d1d01a66012a93cc8cb7dafbe1b5ec453e

[Bug tree-optimization/101031] [12 Regression] wrong code at -O2 on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|wrong code at -O2 on|[12 Regression] wrong code
   |x86_64-linux-gnu|at -O2 on x86_64-linux-gnu
Version|unknown |12.0
   Priority|P3  |P1
   Last reconfirmed||2021-06-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

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

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

--- Comment #4 from Martin Liška  ---
Created attachment 50985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50985&action=edit
test-case

I see the following issue when not using an optimization level:

$ g++ gcc_issue.cc -c
gcc_issue.cc: In instantiation of ‘struct is_default_constructible’:
gcc_issue.cc:10:8:   required from ‘struct
__and_, int, int>’
gcc_issue.cc:29:57:   required by substitution of ‘template, _U2,
int>::valuebool>::type  > pair::pair() [with _U1 = int; _U2 = int;
typename enable_if<__and_, _U2,
int>::valuebool>::type  = ]’
:126:31:   required from here
gcc_issue.cc:18:43: error: non-constant condition for static assertion
   18 |   static_assert(__is_complete_or_unbounded(_Tp{}));
  | ~~^~~
gcc_issue.cc:18:43:   in ‘constexpr’ expansion of
‘__is_complete_or_unbounded(0).integral_constant<1>::operator
integral_constant<1>::value_type()’
gcc_issue.cc:18:43: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:2701
0x65e879 cxx_eval_call_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:2701
0x9a0489 cxx_eval_constant_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6232
0x9acc6d cxx_eval_binary_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:3187
0x99f86a cxx_eval_constant_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6590
0x9a3f47 cxx_eval_outermost_constant_expr
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:7264
0xb955e9 finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
/home/marxin/Programming/gcc/gcc/cp/semantics.c:10306
0xb55ec3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18644
0xb55ec3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18096
0xb710e9 instantiate_class_template_1
/home/marxin/Programming/gcc/gcc/cp/pt.c:12009
0xb710e9 instantiate_class_template(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12268
0xbbfe17 complete_type(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:143
0xbbfe17 complete_type(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:111
0xb7d116 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/marxin/Programming/gcc/gcc/cp/search.c:1148
0xabbe97 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:7113
0xb366f9 tsubst_qualified_id
/home/marxin/Programming/gcc/gcc/cp/pt.c:16364
0xb3889b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:19839
0xb54186 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:19082
0xb54186 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18096
0xb5bf55 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12286
0xb5bf55 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12274
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


while -O is fine:

$ g++ gcc_issue.cc -c -O

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
@Jason: Can you please take a look?

[Bug target/100217] [11/12 Regression] ICE when building valgrind testsuite with -march=z14 since r11-7552

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/101031] [12 Regression] wrong code at -O2 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Confirmed, mine.  Not a dup of PR101009.

[Bug tree-optimization/101031] [12 Regression] wrong code at -O2 on x86_64-linux-gnu

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

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

--- Comment #3 from Richard Biener  ---
Simpler IL:

int a;
char b, e;
static char *c = &b;
static long d;
void f(void);
void __attribute__((noipa)) h() {
  int g = 0;
  for (; g < 2; ++g) {
d = *c;
*c = 1;
b = 0;
  }
  f();
}
void __attribute__((noipa)) f() {
  if (d++)
c = &e;
  for (; a;)
;
}
int main() {
  h();
  if (b != 0)
__builtin_abort ();
  return 0;
}

we end up with

void h ()
{
  char * c.0_14;
  char _24;
  long int _25;

   [local count: 357878152]:
  c.0_14 = c;
  *c.0_14 = 1;
  b = 0;
  _24 = *c.0_14;
  _25 = (long int) _24;
  d = _25;
  *c.0_14 = 1;
  f (); [tail call]
  return;

[Bug c++/100974] [C++23] Implement if consteval

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

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

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

https://gcc.gnu.org/g:117c64266405e244da4dae3ae7b60905af63b955

commit r12-1390-g117c64266405e244da4dae3ae7b60905af63b955
Author: Jakub Jelinek 
Date:   Fri Jun 11 15:50:34 2021 +0200

c++: Add C++23 consteval if support - P1938R3 [PR100974]

The following patch implements consteval if support.
There is a new IF_STMT_CONSTEVAL_P flag on IF_STMT and IF_COND is
boolean_false_node to match the non-manifestly constant evaluation
behavior, while constexpr evaluation special-cases it.  Perhaps cleaner
would be to set the condition to __builtin_is_constant_evaluated () call
but we need the IF_STMT_CONSTEVAL_P flag anyway and the IL would be larger.

And I'm not changing the libstdc++ side, where perhaps we could change
std::is_constant_evaluated definition for
 #ifdef __cpp_if_consteval
case to if consteval { return true; } else { return false; }
but we need to keep it defined to __builtin_is_constant_evaluated ()
for C++20 or older.

2021-06-11  Jakub Jelinek  

PR c++/100974
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Predefine __cpp_if_consteval for
-std=c++2b for P1938R3 consteval if support.
gcc/cp/
* cp-tree.h (struct saved_scope): Add consteval_if_p
member.  Formatting fix for the discarded_stmt comment.
(in_consteval_if_p, IF_STMT_CONSTEVAL_P): Define.
* parser.c (cp_parser_lambda_expression): Temporarily disable
in_consteval_if_p when parsing lambda body.
(cp_parser_selection_statement): Parse consteval if.
* decl.c (struct named_label_entry): Add in_consteval_if member.
(level_for_consteval_if): New function.
(poplevel_named_label_1, check_previous_goto_1, check_goto): Handle
consteval if.
* constexpr.c (cxx_eval_builtin_function_call): Clarify in comment
why CP_BUILT_IN_IS_CONSTANT_EVALUATED needs to *non_constant_p
for !ctx->manifestly_const_eval.
(cxx_eval_conditional_expression): For IF_STMT_CONSTEVAL_P evaluate
condition as if it was __builtin_is_constant_evaluated call.
(potential_constant_expression_1): For IF_STMT_CONSTEVAL_P always
recurse on both branches.
* cp-gimplify.c (genericize_if_stmt): Genericize
IF_STMT_CONSTEVAL_P
as the else branch.
* pt.c (tsubst_expr) : Copy IF_STMT_CONSTEVAL_P.
Temporarily set in_consteval_if_p when recursing on
IF_STMT_CONSTEVAL_P then branch.
(tsubst_lambda_expr): Temporarily disable
in_consteval_if_p when instantiating lambda body.
* call.c (immediate_invocation_p): Return false when
in_consteval_if_p.
gcc/testsuite/
* g++.dg/cpp23/consteval-if1.C: New test.
* g++.dg/cpp23/consteval-if2.C: New test.
* g++.dg/cpp23/consteval-if3.C: New test.
* g++.dg/cpp23/consteval-if4.C: New test.
* g++.dg/cpp23/consteval-if5.C: New test.
* g++.dg/cpp23/consteval-if6.C: New test.
* g++.dg/cpp23/consteval-if7.C: New test.
* g++.dg/cpp23/consteval-if8.C: New test.
* g++.dg/cpp23/consteval-if9.C: New test.
* g++.dg/cpp23/consteval-if10.C: New test.
* g++.dg/cpp23/feat-cxx2b.C: Add __cpp_if_consteval tests.

[Bug c++/100974] [C++23] Implement if consteval

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Implemented for GCC 12.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 100974 Summary: [C++23] Implement if consteval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100974

   What|Removed |Added

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

[Bug target/101022] rs6000: __builtin_altivec_vcmpequt expands to wrong pattern

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

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

--- Comment #4 from Bill Schmidt  ---
Hi Carl -- while you're in there, can you please remove these?

+BU_P10_OVERLOAD_2 (VRLQ, "vrlq")   
+BU_P10_OVERLOAD_2 (VSLQ, "vslq")   
+BU_P10_OVERLOAD_2 (VSRQ, "vsrq")   
+BU_P10_OVERLOAD_2 (VSRAQ, "vsraq") 

They aren't used in the overload table, because we already have vec_rl, vec_sl,
vec_sr, and vec_sra that you rightly use.  So these macros don't provide any
other utility.

Sorry I didn't see this sooner.

Thanks!
Bill

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

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

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #6 from H.J. Lu  ---
Created attachment 50986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50986&action=edit
A patch

[Bug target/99939] CMSE: -march=armv8.1-m.main+mve does not support CMSE correctly.

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

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

commit r12-1391-gc5ed0148347beea1bd34795de146a2454c36
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 15:56:37 2021 +0100

arm: Fix the mve multilib for the broken cmse support (pr99939).

The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.

libgcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.

[Bug fortran/100948] [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069

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

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

--- Comment #4 from José Rui Faustino de Sousa  ---
I am looking into this.

I think I already have a patch for the ICE, but there are further problems
which I am trying to solve.

Best regards,
José Rui

[Bug c++/101015] Poor diagnostic for deprecated alias-declaration

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

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

--- Comment #2 from Marek Polacek  ---
This is because dump_decl does the decoration for TYPE_DECL_ALIAS_P:

1228   if (TYPE_DECL_ALIAS_P (t)
1229   && (flags & TFF_DECL_SPECIFIERS
1230   || flags & TFF_CLASS_KEY_OR_ENUM))
1231 {
1232   pp_cxx_ws_string (pp, "using");
1233   dump_decl (pp, DECL_NAME (t), flags);
1234   pp_cxx_whitespace (pp);
1235   pp_cxx_ws_string (pp, "=");
1236   pp_cxx_whitespace (pp);
1237   dump_type (pp, (DECL_ORIGINAL_TYPE (t)
1238   ? DECL_ORIGINAL_TYPE (t) : TREE_TYPE (t)),
1239  flags);

A way around it would be to disable TYPE_DECL_ALIAS_P temporarily for the
warning:

--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -5519,7 +5519,16 @@ cp_warn_deprecated_use (tree decl, tsubst_flags_t
complain)
}
 }
   else
-warned = warn_deprecated_use (decl, NULL_TREE);
+{
+  // XXX alias_type_or_template_p?
+  const bool using_p = (TREE_CODE (decl) == TYPE_DECL
+   && TYPE_DECL_ALIAS_P (decl));
+  if (using_p)
+   TYPE_DECL_ALIAS_P (decl) = false;
+  warned = warn_deprecated_use (decl, NULL_TREE);
+  if (using_p)
+   TYPE_DECL_ALIAS_P (decl) = true;
+}

   return warned;
 }

and then we get:

101015.C:7:8: warning: ‘A::bad’ is deprecated [-Wdeprecated-declarations]
7 | A::bad j = 0;
  |^
101015.C:3:9: note: declared here
3 |   using bad [[deprecated]] = int;
  | ^~~

But maybe that's too ugly a hack.

[Bug c++/101032] New: Regression on parser with g++11 using experimental c++20 (compiles under c++17)

[kevin.c.eady at gmail dot com via Gcc-bugs]

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

Bug ID: 101032
   Summary: Regression on parser with g++11 using experimental
c++20 (compiles under c++17)
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin.c.eady at gmail dot com
  Target Milestone: ---

the exact version of GCC: g++ (GCC) 11.1.0

the system type / the options given when GCC was configured/built: this is the
official gcc:11.1.0 docker image

the complete command line that triggers the bug: g++ -Wall -Wextra
-Wno-deprecated -fsyntax-only -save-temps -std=c++20 napi-full.h

the compiler output (error messages, warnings, etc.):
napi-full.h:3305:60: error: expected unqualified-id before ')' token
 3305 | TypedThreadSafeFunction();
  |^
napi-full.h:3307:33: error: expected ')' before 'tsFunctionValue'
 3307 | napi_threadsafe_function tsFunctionValue);
  | ^~~~
  | )
napi-full.h:3306:59: note: to match this '('
 3306 | TypedThreadSafeFunction(
  |   ^
napi-full.h:8276:8: error: no declaration matches
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction()'
 8276 | inline TypedThreadSafeFunction::
  |^~
napi-full.h:8276:8: note: no functions named
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction()'
napi-full.h:3175:9: note: 'class Napi::TypedThreadSafeFunction' defined here
 3175 |   class TypedThreadSafeFunction {
  | ^~~
napi-full.h:8283:8: error: no declaration matches
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction(napi_threadsafe_function)'
 8283 | inline TypedThreadSafeFunction::
  |^~
napi-full.h:8283:8: note: no functions named
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction(napi_threadsafe_function)'
napi-full.h:3175:9: note: 'class Napi::TypedThreadSafeFunction' defined here
 3175 |   class TypedThreadSafeFunction {
  | ^~~

the preprocessed file (*.i*) that triggers the bug: it is over the 1000 K size
limit, please see
https://drive.google.com/file/d/1oMEjMEuKG7806DlXbfJaHxAzVF3sUTFs/view?usp=sharing
 


note: when using c++17, the file passes the syntax check

[Bug c++/101033] New: Error message for spelling error in copy assignment operator could be improved

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 101033
   Summary: Error message for spelling error in copy assignment
operator could be improved
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Consider the following:

https://godbolt.org/z/vfdTq9j3x

class S {
  S& operator=(cont S&);
};

There is a spelling error here, gcc-9 rejects with:

:2:16: error: declaration of 'operator=' as non-function
2 |   S& operator=(cont S&);
  |^~~~

The cursor is accurately positioned on the spelling error, but the error
message of gcc-trunk is:

:2:6: error: declaration of 'operator=' as non-function
2 |   S& operator=(cont S&);
  |  ^~~~

which seems to be a bit distracting, and may increase the cost of debugging.

[Bug c++/101032] Regression on parser with g++11 using experimental c++20 (compiles under c++17)

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Please check if this is a dup of 97202.  If TypedThreadSafeFunction is a
constructor, then remove  to make it work.

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

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

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

commit r12-1392-gb8b80b8aa3d9a7abbcb59b651ea5e84c2ea12d0b
Author: Richard Biener 
Date:   Fri Jun 11 12:06:08 2021 +0200

tree-optimization/101025 - fix store-motion dependence checking

This plugs a hole in store-motion where it fails to perform dependence
checking on conditionally executed but not store-motioned refs.

2021-06-11  Richard Biener  

PR tree-optimization/101025
* tree-ssa-loop-im.c (sm_seq_valid_bb): Make sure to process
all refs that require dependence checking.

* gcc.dg/torture/pr101025.c: New testcase.

[Bug tree-optimization/101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[11/12 Regression] wrong|[11 Regression] wrong code
   |code at -O3 on  |at -O3 on x86_64-linux-gnu
   |x86_64-linux-gnu|
  Known to fail|12.0|

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.  Keep more testcases coming ;)  (I have a hunch this code
has more issues...)

[Bug tree-optimization/96392] Optimize x+0.0 if x is an integer

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

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

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

https://gcc.gnu.org/g:5b02ed4b87685c0f7c5da9b46cde3ce56fcfd457

commit r12-1393-g5b02ed4b87685c0f7c5da9b46cde3ce56fcfd457
Author: Roger Sayle 
Date:   Fri Jun 11 17:15:38 2021 +0100

[PATCH] PR tree-optimization/96392 Optimize x+0.0 if x is an integer

The patch implements a missed optimization enhancement.  Under usual
IEEE rules, x+0.0 can't be simplified to x when x might potentially
be an IEEE minus zero (-0.0).  The current logic in the middle-end
checks whether the type of x should honor signed zeros, but with this
patch we introduce tree_expr_maybe_real_minus_zero_p that allows us
to confirm that the value can't possibly be -0.0, for example, the result
of a conversion from an integer type, or the result of fabs (or has a
type that doesn't honor signed zero).

Whilst modifying match.pd, I also converted some additional folding
transformations from "testing the type" to "testing the value".

2020-06-10  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/96392
* fold-const.c (fold_real_zero_addition_p): Take both arguments
of the addition or subtraction, not just the zero.  Use this
other argument in tests for signaling NaNs and signed zeros.
(tree_expr_maybe_real_minus_zero_p): New predicate.
* fold-const.h (fold_real_zero_addition_p): Update prototype.
(tree_expr_maybe_real_minus_zero_p): New function prototype.
* match.pd: Update calls to fold_real_zero_addition_p.
Replace HONOR_NANS with tree_expr_maybe_nan_p.
Replace HONOR_SIGNED_ZEROS with tree_expr_maybe_real_minus_zero_p.
Replace HONOR_SNANS with tree_expr_maybe_signaling_nan_p.
* tree-ssa-reassoc.c (eliminate_using_constants): Update
call to fold_real_zero_addition_p.

gcc/testsuite/ChangeLog
PR tree-optimization/96392
* gcc.dg/pr96392.c: New test.

[Bug libstdc++/101034] New: wrong constraint in std::any's constructor

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 101034
   Summary: wrong constraint in std::any's constructor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

In any#L208:

template , typename _Mgr = _Manager<_VTp>,
  __any_constructible_t<_VTp, initializer_list<_Up>,
  _Args&&...> = false>
explicit
any(in_place_type_t<_Tp>, initializer_list<_Up> __il, _Args&&... __args)


It should be __any_constructible_t<_VTp, initializer_list<_Up>&, _Args&&...> =
false>.

https://godbolt.org/z/afhTbM3b1

#include 

struct S {
  S(std::initializer_list&, int) {}
};

int main() {
  std::any a(std::in_place_type, {0}, 0);
}

[Bug target/100530] [9/10/11/12 Regression] ICE with -g: in add_dwarf_attr with __seg_gs (Alternative address-space) global variable since r8-4385-ga297ccb52e0c894e

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
I see this also with the source code for ./gcc.target/i386/pr100936.c
and flag -g:

$ /home/dcb/gcc/results.20210611.asan.ubsan/bin/gcc -c -g
./gcc.target/i386/pr100936.c
./gcc.target/i386/pr100936.c:5:1: internal compiler error: in add_dwarf_attr,
at
 dwarf2out.c:4493
5 | __seg_gs int var;
  | ^~~~
0x88a057 add_dwarf_attr(die_struct*, dw_attr_struct*)
../../trunk.git/gcc/dwarf2out.c:4493

[Bug tree-optimization/101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

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

--- Comment #8 from Qirun Zhang  ---
(In reply to Richard Biener from comment #7)
> Fixed on trunk sofar.  Keep more testcases coming ;)  (I have a hunch this
> code has more issues...)

Thanks, Richard. Will do.

[Bug libstdc++/101034] wrong constraint in std::any's constructor

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
any#L272 has the same typo:

template 
  __emplace_t, initializer_list<_Up>, _Args&&...>
  emplace(initializer_list<_Up> __il, _Args&&... __args)

[Bug tree-optimization/96392] Optimize x+0.0 if x is an integer

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

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

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

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

commit r12-1394-ga761829ae06a754f72ff957cbedb21f4d98fab70
Author: Roger Sayle 
Date:   Fri Jun 11 17:42:14 2021 +0100

[PATCH] PR tree-optimization/96392 Optimize x+0.0 if x is an integer

Doh! Wrong patch version.  Sorry for the inconvenience.

2020-06-11  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/96392
* fold-const.h (tree_expr_maybe_real_minus_zero_p): Fix prototype.

[Bug libstdc++/101034] wrong constraint in std::any's constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/101032] Regression on parser with g++11 using experimental c++20 (compiles under c++17)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yes, the constructors are declared like this in the class body:

TypedThreadSafeFunction();
TypedThreadSafeFunction(
napi_threadsafe_function tsFunctionValue);

This is not valid in C++20.

You shouold simply write them like this, which is valid in all versions of C++
and easier to read anyway:

TypedThreadSafeFunction();
TypedThreadSafeFunction(napi_threadsafe_function tsFunctionValue);

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

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kevin.c.eady at gmail dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 101032 has been marked as a duplicate of this bug. ***

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

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

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

--- Comment #6 from Jonathan Wakely  ---
If the invalid special member is defined out of the class body, you get another
error:

template
struct F
{
  F();
};

template
inline F::F() { }


101032.C:4:8: error: expected unqualified-id before ‘)’ token
4 |   F();
  |^
101032.C:8:8: error: no declaration matches ‘F::F()’
8 | inline F::F() { }
  |^~~~
101032.C:8:8: note: no functions named ‘F::F()’
101032.C:2:8: note: ‘struct F’ defined here
2 | struct F
  |^

As well as improving the first error (which is the subject of this bug) maybe
the constructor could be parsed as though it had been written correctly, so
that the "no declaration matches" error doesn't happen. Compilation is already
going to fail, we don't need to also complain about the valid function
definition not matching anything.

[Bug c++/101033] Error message for spelling error in copy assignment operator could be improved

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-11

[Bug c++/101033] Error message for spelling error in copy assignment operator could be improved

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/101016] Arm: vld1q polymorphic variants failing with undefined reference to `__ARM_undef` error.

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

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

commit r12-1395-gb13f297f01c943aa167f7c6eb94bed40dce0d553
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 18:11:58 2021 +0100

arm: Fix polymorphic variants failing with undefined reference to
`__ARM_undef` error.

This patch fixes the issue mentioned in PR101016, which is mve polymorphic
variants
failing at linking with undefined reference to "__ARM_undef" error.

gcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* config/arm/arm_mve.h (__arm_vld1q): Change __ARM_mve_coerce(p0,
int8_t const *) to __ARM_mve_coerce1(p0, int8_t *) in the argument
for
the polymorphic variants matching code.
(__arm_vld1q_z): Likewise.
(__arm_vld2q): Likewise.
(__arm_vld4q): Likewise.
(__arm_vldrbq_gather_offset): Likewise.
(__arm_vldrbq_gather_offset_z): Likewise.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* gcc.target/arm/mve/intrinsics/pr101016.c: New test.

[Bug c/101035] New: ICE: in wide_int_to_tree_1, at tree.c:1751

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101035
   Summary: ICE: in wide_int_to_tree_1, at tree.c:1751
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.GWysxNSsSH-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210610 (experimental) [master revision
:697cc07ce:edec2660ff4890ecf8cc191f7c92cf527de51fe2] (GCC)

$ cat mutant.c
__GIMPLE
foo() { t1_1 = __builtin_abs->next; }

$ gcc-trunk -fgimple mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | foo() { t1_1 = __builtin_abs->next; }
  | ^~~
mutant.c: In function ‘foo’:
mutant.c:2:14: error: base variable or SSA name undeclared before ‘=’ token
2 | foo() { t1_1 = __builtin_abs->next; }
  |  ^
mutant.c:2:14: internal compiler error: in wide_int_to_tree_1, at tree.c:1751
0x7ce2c8 wide_int_to_tree_1
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:1751
0x1217cd0 wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:1863
0x1217cd0 build_int_cst(tree_node*, poly_int<1u, long>)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:1503
0x1219918 build_simple_mem_ref_loc(unsigned int, tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:5174
0x95a5db c_parser_gimple_postfix_expression_after_primary
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:1834
0x95a5db c_parser_gimple_postfix_expression
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:1712
0x95b374 c_parser_gimple_binary_expression
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:922
0x95c66f c_parser_gimple_statement
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:859
0x95c66f c_parser_gimple_compound_statement
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:650
0x95c66f c_parser_gimple_compound_statement
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:381
0x95ea87 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:253
0x94db47 c_parser_declaration_or_fndef
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:2533
0x955423 c_parser_external_declaration
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:1777
0x955e89 c_parser_translation_unit
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:1650
0x955e89 c_parse_file()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:22104
0x9b7245 c_common_parse_file()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c-family/c-opts.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug d/100999] d: foreach over a tuple doesn't work on 16-bit targets

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:68f46862d33707450bdf70cfddd91ae2a12527a8

commit r12-1396-g68f46862d33707450bdf70cfddd91ae2a12527a8
Author: Iain Buclaw 
Date:   Fri Jun 11 19:33:07 2021 +0200

d: foreach over a tuple doesn't work on 16-bit targets (PR100999)

Improves semantic passes in the front-end around the `foreach' and
`static foreach' statements to be more resilient to compiling in a
minimal D runtime environment.  Checking of the index type has been
improved as well so now there won't be needless compiler errors when
using 8 or 16-bit integers as index types when the size fits the
expected loop range.

gcc/d/ChangeLog:

PR d/100999
* dmd/MERGE: Merge upstream dmd 7a3808254.

libphobos/ChangeLog:

PR d/100999
* src/MERGE: Merge upstream phobos 55bb17543.

[Bug c/101036] New: ICE: in fold_convert_loc, at fold-const.c:2430

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101036
   Summary: ICE: in fold_convert_loc, at fold-const.c:2430
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.GWysxNSsSH-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210610 (experimental) [master revision
:697cc07ce:edec2660ff4890ecf8cc191f7c92cf527de51fe2] (GCC)

$ cat mutant.c
z1_called;
z1() { z1_called++; }
int z1_called[] = z3;

$ gcc-trunk  mutant.c
mutant.c:1:1: warning: data definition has no type or storage class
1 | z1_called;
  | ^
mutant.c:1:1: warning: type defaults to ‘int’ in declaration of ‘z1_called’
[-Wimplicit-int]
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | z1() { z1_called++; }
  | ^~
mutant.c:3:5: error: conflicting types for ‘z1_called’; have ‘int[]’
3 | int z1_called[] = z3;
  | ^
mutant.c:1:1: note: previous declaration of ‘z1_called’ with type ‘int’
1 | z1_called;
  | ^
mutant.c:3:19: error: ‘z3’ undeclared here (not in a function); did you mean
‘z1’?
3 | int z1_called[] = z3;
  |   ^~
  |   z1
mutant.c: In function ‘z1’:
mutant.c:2:17: internal compiler error: in fold_convert_loc, at
fold-const.c:2430
2 | z1() { z1_called++; }
  |~^~
0x6c27da fold_convert_loc(unsigned int, tree_node*, tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/fold-const.c:2430
0xc3a3fe gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:3202
0xc33e0f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:14009
0xc37aea gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:6863
0xc3831e gimplify_bind_expr
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:1424
0xc34553 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:14280
0xc37aea gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:6863
0xc390e3 gimplify_body(tree_node*, bool)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:15324
0xc39531 gimplify_function_tree(tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:15478
0xa8b027 cgraph_node::analyze()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/cgraphunit.c:670
0xa8df51 analyze_functions
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/cgraphunit.c:1234
0xa8ea21 symbol_table::finalize_compilation_unit()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug d/100999] d: foreach over a tuple doesn't work on 16-bit targets

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

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

commit r11-8553-ga30552af7073aba16af6798a1e6cd0a345b06586
Author: Iain Buclaw 
Date:   Fri Jun 11 19:33:07 2021 +0200

d: foreach over a tuple doesn't work on 16-bit targets (PR100999)

Improves semantic passes in the front-end around the `foreach' and
`static foreach' statements to be more resilient to compiling in a
minimal D runtime environment.  Checking of the index type has been
improved as well so now there won't be needless compiler errors when
using 8 or 16-bit integers as index types when the size fits the
expected loop range.

gcc/d/ChangeLog:

PR d/100999
* dmd/cond.c (lowerArrayAggregate): Run CTFE interpret on foreach
input range.
(createTupleType): Don't generate typeinfo when disabled.
(lowerNonArrayAggregate): Suppress errors when running type
semantic.
(staticForeachPrepare): Don't run CTFE interpret from here.
* dmd/dinterpret.c (ctfeInterpret): Add more shortcut cases.
* dmd/expression.c (Expression::checkPostblit): Don't generate
typeinfo when type is missing from library.
* dmd/expressionsem.c (resolvePropertiesX): Remove early error.
* dmd/statementsem.c (StatementSemanticVisitor::declareVariable):
Don't override index type.
(StatementSemanticVisitor::makeTupleForeachBody): Check index type
is
integral and index range fits type size.
(StatementSemanticVisitor::visit (ForeachStatement*)): Adjust index
range before testing.

libphobos/ChangeLog:

PR d/100999
* src/std/typecons.d (template Proxy): Check for field or property
functions as the else branch.

gcc/testsuite/ChangeLog:

PR d/100999
* gdc.test/compilable/staticforeach.d: Add new tests.
* gdc.test/fail_compilation/diag16976.d: Likewise.
* gdc.test/fail_compilation/fail117.d: Likewise.
* gdc.test/fail_compilation/fail238_m32.d: Likewise.
* gdc.test/fail_compilation/fail238_m64.d: Likewise.
* gdc.test/fail_compilation/fail7424b.d: Likewise.
* gdc.test/fail_compilation/fail7424c.d: Likewise.
* gdc.test/fail_compilation/fail7424d.d: Likewise.
* gdc.test/fail_compilation/fail7424e.d: Likewise.
* gdc.test/fail_compilation/fail7424f.d: Likewise.
* gdc.test/fail_compilation/fail7424g.d: Likewise.
* gdc.test/fail_compilation/fail7424h.d: Likewise.
* gdc.test/fail_compilation/fail7424i.d: Likewise.
* gdc.test/fail_compilation/fail9766.d: Likewise.
* gdc.test/fail_compilation/ice9406.d: Likewise.
* gdc.test/compilable/extra-files/minimal/object.d: New file.
* gdc.test/compilable/interpret5.d: New test.
* gdc.test/compilable/minimal3.d: New test.
* gdc.test/compilable/test21742.d: New test.
* gdc.test/compilable/test22006.d: New test.
* gdc.test/fail_compilation/b12504.d: New test.
* gdc.test/fail_compilation/fail22006.d: New test.
* gdc.test/fail_compilation/test21927.d: New test.
* gdc.test/fail_compilation/test21939.d: New test.

(cherry picked from commit 68f46862d33707450bdf70cfddd91ae2a12527a8)

[Bug libstdc++/101037] New: std::atomic_flag deadlock on Windows

[bjornsundin02 at gmail dot com via Gcc-bugs]

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

Bug ID: 101037
   Summary: std::atomic_flag deadlock on Windows
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjornsundin02 at gmail dot com
  Target Milestone: ---

The attached preprocessed file is a "ping-pong" example where two threads take
turns to wait for the other thread using a C++20 std::atomic_flag. I am fairly
certain that the code is correct and should not hang. I tested the program on
Linux (Ubuntu 21.04), where it works as expected every time. On Windows, with a
build from https://winlibs.com/, it more often than not hangs. The program on
Windows is compiled in exactly the same way as on Linux.

The expected behavior is: the program exits within less than a second.
The observed behavior is: sometimes the program exits within less than a
second, but often it hangs without ever returning.

Below is the complete compiler command and output:
> g++ -v -save-temps -std=c++20 -pthread deadlock_debugging.cpp 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.1.1/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs64_stage/inst_gcc-11-20210605/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-posix-seh, built by Brecht Sanders' --with-tune=generic
--enable-checking=release --enable-threads=posix --disable-sjlj-exceptions
--disable-libunwind-exceptions 
--disable-serial-configure --disable-bootstrap --enable-host-shared
--enable-plugin --disable-default-ssp --disable-rpath --enable-libstdcxx-pch
--enable-libstdcxx-time=yes --disable-libstdcxx-debug
--disable-version-specific-runtime-libs --with-stabs --disable-symvers
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls
--disable-stage1-checking --disable-win32-registry --disable-multilib
--enable-ld --enable-libquadmath --enable-libada --enable-libssp
--enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp
--enable-graphite --enable-mingw-wildcard
--with-mpc=/d/Prog/winlibs64_stage/custombuilt
--with-mpfr=/d/Prog/winlibs64_stage/custombuilt
--with-gmp=/d/Prog/winlibs64_stage/custombuilt
--with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty
--enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto
--enable-clocale=generic --with-libiconv --with-system-zlib
--with-build-sysroot=/R/winlibs64_stage/gcc-11-20210605/build_mingw/mingw-w64
CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210605 (MinGW-W64 x86_64-posix-seh, built by Brecht
Sanders) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-pthread' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.1.1/cc1plus.exe -E -quiet
-v -iprefix c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/ -D_REENTRANT
-U_REENTRANT deadlock_debugging.cpp -mtune=generic -march=x86-64 -std=c++20
-fpch-preprocess -o a-deadlock_debugging.ii
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/x86_64-w64-mingw32"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/backward"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/include"
ignoring nonexistent directory
"R:/winlibs64_stage/inst_gcc-11-20210605/share/gcc/include"
ignoring nonexistent directory
"/R/winlibs64_stage/inst_gcc-11-20210605/share/gcc/include"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/include-fixed"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/x86_64-w64-mingw32

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/backward
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/include
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/include-fixed

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../x86_64-w64-ming

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
The variant with typespec and non-constant length is incorrectly rejected:

program p
  integer :: n = 2
  print *, [character(n) :: 'a', 'b']
end

All versions since at least gcc-7 give:

pr100950-z3.f90:3:0:

   print *, [character(n) :: 'a', 'b']

Error: size of variable 'A.1' is too large

Maybe the issue here is somewhere in trans-array.c(gfc_walk_array_constructor),
but that is unrelated to the issue with constant substring length.

[Bug libstdc++/101037] std::atomic_flag deadlock on Windows

[bjornsundin02 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Björn Sundin  ---
The preprocessed file was too big. Should I attach the original C++ source or a
compressed version of the preprocessed file instead?

[Bug libstdc++/101037] std::atomic_flag deadlock on Windows

[bjornsundin02 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Björn Sundin  ---
Created attachment 50987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50987&action=edit
A short ping-pong example program.

The preprocessed file was too large so I attached the original C++ source
instead.

[Bug target/92469] ICE: output_operand: invalid use of register 'frame' in 7/8/9/10

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

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

--- Comment #15 from H.J. Lu  ---
This isn't completely fixed:

[hjl@gnu-clx-1 gcc]$ ./xgcc -B./
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c -m32
-fdiagnostics-plain-output -O2 -mincoming-stack-boundary=2
-fstack-protector-all -ffat-lto-objects -fno-ident -S -o pr97032.s -mtune=k8
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c: In
function ??sys_socketcall??:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c:14:3:
warning: listing the stack pointer register ??esp?? in a clobber list is
deprecated [-Wdeprecated]
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c:14:3:
note: the value of the stack pointer after an ??asm?? statement must be the
same as it was before the statement
during RTL pass: final
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c:21:1:
internal compiler error: output_operand: invalid use of register 'frame'
0xad9216 output_operand_lossage(char const*, ...)
/export/gnu/import/git/sources/gcc/gcc/final.c:3235
0x11b16c4 ix86_print_operand_address_as
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:13698
0xad9531 output_operand(rtx_def*, int)
/export/gnu/import/git/sources/gcc/gcc/final.c:3677
0xada075 output_asm_insn(char const*, rtx_def**)
/export/gnu/import/git/sources/gcc/gcc/final.c:3589
0x170edad output_1175
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.md:20907
0xadd898 final_scan_insn_1
/export/gnu/import/git/sources/gcc/gcc/final.c:2827
0xaddd6b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/export/gnu/import/git/sources/gcc/gcc/final.c:2940
0xadde47 final_1
/export/gnu/import/git/sources/gcc/gcc/final.c:1997
0xade9e4 rest_of_handle_final
/export/gnu/import/git/sources/gcc/gcc/final.c:4285
0xade9e4 execute
/export/gnu/import/git/sources/gcc/gcc/final.c:4363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-clx-1 gcc]$

[Bug c++/96560] Substitution triggers compile-time error when it shouldn't

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

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

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

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

commit r12-1398-gb0d73a66ae3962fa83309527d85613d72a6aa43d
Author: Patrick Palka 
Date:   Fri Jun 11 16:00:52 2021 -0400

c++: Substitute into function parms in lexical order [PR96560]

This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right instead of right-to-left order, in accordance with DR
1227.

DR 1227
PR c++/96560

gcc/cp/ChangeLog:

* pt.c (tsubst_arg_types): Rearrange so that we substitute into
TYPE_ARG_TYPES in forward order while short circuiting
appropriately.  Adjust formatting.

gcc/testsuite/ChangeLog:

* g++.dg/template/sfinae-dr1227.C: New test.