[Bug c/100902] pointer attachment issues

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:132d3e9d57a522792e300d4c8a91e9d1b8ef5577

commit r11-8588-g132d3e9d57a522792e300d4c8a91e9d1b8ef5577
Author: Jakub Jelinek 
Date:   Sun Jun 6 19:37:06 2021 +0200

openmp: Call c_omp_adjust_map_clauses even for combined target [PR100902]

When looking at in_reduction support for target, I've noticed that
c_omp_adjust_map_clauses is not called for the combined target case.

The following patch fixes it.

Unfortunately, there are other issues.

One is (also mentioned in the PR) that currently the pointer attachment
stuff seems to be clause ordering dependent (the standard says that clause
ordering on the same construct does not matter), the baz and qux cases
in the PR are rejected while when swapped it is accepted.
Note, the order of clauses in GCC really is treated as insignificant
initially and only later on the compiler can adjust the ordering (e.g. when
we sort map clauses based on what they refer to etc.) and in particular,
clauses from parsing is reverse of the order in user code, while
c_omp_split_clauses performed for combined/composite constructs typically
reverses that ordering, i.e. makes it follow the user code ordering.

And another one is I'm slightly afraid c_omp_adjust_map_clauses might
misbehave in templates, though haven't tried to verify it with testcases.
When processing_template_decl, the non-dependent clauses will be handled
usually the same as when not in a template, but dependent clauses aren't
processed or only limited processing is done there, and rest is deferred
till later.  From quick skimming of c_omp_adjust_map_clauses, it seems
it might not be very happy about non-processed map clauses that might
still have the TREE_LIST representation of array sections, or might
not have finalized decls or base decls etc.
So, for this I wonder if cp_parser_omp_target (and other cp/parser.c
callers of c_omp_adjust_map_clauses) shouldn't call it only
if (!processing_template_decl) - perhaps you could add
cp_omp_adjust_map_clauses wrapper that would be
if (!processing_template_decl)
  c_omp_adjust_map_clauses (...);
- and call c_omp_adjust_map_clauses from within pt.c after the clauses
are tsubsted and finish_omp_clauses is called again.

2021-06-06  Jakub Jelinek  

PR c/100902
* c-parser.c (c_parser_omp_target): Call c_omp_adjust_map_clauses
even when target is combined with other constructs.

* parser.c (cp_parser_omp_target): Call c_omp_adjust_map_clauses
even when target is combined with other constructs.

* c-c++-common/gomp/pr100902-1.c: New test.

(cherry picked from commit 7fa4db39b6bcd207bd2b52023ff6b155bd15)

