[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #3 from martin  ---
Created attachment 50968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50968=edit
second test case which segfaults

Playing around with some variants in select_rank_expression2.f90, I can see
that I sometimes get correct results, sometimes the rank is correctly
recognised, but not the type, and (as is the case for attachment
select_rank_expression2.f90) it even can segfault with an invalid memory
access. I get all these behaviours by selecting different sets of the four
"call p(..)" lines and varying the order in which they are executed.

[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #2 from martin  ---
It is releases/gcc-11.1.0:
Using built-in specs.
COLLECT_GCC=gfortran-11
COLLECT_LTO_WRAPPER=.../gcc/lib/gcc/x86_64-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-repo/configure --program-suffix=-11
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-arch=westmere --prefix=.../gcc --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC)

The code is compiled with "-g select_rank_expression.f90 -o
select_rank_expression.x".

[Bug target/100085] Bad code for union transfer from __float128 to vector types

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

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

--- Comment #10 from luoxhu at gcc dot gnu.org ---
float128 to vector __int128 is fixed by:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f700e4b0ee3ef53b48975cf89be26b9177e3a3f3

[Bug c++/100983] New: Deduction guide for member template class rejected at class scope

[brycelelbach at gmail dot com via Gcc-bugs]

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

Bug ID: 100983
   Summary: Deduction guide for member template class rejected at
class scope
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brycelelbach at gmail dot com
  Target Milestone: ---

```
struct X {
  template 
  struct Y {
template 
Y(Ts...) {}
  };

  template 
  Y(Ts...) -> Y;
};
```

I'm fairly confident this is legal code, but GCC rejects it, stating that a
deduction guide is only allowed at namespace scope.

http://eel.is/c++draft/temp.deduct.guide#3.sentence-4 says:

"A deduction-guide shall inhabit the scope to which the corresponding class
template belongs and, for a member class template, have the same access."

... which suggests to me that it is allowed.

https://godbolt.org/z/cWa69scjW

[Bug libstdc++/100982] New: wrong constraint in std::optional::operator=

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 100982
   Summary: wrong constraint in std::optional::operator=
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

There is a typo in optional#L818:

  template
enable_if_t<__and_v<__not_>,
is_constructible<_Tp, const _Up&>,
is_assignable<_Tp&, _Up>,
__not_<__converts_from_optional<_Tp, _Up>>,
__not_<__assigns_from_optional<_Tp, _Up>>>,
optional&>
operator=(const optional<_Up>& __u)

It should be is_assignable<_Tp&, const _Up&>.

https://godbolt.org/z/x7Gb9a5v9

#include 

struct U {};

struct T {
  explicit T(const U&);
  T& operator=(const U&);
  T& operator=(U&&) = delete;
};

int main() {
  std::optional opt1;
  std::optional opt2;
  opt2 = opt1;
}

[Bug target/100981] New: ICE in info_for_reduction, at tree-vect-loop.c:4897

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 100981
   Summary: ICE in info_for_reduction, at tree-vect-loop.c:4897
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gfortran-12.0.0-alpha20210606 snapshot
(g:fed94fc9e704b0de228499495b7ca4d4c79ef76b) ICEs when compiling the following
testcase w/ -march=armv8.3-a -O3 -ftree-parallelize-loops=2 -fno-signed-zeros
-fno-trapping-math:

complex function cdcdot(n, cx)
  implicit none

  integer :: n, i, kx
  complex :: cx(*)
  double precision :: dsdotr, dsdoti, dt1, dt3

  kx = 1
  do i = 1, n
 dt1 = real(cx(kx))
 dt3 = aimag(cx(kx))
 dsdotr = dsdotr + dt1 * 2 - dt3 * 2
 dsdoti = dsdoti + dt1 * 2 + dt3 * 2
 kx = kx + 1
  end do
  cdcdot = cmplx(real(dsdotr), real(dsdoti))
  return
end function cdcdot

% aarch64-linux-gnu-gfortran-12.0.0 -march=armv8.3-a -O3
-ftree-parallelize-loops=2 -fno-signed-zeros -fno-trapping-math -c xrvsc8ow.f90
during GIMPLE pass: vect
xrvsc8ow.f90:9:8:

9 |   do i = 1, n
  |^
internal compiler error: in info_for_reduction, at tree-vect-loop.c:4897
0x7c8b0d info_for_reduction(vec_info*, _stmt_vec_info*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-loop.c:4897
0x122d008 vectorizable_live_operation(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
vec*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-loop.c:8547
0x11ed1d7 can_vectorize_live_stmts
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-stmts.c:10619
0x1216858 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-stmts.c:11003
0x124b296 vect_schedule_slp_node
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-slp.c:6302
0x12596cc vect_schedule_scc
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-slp.c:6516
0x125a71f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-slp.c:6580
0x1236e7c vect_transform_loop(_loop_vec_info*, gimple*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vect-loop.c:9538
0x1265f0f try_vectorize_loop_1
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vectorizer.c:1104
0x1266ca0 vectorize_loops()
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210606/work/gcc-12-20210606/gcc/tree-vectorizer.c:1243

[Bug gcov-profile/100980] New: [GCOV]The assignment statement in the “for” structure caused the wrong coverage

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

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

Bug ID: 100980
   Summary: [GCOV]The assignment statement in the “for” structure
caused the wrong coverage
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat test.c
#include
extern void abort(void);
extern void exit(int);
int main(void) {
  struct foo{
 int i0;
};
  int b,c,d=1;
  for ((b = sizeof(struct foo {
  int i0;
  int i1;
}));
   d; d--)
c = sizeof(struct foo);
}

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

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:extern void abort(void);
-:3:extern void exit(int);
1:4:int main(void) {
-:5:  struct foo{
-:6: int i0;
-:7:};
1:8:  int b,c,d=1;
2:9:  for ((b = sizeof(struct foo {
-:   10:  int i0;
-:   11:  int i1;
-:   12:}));
1:   13:   d; d--)
1:   14:c = sizeof(struct foo);
-:   15:}


line 9 was wrongly marked as executed 2 times

[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #11 from Kewen Lin  ---
Fixed on trunk, will continue to refactor the tree_predictive_commoning_loop
and its callees into class and member functions as suggested.

[Bug tree-optimization/100925] [12 Regression] tree check fail in make_range_step with -O1 in reassoc

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-June/57
   ||2317.html
   Keywords||patch

--- Comment #7 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572317.html

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

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
(In reply to Giuseppe D'Angelo from comment #0)
> Please advise as of what kind of test I could do
> / provide to help you track this one down. 

The testcase doesn't really need to be reduced, just separated from the Qt
build system: some source files and a compiler command line would be fine.

[Bug c++/100838] [11 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[11 Regression]
   |-fno-elide-constructors for |-fno-elide-constructors for
   |C++14 missing required  |C++14 missing required
   |destructor call since   |destructor call since
   |r11-5872-g4eb28483004f8291  |r11-5872-g4eb28483004f8291

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

[Bug c++/89062] class template argument deduction failure with parentheses

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||brycelelbach at gmail dot com

--- Comment #7 from Marek Polacek  ---
*** Bug 100979 has been marked as a duplicate of this bug. ***

[Bug c++/100979] Nested CTAD fails when the outer object is direct initialized and the inner object is list initialized

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I think it's a dup.

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

[Bug c++/100879] [10/11/12 Regression] gcc is complaining of a signed compare when comparing enums of different types (same underlying type)

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed for GCC 12, thanks.

That the warning used -Wsign-compare seems to be because it was associated with
that option before -Wenum-compare was added, and never updated perhaps because
it was dead code for a long time.

[Bug c++/100879] [10/11/12 Regression] gcc is complaining of a signed compare when comparing enums of different types (same underlying type)

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

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

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

https://gcc.gnu.org/g:087253b9951766cbd93286b804ebb1ab59197aa8

commit r12-1314-g087253b9951766cbd93286b804ebb1ab59197aa8
Author: Jason Merrill 
Date:   Tue Jun 8 17:48:49 2021 -0400

c++: remove redundant warning [PR100879]

Before my r277864, build_new_op promoted enums to int before passing them
on
to cp_build_binary_op; after that commit, it doesn't, so
warn_for_sign_compare sees the enum operands and gives a redundant warning.
This warning dates back to 1995, and seems to have been dead code for a
long
time--likely since build_new_op was added in 1997--so let's just remove it.

PR c++/100879

gcc/c-family/ChangeLog:

* c-warn.c (warn_for_sign_compare): Remove C++ enum mismatch
warning.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/enum3.C: New test.

[Bug c++/100956] Unused variable warnings ignore "if constexpr" blocks where variables are conditionally used

[mattreecebentley at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Matt Bentley  ---
Thank you - I'm aware GCC might optimize it out (and failed to test with
GCC10), at least in O2 mode, but other compilers might not, hence the code.

[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait

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

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

Thomas Rodgers  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Rodgers  ---
Fixed in master, backported to releases/gcc-11

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

--- Comment #22 from Andrew Pinski  ---
Without load/store handling, here are the following optimizations that either
can move to match.pd already or need some extra work to do it:

* value_replacement: need to handle !single_non_singleton_phi_for_edges case
and more than one feeder statement (2 max according to the current definition)
* cond_removal_in_popcount_clz_ctz_pattern: need 2 feeder statements and
builtin call handling for feeder statements


* two_value_replacement: recored as PR 100958, it can move already
* abs_replacement: needs PROP_gimple_lswitch so we don't change if statements
early enough
** I think majority of the abs handling is already in match.pd.
* minmax_replacement: has some handling of comparisions which might not be in
the match.pd patterns already.  needs PROP_gimple_lswitch also.
** The handling of:
 if (a <= u)
   b = MAX (a, d);
 x = PHI 
   needs to moved too.


For the ones which cannot move
* factor_out_conditional_conversion: will never move, though it needs
improvement and moved already (PR 56223 and PR 13563)
* spaceship_replacement: cannot move to match.pd depends on use afterwards
which is not hard to deal with in a match pattern.

[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait

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

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

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

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

commit r11-8528-gd7462945387b33744f665d1aa33ba1cec79c03b0
Author: Thomas Rodgers 
Date:   Tue Jun 8 15:51:53 2021 -0700

libstdc++: Fix Wrong param type in :atomic_ref<_Tp*>::wait [PR100889]

libstdc++-v3/ChangeLog:

PR libstdc++/100889
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Extend
coverage of types tested.

(cherry picked from commit 25e5ecdf82b49977e86bfaded236fb34af2705ed)

[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Thomas Rodgers :

https://gcc.gnu.org/g:25e5ecdf82b49977e86bfaded236fb34af2705ed

commit r12-1312-g25e5ecdf82b49977e86bfaded236fb34af2705ed
Author: Thomas Rodgers 
Date:   Tue Jun 8 15:51:53 2021 -0700

libstdc++: Fix Wrong param type in :atomic_ref<_Tp*>::wait [PR100889]

libstdc++-v3/ChangeLog:

PR libstdc++/100889
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Extend
coverage of types tested.

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

--- Comment #21 from Andrew Pinski  ---
Note this is not fully fixed, there is still some more work to do to deal with
the non single_non_singleton_phi_for_edges case which will allow to get rid of
value_replacement.

Note to get rid of early_p check and abs_replacement, we need to add
PROP_gimple_lswitch to say we have lowered switches already.

[Bug c++/100979] New: Nested CTAD fails when the outer object is direct initialized and the inner object is list initialized

[brycelelbach at gmail dot com via Gcc-bugs]

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

Bug ID: 100979
   Summary: Nested CTAD fails when the outer object is direct
initialized and the inner object is list initialized
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brycelelbach at gmail dot com
  Target Milestone: ---

template  struct X { X(T t) {} };

int main() {
  auto t00 = X(1);
  auto t01 = X{1};
  X t02{1};
  X t03(1);

  auto t04 = X(X{1});
  auto t05 = X{X{1}};
  auto t06 = X(X(1));
  auto t07 = X{X(1)};
  X t08(X{1}); // GCC 11.x and up rejects this; MSVC and Clang accept it.
  X t09{X{1}};
  X t10(X(1));
  X t11{X(1)};
}

https://godbolt.org/z/Pbx6cjE7q

[Bug c++/100065] Conditional explicit doesn't work for deduction guide

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

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

--- Comment #3 from Marek Polacek  ---
Fixed on trunk so far, will backport.

[Bug c++/100065] Conditional explicit doesn't work for deduction guide

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r12-1310-g1afa4facb9348cac0349ff9c30066aa25a3608f7
Author: Marek Polacek 
Date:   Mon Jun 7 16:06:00 2021 -0400

c++: explicit() ignored on deduction guide [PR100065]

When we have explicit() with a value-dependent argument, we can't
evaluate it at parsing time, so cp_parser_function_specifier_opt stashes
the argument into the decl-specifiers and grokdeclarator then stores it
into explicit_specifier_map, which is then used when substituting the
function decl.  grokdeclarator stores it for constructors and conversion
functions, but we also need to do it for deduction guides, otherwise
we'll forget that we've seen an explicit-specifier as in the attached
test.

PR c++/100065

gcc/cp/ChangeLog:

* decl.c (grokdeclarator): Store a value-dependent
explicit-specifier even for deduction guides.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/explicit18.C: New test.

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Andrew Pinski :

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

commit r12-1309-gc4574d23cb07340918793a5a98ae7bb2988b3791
Author: Andrew Pinski 
Date:   Tue Jun 1 06:48:05 2021 +

Improve match_simplify_replacement in phi-opt

This improves match_simplify_replace in phi-opt to handle the
case where there is one cheap (non-call) preparation statement in the
middle basic block similar to xor_replacement and others.
This allows to remove xor_replacement which it does too.

OK?  Bootstrapped and tested on x86_64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

Changes since v1:
v3 - Just minor changes to using gimple_assign_lhs
instead of gimple_lhs and fixing a comment.
v2 - change the check on the preparation statement to
allow only assignments and no calls and only assignments
that feed into the phi.

gcc/ChangeLog:

PR tree-optimization/25290
* tree-ssa-phiopt.c (xor_replacement): Delete.
(tree_ssa_phiopt_worker): Delete use of xor_replacement.
(match_simplify_replacement): Allow one cheap preparation
statement that can be moved to before the if.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr96928-1.c: Fix testcase for now that ~
happens on the outside of the bit_xor.

[Bug middle-end/54400] recognize vector reductions

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

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

--- Comment #8 from Marc Glisse  ---
(In reply to Richard Biener from comment #7)
> (note avoiding hadd in the reduc pattern was intended).

Indeed. Except with -Os, or if a processor with a fast hadd appears,
vectorising this doesn't bring anything. It doesn't hurt either though.

[Bug rtl-optimization/80770] suboptimal code negating a 1-bit _Bool field

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Severity|normal  |enhancement
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

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

Though if we lower, we will still need to optimize the following on the gimple
level:
  _1 = BIT_FIELD_REF <_6, 1, 0>;
  _2 = ~_1;
  _8 = BIT_INSERT_EXPR <_6, _2, 0 (1 bits)>;

to _8 = _6 ^ 1;

Or in general:
BIT_INSERT_EXPR <_6, bit_not (BIT_FIELD_REF <_6, bits, shift>), shift (bits)>
to
_6 ^ shiftedmask(bits, shift);

And maybe add:
BIT_INSERT_EXPR <_6, bit_op (BIT_FIELD_REF <_6, bits, shift>, B), shift (bits)>

_6 bit_op (convert (convert:u B) << shift);
Where u is the unsigned type if B is not an unsigned type.

[Bug c++/100879] [10/11/12 Regression] gcc is complaining of a signed compare when comparing enums of different types (same underlying type)

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/57890] gcc 4.8.1 regression: loops become slower

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.9.0, 6.1.0
  Known to work||4.7.0, 7.1.0

--- Comment #6 from Andrew Pinski  ---
Fixed in GCC 7.0:
f:
movdqa  xmm0, XMMWORD PTR .LC0[rip]
mov DWORD PTR c[rip+96], 808464432
movaps  XMMWORD PTR c[rip], xmm0
movaps  XMMWORD PTR c[rip+16], xmm0
movaps  XMMWORD PTR c[rip+32], xmm0
movaps  XMMWORD PTR c[rip+48], xmm0
movaps  XMMWORD PTR c[rip+64], xmm0
movaps  XMMWORD PTR c[rip+80], xmm0
ret
.LC0:
.quad   3472328296227680304
.quad   3472328296227680304

Where GCC 4.7.0 had produced (which is just as ok):
f:
movdqa  xmm0, XMMWORD PTR .LC0[rip]
mov BYTE PTR c[rip+96], 48
mov BYTE PTR c[rip+97], 48
movdqa  XMMWORD PTR c[rip], xmm0
mov BYTE PTR c[rip+98], 48
mov BYTE PTR c[rip+99], 48
movdqa  XMMWORD PTR c[rip+16], xmm0
movdqa  XMMWORD PTR c[rip+32], xmm0
movdqa  XMMWORD PTR c[rip+48], xmm0
movdqa  XMMWORD PTR c[rip+64], xmm0
movdqa  XMMWORD PTR c[rip+80], xmm0
ret
.LC0:
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48
.byte   48

[Bug tree-optimization/49203] missed-optimization: useless expressions not moved out of loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to work||7.0
   Target Milestone|--- |7.0
  Known to fail||4.8.5

--- Comment #3 from Andrew Pinski  ---
Fixed in at least in GCC 7.0:

.L2:
leaq16(%r8), %rsi
movq%r8, %rdx
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
movzbl  (%rdx), %ecx
sall$2, %eax
addq$1, %rdx
andl$3, %ecx
orl %ecx, %eax
cmpq%rsi, %rdx
jne .L3
movl%eax, %edx
addq$4, %r8
movb%ah, 2(%rdi)
shrl$24, %edx
movb%al, 3(%rdi)
addq$4, %rdi
movb%dl, -4(%rdi)
movl%eax, %edx
shrl$16, %edx
movb%dl, -3(%rdi)
cmpq%r8, %r9
jne .L2



   [94.12%]:
  # tmp_37 = PHI 
  # ivtmp.17_17 = PHI 
  _1 = tmp_37 << 2;
  _87 = (void *) ivtmp.17_17;
  _3 = MEM[base: _87, offset: 0B];
  _20 = _3 & 3;
  _4 = (unsigned int) _20;
  tmp_23 = _1 | _4;
  ivtmp.17_15 = ivtmp.17_17 + 1;
  if (ivtmp.17_15 != _83)
goto ; [93.75%]
  else
goto ; [6.25%]

   [5.88%]:
  _5 = tmp_23 >> 24;
  _6 = (unsigned char) _5;
  _76 = (void *) ivtmp.27_82;
  MEM[base: _76, offset: 0B] = _6;
  _7 = tmp_23 >> 16;
  _9 = (unsigned char) _7;
  MEM[base: _76, offset: 1B] = _9;
  _10 = tmp_23 >> 8;
  _12 = (unsigned char) _10;
  MEM[base: _76, offset: 2B] = _12;
  _14 = (unsigned char) tmp_23;
  MEM[base: _76, offset: 3B] = _14;
  ivtmp.27_81 = ivtmp.27_82 + 4;
  ivtmp.28_78 = ivtmp.28_79 + 4;
  if (_71 != ivtmp.28_78)
goto ; [87.51%]
  else
goto ; [12.49%]

   [5.88%]:
  # ivtmp.27_82 = PHI 
  # ivtmp.28_79 = PHI 
  _83 = ivtmp.28_79 + 16;
  goto ; [100.00%]

[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

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10 Regression] ICE: tree
   |ICE: tree check: expected   |check: expected class
   |class 'type', have  |'type', have 'exceptional'
   |'exceptional' (error_mark)  |(error_mark) in
   |in  |equate_type_number_to_die,
   |equate_type_number_to_die,  |at dwarf2out.c:5782
   |at dwarf2out.c:5782 |

--- Comment #13 from Jason Merrill  ---
Fixed for 11.2/12 so far.  Is there interest in fixing this on the 9/10
branches?

[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object

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

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

--- Comment #4 from Jason Merrill  ---
As I mentioned on IRC, it seems like this may just be a matter of properly
passing down flags/member_p in the recursive call to cp_parser_declarator.

[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object

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

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

--- Comment #3 from Marek Polacek  ---
Duh, we don't defer parsing of noexcept for any ptr-operator, like

struct S {
  int& f() noexcept(noexcept(i));
  int i;
};

Awkward, but the fix should be simple.

[Bug c++/100976] [C++23] Make constexpr reference temp constexpr

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

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

--- Comment #2 from Jason Merrill  ---
Or rather,

int main()
{
  constexpr const int  = 42;
  static_assert(r == 42); // { dg-bogus "" }
}

[expr.const]/4.7 says that "a temporary object of non-volatile const-qualified
literal type whose lifetime is extended to that
of a variable that is usable in constant expressions" is usable in a constant
expression.

[Bug target/100973] gcc does not optimise based on knowing that `_mm256_movemask_ps` returns less than 255

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Keywords||missed-optimization
   Last reconfirmed||2021-06-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
This is a target/tree-optimization.  Basically Tree level optimization has no
idea what the builtin does and there is no target hook to querry the back-end
for ranges:
  _3 = __builtin_ia32_movmskps256D.2066 (values_2(D));

[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #12 from Segher Boessenkool  ---
(In reply to H.J. Lu from comment #10)
> > unused_rodata:
> > .section.sdata.used_rodata,"awR"

This is symbol *un*used_rodata.

> used_rodata is in a writable section.  Is this intentional? -m64 generates

Does -mno-readonly-in-sdata help?  Does -msdata=none help?

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

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 50967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50967=edit
Tentativ fix

This patch would fix the testcase.  It is inspired by code in primary.c,
match_string_constant.  Not regtested.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[11 Regression]
   |gcc.dg/analyzer/data-model- |gcc.dg/analyzer/data-model-
   |1.c line 971|1.c line 971

--- Comment #16 from David Malcolm  ---
Should be fixed on trunk (for gcc 12) by the above commit

[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to TC from comment #4)
> (In reply to Patrick Palka from comment #3)
> > Good point, confirmed.  Though I'm not sure if perfect forwarding here is
> > strictly necessary to fix this testcase.  Perhaps the
> > _S_has_simple_extra_args versions of _Partial should be forwarding the bound
> > arguments as prvalues instead of as const lvalues?
> 
> It's pretty easy to come up with counterexamples that don't work (for
> example, the type might be move-only).
> 
> It may be better to limit the "simple" case for take/drop to when the
> argument type is integer-like; that's like 99% of uses anyway. Contrived
> examples gets the perfect forwarding fun but that's fine.
> 
> Similarly, it might be a good idea to restrict the "simple" case for the
> other adaptors a bit - perhaps to the case where the predicate is trivially
> copyable, which should still give good diagnostic for a lot of uses, but
> avoids a performance hit if the function object at issue is
> like...std::function.

That makes sense to me.  Implementation wise I guess this would mean
parameterizing the _S_has_simple_extra_args flag by the actual types of the
extra arguments.   And I suppose we could also use this to declare some partial
applications of split to be simple, e.g. when the pattern argument is a scalar
or a view, and get good diagnostics for split in these cases.

[Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971

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

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

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

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

commit r12-1303-gd3b1ef7a83c0c0cd5b20a1dd1714b868f3d2b442
Author: David Malcolm 
Date:   Tue Jun 8 14:45:57 2021 -0400

analyzer: bitfield fixes [PR99212]

This patch verifies the previous fix for bitfield sizes by implementing
enough support for bitfields in the analyzer to get the test cases to pass.

The patch implements support in the analyzer for reading from a
BIT_FIELD_REF, and support for folding BIT_AND_EXPR of a mask, to handle
the cases generated in tests.

The existing bitfields tests in data-model-1.c turned out to rely on
undefined behavior, in that they were assigning values to a signed
bitfield that were outside of the valid range of values.  I believe that
that's why we were seeing target-specific differences in the test
results (PR analyzer/99212).  The patch updates the test to remove the
undefined behaviors.

gcc/analyzer/ChangeLog:
PR analyzer/99212
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): Add support for folding
BIT_AND_EXPR of compound_svalue and a mask constant.
* region-model.cc (region_model::get_rvalue_1): Implement
BIT_FIELD_REF in terms of...
(region_model::get_rvalue_for_bits): New function.
* region-model.h (region_model::get_rvalue_for_bits): New decl.
* store.cc (bit_range::from_mask): New function.
(selftest::test_bit_range_intersects_p): New selftest.
(selftest::assert_bit_range_from_mask_eq): New.
(ASSERT_BIT_RANGE_FROM_MASK_EQ): New macro.
(selftest::assert_no_bit_range_from_mask_eq): New.
(ASSERT_NO_BIT_RANGE_FROM_MASK): New macro.
(selftest::test_bit_range_from_mask): New selftest.
(selftest::analyzer_store_cc_tests): Call the new selftests.
* store.h (bit_range::intersects_p): New.
(bit_range::from_mask): New decl.
(concrete_binding::get_bit_range): New accessor.
(store_manager::get_concrete_binding): New overload taking
const bit_range &.

gcc/testsuite/ChangeLog:
PR analyzer/99212
* gcc.dg/analyzer/bitfields-1.c: New test.
* gcc.dg/analyzer/data-model-1.c (struct sbits): Make bitfields
explicitly signed.
(test_44): Update test values assigned to the bits to ones that
fit in the range of the bitfield type.  Remove xfails.
(test_45): Remove xfails.

Signed-off-by: David Malcolm 

[Bug c++/100976] [C++23] Make constexpr reference temp constexpr

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

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

--- Comment #1 from Jason Merrill  ---
  constexpr const int  = 42;
  static_assert(r == 42);

[Bug c++/100975] [C++23] Allow pointer to array of auto

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

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

--- Comment #1 from Jason Merrill  ---
  int a[3];
  auto (*p)[3] = 

[Bug rtl-optimization/100978] New: [10/11/12 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -O3 -frename-registers -fno-sched-critical-path-heuristic -f

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 100978
   Summary: [10/11/12 Regression] ICE: qsort checking failed:
qsort comparator non-negative on sorted output: 1 with
-O3 -frename-registers
-fno-sched-critical-path-heuristic
-fsched2-use-superblocks
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 50966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50966=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 -frename-registers
-fno-sched-critical-path-heuristic -fsched2-use-superblocks testcase.c 
testcase.c: In function 'foo':
testcase.c:21:1: error: qsort comparator non-negative on sorted output: 1
   21 | }
  | ^
during RTL pass: sched2
testcase.c:21:1: internal compiler error: qsort checking failed
0xa1bf87 qsort_chk_error
/repo/gcc-trunk/gcc/vec.c:214
0xa1c093 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*, void*), void*)
/repo/gcc-trunk/gcc/vec.c:256
0x1d79fb5 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/sort.cc:270
0x1bd83c0 ready_sort_real
/repo/gcc-trunk/gcc/haifa-sched.c:3095
0x1be09c5 ready_sort
/repo/gcc-trunk/gcc/haifa-sched.c:3111
0x1be09c5 schedule_block(basic_block_def**, void*)
/repo/gcc-trunk/gcc/haifa-sched.c:6709
0x1cb32ab schedule_ebb(rtx_insn*, rtx_insn*, bool)
/repo/gcc-trunk/gcc/sched-ebb.c:536
0x1cb39d2 schedule_ebbs()
/repo/gcc-trunk/gcc/sched-ebb.c:655
0x1015b2c rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.c:3740
0x1015b2c execute
/repo/gcc-trunk/gcc/sched-rgn.c:3878
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1295-20210608150918-g7a56d3d3e99-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-1295-20210608150918-g7a56d3d3e99-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210608 (experimental) (GCC)

[Bug preprocessor/100904] [9/10/11/12 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
David, can you please have a look?  Thanks.

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

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Setting a breakpoint in gfc_simplify_len, it appears that the substring length
is not properly set:

(gdb) p e->ref->type
$4 = REF_SUBSTRING
(gdb) p *e->ref->u.ss.start->value.integer._mp_d
$15 = 1
(gdb) p *e->ref->u.ss.end->value.integer._mp_d
$16 = 2
(gdb) p *e->ref->u.ss.length->length->value.integer._mp_d 
$17 = 8

[Bug c++/100977] [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/93955] detect conversion from pointer type to arithmetic type in constexpr

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Resolved by r11-893.

[Bug c++/100977] New: [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31

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

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

Bug ID: 100977
   Summary: [C++23] Implement C++ Identifier Syntax using Unicode
Standard Annex 31
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
Blocks: 98940
  Target Milestone: ---

https://wg21.link/p1949r7

This seems like largely a matter of adding another category to
libcpp/ucnid.tab.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug c++/100976] [C++23] Make constexpr reference temp constexpr

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/100975] [C++23] Allow pointer to array of auto

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/100976] New: [C++23] Make constexpr reference temp constexpr

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

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

Bug ID: 100976
   Summary: [C++23] Make constexpr reference temp constexpr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
Blocks: 98940
  Target Milestone: ---

https://wg21.link/cwg2481


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

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

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/100975] New: [C++23] Allow pointer to array of auto

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

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

Bug ID: 100975
   Summary: [C++23] Allow pointer to array of auto
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
Blocks: 98940
  Target Milestone: ---

https://wg21.link/cwg2397


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

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

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

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

Bug ID: 100974
   Summary: [C++23] Implement if consteval
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
Blocks: 98940
  Target Milestone: ---

https://wg21.link/p1938r3


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

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

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jun 08, 2021 at 05:09:05PM +, gs...@t-online.de wrote:
> 
> It should be valid, type-spec is explicitly given and the ac-values
> are type compatible (see e.g. F2018 7.8). With len(x(1:2))==2 the
> following simplified example works :
> 

Thanks for the leg work with the standard.  I was heading
out the door for work when I saw Richard's comment.  I
simply wanted to confirm that it is indeed a FE bug.

Likely, needed to check array.c(walk_array_constructor)
to see how the typespec/conversion is handled and possibly
array.c(gfc_match_array_constructor).

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 11.2/12.

[Bug c++/100973] New: gcc does not optimise based on knowing that `_mm256_movemask_ps` returns less than 255

[denis.yaroshevskij at gmail dot com via Gcc-bugs]

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

Bug ID: 100973
   Summary: gcc does not optimise based on knowing that
`_mm256_movemask_ps` returns less than 255
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.yaroshevskij at gmail dot com
  Target Milestone: ---

Options: -O3 -std=c++20 -DNDEBUG -mavx

Code:

```
#include 

int masking_should_evaporate(__m256 values) {
  int top_bits = _mm256_movemask_ps(values);
  top_bits &= 255;
  return top_bits;
}
```

Godbolt: https://gcc.godbolt.org/z/a81qPWcon


For this code top_bits &= 255 does not actually do anything. Clang can optimise
based on that:

```
   vmovmskps   eax, ymm0
   vzeroupper
   ret
```

It comes from real code.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

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

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

commit r11-8526-g5af06ce836d4d8d1654db3855db8b86a994faf49
Author: Jason Merrill 
Date:   Tue Jun 8 09:19:58 2021 -0400

c++: braced-list overload resolution [PR100963]

My PR969626 patch made us ignore template candidates when there's a perfect
non-template candidate.  In this case, we were considering B(int) a perfect
match for B({0}), but the brace elision makes it imperfect.

PR c++/100963

gcc/cp/ChangeLog:

* call.c (perfect_conversion_p): Check check_narrowing.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist124.C: New test.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

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

https://gcc.gnu.org/g:91349e57bbfd010156b9128b2ad751c8843e7245

commit r12-1299-g91349e57bbfd010156b9128b2ad751c8843e7245
Author: Jason Merrill 
Date:   Tue Jun 8 09:19:58 2021 -0400

c++: braced-list overload resolution [PR100963]

My PR969626 patch made us ignore template candidates when there's a perfect
non-template candidate.  In this case, we were considering B(int) a perfect
match for B({0}), but the brace elision makes it imperfect.

PR c++/100963

gcc/cp/ChangeLog:

* call.c (perfect_conversion_p): Check check_narrowing.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist124.C: New test.

[Bug preprocessor/100904] [9/10/11/12 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r7-1651-gac81cf0b2bf5efdd716d10d1c218eb5a17e1035b

[Bug fortran/53653] [IR Tracking] Disallow abstract/unlimited-polymorphic types in array constructors

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #3 from G. Steinmetz  ---

Very similar :

$ cat zz1.f90
program p
   type t
   end type
   class(t), allocatable :: a, b(:)
   allocate (b, source=[a])
end


$ gfortran-12-20210606 -c zz1.f90
zz1.f90:5:27:

5 |allocate (b, source=[a])
  |   1
internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1249
0x81cbea gfc_get_element_type(tree_node*)
../../gcc/fortran/trans-types.c:1249
0x7a1f4c gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*,
tree_node*, tree_node*, bool, bool, bool, locus*)
../../gcc/fortran/trans-array.c:1329
0x7ac382 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5319
0x7ac615 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7555
0x815fff gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6289
0x79e617 trans_code
../../gcc/fortran/trans.c:2090
0x7c4bc4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6893
0x74b3f6 translate_all_program_units
../../gcc/fortran/parse.c:6461
0x74b3f6 gfc_parse_file()
../../gcc/fortran/parse.c:6730
0x79772f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/100972] New: Missing error with "implicit none (external)"

[gscfq--- via Gcc-bugs]

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

Bug ID: 100972
   Summary: Missing error with "implicit none (external)"
   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: ---

In the following example function g has no known interface and is
not declared external. implicit none (external) does not catch it.
Affects versions down to at least r5.


$ cat z1.f90
program p
   implicit none (external)
   real, external :: f
   real :: a, b
   a = f()
   b = g()
end


$ gfortran-12-20210606 -c z1.f90
$

BTW, ifort/ifx 2021.2 gets it right with
error #8889: Explicit declaration of the EXTERNAL attribute is required. [G]

[Bug fortran/100971] New: ICE: Bad IO basetype (7)

[gscfq--- via Gcc-bugs]

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

Bug ID: 100971
   Summary: ICE: Bad IO basetype (7)
   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: ---

This invalid code z1 affects versions down to at least r5.
For reference, the case z0 is already rejected.


$ cat z0.f90
program p
   type t
   end type
   class(t), allocatable :: a
   print *, a
end


$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: a
   print *, [a]
end


$ gfortran-12-20210606 -c z0.f90
z0.f90:5:13:

5 |print *, a
  | 1
Error: Data transfer element at (1) cannot be polymorphic unless it is
processed by a defined input/output procedure


$ gfortran-12-20210606 -c z1.f90
f951: internal compiler error: Bad IO basetype (7)
0x6ea049 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x6eb76a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x7f9e09 transfer_expr
../../gcc/fortran/trans-io.c:2507
0x7fd430 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2661
0x79e6c7 trans_code
../../gcc/fortran/trans.c:2138
0x7faefe build_dt
../../gcc/fortran/trans-io.c:2026
0x79e6a7 trans_code
../../gcc/fortran/trans.c:2110
0x7c4bc4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6893
0x74b3f6 translate_all_program_units
../../gcc/fortran/parse.c:6461
0x74b3f6 gfc_parse_file()
../../gcc/fortran/parse.c:6730
0x79772f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

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

[gscfq--- via Gcc-bugs]

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

Bug ID: 100970
   Summary: ICE in output_constructor_regular_field, at
varasm.c:5514
   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: ---

These invalid codes (different shape for array assignment, see z0)
affect versions down to at least r5. Case z1 is silently accepted
(but not with -m32). I wonder how this could be related to pr100950.


$ cat z0.f90
module m
   integer :: a(1) = [1, 2]
end


$ cat z1.f90
module m
   type t
  integer :: a(1) = [1, 2]
  real, pointer :: b => null()
   end type
end


$ cat z2.f90
module m
   type t
  integer :: a(1) = [1, 2, 3]
  real, pointer :: b => null()
   end type
end


$ cat z3.f90
module m
   type t
  integer :: a(1) = [1, 2, 3, 4]
  real, pointer :: b => null()
   end type
end


$ cat z4.f90
module m
   type t
  integer :: a(1) = [1, 2, 3, 4, 5]
  real, pointer :: b => null()
   end type
   type(t) :: x
end


$ gfortran-12-20210606 -c z0.f90
z0.f90:2:18:

2 |integer :: a(1) = [1, 2]
  |  1
Error: Different shape for array assignment at (1) on dimension 1 (1 and 2)

$ gfortran-12-20210606 -c z1.f90

$ gfortran-12-20210606 -c z4.f90
z4.f90:7:3:

7 | end
  |   ^
internal compiler error: in output_constructor_regular_field, at varasm.c:5514
0xf3fdad output_constructor_regular_field
../../gcc/varasm.c:5514
0xf3fdad output_constructor
../../gcc/varasm.c:5820
0xf400ef output_constant
../../gcc/varasm.c:5172
0xf400ef assemble_variable_contents
../../gcc/varasm.c:2235
0xf47e8d assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2414
0xf4a18a varpool_node::assemble_decl()
../../gcc/varpool.c:595
0x8b0a8f output_in_order
../../gcc/cgraphunit.c:2135
0x8b0a8f symbol_table::compile()
../../gcc/cgraphunit.c:2353
0x8b33af symbol_table::compile()
../../gcc/cgraphunit.c:2540
0x8b33af symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2537

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

[gscfq--- via Gcc-bugs]

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

--- Comment #5 from G. Steinmetz  ---

It should be valid, type-spec is explicitly given and the ac-values
are type compatible (see e.g. F2018 7.8). With len(x(1:2))==2 the
following simplified example works :


$ cat zz1.f90
program p
   print *, [character(2) :: 'a', 'b']
   print *
   print *, 'len :', len ([character(3) :: 'a', 'bc', 'def', 'last'])
   print *, 'size:', size([character(3) :: 'a', 'bc', 'def', 'last'])
   print *, [character(3) :: 'a', 'bc', 'def', 'last']
end


$ gfortran zz1.f90 && ./a.out
 a b

 len :   3
 size:   4
 a  bc deflas

[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #11 from Peter Bergner  ---
(In reply to H.J. Lu from comment #10)
> (In reply to seurer from comment #9)
> > 
> > seurer@gcc1-power7:~/gcc/git/build/gcc-test$ grep .rodata attr-retain-1.s 
> > .string "used_rodata2"
> > .string "unused_rodata"
> > .string "used_rodata"
> > .globl used_rodata2
> > .globl unused_rodata
> > .globl used_rodata
> > .type   unused_rodata, @object
> > .size   unused_rodata, 4
> > unused_rodata:
> > .section.sdata.used_rodata,"awR"
> ^
> used_rodata is in a writable section.  Is this intentional? -m64 generates
> 
> .section.rodata.used_rodata,"aR"
> .align 2
> .type   used_rodata, @object
> .size   used_rodata, 4
> used_rodata:
> .long   2   
> 
> which looks correct.  If it is intentional, test should exclude -m32 for
> powerpc64-linux-gnu.

Adding Alan for his input here.

[Bug c/100920] bogus warnings with -Wscalar-storage-order

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

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

--- Comment #10 from Eric Botcazou  ---
> Raising one for these cases is really problematic. Functions using void in
> stead of an explicit type are explicitly saying that the type does not
> matter. There never is a warning for any other type where you pass them. so
> I hope  you can give this one another go.

No, the warning needs to be conservative.

[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
AFAIU the test it works for me with GCC10, 11, and 12.

What is tour output of

Fortran -v?

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

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> So we hit
> 
> /* Check if a STRING_CST fits into the field.
>Tolerate only the case when the NUL termination
>does not fit into the field.   */
> 
> static bool
> check_string_literal (tree string, unsigned HOST_WIDE_INT size)
> {
> ...
>   if (mem_size != size)
> return false;
> 
> so in this case the NUL termination is missing.  TREE_STRING_LENGTH is 1
> but the field size is 2.  The CTOR is
> 
> {"a", "b"}
> 
> and has a type of char[2][2].  Looks like a FE bug to me.

Yes, it's a FE bug.

If the line is changed to 

   print *, [character(len(x(1:2))) :: 'a ', ' b']

or

   print *, [character(len(x(1:1))) :: 'a', 'b']

the code compiles and runs as expected.  The type
declaration is set to 2 while the elements in the
constructor have a len of 1.  The FE should likely
check for too short of an element and blank pad.

However, someone needs to check if this is a valid
structure constructor, because technically the 
elements are type incompatible with declared type
(ie., different type kind parameters).

[Bug debug/100969] New: Incorrect debug info for struct under O1 optimization

[liyd2021 at gmail dot com via Gcc-bugs]

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

Bug ID: 100969
   Summary: Incorrect debug info for struct under O1 optimization
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liyd2021 at gmail dot com
  Target Milestone: ---

Reproduced on: gcc 11.1.0, 9.3.0, 8.4.0 with gdb or lldb (Ubuntu 20.04.2)

$ cat test.c
struct foo { int a, b, c; };

void not_opt(struct foo x) __attribute__((noipa));
void not_opt(struct foo x) {}

int main ()
{
struct foo f = { 7, 8, 9 };
not_opt(f);
return 0;
}

Compile command:
$ gcc -g -O1 test.c -o test
$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/vm/opt/gcc-11.1.0/libexec/gcc/x86_64-unknown-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/vm/var/tmp/vm/gcc-11.1.0_source/gcc-11.1.0/configure
--prefix=/home/vm/opt/gcc-11.1.0 --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-linker-build-id
--enable-languages=c,c++,lto --disable-vtable-verify
--with-default-libstdcxx-abi=new --enable-libstdcxx-debug
--without-included-gettext --enable-plugin --disable-initfini-array
--disable-libgcj --enable-plugin --disable-multilib --with-tune=generic
--build=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --with-pkgversion=vm
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0

Debugging with gdb:
(gdb) l
1 struct foo { int a, b, c; };
2
3 void not_opt(struct foo x) __attribute__((noipa));
4 void not_opt(struct foo x) {}
5
6 int main ()
7 {
8 struct foo f = { 7, 8, 9 };
9 not_opt(f);
10 return 0;
(gdb) b 9
(gdb) r
(gdb) print f
$1 = {a = 7, b = 8, c = 0} <-- **BUG**: c should be 9

LLDB also reports c = 0. Should be a debug-info bug.

[Bug libstdc++/100947] gthr-default.h

[kclifford at tranaptic dot ca via Gcc-bugs]

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

--- Comment #2 from Keith Clifford  ---
The configure command is:

configure --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=arm-eabi
--enable-__cxa_atexit --with-pkgversion=Tranaptic-2021/06/06-12:09:39
--with-bugurl=none --enable-languages=c,c++ --enable-interwork
--enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs
--disable-shared --disable-threads --disable-win32-registry --disable-nls
--with-newlib --with-gmp=/home/cross-gcc/11.1.0/cross-local
--with-mpfr=/home/cross-gcc/11.1.0/cross-local
--with-mpc=/home/cross-gcc/11.1.0/cross-local --with-host-libstdcxx=-lstdc++
-lsupc++ --prefix=/home/cross-gcc/11.1.0/arm-eabi -v

I'm already using --disable-threads so no it doesn't help.

[Bug fortran/100965] [OpenMP] ICE: Error: incorrect sharing of tree nodes

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 50965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50965=edit
gcc12-pr100965.patch

Untested fix.

[Bug fortran/100965] [OpenMP] ICE: Error: incorrect sharing of tree nodes

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug tree-optimization/81815] Invalid conditional reduction

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||8.1.0
  Known to fail||7.5.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed in GCC 8+.

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.5.0

--- Comment #6 from Richard Biener  ---
Fixed in GCC 8+.

[Bug libgomp/59546] wrong behavior with reduction

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
Invalid then.

[Bug target/57952] AVX/AVX2 no ymm registers used in a trivial reduction

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.1.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Richard Biener  ---
I can now see this vectorized with at least GCC 10 and up.  Note we're
vectorizing the _outer_ loop here but we also manage to vectorize the
inner loop only if I comment out the outer one, it just looks less efficient.

.L2:
vmovdqa %ymm6, %ymm2
movl$1000, %eax
.p2align 4,,10
.p2align 3
.L3:
vmovdqa %ymm2, %ymm0
vpaddd  %ymm6, %ymm2, %ymm2
vcvtdq2ps   %ymm0, %ymm0
vaddps  %ymm5, %ymm0, %ymm0
vmulps  %ymm11, %ymm0, %ymm0
vmovaps %ymm0, %ymm1
vfmadd132ps %ymm10, %ymm9, %ymm1
vfmadd132ps %ymm0, %ymm8, %ymm1
vfmadd132ps %ymm0, %ymm7, %ymm1
vfmadd132ps %ymm0, %ymm5, %ymm1
vfmadd132ps %ymm0, %ymm4, %ymm1
vfmadd132ps %ymm1, %ymm4, %ymm0
vaddps  %ymm0, %ymm3, %ymm3
decl%eax
jne .L3
incl%edx
cmpl$12, %edx
jne .L2

[Bug target/58790] [missed optimization] reduction of masks of builtin vectors not transformed to ptest or movemask instructions

[kretz at kde dot org via Gcc-bugs]

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

--- Comment #4 from Matthias Kretz (Vir)  ---
I'm still not familiar with this part of GCC, but isn't `_2 == { -1, -1, -1, -1
}` equivalent to _1, i.e. it reverses VEC_COND_EXPR? However, if the `==` is
supposed to return a scalar boolean instead of a vector boolean, then that's
the expression which most generally describes all_equal1.

[Bug other/100968] New: libiberty: stuck in infinite loop in nm-new while demangling rust symbols

[terrynini38514 at gmail dot com via Gcc-bugs]

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

Bug ID: 100968
   Summary: libiberty: stuck in infinite loop in nm-new while
demangling rust symbols
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terrynini38514 at gmail dot com
  Target Milestone: ---

Created attachment 50964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50964=edit
demangling POC

Sorry for didn't identify the actual version of libiberty, but this bug can be
reproduce by clone the latest version (2.36.50) of binutils-gdb.

The POC cause nm-new stuck in infinite loop at rust-demangle.c:1024 and
rust-demangle.c:747 while using the nm-new with option -C, and there are more
similar case I found, I can attach them if needed. All of these cases just
stuck in a infinite loop in rust-demangle.c.

And I want to apply for CVE, if that requires me to do anything more, like
attach a valid patch or something ? Let me know, please.

Thanks.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 58821 Summary: conditional reduction does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58821

   What|Removed |Added

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

[Bug tree-optimization/58821] conditional reduction does not vectorize

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||7.5.0
 Status|NEW |RESOLVED

--- Comment #2 from Richard Biener  ---
This now works, at least GCC 7+.  I believe we fix this up in if-conversion
via is_cond_scalar_reduction & friends which was added 2014.

[Bug target/58790] [missed optimization] reduction of masks of builtin vectors not transformed to ptest or movemask instructions

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-08
 Target||x86_64-*-* i?86-*-*

--- Comment #3 from Richard Biener  ---
So it's slightly more complex than a BB reduction with plus since SLP sees

   [local count: 1073741824]:
  _1 = a_8(D) == b_9(D);
  _2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
  _3 = BIT_FIELD_REF <_2, 32, 0>;
  if (_3 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1006632961]:
  goto ; [100.00%]

   [local count: 536870913]:
  _4 = BIT_FIELD_REF <_2, 32, 32>;
  if (_4 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
...

and thus it requires some if-conversion.  Maybe this is even good enough
for pattern matching in forwprop, turning it into

   if (_2 == { -1, -1, -1, -1 })

[Bug inline-asm/100953] Add memory clobbers just for reads or just for writes

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

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

--- Comment #2 from Segher Boessenkool  ---
Sure :-)  But syntactically it probably is best put amongst the clobbers,
all code parsing that already knows about handling various special cases
of syntax (well, just "memory" and "cc", and the various ways of naming
registers).

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net via Gcc-bugs]

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

--- Comment #3 from mojo at world3 dot net ---
Apologies, I noticed I had -Og on. Tried with -O3 and it optimised the struct
away. With -O2 it uses the Z register with displacement, reading data from
flash.

So it seems that only -Og produces poor code with V11. The older version 5.4.0
has issues either way. Not sure if that is a bug or just necessary for
debugging.

[Bug debug/100852] [11/12 Regression] -fcompare-debug failure (length) with -Og -fif-conversion -fno-tree-ccp -fno-tree-copy-prop

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50963=edit
gcc12-pr100852.patch

Untested fix.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net via Gcc-bugs]

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

--- Comment #2 from mojo at world3 dot net ---
avr-gcc-11.1.0-x64-windows>bin\avr-gcc -Og  -xc -Wall -mmcu=atxmega64a1u test.c
avr-gcc-11.1.0-x64-windows>bin\avr-objdump -h -S a.out > list.s

Still producing code like this

 2de:   18 97   sbiwr26, 0x08   ; 8
 2e0:   19 96   adiwr26, 0x09   ; 9

Thanks.

[Bug middle-end/54400] recognize vector reductions

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Hmm, with vectorizer support we get

   [local count: 1073741824]:
  _7 = .REDUC_PLUS (v_3(D)); [tail call]
  return _7;

but

f:
.LFB5669:
.cfi_startproc
movapd  %xmm0, %xmm1
unpckhpd%xmm0, %xmm0
addpd   %xmm1, %xmm0
ret

(note avoiding hadd in the reduc pattern was intended).  Not sure if
two element reduction vectorization is worthwhile - my current patch
bails w/o -fassociative-math (which is supposedly unnecessary for
two elements).

But mine anyway.

[Bug c++/91706] [9/10/11/12 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 #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:46c1a9f6d03ab444b42c41067597e3fbfba38486

commit r11-8524-g46c1a9f6d03ab444b42c41067597e3fbfba38486
Author: Jason Merrill 
Date:   Fri Apr 16 11:13:40 2021 -0400

c++: alias with same name as base fn [PR91706]

This is a bit complex.  Looking up c in the definition of D::c finds
C::c, OK.  Looking up c in the definition of E finds D::c, OK.  Since the
alias is not dependent, we strip it from the template argument, leaving

using E = A())>;

where 'c' still refers to C::c.  But instantiating E looks up 'c' again and
finds D::c, which isn't a function, and sadness ensues.

I think the bug here is looking up 'c' in D at instantiation time; the
declaration we found before is not dependent.  This seems to happen because
baselink_for_fns gets BASELINK_BINFO wrong; it is supposed to be the base
where lookup found the functions, C in this case.

gcc/cp/ChangeLog:

PR c++/91706
* semantics.c (baselink_for_fns): Fix BASELINK_BINFO.

gcc/testsuite/ChangeLog:

PR c++/91706
* g++.dg/template/lookup17.C: New test.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/100923] [9/10/11 Regression] wrong code at -O2 and above on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] wrong
   |wrong code at -O2 and above |code at -O2 and above on
   |on x86_64-linux-gnu |x86_64-linux-gnu
  Known to work||12.0

--- Comment #7 from Richard Biener  ---
OK, fixed on trunk.  Let's see if there's any fallout optimization-wise.

[Bug tree-optimization/100923] [9/10/11/12 Regression] wrong code at -O2 and above on x86_64-linux-gnu

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

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

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

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

commit r12-1295-g7a56d3d3e99cc77ad8a6a674870c814da6225675
Author: Richard Biener 
Date:   Tue Jun 8 12:52:12 2021 +0200

tree-optimization/100923 - fix alias-ref construction wrt availability

This PR shows that building an ao_ref from value-numbers is prone to
expose bogus contextual alias info to the oracle.  The following makes
sure to construct ao_refs from SSA names available at the program point
only.

On the way it modifies the awkward valueize_refs[_1] API.

2021-06-08  Richard Biener  

PR tree-optimization/100923
* tree-ssa-sccvn.c (valueize_refs_1): Take a pointer to
the operand vector to be valueized.
(valueize_refs): Likewise.
(valueize_shared_reference_ops_from_ref): Adjust.
(valueize_shared_reference_ops_from_call): Likewise.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.  Re-valueize
with honoring availability when we are about to create
the ao_ref and valueized before.
(vn_reference_lookup): Likewise.
(vn_reference_insert_pieces): Adjust.

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

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258) with -fno-rtti

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
ice.d:4:7: internal compiler error: Segmentation fault
4 | aa[0] = 1;
  |   ^
0xe958af crash_signal
../../gcc/toplev.c:327
0x88d8b8 TypeInfoDeclaration::TypeInfoDeclaration(Type*)
../../gcc/d/dmd/declaration.c:1258
0x88ddb8
TypeInfoAssociativeArrayDeclaration::TypeInfoAssociativeArrayDeclaration(Type*)
../../gcc/d/dmd/declaration.c:1461
0x88de11 TypeInfoAssociativeArrayDeclaration::create(Type*)
../../gcc/d/dmd/declaration.c:1472
0x9de4f5 create_typeinfo(Type*, Module*)
../../gcc/d/typeinfo.cc:1559
0x9de8fa build_typeinfo(Loc const&, Type*)
../../gcc/d/typeinfo.cc:1394
0x9cd628 ExprVisitor::visit(IndexExp*)
../../gcc/d/expr.cc:1266
0x9c9ae0 build_expr(Expression*, bool, bool)
../../gcc/d/expr.cc:3129
0x9cdedc ExprVisitor::visit(AssignExp*)
../../gcc/d/expr.cc:1218
0x9c9ae0 build_expr(Expression*, bool, bool)
../../gcc/d/expr.cc:3129
0x9ca54c ExprVisitor::visit(CommaExp*)
../../gcc/d/expr.cc:1330
0x9c9ae0 build_expr(Expression*, bool, bool)
../../gcc/d/expr.cc:3129
0x9c9b8b build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3152
0x9d8101 IRVisitor::visit(ExpStatement*)
../../gcc/d/toir.cc:1092
0x9d7c1f IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:274
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1109
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1099
0x9d7c1f IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:274
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1109
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1099
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug d/100967] New: d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258) with -fno-rtti

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 100967
   Summary: d: ICE: Segmentation fault
(../../gcc/d/dmd/declaration.c:1258) with -fno-rtti
   Product: gcc
   Version: 9.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

With an empty object module - or an object module without a `class Object'
definition, a segfault occurs when attempting to use anything that requires
TypeInfo.

---
module object;
extern(C) int main()
{
int[int] aa;
aa[0] = 1;
return 0;
}

[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Patrick Palka from comment #3)
> Good point, confirmed.  Though I'm not sure if perfect forwarding here is
> strictly necessary to fix this testcase.  Perhaps the
> _S_has_simple_extra_args versions of _Partial should be forwarding the bound
> arguments as prvalues instead of as const lvalues?

It's pretty easy to come up with counterexamples that don't work (for example,
the type might be move-only).

It may be better to limit the "simple" case for take/drop to when the argument
type is integer-like; that's like 99% of uses anyway. Contrived examples gets
the perfect forwarding fun but that's fine.

Similarly, it might be a good idea to restrict the "simple" case for the other
adaptors a bit - perhaps to the case where the predicate is trivially copyable,
which should still give good diagnostic for a lot of uses, but avoids a
performance hit if the function object at issue is like...std::function.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||10.3.0, 9.4.0
  Known to fail||11.1.0
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2021-06-08

--- Comment #2 from Patrick Palka  ---
Confirmed, started with r11-7289.

Reduced:

#include 

struct B {
  B(int) = delete;
  template B(std::initializer_list);
};

int main() {
  B({0});
}

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mattreecebentley at gmail dot 
com

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

[Bug c++/100956] Unused variable warnings ignore "if constexpr" blocks where variables are conditionally used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The warning is already fixed in the GCC 10 branch.

N.B. if you have a loop that does nothing but run trivial destructors, GCC will
optimize it out anyway.

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

[Bug libstdc++/100947] gthr-default.h

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

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

--- Comment #1 from Jonathan Wakely  ---
Please provide your full configure command.

Does using --disable-threads make any difference?