[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-8587-g1c1ee19e7023e18ba63324e06ae9387bde227357
Author: Jakub Jelinek 
Date:   Fri Jun 4 11:20:02 2021 +0200

x86: Fix ix86_expand_vector_init for V*TImode [PR100887]

We have vec_initv4tiv2ti and vec_initv2titi patterns which call
ix86_expand_vector_init and assume it works for those modes.  For the
case of construction from two half-sized vectors, the code assumes it
will always succeed, but we have only insn patterns with SImode and DImode
element types.  QImode and HImode element types are already handled
by performing it with same sized vectors with SImode elements and the
following patch extends that to V*TImode vectors.

2021-06-04  Jakub Jelinek  

PR target/100887
* config/i386/i386-expand.c (ix86_expand_vector_init): Handle
concatenation from half-sized modes with TImode elements.

(cherry picked from commit b7dd2e4eeb44bc8678ecde8a6c7401de85e63561)

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
Version|unknown |11.0
 Target||x86_64-linux-gnu
Summary|wrong code at -O3 on|[11/12 Regression] wrong
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
   Target Milestone|--- |11.2

[Bug target/100762] [mips+msa] ICE when comparing 64 bit vectors

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at mengyan1223 dot wang

--- Comment #2 from Xi Ruoyao  ---
11.1.0 also ICE with this case.

[Bug tree-optimization/101105] 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=101105

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

[Bug tree-optimization/101105] New: 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=101105

Bug ID: 101105
   Summary: wrong code at -O3 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 regression in 11.

$ gcc-trunk -v
Configured with: ../gcc/configure --prefix=/nethome/qzhang414/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210616 (experimental) [master revision
041f7417707:a530c589490:3155d51bfd1de8b6c4645dcb2292248a8d7cc3c9] (GCC)



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

$ gcc-trunk -O3 abc.c ; ./a.out
Segmentation fault


$ cat abc.c
short a;
int b[5][4] = {2, 2};
long *c;
int d;
short(e)(f) { return f == 0 || a && f == 1 ? 0 : a; }
int main() {
  int g, h;
  g = 3;
  for (; g >= 0; g--) {
h = 3;
for (; h >= 0; h--)
  b[g][h] = b[0][1] && e(1);
  }
  d = b[0][1];
  if (d)
*c = 4073709551611;
  printf("%d\n", 2);
}

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

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-9926-g4b98b55e0e8b4051f4e3b0afc76b506b01f0889f
Author: Jason Merrill 
Date:   Fri Jun 11 16:55:30 2021 -0400

c++: constexpr and array[0] [PR101029]

build_vec_init_elt exits early if we're initializing a zero-element array,
so build_vec_init needs to do the same to avoid trying to instantiate
things
after we've already started throwing important bits away.

PR c++/101029

gcc/cp/ChangeLog:

* init.c (build_vec_init): Shortcut [0] case.

gcc/testsuite/ChangeLog:

* g++.dg/ext/array4.C: New test.

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

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-8586-gda25516718cb150cc938f5947650c9ab486505c6
Author: Jason Merrill 
Date:   Wed Jun 16 17:42:15 2021 -0400

c++: Tweak PR101029 fix

The case of an initializer with side effects for a zero-length array seems
extremely unlikely, but we should still return the right type in that case.

PR c++/101029

gcc/cp/ChangeLog:

* init.c (build_vec_init): Preserve the type of base.

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

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r12-1548-gff4deb4b1d0c5947669ddc76fde4db83e28009d8
Author: Jason Merrill 
Date:   Wed Jun 16 17:42:15 2021 -0400

c++: Tweak PR101029 fix

The case of an initializer with side effects for a zero-length array seems
extremely unlikely, but we should still return the right type in that case.

PR c++/101029

gcc/cp/ChangeLog:

* init.c (build_vec_init): Preserve the type of base.

[Bug c++/100485] False positive in -Wmismatched-new-delete

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

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

--- Comment #8 from Martin Sebor  ---
(In reply to fiesh from comment #7)
> On a random related note, the man page says -Wmismatched-new-delete is
> enabled by default, but playing around with it, it seems it's only turned on
> by -Wall: https://godbolt.org/z/n1s6Y8G85

Thanks, I just fixed it in r12-1544.

[Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails

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

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

Bug ID: 101104
   Summary: test case g++.dg/tsan/pthread_cond_clockwait.C fails
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:54f0224d55a1b56dde092460ddf76913670e6efc, r12-228 

These have not worked right on powerpc64 since they were introduced.

FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os


commit 54f0224d55a1b56dde092460ddf76913670e6efc
Author: Patrick McGehearty 
Date:   Wed Apr 28 19:14:48 2021 +

Practical improvement to libgcc complex divide

[Bug c++/101078] [9/10 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug c++/101078] [9/10 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression] Rejected
   |Rejected code since |code since
   |r12-1272-gf07edb5d7f3e7721  |r12-1272-gf07edb5d7f3e7721

--- Comment #7 from Jason Merrill  ---
And 11.

[Bug c++/101078] [9/10/11 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:84171488f5eed37020f0ecf8ef9b7a466e501da0

commit r11-8584-g84171488f5eed37020f0ecf8ef9b7a466e501da0
Author: Jason Merrill 
Date:   Wed Jun 16 16:09:59 2021 -0400

c++: static memfn from non-dependent base [PR101078]

After my patch for PR91706, or before that with the qualified call,
tsubst_baselink returned a BASELINK with BASELINK_BINFO indicating a base
of
a still-dependent derived class.  We need to look up the relevant base
binfo
in the substituted class.

PR c++/101078

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Update binfos in non-dependent case.

gcc/testsuite/ChangeLog:

* g++.dg/template/access39.C: New test.

[Bug c++/101078] [9/10/11 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression]
   |Rejected code since |Rejected code since
   |r12-1272-gf07edb5d7f3e7721  |r12-1272-gf07edb5d7f3e7721

--- Comment #5 from Jason Merrill  ---
Fixed for 12 so far.

[Bug c++/101078] [9/10/11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:6816a44dfe1b5fa9414490a18a4aa723b6f38f18

commit r12-1543-g6816a44dfe1b5fa9414490a18a4aa723b6f38f18
Author: Jason Merrill 
Date:   Wed Jun 16 16:09:59 2021 -0400

c++: static memfn from non-dependent base [PR101078]

After my patch for PR91706, or before that with the qualified call,
tsubst_baselink returned a BASELINK with BASELINK_BINFO indicating a base
of
a still-dependent derived class.  We need to look up the relevant base
binfo
in the substituted class.

PR c++/101078
PR c++/91706

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Update binfos in non-dependent case.

gcc/testsuite/ChangeLog:

* g++.dg/template/access39.C: New test.

[Bug c++/91706] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:6816a44dfe1b5fa9414490a18a4aa723b6f38f18

commit r12-1543-g6816a44dfe1b5fa9414490a18a4aa723b6f38f18
Author: Jason Merrill 
Date:   Wed Jun 16 16:09:59 2021 -0400

c++: static memfn from non-dependent base [PR101078]

After my patch for PR91706, or before that with the qualified call,
tsubst_baselink returned a BASELINK with BASELINK_BINFO indicating a base
of
a still-dependent derived class.  We need to look up the relevant base
binfo
in the substituted class.

PR c++/101078
PR c++/91706

gcc/cp/ChangeLog:

* pt.c (tsubst_baselink): Update binfos in non-dependent case.

gcc/testsuite/ChangeLog:

* g++.dg/template/access39.C: New test.

[Bug c++/99910] [11/12 Regression] g++.dg/modules/xtreme-header-2_b.C ICE

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Confirmed with native x86_64-linux compiler as well.  Also reported on power
(besides x86_64) so it's likely target-independent:

Running target unix
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++2b (test for excess errors)

https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/700795.html

[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-1542-gcfe0a2ec26867b290eb84af00317e60f8b67455c
Author: Harald Anlauf 
Date:   Wed Jun 16 22:04:22 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-1542-gcfe0a2ec26867b290eb84af00317e60f8b67455c
Author: Harald Anlauf 
Date:   Wed Jun 16 22:04:22 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:72e3d92178b44a3722519ec68e72e307443bda70

commit r12-1540-g72e3d92178b44a3722519ec68e72e307443bda70
Author: Harald Anlauf 
Date:   Wed Jun 16 21:54:16 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:72e3d92178b44a3722519ec68e72e307443bda70

commit r12-1540-g72e3d92178b44a3722519ec68e72e307443bda70
Author: Harald Anlauf 
Date:   Wed Jun 16 21:54:16 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

[Bug libstdc++/100806] deadlock in std::counting_semaphore

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

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

--- Comment #2 from Thomas Rodgers  ---
I have confirmed that this is new issue, not related to PR100334.

When there are waiting threads and the semaphore attempts to release one of
the waiting threads, the FUTEX_WAKE syscall's return indicates that 1 thread is
woken, as expected, but it is unclear to me why there is no forward progress at
that point.

I have replaced the algorithm with a simplified version (similar to what is in
libc++) and observe the same result. Further investigation is required. I have
submitted an interim patch that forces wake all which appears to address the
issue.

[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files

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

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-8583-gbb2e908638758097e261bca1a4825d171a18af9c
Author: Jason Merrill 
Date:   Mon Jun 14 17:37:43 2021 -0400

libcpp: location comparison within macro [PR100796]

The patch for 96391 changed linemap_compare_locations to give up on
comparing locations from macro expansions if we don't have column
information.  But in this testcase, the BOILERPLATE macro is multiple lines
long, so we do want to compare locations within the macro.  So this patch
moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it
for failing gracefully.

PR c++/100796
PR preprocessor/96391

libcpp/ChangeLog:

* line-map.c (linemap_compare_locations): Only use comparison with
LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort.

gcc/testsuite/ChangeLog:

* g++.dg/plugin/location-overflow-test-pr100796.c: New test.
* g++.dg/plugin/plugin.exp: Run it.

[Bug c++/100796] [11 Regression] GCC does not honor #pragma diagnostic ignored when using the integrated preprocessor

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-8583-gbb2e908638758097e261bca1a4825d171a18af9c
Author: Jason Merrill 
Date:   Mon Jun 14 17:37:43 2021 -0400

libcpp: location comparison within macro [PR100796]

The patch for 96391 changed linemap_compare_locations to give up on
comparing locations from macro expansions if we don't have column
information.  But in this testcase, the BOILERPLATE macro is multiple lines
long, so we do want to compare locations within the macro.  So this patch
moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it
for failing gracefully.

PR c++/100796
PR preprocessor/96391

libcpp/ChangeLog:

* line-map.c (linemap_compare_locations): Only use comparison with
LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort.

gcc/testsuite/ChangeLog:

* g++.dg/plugin/location-overflow-test-pr100796.c: New test.
* g++.dg/plugin/plugin.exp: Run it.

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

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-8582-gd92613ec5529cecd66ef0c21b894c7f70ace7f87
Author: Jason Merrill 
Date:   Fri Jun 11 16:55:30 2021 -0400

c++: constexpr and array[0] [PR101029]

build_vec_init_elt exits early if we're initializing a zero-element array,
so build_vec_init needs to do the same to avoid trying to instantiate
things
after we've already started throwing important bits away.

PR c++/101029

gcc/cp/ChangeLog:

* init.c (build_vec_init): Shortcut [0] case.

gcc/testsuite/ChangeLog:

* g++.dg/ext/array4.C: New test.

[Bug c++/101078] [9/10/11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug driver/101103] -fsanitise=undef gives better help than -fsanitize=undef

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

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

--- Comment #2 from Jakub Jelinek  ---
-fsanitize*= doesn't take an enum but comma separated list of enums though.

[Bug driver/101103] -fsanitise=undef gives better help than -fsanitize=undef

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2021-06-16
 Ever confirmed|0   |1
  Component|sanitizer   |driver
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
This is true for almost all options that take an enum really.

[Bug sanitizer/101103] New: -fsanitise=undef gives better help than -fsanitize=undef

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

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

Bug ID: 101103
   Summary: -fsanitise=undef gives better help than
-fsanitize=undef
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

-fsanitise=undef gives
  gcc: error: unrecognized command line option '-fsanitise=undef'; did you mean
'-
fsanitize=undefined'?

while -fsanitize=undef gives just
  gcc: error: unrecognized argument to '-fsanitize=' option: 'undef'

[Bug c++/101078] [9/10/11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|11.2|9.5
 CC||jakub at gcc dot gnu.org
Summary|[11/12 Regression] Rejected |[9/10/11/12 Regression]
   |code since  |Rejected code since
   |r12-1272-gf07edb5d7f3e7721  |r12-1272-gf07edb5d7f3e7721

--- Comment #3 from Jakub Jelinek  ---
Indeed.  When the f call is in a method of B rather than of a nested class, it
works fine and when it isn't in a template too.
Extending to 9/10 too because of the B::f() case but should be kept P1 because
the f() case is a regression since 11.1.

[Bug c++/99910] [11/12 Regression] g++.dg/modules/xtreme-header-2_b.C ICE

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

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

--- Comment #5 from Hans-Peter Nilsson  ---
This and several other FAILs have re-appeared on master for cris-elf.
I think my autotester log entry is to the point:

... 2021-06-15-15:17:36 1de31913d20a (f: 88, p: 46598)
*** regress-11 (f: 99, p: 46599), gcc 71790f398e11, cris-elf at
2021-06-15-21:07:02 on pchp3, log at
/x/checkout/gcc_latest/logfile.71790f398e11.2021-06-15-21:07:02
--- regress.prev2021-06-15 23:04:22.0 +0200
+++ regress 2021-06-16 05:26:34.662416022 +0200
@@ -0,0 +1,11 @@
+g++.sum g++.dg/modules/hello-1_b.C
+g++.sum g++.dg/modules/pr99425-2_b.X
+g++.sum g++.dg/modules/string-1_b.C
+g++.sum g++.dg/modules/xtreme-header-1_b.C
+g++.sum g++.dg/modules/xtreme-header-2_b.C
+g++.sum g++.dg/modules/xtreme-header-3_b.C
+g++.sum g++.dg/modules/xtreme-header-4_b.C
+g++.sum g++.dg/modules/xtreme-header-5_b.C
+g++.sum g++.dg/modules/xtreme-header-6_b.C
+g++.sum g++.dg/modules/xtreme-header_b.C
+g++.sum g++.dg/modules/xtreme-tr1_b.C

(No regressions at 1de31913d20a aka. r12-1482
11 regressions as per above at r12-1490)
I haven't looked further into the failures.

[Bug fortran/101102] New: ICE in propagate_necessity, at tree-ssa-dce.c:980

[gscfq--- via Gcc-bugs]

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

Bug ID: 101102
   Summary: ICE in propagate_necessity, at tree-ssa-dce.c:980
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   type t
  real :: a
   end type
   type(t) :: x[*]
   data x /t(2.0+a)/
   dimension :: a(2)
end


$ gfortran-12-20210613 -c z1.f90 -fcoarray=single
z1.f90:6:13:

6 |data x /t(2.0+a)/
  | 1
Error: non-constant initialization expression at (1)


$ gfortran-12-20210613 -c z1.f90 -fcoarray=lib -O1
during GIMPLE pass: cddce
z1.f90:8:3:

8 | end
  |   ^
internal compiler error: in propagate_necessity, at tree-ssa-dce.c:980
0xd7022b propagate_necessity
../../gcc/tree-ssa-dce.c:980
0xd71056 perform_tree_ssa_dce
../../gcc/tree-ssa-dce.c:1673
0xd72475 tree_ssa_cd_dce
../../gcc/tree-ssa-dce.c:1717
0xd72475 execute
../../gcc/tree-ssa-dce.c:1789

---

z1.f90:1:9:

1 | program p
  | ^
Error: type mismatch in binary expression
real(kind=4)

real(kind=4)[2]

real(kind=4)

_5 = a + 2.0e+0;
z1.f90:1:9: internal compiler error: 'verify_gimple' failed
0xe64aad verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5161
0xb1f5d1 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15407
0xb1f877 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15478
0xedd360 gimplify_all_functions
../../gcc/tree-nested.c:3672
0xedd34f gimplify_all_functions
../../gcc/tree-nested.c:3676
0xee56c0 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3693
0x94df9a cgraph_node::analyze()
../../gcc/cgraphunit.c:676
0x951436 analyze_functions
../../gcc/cgraphunit.c:1234
0x95262d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2508

[Bug fortran/101101] New: ICE in gfc_build_array_type, at fortran/trans-types.c:1391

[gscfq--- via Gcc-bugs]

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

Bug ID: 101101
   Summary: ICE in gfc_build_array_type, at
fortran/trans-types.c:1391
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Test case in addition to pr99138, pr99254 and pr99266,
affects versions down to at least r5 :


$ cat z1.f90
subroutine s(x)
   type t
   end type
   class(t) :: x
   dimension :: x(:)
end


$ gfortran-12-20210613 -c z1.f90
z1.f90:1:12:

1 | subroutine s(x)
  |1
internal compiler error: Segmentation fault
0xc7bfff crash_signal
../../gcc/toplev.c:327
0x82022a gfc_build_array_type
../../gcc/fortran/trans-types.c:1391
0x8e gfc_get_derived_type(gfc_symbol*, int)
../../gcc/fortran/trans-types.c:2791
0x8229d8 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1170
0x822c2e gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2281
0x821174 gfc_get_function_type(gfc_symbol*, gfc_actual_arglist*, char const*)
../../gcc/fortran/trans-types.c:3126
0x7bac44 build_function_decl
../../gcc/fortran/trans-decl.c:2386
0x7c0836 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:3085
0x7c6e26 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6787
0x74c876 translate_all_program_units
../../gcc/fortran/parse.c:6461
0x74c876 gfc_parse_file()
../../gcc/fortran/parse.c:6730
0x798bbf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/101100] New: [9/10/11/12 Regression] ICE in trans_caf_token_assign, at fortran/trans-expr.c:9433

[gscfq--- via Gcc-bugs]

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

Bug ID: 101100
   Summary: [9/10/11/12 Regression] ICE in trans_caf_token_assign,
at fortran/trans-expr.c:9433
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r7 :


$ cat z1.f90
program p
   type t
  procedure(), pointer, nopass :: f
   end type
   type(t) :: x[*]
   x%f => null()
end


$ gfortran-6 -c z1.f90 -fcoarray=lib
$ gfortran-12-20210613 -c z1.f90 -fcoarray=single
$
$ gfortran-12-20210613 -c z1.f90 -fcoarray=lib
z1.f90:6:16:

6 |x%f => null()
  |1
internal compiler error: Segmentation fault
0xc7bfff crash_signal
../../gcc/toplev.c:327
0x9a9f57 build_fold_indirect_ref_loc(unsigned int, tree_node*)
../../gcc/fold-const.c:15991
0x7dd4d6 trans_caf_token_assign
../../gcc/fortran/trans-expr.c:9433
0x7dd4d6 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9586
0x79f8c7 trans_code
../../gcc/fortran/trans.c:1926
0x7c6054 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6893
0x74c876 translate_all_program_units
../../gcc/fortran/parse.c:6461
0x74c876 gfc_parse_file()
../../gcc/fortran/parse.c:6730
0x798bbf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c++/101099] New: [9/10/11/12 Regression] ICE in type_unification_real, at cp/pt.c:22173

[gscfq--- via Gcc-bugs]

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

Bug ID: 101099
   Summary: [9/10/11/12 Regression] ICE in type_unification_real,
at cp/pt.c:22173
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r9 between and 20190615 and 20190727, r8 accepts it.
With options -std=gnu++11 -fconcepts and several testsuite files
or the following variant :


$ cat z1.cc
#include 
constexpr auto list = { 1, 2, 3 };


$ g++-8 -c z1.cc -std=gnu++11 -fconcepts
$
$ g++-12-20210613 -c z1.cc -std=gnu++11 -fconcepts
z1.cc:2:33: internal compiler error: in type_unification_real, at cp/pt.c:22173
2 | constexpr auto list = { 1, 2, 3 };
  | ^
0x8313d8 type_unification_real
../../gcc/cp/pt.c:22173
0x819606 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29619
0x745bf6 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7834
0x802791 cp_parser_init_declarator
../../gcc/cp/parser.c:22044
0x7e348a cp_parser_simple_declaration
../../gcc/cp/parser.c:14587
0x8081f5 cp_parser_declaration
../../gcc/cp/parser.c:14284
0x80770b cp_parser_translation_unit
../../gcc/cp/parser.c:4942
0x80770b c_parse_file()
../../gcc/cp/parser.c:45611
0x8d7412 c_common_parse_file()
../../gcc/c-family/c-opts.c:1219

[Bug c++/101098] New: [11/12 Regression] ICE in instantiate_body, at cp/pt.c:25858

[gscfq--- via Gcc-bugs]

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

Bug ID: 101098
   Summary: [11/12 Regression] ICE in instantiate_body, at
cp/pt.c:25858
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20200621 and 20200628, r9 accepts it.
With option -fconcepts and file g++.dg/cpp2a/concepts-explicit-spec1.C
or the following variant :


$ cat z1.cc
template concept C = __is_class(T);
struct Y { int n; } y;
template void g(T) { }
int called;
template<> void g(Y) { called = 3; }
int main() { g(y); }


$ g++-9 -c z1.cc -fconcepts
$
$ g++-12-20210613 -c z1.cc -fconcepts
z1.cc: In instantiation of 'void g(T) [with T = Y]':
z1.cc:6:15:   required from here
z1.cc:3:27: internal compiler error: Segmentation fault
3 | template void g(T) { }
  |   ^
0xd4d42f crash_signal
../../gcc/toplev.c:327
0x822254 instantiate_body
../../gcc/cp/pt.c:25858
0x823223 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26141
0x83d9eb instantiate_pending_templates(int)
../../gcc/cp/pt.c:26220
0x752232 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4966

[Bug middle-end/54202] Overeager warning about freeing non-heap objects

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

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

--- Comment #10 from Martin Sebor  ---
(In reply to Serdar Sanli from comment #9)
> A simpler example not involving any globals, causing Wfree-nonheap-object
> warning since GCC11

This is actually a bug in the example: it's invalid to decrement a pointer to
the beginning of an object as done in Foo::allocate.

[Bug middle-end/90404] No warning on attempts to modify a const object

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100994

--- Comment #9 from Martin Jambor  ---
As discussed on the mailing list, such warning should also catch situations
like the testcase in pr100994 comment #4.

[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files

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

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

--- Comment #25 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:9e64426dae129cca5b62355ef6c5a3bd6137e830

commit r12-1538-g9e64426dae129cca5b62355ef6c5a3bd6137e830
Author: Jason Merrill 
Date:   Mon Jun 14 17:37:43 2021 -0400

libcpp: location comparison within macro [PR100796]

The patch for 96391 changed linemap_compare_locations to give up on
comparing locations from macro expansions if we don't have column
information.  But in this testcase, the BOILERPLATE macro is multiple lines
long, so we do want to compare locations within the macro.  So this patch
moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it
for failing gracefully.

PR c++/100796
PR preprocessor/96391

libcpp/ChangeLog:

* line-map.c (linemap_compare_locations): Only use comparison with
LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort.

gcc/testsuite/ChangeLog:

* g++.dg/plugin/location-overflow-test-pr100796.c: New test.
* g++.dg/plugin/plugin.exp: Run it.

[Bug c++/100796] [11 Regression] GCC does not honor #pragma diagnostic ignored when using the integrated preprocessor

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:9e64426dae129cca5b62355ef6c5a3bd6137e830

commit r12-1538-g9e64426dae129cca5b62355ef6c5a3bd6137e830
Author: Jason Merrill 
Date:   Mon Jun 14 17:37:43 2021 -0400

libcpp: location comparison within macro [PR100796]

The patch for 96391 changed linemap_compare_locations to give up on
comparing locations from macro expansions if we don't have column
information.  But in this testcase, the BOILERPLATE macro is multiple lines
long, so we do want to compare locations within the macro.  So this patch
moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it
for failing gracefully.

PR c++/100796
PR preprocessor/96391

libcpp/ChangeLog:

* line-map.c (linemap_compare_locations): Only use comparison with
LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort.

gcc/testsuite/ChangeLog:

* g++.dg/plugin/location-overflow-test-pr100796.c: New test.
* g++.dg/plugin/plugin.exp: Run it.

[Bug c++/101095] Bogus "error: conflicting global module declaration" for abbreviated function template using placeholder type in noexcept

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This causes:

FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++2b (test for excess errors)

[Bug tree-optimization/101097] New: Vectorizer is too eager to use vec_unpack

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 101097
   Summary: Vectorizer is too eager to use vec_unpack
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following two testcases:

void
foo (unsigned short* p1, unsigned short* p2, int* __restrict p3)
{
for (int i = 0 ; i != 8; i++)
 p3[i] = p1[i] + p2[i];
 return;
}

void
bar (unsigned short* p1, unsigned short* p2, int* __restrict p3)
{
for (int i = 0 ; i != 4; i++)
 p3[i] = p1[i] + p2[i];
 return;
}

compile with -O3 -mavx2 to:

foo:
vmovdqu (%rdi), %xmm1
vmovdqu (%rsi), %xmm0
vpmovzxwd   %xmm1, %xmm3
vpsrldq $8, %xmm1, %xmm1
vpmovzxwd   %xmm0, %xmm2
vpsrldq $8, %xmm0, %xmm0
vpmovzxwd   %xmm1, %xmm1
vpaddd  %xmm3, %xmm2, %xmm2
vpmovzxwd   %xmm0, %xmm0
vmovdqu %xmm2, (%rdx)
vpaddd  %xmm1, %xmm0, %xmm0
vmovdqu %xmm0, 16(%rdx)
ret

bar:
vpmovzxwd   (%rsi), %xmm1
vpmovzxwd   (%rdi), %xmm0
vpaddd  %xmm1, %xmm0, %xmm0
vmovdqu %xmm0, (%rdx)
ret

However, with "foo" the vec_unpack* named patterns somehow interfere with the
compilation, preventing the compiler to generate code, similar to "bar", but
with %ymm registers.

Disabling vec_unpacku_hi_ and vec_unpacku_lo_ patterns in sse.md
results in the optimal code for foo:

foo:
vpmovzxwd   (%rsi), %ymm0
vpmovzxwd   (%rdi), %ymm1
vpaddd  %ymm1, %ymm0, %ymm0
vmovdqu %ymm0, (%rdx)
vzeroupper
ret

[Bug target/101096] New: AVX512 VPMOV instruction should be used to downconvert vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 101096
   Summary: AVX512 VPMOV instruction should be used to downconvert
vectors
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcases should use VPMOV downconvert instruction with AVX512VL:

void
foo (unsigned short* p1, unsigned short* p2, char* __restrict p3)
{
for (int i = 0 ; i != 16; i++)
 p3[i] = p1[i] + p2[i];
 return;
}

void
foo1 (unsigned int* p1, unsigned int* p2, short* __restrict p3)
{
for (int i = 0 ; i != 8; i++)
 p3[i] = p1[i] + p2[i];
 return;
}

gcc -O3 -mavx512vl:

foo:
vpbroadcastw.LC1(%rip), %xmm0
vpand   16(%rsi), %xmm0, %xmm2
vpand   (%rsi), %xmm0, %xmm1
vpackuswb   %xmm2, %xmm1, %xmm1
vpand   (%rdi), %xmm0, %xmm2
vpand   16(%rdi), %xmm0, %xmm0
vpackuswb   %xmm0, %xmm2, %xmm0
vpaddb  %xmm0, %xmm1, %xmm0
vmovdqu %xmm0, (%rdx)
ret

foo1:
vpbroadcastd.LC3(%rip), %xmm0
vpand   16(%rsi), %xmm0, %xmm2
vpand   (%rsi), %xmm0, %xmm1
vpackusdw   %xmm2, %xmm1, %xmm1
vpand   (%rdi), %xmm0, %xmm2
vpand   16(%rdi), %xmm0, %xmm0
vpackusdw   %xmm0, %xmm2, %xmm0
vpaddw  %xmm0, %xmm1, %xmm0
vmovdqu %xmm0, (%rdx)
ret

[Bug ipa/100791] [10 Regression] ICE: verify_gimple failed

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.1
  Known to fail||10.3.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug ipa/100513] [10 Regression] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3 since r11-6411-gae99b315ba5b9e1c

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail||10.3.0
  Known to work||10.3.1

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

[Bug tree-optimization/100492] [10 Regression] wrong code at -O3 (generated code hangs)

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.1
  Known to fail|10.3.1  |10.3.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

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

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-9924-gb7878d4e179c72ad69cdd103fbbfe16bc38010db
Author: Richard Biener 
Date:   Mon Jun 14 14:57:26 2021 +0200

tree-optimization/100934 - properly mark irreducible regions for DOM

The jump threading code requires marked irreducible regions for the
purpose of validating jump threading paths but DOM fails to provide
that resulting in mised number of iteration upper bounds clearing.

2021-06-14  Richard Biener  

PR tree-optimization/100934
* tree-ssa-dom.c (pass_dominator::execute): Properly
mark irreducible regions.

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

(cherry picked from commit 788bb7edb3975b80c4cb16323e7a5e55a2471e46)

[Bug ipa/100791] [10 Regression] ICE: verify_gimple failed

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

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

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

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

commit r10-9923-gbe85daaecc3ae2da8707e22dc1ef19c21c3e503f
Author: Richard Biener 
Date:   Fri May 28 13:31:35 2021 +0200

ipa/100791 - copy fntype when processing __builtin_va_arg_pack

This missing copying exposed a type mismatch in the IL.

2021-05-28  Richard Biener  

PR ipa/100791
* tree-inline.c (copy_bb): When processing __builtin_va_arg_pack
copy fntype from original call.

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

(cherry picked from commit 359c0a86e2974a9f3036bc05b6e6c661f2c463cf)

[Bug ipa/100513] [10 Regression] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3 since r11-6411-gae99b315ba5b9e1c

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

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

--- Comment #27 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:37d845ac59b26e0beb97e7d0d138cb9995d6ada2

commit r10-9922-g37d845ac59b26e0beb97e7d0d138cb9995d6ada2
Author: Richard Biener 
Date:   Tue May 11 13:23:45 2021 +0200

ipa/100513 - fix SSA_NAME_DEF_STMT corruption in IPA param manip

This fixes unintended clobbering of SSA_NAME_DEF_STMT of the
cloned/inlined from SSA name during IPA parameter manipulation
of call stmt LHSs.  gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT
of the lhs to the stmt being modified but when
ipa_param_body_adjustments::modify_call_stmt is called the
cloning/inlining process has not yet remapped the stmts operands
to the copy variants but they are still original.

2021-05-11  Richard Biener  

PR ipa/100513
* ipa-param-manipulation.c
(ipa_param_body_adjustments::modify_call_stmt): Avoid
altering SSA_NAME_DEF_STMT by adjusting the calls LHS
via gimple_call_lhs_ptr.

(cherry picked from commit 7e0fe7761da9255c9342788956c37b426875d872)

[Bug tree-optimization/100509] [9/10 Regression] ICE at -O3: in fold_convert_loc with variable (attribute) alias of different types

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-9921-gcd712310edc2ffeec8982ba5f9aeaa0b14e93cf1
Author: Richard Biener 
Date:   Tue May 11 10:58:35 2021 +0200

middle-end/100509 - avoid folding constant to aggregate type

When folding a constant initializer looking through aliases to
incompatible types can lead to us trying to fold a constant
to an aggregate type which can't work.  Simply avoid trying
to constant fold non-register typed symbols.

2021-05-11  Richard Biener  

PR middle-end/100509
* gimple-fold.c (fold_gimple_assign): Only call
get_symbol_constant_value on register type symbols.

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

(cherry picked from commit ca8e8301180fa71de1a76769fc038df2ab85dfeb)

[Bug tree-optimization/100492] [10 Regression] wrong code at -O3 (generated code hangs)

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-9920-gcedce283c319103e039ae2659d0d7473dd8efeca
Author: Richard Biener 
Date:   Mon May 10 11:37:27 2021 +0200

tree-optimization/100492 - avoid irreducible regions in loop distribution

When we distribute away a condition we rely on the ability to
change it to either 1 != 0 or 0 != 0 depending on the direction
of the exit branch in the respective loop.  But when the loop
contains an irreducible sub-region then for the conditions inside
this this fails and can lead to infinite loops being generated.

Avoid distibuting loops with irreducible sub-regions.

2021-05-10  Richard Biener  

PR tree-optimization/100492
* tree-loop-distribution.c (find_seed_stmts_for_distribution):
Find nothing when the loop contains an irreducible region.

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

(cherry picked from commit 60af2db18013a0339302928ba98fee893ccc1957)

[Bug target/89021] Implement mmintrin.h in SSE

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

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

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

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

commit r12-1537-gdd835ec24be9b1a89c6b0c78673de88c81a23966
Author: Uros Bizjak 
Date:   Wed Jun 16 16:07:01 2021 +0200

ii386: Add missing two element 64bit vector permutations [PR89021]

In addition to V8QI permutations, several other missing permutations are
added for 64bit vector modes for TARGET_SSSE3 and TARGET_SSE4_1 targets.

2021-06-16  Uroš Bizjak  

gcc/
PR target/89021
* config/i386/i386-expand.c (expand_vec_perm_2perm_pblendv):
Handle 64bit modes for TARGET_SSE4_1.
(expand_vec_perm_pshufb2): Handle 64bit modes for TARGET_SSSE3.
(expand_vec_perm_even_odd_pack): Handle V4HI mode.
(expand_vec_perm_even_odd_1) : Expand via
expand_vec_perm_pshufb2 for TARGET_SSSE3 and via
expand_vec_perm_even_odd_pack for TARGET_SSE4_1.
* config/i386/mmx.md (mmx_packusdw): New insn pattern.

[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #12 from Andrew Macleod  ---
My understanding from a quick check around is we usually expect 8-10 MB of
stack space.  I have an idea how to flatten the call stack a bit, so leave this
open for that purpose if nothing else.

[Bug libstdc++/100558] std::ranges::views operator| fails to compile

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||j.galecki11 at gmail dot com

--- Comment #4 from Patrick Palka  ---
*** Bug 101091 has been marked as a duplicate of this bug. ***

[Bug libstdc++/101091] std::views::take and std::views::drop are overconstrained

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Patrick Palka  ---
Thanks for the bug report.  This regression is already fixed for GCC 11.2 and
12, see PR100558.

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

[Bug middle-end/54202] Overeager warning about freeing non-heap objects

[mserdarsanli at gmail dot com via Gcc-bugs]

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

Serdar Sanli  changed:

   What|Removed |Added

 CC||mserdarsanli at gmail dot com

--- Comment #9 from Serdar Sanli  ---
A simpler example not involving any globals, causing Wfree-nonheap-object
warning since GCC11
https://godbolt.org/z/MYn1zrjE4

===
struct Foo {
void allocate(int n);
void deallocate();

int *_data;
};

void Foo::allocate(int n) {
_data = new int[n] - 1;
}

void Foo::deallocate() {
delete[] (_data+1);
}

[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)

[john at thesnappy dot net via Gcc-bugs]

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

--- Comment #11 from J.M. Eubank  ---
Confirmed that building with a larger default stack size on Windows works to
bootstrap GCC and binutils and dependencies - I chose -Wl,--stack=10485760 (10
MiB) but probably 2-4 MiB would be sufficient.

[Bug tree-optimization/100981] [11 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4897

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||11.1.0
  Known to work||11.1.1
 Resolution|--- |FIXED

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

[Bug tree-optimization/101009] [10/11 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 #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:83758b7b67629ef4492a51e5a255f0070c07574a

commit r11-8581-g83758b7b67629ef4492a51e5a255f0070c07574a
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.

(cherry picked from commit 336c41dbcb21740f8964021e157bc69ca547059b)

[Bug tree-optimization/100981] [11 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4897

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8580-g68d2dbf845d8589c2a227a3097cbcff9429244b0
Author: Richard Biener 
Date:   Wed Jun 9 14:48:35 2021 +0200

tree-optimization/100981 - fix SLP patterns involving reductions

The following fixes the SLP FMA patterns to preserve reduction
info and the reduction vectorization to consider internal function
call defs for the reduction stmt.

2021-06-09  Richard Biener  

PR tree-optimization/100981
gcc/
* tree-vect-loop.c (vect_create_epilog_for_reduction): Use
gimple_get_lhs to also handle calls.
* tree-vect-slp-patterns.c (complex_pattern::build): Transfer
reduction info.

gcc/testsuite/
* gfortran.dg/vect/pr100981-1.f90: New testcase.

libgomp/
* testsuite/libgomp.fortran/pr100981-2.f90: New testcase.

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

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8579-g8c90437109c30a0b6d2cf861c6f0cee8b69965ef
Author: Richard Biener 
Date:   Mon Jun 14 14:57:26 2021 +0200

tree-optimization/100934 - properly mark irreducible regions for DOM

The jump threading code requires marked irreducible regions for the
purpose of validating jump threading paths but DOM fails to provide
that resulting in mised number of iteration upper bounds clearing.

2021-06-14  Richard Biener  

PR tree-optimization/100934
* tree-ssa-dom.c (pass_dominator::execute): Properly
mark irreducible regions.

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

(cherry picked from commit 788bb7edb3975b80c4cb16323e7a5e55a2471e46)

[Bug ipa/100791] [10/11 Regression] ICE: verify_gimple failed

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8578-gbfd841cacd6f0a641413912cea39a4561c73f0cb
Author: Richard Biener 
Date:   Fri May 28 13:31:35 2021 +0200

ipa/100791 - copy fntype when processing __builtin_va_arg_pack

This missing copying exposed a type mismatch in the IL.

2021-05-28  Richard Biener  

PR ipa/100791
* tree-inline.c (copy_bb): When processing __builtin_va_arg_pack
copy fntype from original call.

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

(cherry picked from commit 359c0a86e2974a9f3036bc05b6e6c661f2c463cf)

[Bug c/101090] incorrect -Wunused-value warning on remquo with constant values

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
We warn about

(gdb) p expr
$2 = 
(gdb) p debug_generic_expr (expr)
quo = 0;, 1.0e+0

which is folded from the call via do_mpfr_remquo:

  /* Dereference the quo pointer argument.  */
  arg_quo = build_fold_indirect_ref (arg_quo);
  /* Proceed iff a valid pointer type was passed in.  */
  if (TYPE_MAIN_VARIANT (TREE_TYPE (arg_quo)) == integer_type_node)
{
  /* Set the value. */
  tree result_quo
= fold_build2 (MODIFY_EXPR, TREE_TYPE (arg_quo), arg_quo,
   build_int_cst (TREE_TYPE (arg_quo),
  integer_quo));
  TREE_SIDE_EFFECTS (result_quo) = 1;
  /* Combine the quo assignment with the rem.  */
  result = non_lvalue (fold_build2 (COMPOUND_EXPR, type,
result_quo, result_rem));

but we should probably set TREE_NO_WARNING on the COMPOUND_EXPR.

[Bug ada/101094] [11/12 regression] 'Enum_Rep returns a unsigned value for the negative representation in gcc-11

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.2
Summary|[11 regression] 'Enum_Rep   |[11/12 regression]
   |returns a unsigned value|'Enum_Rep returns a
   |for the negative|unsigned value for the
   |representation in gcc-11|negative representation in
   ||gcc-11

[Bug fortran/94048] ICE and other problems using rank intrinsic to set array size

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

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

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

--- Comment #4 from José Rui Faustino de Sousa  ---
Fixed by PR96726

[Bug c/101089] [OpenMP] Diagnostic difference with clang

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is unclear and I guess needs discussion in OpenMP language committee. 
When a variable is only mentioned in aligned clause (note, not in its alignment
expression if any), but not really used anywhere, I don't think it actually
needs the variable to be referenced on the outer construct, similarly how e.g.
private(c) on simd or for and default(none) on parallel not combined with it is
not an error.
If you actually use the variable, sure, that is different.

[Bug c++/101095] New: Bogus "error: conflicting global module declaration" for abbreviate function template using placeholder type in noexcept

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

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

Bug ID: 101095
   Summary: Bogus "error: conflicting global module declaration"
for abbreviate function template using placeholder
type in noexcept
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

cat > mod.h < concept rhubarb = true;
template constexpr bool nothrow = true;
void donkey(rhubarb auto i) noexcept(nothrow) { }
#endif
EOT

cat > mod.H < mod.C <
void donkey(auto:1)’
5 | void donkey(rhubarb auto i) noexcept(nothrow) { }
  |  ^~
In file included from mod.C:1:
mod.h:5:6: note: existing declaration ‘template  requires 
rhubarb void donkey(auto:1)’
5 | void donkey(rhubarb auto i) noexcept(nothrow) { }
  |  ^~
mod.C:6:3: note: during load of binding ‘::donkey’
6 |   donkey(1);
  |   ^~


The code compiles OK if the noexcept-specifier doesn't refer to the auto:1
type.

[Bug ada/101094] New: [11 regression] 'Enum_Rep returns a unsigned value for the negative representation in gcc-11

[demoonlit at panathenaia dot halfmoon.jp via Gcc-bugs]

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

Bug ID: 101094
   Summary: [11 regression] 'Enum_Rep returns a unsigned value for
the negative representation in gcc-11
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demoonlit at panathenaia dot halfmoon.jp
  Target Milestone: ---

'Enum_Rep returns a unsigned value for the run-time value having the negative
representation in gcc-11.
It also returns just a representation value for the compile-time value.

In gcc-10 or older, it always returns just a representation value.
Is this intentional changed or not?

Test code
-

with Ada.Text_IO;
with Ada.Integer_Text_IO;
procedure main is
   type T is (Nega, Zero, Posi);
   for T use (Nega => -1, Zero => 0, Posi => 1);
begin
   -- literal
   Ada.Text_IO.Put ("Lite:");
   Ada.Integer_Text_IO.Put (T'Enum_Rep (Nega)); -- "-1"
   Ada.Text_IO.New_Line;
   -- compile-time constant
   declare
  Cons : constant T := Nega;
   begin
  Ada.Text_IO.Put ("Cons:");
  Ada.Integer_Text_IO.Put (T'Enum_Rep (Cons)); -- "-1"
  Ada.Text_IO.New_Line;
   end;
   -- variable
   declare
  Vari : T := T'Value ("Nega");
   begin
  Ada.Text_IO.Put ("Vari:");
  Ada.Integer_Text_IO.Put (T'Enum_Rep (Vari)); -- "255"
  Ada.Text_IO.New_Line;
   end;
   -- parameter
   declare
  procedure Sub1 (Para : T) is
  begin
 Ada.Text_IO.Put ("Para:");
 Ada.Integer_Text_IO.Put (T'Enum_Rep (Para)); -- "255"
 Ada.Text_IO.New_Line;
  end Sub1;
   begin
  Sub1 (Nega);
   end;
end main;

With gcc-10
---

$ gnatmake --version
GNATMAKE 10.2.0
Copyright (C) 1995-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.

$ gnatmake main
gcc -c main.adb
gnatbind -x main.ali
gnatlink main.ali

$ ./main
Lite: -1
Cons: -1
Vari: -1
Para: -1

With gcc-11
---

$ gnatmake --version
GNATMAKE 11.1.0
Copyright (C) 1995-2021, 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.

$ gnatmake main
gcc -c main.adb
gnatbind -x main.ali
gnatlink main.ali

% ./main
Lite: -1
Cons: -1
Vari:255
Para:255

Thanks.

[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #16 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r12-1529-gd7deee423f993bee8ee440f6fe0c9126c316c64b
Author: Martin Jambor 
Date:   Wed Jun 16 13:18:46 2021 +0200

tree-sra: Do not refresh readonly decls (PR 100453)

When SRA transforms an assignment where the RHS is an aggregate decl
that it creates replacements for, the (least efficient) fallback
method of dealing with them is to store all the replacements back into
the original decl and then let the original assignment takes its
course.

That of course should not need to be done for TREE_READONLY bases
which cannot change contents.  The SRA code handled this situation
only for DECL_IN_CONSTANT_POOL const decls, this patch modifies the
check so that it tests for TREE_READONLY and I also looked at all
other callers of generate_subtree_copies and added checks to another
one dealing with the same exact situation and one which deals with it
in a non-assignment context.

gcc/ChangeLog:

2021-06-11  Martin Jambor  

PR tree-optimization/100453
* tree-sra.c (create_access): Disqualify any const candidates
which are written to.
(sra_modify_expr): Do not store sub-replacements back to a const
base.
(handle_unscalarized_data_in_subtree): Likewise.
(sra_modify_assign): Likewise.  Earlier, use TREE_READONLy test
instead of constant_decl_p.

gcc/testsuite/ChangeLog:

2021-06-10  Martin Jambor  

PR tree-optimization/100453
* gcc.dg/tree-ssa/pr100453.c: New test.

[Bug tree-optimization/100250] [11 Regression] ICE related to -Wmaybe-uninitialized

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||heinrich.heinzer at gmail dot 
com

--- Comment #7 from Martin Liška  ---
*** Bug 101092 has been marked as a duplicate of this bug. ***

[Bug c/101092] internal compiler error: Segmentation fault

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

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

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

[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #14 from rguenther at suse dot de  ---
On Wed, 16 Jun 2021, alexander.gr...@tu-dresden.de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
> 
> --- Comment #13 from Alexander Grund  ---
> > But what you can see is that the resulting pointer is used for the 
> > initialization and not the placement address as literally written in source.
> 
> So I assume it was supposed to be "Y::Y (D_6557, 1);" ?
> 
> > I'm not sure how one can solve this issue with using placement new
> > but are unions not sufficiently restricted so that copy assignment
> > should work (and activate the appropriate union member)?  Thus
> > 
> >   slot->mutable_value = pair(k, v);
> 
> The problem is not the copy, the problem is that the value may contain any 
> kind
> of data, think e.g. a pair of strings. And at the initial point (i.e. first
> emplace) the slot is a casted pointer into uninitialized data. I.e. the above
> would be an assignment into an object which does not exist. And (especially)
> for such non-trivial types this would break.
> 
> I think it will work for trivial types though, although it is UB due to
> lifetime rules: You can't use an object (here: assign to) which has not 
> started
> its lifetime yet.

I see.  I would need to read up what kind of restrictions recent C++
standards place on union members, but in C a store to a non-active
union member makes that active and IIRC for tradidional POD data types
the same should hold true for C++, even w/o requiring an explicit
placement new.

> However e.g. pair has custom copy and regular constructors so I think it will
> run into the issue you mentioned: The ctor will access the object via the
> this-pointer and not via the full union-thing and hence might misoptimise 
> later
> 
> This would mean that in conclusion the use case of putting std::pairs in an
> union and accessing them via aliasing is unsupported by (at least) GCC. Is 
> that
> correct?

Without restricting the set of C++ features used, yes.  Even
accessing the data via union.memb.getX (); would involve a 'this'
pointer and thus break things.  std::pair is probably a special-case
that might work since you use pair.first rather than a method though ;)

You can see this type-punning via unions exception was invented
for C ;)

[Bug c++/101093] New: C++20 Module ICE cannot define 'enum class std::align_val_t' in different module

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 101093
   Summary: C++20 Module ICE cannot define 'enum class
std::align_val_t' in different module
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 51030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51030=edit
preprocess file

D:\hg\fast_io\src>g++ -c fast_io.cc -fmodules-ts -std=c++20 -s -flto
-march=native -Ofast
In file included from
d:\x86_64-w64-mingw32\include\c++\12.0.0\bits\stl_iterator.h:82,
 from ../include/fast_io_core_impl/freestanding/iterator.h:6,
 from ../include/fast_io_core_impl/freestanding/impl.h:12,
 from ../include/fast_io_core.h:22,
 from ../include/fast_io_freestanding.h:12,
 from ../include/fast_io_hosted.h:17,
 from ../include/fast_io.h:9,
 from fast_io.cc:6:
d:\x86_64-w64-mingw32\include\c++\12.0.0\new:89:27: error: cannot define 'enum
class std::align_val_t' in different module
   89 |   enum class align_val_t: size_t {};
  |   ^~
: note: declared here
d:\x86_64-w64-mingw32\include\c++\12.0.0\new:89:27: internal compiler error:
tree check: expected class 'type', have 'exceptional' (error_mark) in
start_enum, at cp/decl.c:15807
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/101091] std::views::take and std::views::drop are overconstrained

[j.galecki11 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jakub Gałecki  ---
Consider the following example: https://godbolt.org/z/YYzqWaM9G

#include 
#include 
#include 

void copy_drop_n1(const std::vector& src, std::vector& dest,
  std::size_t n) {  // size_t - narrowing conversion
  std::ranges::copy(src | std::views::drop(n), begin(dest) + n);
}

void copy_drop_n2(const std::vector& src, std::vector& dest,
  std::ptrdiff_t n) {  // ptrdiff_t
  std::ranges::copy(src | std::views::drop(n), begin(dest) + n);
}

As per the standard [range.take.overview]:
The name views​::​take denotes a range adaptor object ([range.adaptor.object]).
Let E and F be expressions, let T be remove_­cvref_­t, and let D
be range_­difference_­t. If decltype((F)) does not model
convertible_­to, views​::​take(E, F) is ill-formed. Otherwise, the
expression views​::​take(E, F) is expression-equivalent to [...]

The example above should therefore compile for size_t as well as ptrdiff_t,
since size_t is convertible to ptrdiff_t. This is a regression from libstdc++
version 10.x, where both functions compile.

[Bug c/101092] internal compiler error: Segmentation fault

[heinrich.heinzer at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Heinrich Heinzer  ---
Created attachment 51029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51029=edit
source file that triggers the bug

[Bug c/101092] New: internal compiler error: Segmentation fault

[heinrich.heinzer at gmail dot com via Gcc-bugs]

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

Bug ID: 101092
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: heinrich.heinzer at gmail dot com
  Target Milestone: ---

Created attachment 51028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51028=edit
preprocessed file (*.i*) that triggers the bug

Output of `gcc -v`:
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC)


Complete command line that triggers the bug:
gcc polytools.c


Compiler output:
% gcc polytools.c   
during RTL pass: expand
polytools.c: In function ‘poly_gauss_jacobi_h’:
polytools.c:125:5: internal compiler error: Segmentation fault
  125 | poly_jacobi_f_d(1, , _z, 0, n, alpha, beta);
  | ^~~
0x1614f98 internal_error(char const*, ...)
???:0
0x65c488 attr_access::array_as_string[abi:cxx11](tree_node*) const
???:0
0x775dc9 expand_call(tree_node*, rtx_def*, int)
???:0
0x89252e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Preprocessed file:
a-polytools.i (see attachments)

[Bug libstdc++/101091] New: std::views::take and std::views::drop are overconstrained

[j.galecki11 at gmail dot com via Gcc-bugs]

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

Bug ID: 101091
   Summary: std::views::take and std::views::drop are
overconstrained
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.galecki11 at gmail dot com
  Target Milestone: ---

[Bug c/101090] New: incorrect -Wunused-value warning on remquo with constant values

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 101090
   Summary: incorrect -Wunused-value warning on remquo with
constant values
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

When remquo is used with constant values, GCC emits the following warning:
warning: right-hand operand of comma expression has no effect [-Wunused-value]

According to the following testcase compiled with the "-Wunused-value -c"
options, the warning is obtained only for f2, i.e. is does not occur when the
function is not called remquo or when non-constant values are used.

double r (double, double, int *);
double remquo (double, double, int *);

int f1 (void)
{
  int quo;
  r (1.0, 3.0, );
  return quo;
}

int f2 (void)
{
  int quo;
  remquo (1.0, 3.0, );
  return quo;
}

int f3 (double x, double y)
{
  int quo;
  remquo (x, y, );
  return quo;
}

Testcase also available on https://godbolt.org/z/Px44sxn4h for testing, where I
can see that this bug was introduced in GCC 9.1.0 and is still present in the
trunk.

[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"

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

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

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

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

commit r12-1527-gb4b50bf2864e09f028a39a3f460222632c4d7348
Author: Jakub Jelinek 
Date:   Wed Jun 16 12:17:55 2021 +0200

stor-layout: Create DECL_BIT_FIELD_REPRESENTATIVE even for bitfields in
unions [PR101062]

The following testcase is miscompiled on x86_64-linux, the bitfield store
is implemented as a RMW 64-bit operation at d+24 when the d variable has
size of only 28 bytes and scheduling moves in between the R and W part
a store to a different variable that happens to be right after the d
variable.

The reason for this is that we weren't creating
DECL_BIT_FIELD_REPRESENTATIVEs for bitfields in unions.

The following patch does create them, but treats all such bitfields as if
they were in a structure where the particular bitfield is the only field.

2021-06-16  Jakub Jelinek  

PR middle-end/101062
* stor-layout.c (finish_bitfield_representative): For fields in
unions
assume nextf is always NULL.
(finish_bitfield_layout): Compute bit field representatives also in
unions, but handle it as if each bitfield was the only field in the
aggregate.

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

[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
Bug 101025 depends on bug 101088, which changed state.

Bug 101088 Summary: [12 Regression] ICE in sm_seq_valid_bb, at 
tree-ssa-loop-im.c:2383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101088

   What|Removed |Added

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

[Bug tree-optimization/101088] [12 Regression] ICE in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||101025
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101025
[Bug 101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

[Bug tree-optimization/101088] [12 Regression] ICE in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383

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

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

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

https://gcc.gnu.org/g:43fc4234ad3d9302d3460385b6fdb5e3f59b6986

commit r12-1526-g43fc4234ad3d9302d3460385b6fdb5e3f59b6986
Author: Richard Biener 
Date:   Wed Jun 16 09:49:18 2021 +0200

tree-optimization/101088 - fix SM invalidation issue

When we face a sm_ord vs sm_unord for the same ref during
store sequence merging we assert that the ref is already marked
unsupported.  But it can be that it will only be marked so
during the ongoing merging so instead of asserting mark it here.

Also apply some optimization to not waste resources to search
for already unsupported refs.

2021-06-16  Richard Biener  

PR tree-optimization/101088
* tree-ssa-loop-im.c (sm_seq_valid_bb): Only look for
supported refs on edges.  Do not assert same ref but
different kind stores are unsuported but mark them so.
(hoist_memory_references): Only look for supported refs
on exits.

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

[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing

[alexander.grund--- via Gcc-bugs]

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

--- Comment #13 from Alexander Grund  ---
> But what you can see is that the resulting pointer is used for the 
> initialization and not the placement address as literally written in source.

So I assume it was supposed to be "Y::Y (D_6557, 1);" ?

> I'm not sure how one can solve this issue with using placement new
> but are unions not sufficiently restricted so that copy assignment
> should work (and activate the appropriate union member)?  Thus
> 
>   slot->mutable_value = pair(k, v);

The problem is not the copy, the problem is that the value may contain any kind
of data, think e.g. a pair of strings. And at the initial point (i.e. first
emplace) the slot is a casted pointer into uninitialized data. I.e. the above
would be an assignment into an object which does not exist. And (especially)
for such non-trivial types this would break.

I think it will work for trivial types though, although it is UB due to
lifetime rules: You can't use an object (here: assign to) which has not started
its lifetime yet.

However e.g. pair has custom copy and regular constructors so I think it will
run into the issue you mentioned: The ctor will access the object via the
this-pointer and not via the full union-thing and hence might misoptimise later

This would mean that in conclusion the use case of putting std::pairs in an
union and accessing them via aliasing is unsupported by (at least) GCC. Is that
correct?

[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 16 Jun 2021, alexander.gr...@tu-dresden.de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
> 
> Alexander Grund  changed:
> 
>What|Removed |Added
> 
> Version|8.4.0   |8.5.0
>   Known to fail||8.3.0, 8.4.0, 8.5.0
>   Known to work||9.1.0
> 
> --- Comment #10 from Alexander Grund  ---
> > My suspicion is, that GCC loads the value of slot2 before constructing the 
> > object
> 
> I have just confirmed that: memsetting the whole region with a magic value
> shows exactly that: Where a new value should be created and then returned, 
> then
> the memset-value is returned instead. When the map already has an entry for 
> the
> key (i.e. no new value created) then the existing value (i.e. the correct one)
> is returned.
> 
> Question now: Is the in-place construction UB and just happens to "normally"
> work or is that an optimizer bug that was fixed or gone latent? And how to
> proceed to further narrow this down?

I think what can be clearly said is that in-place construction of
a union member and then accessing the constructed object via
another union member (aka do type punning via unions) is not supported
even if the later access has the union visible in the access
(because the in-place construction does not).

For simple cases if everything is inlined GCC usually plays nice
and does what-you-mean in case it can see must-aliases, thus

 *(int *)x = 1;
 *(float *)x = 0.f;
 return *(int *)x;

is, even if technically UB, _not_ "miscompiled" ("miscompiled" it
would optimize to return 1).

[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
On Wed, 16 Jun 2021, alexander.gr...@tu-dresden.de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
> 
> --- Comment #9 from Alexander Grund  ---
> > Note that when the union type is visible in the access path then GCC allows 
> > punning without further restrictions. Thus the accesses as written above 
> > are OK.
> 
> Now I have to ask again for clarification because this seemingly contradicts
> your previous statement. So let me try to state the previous question again:
> 
> Given a pointer `slot_type* slot` (where slot_type is the union as defined
> before) is it legal to access `slot->value.first`, 
> `slot->mutable_value.first`,
> `slot->key` interchangeably?
> 
> In all 3 accesses the union is visible in the access path (if I understood 
> that
> correctly) so the type punning should be ok, shouldn't it?

Yes - but it routinely happens that in C++ you end up returning a
reference to the union member as abstraction and an access to that 
reference does _not_ have the union visible but only the member.

> > the circumstances have been so there's incentive to do an invalid 
> > transform... 
> 
> So is this indeed a GCC bug which may be fixed or gone latent?

I don't think so, but we cannot rule this out at this point (but see 
above).

> Otherwise, maybe the construction is the problem? What Abseil basically 
> does is allocating a (suitably aligned) buffer of chars and in-place 
> constructing those slot_type unions/pairs there as needed (i.e. similar 
> to std::vector) After abstractions what basically happens is:
> 
> // alloc buffer done, then:
> slot_type* slot_buffer = reinterpret_cast(buffer);
> 
> // on emplace:
> size_t x = ...;
> slot_type* slot = slot_buffer + x;
> new(slot) slot_type;
> new(>mutable_value) pair(k, v);
> slot_type* slot2 = slot_buffer + x; // same as before, actually done through
> the iterator
> idx_vec[i] = slot2->value.second;

so if slot_type is the union type then

  new(>mutable_value) pair(k, v)

looks problematic since that calls operator new with a pointer to the
union member and the actual construction receives >mutable_value
as address of type decltype (slot->mutable_value) * which falls foul
of the union punning rule.

I'm not sure how one can solve this issue with using placement new
but are unions not sufficiently restricted so that copy assignment
should work (and activate the appropriate union member)?  Thus

  slot->mutable_value = pair(k, v);

?  The compiler should hopefully be able to elide the copy.

> My suspicion is, that GCC loads the value of slot2 before constructing the
> object, at least sometimes. Printing the values in the vector often shows a 
> run
> of zeroes before some other (potentially correct) values. I'd guess the 
> correct
> values happen, when no insertion took place, i.e. the construction was done
> already in a prior loop iteration.

Yes, GCC would simply "skip" the offending placement new and if it finds
a suitable definition before it would replace the load with said 
definition.

To expand on the placement new issue if you for example have

struct Y { Y(int); };
union X { int i; float f; };

void foo (void *p)
{
  X *q = reinterpret_cast  (p);
  new (>i) Y (1);
}

we end up with (early unoptimized IL):

void __GIMPLE (void * p)
{
  void * D_6558;
  void * D_6557;
  union X * q;

  q = p;
  D_6558 = >i;
  D_6557 = operator new (1ul, D_6558);
  try
{
  Y::Y (D_6571, 1);
}
  catch
{
  operator delete (D_6557, D_6558);
}
}

where 'operator new' is the usual noop that just returns the passed
pointer here.  But what you can see is that the resulting pointer
is used for the initialization and not the placement address as
literally written in source.  And even then, the CTOR that is
involved of course sees only 'this' which is a plain pointer to
its class type and all accesses in the CTOR will not have the
union visible.

That might be unexpected but I think it's a quite natural
consequence of C++ abstraction :/

[Bug c/101089] New: [OpenMP] Diagnostic difference with clang

[lebedev.ri at gmail dot com via Gcc-bugs]

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

Bug ID: 101089
   Summary: [OpenMP] Diagnostic difference with clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lebedev.ri at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/KPc5hM3f9

clang:

:4:39: error: variable 'c' must have explicitly specified data sharing
attributes
#pragma omp parallel for simd aligned(c) firstprivate(a) default(none)
  ^
:4:66: note: explicit data sharing attribute requested here
#pragma omp parallel for simd aligned(c) firstprivate(a) default(none)
 ^
1 error generated.
Compiler returned: 1

gcc:

no diagnostic.

[Bug c++/101029] [10/11/12 regression] 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 #8 from Jonathan Wakely  ---
It's only fixed on trunk so far, which will become the 12.1 release in 10-11
months.

It's a regression, so either the compiler fix should get backported to the
release branches (including the gcc-10 branch) or the static_assert in the
standard library header should get removed.

https://gcc.gnu.org/develop.html

[Bug c++/101087] [9/10/11/12 Regression] Unevaluated operand of sizeof affects noexcept operator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |9.5
   Last reconfirmed||2021-06-16
Summary|Unevaluated operand of  |[9/10/11/12 Regression]
   |sizeof affects noexcept |Unevaluated operand of
   |operator|sizeof affects noexcept
   ||operator
  Known to fail||10.3.0, 11.1.0, 12.0,
   ||4.8.0, 9.4.0
  Known to work||4.7.4
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
It compiled with GCC 4.7 but stopped with r192141 (or r192142 but almost
certainly the former):

cp-tree.h (SIZEOF_EXPR_TYPE_P): Define.

cp/
* cp-tree.h (SIZEOF_EXPR_TYPE_P): Define.
* tree.c (cp_tree_equal): Handle SIZEOF_EXPR with
SIZEOF_EXPR_TYPE_P.
* mangle.c (write_expression): Likewise.
* cxx-pretty-print.c (pp_cxx_unary_expression): Likewise.
* error.c (dump_expr): Likewise.
* parser.c (cp_parser_unary_expression): For sizeof call
cxx_sizeof_or_alignof_{type,expr} just for diagnostics and
return SIZEOF_EXPR with the operand.
* pt.c (tsubst_copy, tsubst_copy_and_build): For SIZEOF_EXPR,
call cxx_sizeof_or_alignof_{type,expr} for diagnostics, but
return SIZEOF_EXPR with tsubsted operand.
(value_dependent_expression_p): Handle SIZEOF_EXPR with
SIZEOF_EXPR_TYPE_P.
(instantiation_dependent_r): Likewise.
* call.c (null_ptr_cst_p): Call maybe_constant_value for C++98.
* semantics.c (finish_call_expr): Call
sizeof_pointer_memaccess_warning if needed.
(cxx_eval_constant_expression): Handle SIZEOF_EXPR.
(potential_constant_expression_1): Remove early exit for
C++98.  Handle PROPERTY_REF.
* decl.c (duplicate_decls): When redeclaring a builtin function,
keep the merged decl builtin also if newdecl is a gnu_inline
inline definition.
(fold_sizeof_expr_r): New function.
(compute_array_index_type): Fold SIZEOF_EXPRs in itype.
* cp-gimplify.c (cp_genericize_r): Fold SIZEOF_EXPR.
* typeck.c (cp_build_binary_op): For warn_for_sign_compare
try harder using maybe_constant_value to get INTEGER_CSTs.

* decl.c (stabilize_vla_size): Call pointer_set_destroy
at the end.
testsuite/
* g++.dg/torture/Wsizeof-pointer-memaccess1.C: New test.
* g++.dg/torture/Wsizeof-pointer-memaccess2.C: New test.
* g++.dg/warn/Wsign-compare-5.C: New test.
* g++.dg/warn/Wsizeof-pointer-memaccess-1.C: New test.
* g++.dg/warn/Wnull-conversion-1.C: For c++11 add dg-error.
* g++.dg/ext/builtin30.C: New test.
* g++.dg/ext/vla12.C: New test.
* gcc.dg/builtins-85.c: New test.
libstdc++-v3/
* testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust line
numbers.

[Bug c++/101029] [10/11/12 regression] 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 #7 from Jim Walker  ---
Thanks for the fast work on this issue. How does it work for gcc bugs in terms
of getting into a release? Would there be a 10.x release that includes this?

[Bug rtl-optimization/46235] inefficient bittest code generation

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

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

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

https://gcc.gnu.org/g:3155d51bfd1de8b6c4645dcb2292248a8d7cc3c9

commit r12-1525-g3155d51bfd1de8b6c4645dcb2292248a8d7cc3c9
Author: Roger Sayle 
Date:   Wed Jun 16 09:56:09 2021 +0100

[PATCH] PR rtl-optimization/46235: Improved use of bt for bit tests on
x86_64.

This patch tackles PR46235 to improve the code generated for bit tests
on x86_64 by making more use of the bt instruction.  Currently, GCC emits
bt instructions when followed by condition jumps (thanks to Uros'
splitters).
This patch adds splitters in i386.md, to catch the cases where bt is
followed
by a conditional move (as in the original report), or by a setc/setnc (as
in
comment 5 of the Bugzilla PR).

With this patch, the function in the original PR
int foo(int a, int x, int y) {
if (a & (1 << x))
   return a;
   return 1;
}

which with -O2 on mainline generates:
foo:movl%edi, %eax
movl%esi, %ecx
sarl%cl, %eax
testb   $1, %al
movl$1, %eax
cmovne  %edi, %eax
ret

now generates:
foo:btl %esi, %edi
movl$1, %eax
cmovc   %edi, %eax
ret

Likewise, IsBitSet1 and IsBitSet2 (from comment 5)
bool IsBitSet1(unsigned char byte, int index) {
return (byte & (1<> index) & 1;
}

Before:
movzbl  %dil, %eax
movl%esi, %ecx
sarl%cl, %eax
andl$1, %eax
ret

After:
movzbl  %dil, %edi
btl %esi, %edi
setc%al
ret

According to Agner Fog, SAR/SHR r,cl takes 2 cycles on skylake,
where BT r,r takes only one, so the performance improvements on
recent hardware may be more significant than implied by just
the reduced number of instructions.  I've avoided transforming cases
(such as btsi_setcsi) where using bt sequences may not be a clear
win (over sarq/andl).

2010-06-15  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/46235
* config/i386/i386.md: New define_split for bt followed by cmov.
(*bt_setcqi): New define_insn_and_split for bt followed by
setc.
(*bt_setncqi): New define_insn_and_split for bt then setnc.
(*bt_setnc): New define_insn_and_split for bt followed
by setnc with zero extension.

gcc/testsuite/ChangeLog
PR rtl-optimization/46235
* gcc.target/i386/bt-5.c: New test.
* gcc.target/i386/bt-6.c: New test.
* gcc.target/i386/bt-7.c: New test.

[Bug tree-optimization/101088] [12 Regression] ICE in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Just for the record, started with r12-1392-gb8b80b8aa3d9a7ab.

[Bug rtl-optimization/101086] ICE at -O2 and -O3 on x86_64-linux-gnu with "-ftracer -fvar-tracking-assignments -fsel-sched-pipelining -fselective-scheduling -fschedule-insns": in create_block_for_book

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

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

Martin Liška  changed:

   What|Removed |Added

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

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
[Bug 85099] [meta-bug] selective scheduling issues

[Bug tree-optimization/101083] [12 Regression] ICE with -Ofast in TYPE_VECTOR_SUBPARTS, at tree.h:3929

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

--- Comment #8 from Martin Liška  ---
Created attachment 51027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51027=edit
Another test-case

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Martin Liška  ---
I'm sorry, but the compile-time hog is still not resolved. I can still see it
in cam4 SPEC benchmark and I'm attaching one another yarpgen test-case.

[Bug tree-optimization/101083] [12 Regression] ICE with -Ofast in TYPE_VECTOR_SUBPARTS, at tree.h:3929

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

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

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

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

commit r12-1493-g4e56b1347687a33efa47d13d357ae3b7ab759c99
Author: Richard Biener 
Date:   Wed Jun 16 08:56:21 2021 +0200

tree-optimization/101083 - fix ICE with SLP reassoc

This makes us pass down the vector type for the two-operand
SLP node build rather than picking that from operand one which,
when constant or external, could be NULL.

2021-06-16  Richard Biener  

PR tree-optimization/101083
* tree-vect-slp.c (vect_slp_build_two_operator_nodes): Get
vectype as argument.
(vect_build_slp_tree_2): Adjust.

* gcc.dg/vect/pr97832-4.c: New testcase.

[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing

[alexander.grund--- via Gcc-bugs]

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

Alexander Grund  changed:

   What|Removed |Added

Version|8.4.0   |8.5.0
  Known to fail||8.3.0, 8.4.0, 8.5.0
  Known to work||9.1.0

--- Comment #10 from Alexander Grund  ---
> My suspicion is, that GCC loads the value of slot2 before constructing the 
> object

I have just confirmed that: memsetting the whole region with a magic value
shows exactly that: Where a new value should be created and then returned, then
the memset-value is returned instead. When the map already has an entry for the
key (i.e. no new value created) then the existing value (i.e. the correct one)
is returned.

Question now: Is the in-place construction UB and just happens to "normally"
work or is that an optimizer bug that was fixed or gone latent? And how to
proceed to further narrow this down?

[Bug tree-optimization/101080] wrong code with "-O3"

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1) 
> But it's a nice testcase.

The other PR has basically the same testcase even already and about the same
size.