[Bug tree-optimization/95804] [11 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7

[amker at gcc dot gnu.org]

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

--- Comment #11 from bin cheng  ---
(In reply to Richard Biener from comment #8)
> Fixed - note it needs to be backported when the PR95638 fix is backported.

I backported PR95638/PR95804 to GCC-10/GCC-9 branches.  However, unnecessary to
backport to GCC-8, because the starting issue (pr94125) is not exposed on it.

[Bug demangler/96143] New: C++ demangler should not add a lambda as a substitution

[ian at airs dot com]

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

Bug ID: 96143
   Summary: C++ demangler should not add a lambda as a
substitution
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

The C++ demangler adds a lambda as a substitution in d_lambda in
libiberty/cp-demangle.c.  However, the C++ compiler does not add a lambda as a
substitution in write_closure_type_name in cp/mangle.c.  According to
https://codesourcery.com/cxx-abi, the compiler is correct and the demangler is
not.

Here is a test case that shows the problem:

template
struct A {
  typedef int X;
};

template
inline typename A::X
F2(F f) {
  return 0;
}

void F() {
  F2([]{});
}

This produces the symbol _Z2F2IZ1FvEUlvE_EN1AIT_E1XES2_, which is the type of
F2 instantiated with a lambda.  Currently the demangler demangles this as

A::X F2(A)

Note the final (A).  That does not make sense.  The argument type of F2 is not
A, which doesn't even make sense by itself.  The argument type is a lambda.

Compare to the output of llvm-cxxfilt:

A::X F2(F()::'lambda'())

Here the argument is correctly shown as a lambda.

I can send a patch.

[Bug tree-optimization/95804] [11 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8731-g8c25c91b117d814cf5c1deffd8a79b03fce68621
Author: Bin Cheng 
Date:   Thu Jul 9 18:10:03 2020 +0800

Schedule reduction partition in the last.

If reduction partition's SCC is broken by runtime alias checks, force
a negative post order to it so that it will be scheduled in the last.

2020-07-09  Bin Cheng  

gcc/
PR tree-optimization/95804
* tree-loop-distribution.c (break_alias_scc_partitions): Force
negative post order to reduction partition.

gcc/testsuite/
PR tree-optimization/95804
* gcc.dg/tree-ssa/pr95804.c: New test.

(cherry picked from commit dd21b03900085c4d60bf03207ad28bcbfbc86a4b)

[Bug tree-optimization/95638] [10 Regression] Legit-looking code doesn't work with -O2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Bin Cheng :

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

commit r9-8730-gdc7a8afce35eb8948b481b5bcb8d26124a267f55
Author: Bin Cheng 
Date:   Sat Jun 20 15:42:12 2020 +0800

Record and restore postorder information in breaking alias sccs.

gcc/
PR tree-optimization/95638
* tree-loop-distribution.c (pg_edge_callback_data): New field.
(loop_distribution::break_alias_scc_partitions): Record and restore
postorder information.  Fix memory leak.

gcc/testsuite/
PR tree-optimization/95638
* g++.dg/tree-ssa/pr95638.C: New test.

(cherry picked from commit 2c0069fafb53ccb7a45a6815025dfcbd2882a36e)

[Bug tree-optimization/95804] [11 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8454-gc7247272375899af51726df8424e911f00374200
Author: Bin Cheng 
Date:   Thu Jul 9 18:10:03 2020 +0800

Schedule reduction partition in the last.

If reduction partition's SCC is broken by runtime alias checks, force
a negative post order to it so that it will be scheduled in the last.

2020-07-09  Bin Cheng  

gcc/
PR tree-optimization/95804
* tree-loop-distribution.c (break_alias_scc_partitions): Force
negative post order to reduction partition.

gcc/testsuite/
PR tree-optimization/95804
* gcc.dg/tree-ssa/pr95804.c: New test.

(cherry picked from commit dd21b03900085c4d60bf03207ad28bcbfbc86a4b)

[Bug tree-optimization/95638] [10 Regression] Legit-looking code doesn't work with -O2

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8453-gf737ca45bee4ea61571393e04495955aeb7d67ab
Author: Bin Cheng 
Date:   Sat Jun 20 15:42:12 2020 +0800

Record and restore postorder information in breaking alias sccs.

gcc/
PR tree-optimization/95638
* tree-loop-distribution.c (pg_edge_callback_data): New field.
(loop_distribution::break_alias_scc_partitions): Record and restore
postorder information.  Fix memory leak.

gcc/testsuite/
PR tree-optimization/95638
* g++.dg/tree-ssa/pr95638.C: New test.

(cherry picked from commit 2c0069fafb53ccb7a45a6815025dfcbd2882a36e)

[Bug c++/95976] [[no_unique_address]] on union members has the opposite-of-intended effect

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/96052] Unlike Clang, alignment specifier is ignored on empty no_unique_address members

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-07-10
 Ever confirmed|0   |1

[Bug target/96139] Vector element extract mistypes long long int down to long int

[munroesj at gcc dot gnu.org]

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

--- Comment #3 from Steven Munroe  ---
(In reply to Bill Schmidt from comment #2)
> Have you tried it for -m32, out of curiosity?

no

[Bug c++/93892] Aggregate initialisation of std::array takes forever to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> PR 80272 seems like an exact dup.

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

[Bug c++/80272] g++ runs out of memory with aggregate init of large std::array of non-trivial class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||zoid at riseup dot net

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

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

[vvinayag at arm dot com]

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

vvinayag at arm dot com changed:

   What|Removed |Added

 CC||vvinayag at arm dot com

--- Comment #10 from vvinayag at arm dot com ---
(In reply to CVS Commits from comment #9)
> The master branch has been updated by Ilya Leoshkevich :
> 
> https://gcc.gnu.org/g:d59a576b8b5e12c3a56f0262912090e2921f5daa
> 
> commit r11-1785-gd59a576b8b5e12c3a56f0262912090e2921f5daa
> Author: Ilya Leoshkevich 
> Date:   Mon Jun 29 20:36:03 2020 +0200
> 
> Redefine NULL to nullptr
> 
> Bootstrap with musl libc fails with numerous "missing sentinel in
> function call" errors.  This is because musl defines NULL as 0L for C++,
> but gcc requires sentinel value to be a pointer or __null.
> 
> Jonathan Wakely says:
> 
> To be really safe during stage 1, GCC should not use NULL as a
> pointer sentinel in C++ code anyway.
> 
> The bootstrap compiler could define it to 0 or 0u, neither of which
> is guaranteed to be OK to pass as a varargs sentinel where a null
> pointer is expected.  Any of (void*)0 or (void*)NULL or nullptr
> would be safe.
> 
> While it is possible to fix this by replacing NULL sentinels with
> nullptrs, such approach would generate backporting conflicts, therefore
> simply redefine NULL to nullptr at the end of system.h, where it would
> not confuse system headers.
> 
> gcc/ChangeLog:
> 
> 2020-06-30  Ilya Leoshkevich  
> 
> PR bootstrap/95700
> * system.h (NULL): Redefine to nullptr.

I think this patch breaks arm native and aarch64 native builds when compiling
gcc/gcc/genmodes.c.

gcc/gcc/genmodes.c: In function 'const char* get_mode_class(mode_data*)':

gcc/gcc/system.h:1273:14: error: 'nullptr' was not declared in this scope
 #define NULL nullptr
  ^
gcc/gcc/genmodes.c:1221:14: note: in expansion of macro 'NULL'
   return NULL;
  ^

[Bug target/96125] __attribute__((target("cpu=power10,mma"))) does not set TARGET_MMA

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

--- Comment #5 from Peter Bergner  ---
Fixed on trunk.  I'll backport to GCC10 tomorrow, after our nightly regtesters
have blessed it.

[Bug middle-end/95270] OpenACC 'enter data attach' looks up target memory object displaced by pointer size

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Julian Brown :

https://gcc.gnu.org/g:0d00fe404c162ad0cf922ca8455aa23a74042b63

commit r11-1976-g0d00fe404c162ad0cf922ca8455aa23a74042b63
Author: Julian Brown 
Date:   Tue Jun 9 06:21:34 2020 -0700

openacc: Set bias to zero for explicit attach/detach clauses in C and C++

This is a fix for the pointer (or array) size inadvertently being used
for the bias with attach and detach mapping kinds, for both C and C++.

2020-07-09  Julian Brown  
Thomas Schwinge  

gcc/c/
PR middle-end/95270
* c-typeck.c (c_finish_omp_clauses): Set OMP_CLAUSE_SIZE (bias) to
zero
for standalone attach/detach clauses.

gcc/cp/
PR middle-end/95270
* semantics.c (finish_omp_clauses): Likewise.

include/
PR middle-end/95270
* gomp-constants.h (gomp_map_kind): Expand comment for
attach/detach
mapping kinds.

gcc/testsuite/
PR middle-end/95270
* c-c++-common/goacc/mdc-1.c: Update expected dump output for zero
bias.

libgomp/
PR middle-end/95270
* testsuite/libgomp.oacc-c-c++-common/pr95270-1.c: New test.
* testsuite/libgomp.oacc-c-c++-common/pr95270-2.c: New test.

[Bug target/96139] Vector element extract mistypes long long int down to long int

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Have you tried it for -m32, out of curiosity?

[Bug c++/96142] is_constant_evaluated() returns false for variable with constant initialization

[barry.revzin at gmail dot com]

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

Barry Revzin  changed:

   What|Removed |Added

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

--- Comment #1 from Barry Revzin  ---
Never mind, "constant initialization" and "constant-initialized" are actually
not the same thing, gcc is correct here.

[Bug c++/96077] GCC accepts ill-legal local enum definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
We probably need to commit like this to get errors:

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -19412,7 +19412,10 @@ cp_parser_enum_specifier (cp_parser* parser)
 "ISO C++ forbids empty unnamed enum");
}
   else
-   cp_parser_enumerator_list (parser, type);
+   {
+ cp_parser_commit_to_tentative_parse (parser);
+ cp_parser_enumerator_list (parser, type);
+   }

   /* Consume the final '}'.  */
   braces.require_close (parser);

[Bug libstdc++/94749] std::istream::ignore discards too many characters

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The fix is actually not right, it fails to discard the delimiter if it occurs
after ignoring more than numeric_limits::max() characters.

I have a fix for that though.

[Bug c++/96141] Coroutine and noexcept(false) destructor cause: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2817

[familiebaumanns at gmail dot com]

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

--- Comment #2 from Bernd Baumanns  ---
Created attachment 48854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48854&action=edit
II File

II File

[Bug c++/96141] Coroutine and noexcept(false) destructor cause: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2817

[familiebaumanns at gmail dot com]

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

--- Comment #1 from Bernd Baumanns  ---
Here you can see the error at godbolt:
https://godbolt.org/z/PGarTE

[Bug c++/96142] New: is_constant_evaluated() returns false for variable with constant initialization

[barry.revzin at gmail dot com]

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

Bug ID: 96142
   Summary: is_constant_evaluated() returns false for variable
with constant initialization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from StackOverflow (https://stackoverflow.com/q/62822725/2069064), this
program:

#include 

int main() {
  int i = std::is_constant_evaluated();
  return i;
}

with gcc returns 0. But it should return 1, this basically matches the example
we have in [expr.const]/14 with the initialization of p.

[Bug c++/96141] New: Coroutine and noexcept(false) destructor cause: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2817

[familiebaumanns at gmail dot com]

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

Bug ID: 96141
   Summary: Coroutine and noexcept(false) destructor cause:
internal compiler error: in gimplify_var_or_parm_decl,
at gimplify.c:2817
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: familiebaumanns at gmail dot com
  Target Milestone: ---

Created attachment 48853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48853&action=edit
Source file

Expected Behaviour:
==
Compile without error.


Actual Behaviour:
==
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2817
If the destructor of "Data" is changed to noexcept(true) - no compile error
occurs.


G++-Version:
==
g++-11 (GCC) 11.0.0 20200630 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiler Output:
==
g++-11 -fcoroutines -std=c++2a coroutine_error.cpp
coroutine_error.cpp: In function ‘std::generator Do()’:
coroutine_error.cpp:280:1: internal compiler error: in
gimplify_var_or_parm_decl, at gimplify.c:2817
  280 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Extended Compiler-Output:
==
g++-11 -v -save-temps -fcoroutines -std=c++2a coroutine_error.cpp

bernd@bernd-pc:/mnt/c/Users/Bernd/Desktop$ g++-11 -v -save-temps -fcoroutines
-std=c++2a coroutine_error.cpp
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/local/gcc-11/libexec/gcc/x86_64-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-master/configure -v --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --prefix=/usr/local/gcc-11
--enable-checking=release --enable-languages=c,c++ --disable-multilib
--program-suffix=-11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200630 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fcoroutines' '-std=c++20'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/local/gcc-11/libexec/gcc/x86_64-linux-gnu/11.0.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE coroutine_error.cpp -mtune=generic
-march=x86-64 -std=c++20 -fcoroutines -fpch-preprocess -o a-coroutine_error.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-11/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-11/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0

/usr/local/gcc-11/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-linux-gnu

/usr/local/gcc-11/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
 /usr/local/gcc-11/lib/gcc/x86_64-linux-gnu/11.0.0/include
 /usr/local/include
 /usr/local/gcc-11/include
 /usr/local/gcc-11/lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fcoroutines' '-std=c++20'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/local/gcc-11/libexec/gcc/x86_64-linux-gnu/11.0.0/cc1plus -fpreprocessed
a-coroutine_error.ii -quiet -dumpdir a- -dumpbase coroutine_error.cpp
-dumpbase-ext .cpp -mtune=generic -march=x86-64 -std=c++20 -version
-fcoroutines -o a-coroutine_error.s
GNU C++20 (GCC) version 11.0.0 20200630 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 11.0.0 20200630 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (GCC) version 11.0.0 20200630 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 11.0.0 20200630 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bb9157b4f3559041919c25088e2affde
coroutine_error.cpp: In function ‘std::generator Do()’:
coroutine_error.cpp:280:1: internal compiler error: in
gimplify_var_or_parm_decl, at gimplify.c:2817
  280 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gcc dot gnu.org]

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

Andrew Benson  changed:

   What|Removed |Added

 CC||abensonca at gcc dot gnu.org
 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Andrew Benson  ---
No - this can be resolved - PR87103 was resolved which fixed the remaining
issue with this PR. Apologies for not resolving sooner.

[Bug fortran/93473] ICE on valid with long module + submodule names

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Anything left to do?

I looked at the gcc-testresults, and it appears things are fixed now,
e.g. for Solaris or aarch64.

[Bug target/96125] __attribute__((target("cpu=power10,mma"))) does not set TARGET_MMA

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r11-1973-gfd263be4b523ff1b7f7dda49d856cc57221e8d21
Author: Peter Bergner 
Date:   Thu Jul 9 15:52:59 2020 -0500

rs6000: Allow MMA built-in initialization regardless of compiler options

Built-in initialization occurs only once and fairly early, when the
command line options are in force.  If the -mcpu= is pre-power10,
then we fail to initialize the MMA built-ins, so they are not
available to call in a #pragma target/attribute target function.
The fix is to basically always (on server type cpus) initialize the MMA
built-ins so we can use them in #pragma target/attribute target functions.

2020-07-09  Peter Bergner  

gcc/
PR target/96125
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Define the
MMA
specific types __vector_quad and __vector_pair, and initialize the
MMA built-ins if TARGET_EXTRA_BUILTINS is set.
(mma_init_builtins): Don't test for mask set in
rs6000_builtin_mask.
Remove now unneeded mask variable.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add the
OPTION_MASK_MMA flag for power10 if not already set.

gcc/testsuite/
PR target/96125
* gcc.target/powerpc/pr96125.c: New test.

[Bug fortran/89574] [8/9/10/11 Regression] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3792

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> Since changing "module init" to "module init1" avoid the issue in all
> cases, this lookslike a namespace / symbol issue.

I spent some time debugging this, and I am really confused now.

For reasons I do not understand, we end up in gfc_get_extern_function_decl,

2095  gsym = gfc_find_gsymbol (gfc_gsym_root, sym->name);

where we do not distinguish between the module that contains test_sub,
and the renamed-on-use subroutine from module mod.

Shouldn't we have entered mangled names in the tree that is pointed to by
gfc_gsym_root, instead of the unmangled ones?

Only if the name is of the bind-c type we have to use the "raw" name.

What am I missing?

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #14 from Thomas Koenig  ---
Created attachment 48852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48852&action=edit
Patch which ought to work

[Bug c++/96077] GCC accepts ill-legal local enum definition

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Doesn't even need to be in the ?: operator:

int
main ()
{
  enum { E = (2 } e;
  if (E != 2)
__builtin_abort ();
}

[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
Similarly va_start can't handle ref parameters either.

void test_va_start(ref va_list a, ...) { return va_start(a, a); }
---
0x623234 expand_intrinsic_vastart
../../gcc/d/intrinsics.cc:549
0x623234 maybe_expand_intrinsic(tree_node*)
../../gcc/d/intrinsics.cc:848
0x7a1381 d_build_call(TypeFunction*, tree_node*, tree_node*,
Array*)
../../gcc/d/d-codegen.cc:1947
0x7b3153 ExprVisitor::visit(CallExp*)
../../gcc/d/expr.cc:1843
0x7b131a build_expr(Expression*, bool)
../../gcc/d/expr.cc:3085
0x7b13c1 build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3108
0x7bd411 IRVisitor::visit(ExpStatement*)
../../gcc/d/toir.cc:1040
0x7bd11c IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:273
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1057
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1047
0x7bd11c IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:273
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1057
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1047
0x7bcfed IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:273
0x7bcfed build_function_body(FuncDeclaration*)
../../gcc/d/toir.cc:1469
0x7b08bf DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:1006
0x7ad36f build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x7bad80 build_module_tree(Module*)
../../gcc/d/modules.cc:728
0x7afa5b DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:147
0x7ad36f build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047

[Bug d/96140] New: internal compiler error: in expand_intrinsic_vaarg

[ibuclaw at gdcproject dot org]

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

Bug ID: 96140
   Summary: internal compiler error: in expand_intrinsic_vaarg
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

void test_va_arg(ref int a, ...) { return va_arg!int(_argptr, a); }
---
0x6231bc expand_intrinsic_vaarg
../../gcc/d/intrinsics.cc:514
0x6231bc maybe_expand_intrinsic(tree_node*)
../../gcc/d/intrinsics.cc:845
0x7a1381 d_build_call(TypeFunction*, tree_node*, tree_node*,
Array*)
../../gcc/d/d-codegen.cc:1947
0x7b3153 ExprVisitor::visit(CallExp*)
../../gcc/d/expr.cc:1843
0x7b131a build_expr(Expression*, bool)
../../gcc/d/expr.cc:3085
0x7b13c1 build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3108
0x7bd411 IRVisitor::visit(ExpStatement*)
../../gcc/d/toir.cc:1040
0x7bd11c IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:273
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1057
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1047
0x7bd11c IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:273
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1057
0x7bd11c IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1047
0x7bcfed IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:273
0x7bcfed build_function_body(FuncDeclaration*)
../../gcc/d/toir.cc:1469
0x7b08bf DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:1006
0x7ad36f build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x7bad80 build_module_tree(Module*)
../../gcc/d/modules.cc:728
0x7afa5b DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:147
0x7ad36f build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/96139] Vector element extract mistypes long long int down to long int

[munroesj at gcc dot gnu.org]

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

--- Comment #1 from Steven Munroe  ---
Created attachment 48851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48851&action=edit
Test case for printf of vector long long int elements

[Bug fortran/96080] OpenACC/Fortran runtime library routines vs. Fortran 'pointer'

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
In contrast, see the same example with 'dimension(:)' removed, that is, scalar
data.  Here, we see the directives and the runtime library routines behave in
the same way for Fortran 'pointer'.

program main
  use openacc
  implicit none
  integer, target :: data
  integer, pointer :: data_p

  call acc_create(data) ! h=0x7fffd79c, s=4
  ! NEW
  ! (gdb) print tgt
  ! $2 = (struct target_mem_desc *) 0xa7a690
  ! (gdb) print/x *tgt
  ! $3 = {refcount = 0x1, array = 0xb18570, tgt_start = 0x7fffcf00,
tgt_end = 0x7fffcf04, to_free = 0x7fffcf00, prev = 0x0, list_count =
0x1, device_descr = 0x80aae0, list = 0xa7a6d0}
  ! (gdb) print/x tgt->list[0]
  ! $4 = {key = 0xb18570, copy_from = 0x0, always_copy_from = 0x0,
do_detach = 0x0, offset = 0x0, length = 0x4}

  data_p => data

  call acc_copyin(data_p) ! h=0x7fffd79c, s=4
  ! This is 'data'!
  ! (gdb) print n
  ! $5 = (splay_tree_prefix_splay_tree_key) 0xb18570
  !   OLD 'data'
  ! '++dynamic_refcount'
  ! That means, this does *not* create a new mapping, 'acc_copyin(data_p)'
*does* dereference 'data_p => data'.
  ! That means, we cannot use this to create a "pointer object 'data_p'" on
the device.

  print *, acc_is_present(data_p) ! h=0x7fffd79c, s=4
  ! This is 'data'!
  ! (gdb) print n
  ! $6 = (splay_tree_prefix_splay_tree_key) 0xb18570
  ! Mapped.

  !$acc enter data copyin(data_p)
  ! 0 ("to" '*data_p'), 1 ("pointer assign" 'data_p')
  !   (gdb) print n
  !   $8 = (splay_tree_prefix_splay_tree_key) 0xb18570
  ! OLD 'data'
  !   '++dynamic_refcount'

  print *, acc_is_present(data_p) ! h=0x7fffd79c, s=4
  ! Same as above; mapped.

  !$acc serial present(data_p)
  ! 0 ("force_present" '*data_p')
  !   (gdb) print n
  !   $10 = (splay_tree_prefix_splay_tree_key) 0xb18570
  ! OLD 'data' -- expected
  ! 1 ("pointer assign" 'data_p')
  !   [...]
  data_p = 55
  !$acc end serial
end program main

In contrast to an 'integer, dimension(:), pointer :: data_p', we cannot use an
'integer, pointer :: data_p' to create a "pointer object 'data_p'" on the
device.  That's confusing (at least for me).  Plus the original confusion about
'acc_on_device' etc. behaving differently (non-sensical?).

Re: stdc++ issue: extremely long compile time with large number of string literals

[Mandeep Sandhu via Gcc-bugs]

On Thu, Jul 9, 2020 at 1:33 AM Jonathan Wakely  wrote:
>
> > I'm not sure if this is the right mailing list for asking about
>
> No it's not, this list is for automated mails from our bug database.
>
> > (possible) g++ issues. If not, I'd appreciate it if someone can point
> > me to the right one.
>
> See https://gcc.gnu.org/lists.html which tells you that gcc-help is
> the right list.

Thanks Jonathan! I'll post my question there.

-mandeep

>
>

[Bug c/96139] New: Vector element extract mistypes long long int down to long int

[munroesj at gcc dot gnu.org]

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

Bug ID: 96139
   Summary: Vector element extract mistypes long long int down to
long int
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: munroesj at gcc dot gnu.org
  Target Milestone: ---

When printing vector element for example:
  printf ("%s %016llx,%016llx\n", prefix, val[1], val[0]);

where val is a vector unsigned long long int -Wall reports:

../src/printll.c: In function ‘print_v2xint64’:
../src/printll.c:20:21: warning: format ‘%llx’ expects argument of type ‘long
long unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
   printf ("%s %016llx,%016llx\n", prefix, val[1], val[0]);
 ^

Here gcc claims that val[1] is a ‘long unsigned int’ then it is actually typed
as:

typedef __vector unsigned long long int vui64_t;

Some how the vector element extract has dropped the long long int type to long
int. This should not be an issue for PPC64 as long long int and long int are
both 64-bit but would matter for PPC32.

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[heckflosse67 at gmx dot de]

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

--- Comment #7 from Ingo Weyrich  ---
Richard, does you last comment mean, you already fixed it?. How can I test?
Maybe using godbolt?

Ingo

[Bug fortran/96080] OpenACC/Fortran runtime library routines vs. Fortran 'pointer'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

Summary|[OpenACC] 'acc_is_present'  |OpenACC/Fortran runtime
   |for Fortran 'pointer'   |library routines vs.
   ||Fortran 'pointer'
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2020-07-09

--- Comment #1 from Thomas Schwinge  ---
This problem does *not* seem to be specific to just 'acc_is_present', but
probably all (?) OpenACC/Fortran runtime library routines?  Consider the
following transcript, where we see the directives behave as expected for
Fortran 'pointer' to 'dimension(:)', but the runtime library routines do not.

program main
  use openacc
  implicit none
  integer, dimension(:), target :: data(19) ! 19 * 4 = 76 = 0x4c
  integer, dimension(:), pointer :: data_p

  call acc_create(data) ! h=0x7fffd6d0, s=76
  ! NEW
  ! (gdb) print tgt
  ! $2 = (struct target_mem_desc *) 0xa7b690
  ! (gdb) print/x *tgt
  ! $3 = {refcount = 0x1, array = 0xb19480, tgt_start = 0x7fffcf00,
tgt_end = 0x7fffcf4c, to_free = 0x7fffcf00, prev = 0x0, list_count =
0x1, device_descr = 0x80bae0, list = 0xa7b6d0}
  ! (gdb) print/x tgt->list[0]
  ! $4 = {key = 0xb19480, copy_from = 0x0, always_copy_from = 0x0,
do_detach = 0x0, offset = 0x0, length = 0x4c}

  data_p => data

  call acc_copyin(data_p) ! h=0xb191b0, s=76
  ! NEW
  ! (gdb) print tgt
  ! $7 = (struct target_mem_desc *) 0xa7abc0
  ! (gdb) print/x *tgt
  ! $8 = {refcount = 0x1, array = 0xc21cd0, tgt_start = 0x7fffcf000200,
tgt_end = 0x7fffcf00024c, to_free = 0x7fffcf000200, prev = 0x0, list_count =
0x1, device_descr = 0x80bae0, list = 0xa7ac00}
  ! (gdb) print/x tgt->list[0]
  ! $9 = {key = 0xc21cd0, copy_from = 0x0, always_copy_from = 0x0,
do_detach = 0x0, offset = 0x0, length = 0x4c}
  ! That means, this creates a new mapping, 'acc_copyin(data_p)' does *not*
dereference 'data_p => data'.  So far, so good?  But:

  print *, acc_is_present(data_p) ! h=0xb18db0, s=76
  ! Not mapped; this neither looks up the 'acc_create(data)', nor the
'acc_copyin(data_p)'.

  !$acc enter data copyin(data_p)
  ! 0 ("to" '*data_p.data')
  !   (gdb) print n
  !   $12 = (splay_tree_prefix_splay_tree_key) 0xb19480
  ! OLD 'data' -- expected
  ! '++dynamic_refcount'
  ! 1 ("pset" 'data_p'), 2 ("pointer assign" 'data_p.data')
  !   NEW
  ! Was somewhat expecting this would look up what 'acc_copyin(data_p)'
mapped?
  !   (gdb) print tgt
  !   $4 = (struct target_mem_desc *) 0xc38000
  !   (gdb) print/x *tgt
  !   $5 = {refcount = 0x1, array = 0xc38770, tgt_start = 0x7fffcf000400,
tgt_end = 0x7fffcf000440, to_free = 0x7fffcf000400, prev = 0x0, list_count =
0x2, device_descr = 0x80bae0, list = 0xc38040}
  !   (gdb) print/x tgt->list[0]
  !   $6 = {key = 0xc38770, copy_from = 0x0, always_copy_from = 0x0,
do_detach = 0x0, offset = 0x0, length = 0x40}
  !   (gdb) print/x tgt->list[1] 
  !   $7 = {key = 0xc38770, copy_from = 0x0, always_copy_from = 0x0,
do_detach = 0x0, offset = 0x0, length = 0x0}

  print *, acc_is_present(data_p) ! h=0xb18db0, s=76
  ! Same as above; still isn't mapped.

  !$acc serial present(data_p)
  ! 0 ("force_present" '*data_p.data')
  !   (gdb) print n
  !   $14 = (splay_tree_prefix_splay_tree_key) 0xb19480
  ! OLD 'data' -- expected
  ! 1 ("pset" 'data_p'), 2 ("pointer assign" 'data_p.data')
  !   (gdb) print n
  !   $10 = (splay_tree_prefix_splay_tree_key) 0xc38770
  ! OLD "pset" 'data_p' (from 'enter data copyin(data_p)') -- expected
  data_p(5) = 55
  !$acc end serial
end program main

[Bug c++/96138] New: DR 458: Hiding of member template parameters by other members

[mpolacek at gcc dot gnu.org]

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

Bug ID: 96138
   Summary: DR 458: Hiding of member template parameters by other
members
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This test from [temp.local] should now compile:

template struct A {
  struct B { /* ... */ };
  typedef void C;
  void f();
  template void g(U);
};

template void A::f() {
  B b;  // A's B, not the template parameter
}

template template void A::g(C) {
  B b;  // A's B, not the template parameter
  C c;  // the template parameter C, not A's C
}

but it seems we choose A::C.

[Bug c++/92171] accept incorrect access of static constexpr member when read from a reference

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
I think this is another example:

template struct A {
  static constexpr int size() { return N; }
};

template void f1(T t) {
  constexpr int k = t.size();
}

template void f2(const T &t) {
  constexpr int k = t.size(); // error
}

template void f3(const T &t) {
  constexpr int k = T::size();
}

void g(A<3> a)
{
  f1(a);
  f2(a);
  f3(a);
}

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

--- Comment #3 from Haoxin Tu  ---
(In reply to Marek Polacek from comment #2)

> I would treat them just like ICEs.  They are useful if the testcase isn't
> complete garbage.  This one is sort of useful because it shows that my
> change above has a corner case that I didn't consider.

Ok, I got it. Thank you, Marek.

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-09
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
   Keywords||compile-time-hog
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Started with my:
r11-86-gef3479afc5ab415f00a53fc6f6a990df7f6a0747

(In reply to Haoxin Tu from comment #1)
> Also, I want to know are those cases (invalid code but makes GCC hang on)
> worth reporting? If those cases can help improve the GCC FE or its
> performance, I will continue to file more reports. Otherwise, I will just
> stop doing that.

I would treat them just like ICEs.  They are useful if the testcase isn't
complete garbage.  This one is sort of useful because it shows that my change
above has a corner case that I didn't consider.

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Richard Biener :
> 
> https://gcc.gnu.org/g:9ddea9306251b7d4e4fd1d67a5941ef7448b2e66
> 
> commit r11-1972-g9ddea9306251b7d4e4fd1d67a5941ef7448b2e66
> Author: Richard Biener 
> Date:   Thu Jul 9 16:06:04 2020 +0200
> 
> fixup BIT_FIELD_REF detection in SLP discovery
> 
> This fixes a thinko where we end up combining a BIT_FIELD_REF
> and a memory access, fixed by checking all stmts are a load or
> none.
> 
> 2020-07-09  Richard Biener  
> 
> PR tree-optimization/96133
> * tree-vect-slp.c (vect_build_slp_tree_1): Compare load_p
> status between stmts.

Whoops - this was for PR96134.

[Bug c++/96132] [11 Regression] ICE in is_really_empty_class

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96134] [11 Regression] ICE in tree_to_poly_uint64, at tree.c:2985 since r11-1801-g9e5508c2d006f2d4

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The master branch has been updated by Richard Biener :

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

commit r11-1972-g9ddea9306251b7d4e4fd1d67a5941ef7448b2e66
Author: Richard Biener 
Date:   Thu Jul 9 16:06:04 2020 +0200

fixup BIT_FIELD_REF detection in SLP discovery

This fixes a thinko where we end up combining a BIT_FIELD_REF
and a memory access, fixed by checking all stmts are a load or
none.

2020-07-09  Richard Biener  

PR tree-optimization/96133
* tree-vect-slp.c (vect_build_slp_tree_1): Compare load_p
status between stmts.

[Bug tree-optimization/96134] [11 Regression] ICE in tree_to_poly_uint64, at tree.c:2985 since r11-1801-g9e5508c2d006f2d4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

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

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

--- Comment #15 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you!

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

[rguenth at gcc dot gnu.org]

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

Bug 96134 Summary: [11 Regression] ICE in tree_to_poly_uint64, at tree.c:2985 
since r11-1801-g9e5508c2d006f2d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96134

   What|Removed |Added

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

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1972-g9ddea9306251b7d4e4fd1d67a5941ef7448b2e66
Author: Richard Biener 
Date:   Thu Jul 9 16:06:04 2020 +0200

fixup BIT_FIELD_REF detection in SLP discovery

This fixes a thinko where we end up combining a BIT_FIELD_REF
and a memory access, fixed by checking all stmts are a load or
none.

2020-07-09  Richard Biener  

PR tree-optimization/96133
* tree-vect-slp.c (vect_build_slp_tree_1): Compare load_p
status between stmts.

[Bug c++/95497] [11 Regression] ICE: concepts with a fully known / complete type in requires

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:614662064ad4993a2aaecf190e7399ac5279e78e

commit r11-1971-g614662064ad4993a2aaecf190e7399ac5279e78e
Author: Patrick Palka 
Date:   Thu Jul 9 13:47:13 2020 -0400

c++: Partially revert fix for PR c++/95497 [PR96132]

I was mistaken to assume that a dependent type is necessarily
incomplete, and indeed there are multiple places in the frontend where
we check a type for both dependency and completeness.  So this patch
partially reverts the fix for PR95497, restoring the dependent_type_p
check that guarded the call to is_really_empty_class below.

gcc/cp/ChangeLog:

PR c++/96132
* constexpr.c (potential_constant_expression_1) :
Restore dependent_type_p check that guarded the call to
is_really_empty_class.

gcc/testsuite/ChangeLog:

PR c++/96132
* g++.dg/template/incomplete12.C: New test.

[Bug c++/96132] [11 Regression] ICE in is_really_empty_class

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:614662064ad4993a2aaecf190e7399ac5279e78e

commit r11-1971-g614662064ad4993a2aaecf190e7399ac5279e78e
Author: Patrick Palka 
Date:   Thu Jul 9 13:47:13 2020 -0400

c++: Partially revert fix for PR c++/95497 [PR96132]

I was mistaken to assume that a dependent type is necessarily
incomplete, and indeed there are multiple places in the frontend where
we check a type for both dependency and completeness.  So this patch
partially reverts the fix for PR95497, restoring the dependent_type_p
check that guarded the call to is_really_empty_class below.

gcc/cp/ChangeLog:

PR c++/96132
* constexpr.c (potential_constant_expression_1) :
Restore dependent_type_p check that guarded the call to
is_really_empty_class.

gcc/testsuite/ChangeLog:

PR c++/96132
* g++.dg/template/incomplete12.C: New test.

[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull

[slyfox at inbox dot ru]

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

--- Comment #6 from Sergei Trofimovich  ---
(In reply to Martin Sebor from comment #4)
> The warning in the test case in comment #3 looks correct to me.

Thank you! I'll try to re-reduce and not introduce new NULLs.

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
Also, I want to know are those cases (invalid code but makes GCC hang on) worth
reporting? If those cases can help improve the GCC FE or its performance, I
will continue to file more reports. Otherwise, I will just stop doing that.

Thanks

[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|tree-optimization   |c++

--- Comment #5 from Martin Sebor  ---
It's the generic front end code where the problem manifests: adjusting
Component.

[Bug c++/96137] New: [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

Bug ID: 96137
   Summary: [11 Regression] GCC hang on in invalid function
definition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This simple code makes GCC-trunk hang on. The memory seems ok, only with
endless compiling.

$cat bug.cc
void a () { .operator b }

$g++ bug.cc
bug.cc: In function ‘void a()’:
bug.cc:1:13: error: expected primary-expression before ‘.’ token
1 | void a () { .operator b }
  | ^
...

I tested the trunk version:
GCC version 11.0.0 20200708 (experimental) (GCC) 

The GCC-10 or GCC-9 compiles this as normal. I guess this is a regression
issue?

Thanks,
Haoxin

[Bug tree-optimization/96003] [11 Regression] Maybe a false positive for -Werror=nonnull

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords|rejects-valid   |
   Last reconfirmed||2020-07-09
 Blocks||95507
Summary|Maybe a false positive for  |[11 Regression] Maybe a
   |-Werror=nonnull |false positive for
   ||-Werror=nonnull

--- Comment #4 from Martin Sebor  ---
Confirmed for the test case in comment #0.  It's a warning, not an error
(except with -Werror if requested), so removing rejects-valid.  The warning is
doing what it's designed to do.  The corresponding diagnostic is emitted prior
to r11-1697 for the following C code:

$ cat z.c && gcc -S -Wall -fdump-tree-optimized=/dev/stdout z.c
__attribute__ ((nonnull)) void f (void*);

void g (void **p)
{
  f (p ? *p : 0);
}
z.c: In function ‘g’:
z.c:5:3: warning: argument 1 null where non-null expected [-Wnonnull]
5 |   f (p ? *p : 0);
  |   ^
z.c:1:32: note: in a call to function ‘f’ declared ‘nonnull’
1 | __attribute__ ((nonnull)) void f (void*);
  |^

Unless the warning code is removed from the front end and made to rely solely
on the middle end I'm not sure what the generic front end part can do to avoid
triggering.  Perhaps the C++ front end could wrap the 'r != 0B ? &r->D.2352 :
0B' expression somehow to briefly hide it.

The warning in the test case in comment #3 looks correct to me.  The function
template

  template  void e::operator++() { d()->b(); }

is instantiated as a result of the calls to e begin() and e end()
emitted by the for (auto i : g) loop.  With d being e*, the d() expression
evaluates to a null pointer, so the call is ((e*)0)->b().


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull

[Bug middle-end/96136] New: [11 regression] ICE in reduce_to_bit_field_precision

[clyon at gcc dot gnu.org]

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

Bug ID: 96136
   Summary: [11 regression] ICE in reduce_to_bit_field_precision
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since r11-1914-g760df6d296b8fc59796f42dca5eb14012fbfa28b, I've noticed an ICE
while building glibc-2.29 when GCC is configured --target
arm-none-linux-gnueabihf  --with-cpu cortex-a15 --with-mode thumb --with-fpu
neon-vfpv4

$ arm-none-linux-gnueabihf-gcc -c -O2 iso646.i
during RTL pass: expand
In file included from iso646.c:901:
../iconv/skeleton.c: In function 'gconv':
../iconv/skeleton.c:390:1: internal compiler error: in
reduce_to_bit_field_precision, at expr.c:11530
  390 | FUNCTION_NAME (struct __gconv_step *step, struct __gconv_step_data
*data,
  | ^
0x92fdc3 reduce_to_bit_field_precision
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:11530
0x9397b9 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:9276
0x9254c0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:10152
0x92fbbe expand_expr
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.h:282
0x92fbbe expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:8065
0x939972 expand_cond_expr_using_cmove
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:8519
0x939972 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:9869
0x7ead60 expand_gimple_stmt_1
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:3787
0x7ead60 expand_gimple_stmt
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:3847
0x7f20cb expand_gimple_basic_block
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:5888
0x7f47bb execute
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:6572

[Bug c++/96105] GCC not consistent on whether no_unique_address array is an empty data member

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Other no_unique_address ABI issues: PR96052, PR95976

[Bug c++/96105] GCC not consistent on whether no_unique_address array is an empty data member

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
fixed for 10.2

[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #3)
> > Adding hash::operator()(string_view) is an interesting idea for the
> > standard though.
> 
> Indeed. If we want to, I think it is possible to add some overloads for when
> the argument is exactly const char* or string_view, which should remain
> conforming and provide a significant part of the benefits.

It would probably have to be:

  template
requires same_as>
size_t
operator()(T) const;

otherwise it can introduce ambiguities for things convertible to both string
and string_view. But that annoyance aside, it seems worth exploring.

[Bug tree-optimization/96135] New: [9/10/11 regression] bswap not detected by bswap pass, unexpected results between optimization levels

[tobi at gcc dot gnu.org]

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

Bug ID: 96135
   Summary: [9/10/11 regression] bswap not detected by bswap pass,
unexpected results between optimization levels
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobi at gcc dot gnu.org
  Target Milestone: ---

This is an odd one, and it seems different from the other bswap bugs that I
could find in bugzilla.  This is on x64.

Compiler Explorer link is here: https://godbolt.org/z/arTf5T

Full source code:
==
constexpr long long bswap64(long long in) // unsigned long long behaves the
same
{
union {
long long v;
char c[8];
} u{in};
union {
char c[8];
long long v;
} v{ u.c[7], u.c[6], u.c[5], u.c[4], u.c[3], u.c[2], u.c[1], u.c[0]};
return v.v;
}

long long f(long long i)
{
return bswap64(i);
}

constexpr long long bswapD(double x)
{
return bswap64(*(long long*)&x);
}

long long g(double x)
{
return bswapD(x);
}
===

There are three observations / bugs:
1) bswapD is never recognized as byte-swapping
2) bswap64 is optimized to bswap at -O2 but not at -O3
3) 131t.bswap never shows bswap, apparently the pass doesn't detect this way of
writing bswap, leaving it to the RTL optimizers.  Hence I classified this as
tree-optimization bug.

Verified at -O2 with 9.3, 10.1 and trunk on the compiler explorer.

I'm flagging this as a regression because at -O2 gcc 8.3 detects bswap in both
cases, but I'm guessing that this is by some accident.  In 7.5 neither function
is compiled as bswap.

[Bug tree-optimization/96134] [11 Regression] ICE in tree_to_poly_uint64, at tree.c:2985 since r11-1801-g9e5508c2d006f2d4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

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

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[cvs-commit at gcc dot gnu.org]

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

--- Comment #59 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-1970-gfab263ab0fc10ea08409b80afa7e8569438b8d28
Author: H.J. Lu 
Date:   Wed Jan 23 06:33:58 2019 -0800

x86: Enable FMA in rsqrt2 expander

Enable FMA in rsqrt2 expander and fold rsqrtv16sf2 expander into
rsqrt2 expander which expands to UNSPEC_RSQRT28 for TARGET_AVX512ER.
Although it doesn't show performance change in our workloads, FMA can
improve other workloads.

gcc/

PR target/88713
* config/i386/i386-expand.c (ix86_emit_swsqrtsf): Enable FMA.
* config/i386/sse.md (VF_AVX512VL_VF1_128_256): New.
(rsqrt2): Replace VF1_128_256 with VF_AVX512VL_VF1_128_256.
(rsqrtv16sf2): Removed.

gcc/testsuite/

PR target/88713
* gcc.target/i386/pr88713-1.c: New test.
* gcc.target/i386/pr88713-2.c: Likewise.

[Bug tree-optimization/96134] [11 Regression] ICE in tree_to_poly_uint64, at tree.c:2985 since r11-1801-g9e5508c2d006f2d4

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-09
 Ever confirmed|0   |1
 Blocks||26163

--- Comment #1 from Martin Liška  ---
Reduced from 416.gamess benchmark.


Referenced Bugs:

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

[Bug c++/95963] [11 Regression] ICE: Segmentation fault (in contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96134] New: [11 Regression] ICE in tree_to_poly_uint64, at tree.c:2985 since r11-1801-g9e5508c2d006f2d4

[marxin at gcc dot gnu.org]

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

Bug ID: 96134
   Summary: [11 Regression] ICE in tree_to_poly_uint64, at
tree.c:2985 since r11-1801-g9e5508c2d006f2d4
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

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

The following ICEs:

$ gcc -O3 x.f90 -c
...
internal compiler error: in tree_to_poly_uint64, at tree.c:2985
0x735beb tree_to_poly_uint64(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:2985
0x10cc8f5 bit_field_size(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.h:5176
0x10cc8f5 vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1337
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10ccbb6 vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1510
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
0x10cbdef vect_build_slp_tree_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1411
0x10cb3d1 vect_build_slp_tree
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:1193
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug target/95766] Failure to directly use vpbroadcastd for _mm_set1_epi32 when passing unsigned short

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Kirill, any thoughts on that?

[Bug target/95766] Failure to directly use vpbroadcastd for _mm_set1_epi32 when passing unsigned short

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 48849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48849&action=edit
gcc11-pr95766.patch

For that, we could use something like this (even though:
FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-1.c scan-assembler-times
vpbroadcastmb2q[ \\t]+[^{\n]*%k[0-7][^\n]*%zmm[0-9]+(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx512cd-vpbroadcastmw2d-1.c scan-assembler-times
vpbroadcastmw2d[ \\t]+[^{\n]*%k[0-7][^\n]*%zmm[0-9]+(?:\n|[ \\t]+#) 1
would need adjustment for that, so that we give the RA a choice.
Or use UNSPEC for the patterns, so that it matches only the intrinsics and
nothing else.

[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:38250e577e26de7aace65b4d32a94a1404f076a9

commit r10-8450-g38250e577e26de7aace65b4d32a94a1404f076a9
Author: Jonathan Wakely 
Date:   Wed May 27 22:08:15 2020 +0100

libstdc++: Fix view adaptors for mixed-const sentinels and iterators (PR
95322)

The bug report is that transform_view's sentinel cannot be
compared to its iterator.  The comparison is supposed to use
operator==(iterator, sentinel) after converting
sentinel to sentinel. However, the operator== is a hidden
friend so is not a candidate when comparing iterator with
sentinel. The required conversion would only happen if we'd found
the operator, but we can't find the operator until after the conversion
happens.

A new LWG issue has been reported, but not yet assigned a number.  The
solution suggested by Casey Carter is to make the hidden friends of the
sentinel types work with iterators of any const-ness, so that no
conversions are required.

Patrick Palka observed that join_view has a similar problem and a
similar fix is used for its sentinel.

PR libstdc++/95322
* include/std/ranges (transform_view::_Sentinel): Allow hidden
friends to work with _Iterator and _Iterator.
(join_view::_Sentinel): Likewise.
* testsuite/std/ranges/adaptors/95322.cc: New test.

(cherry picked from commit 6c2582c0406250c66e2eb3651f8e8638796b7f53)

[Bug target/96128] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Martin Liška  ---
All right, I have a feasible solution.

[Bug c++/89962] likely/unlikely attributes don't work on a compound-statement

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |10.0
 Resolution|--- |FIXED

--- Comment #2 from Jonathan Wakely  ---
The warning is gone with r275978:

Handle [[likely]] on compound-statement.

I overlooked this case when adding [[likely]] handling to
cp_parser_statement.

* parser.c (cp_parser_statement): Handle [[likely]] on
compound-statement.

So fixed.

[Bug target/96128] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Thu, 9 Jul 2020, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96128
> 
> --- Comment #2 from Martin Liška  ---
> (In reply to Richard Biener from comment #1)
> > Just trace make_ssa_name ...
> 
> So this one is leftover from gimplify.c where we expand the first argument to
> assignment to a SSA NAME and so we end up only with the vector comparisons, 
> but
> no VEC_COND_EXPR.
> Would it be possible to remove the SSA_NAME in gimplify.c when we know the
> VEC_COND_EXPR is expanded to no-op?

Somehow switch gimplifying of the operand and evaluating "expanded to 
no-op", other than that, no - the gimplifier doesn't perform DCE.

[Bug target/96128] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> Just trace make_ssa_name ...

So this one is leftover from gimplify.c where we expand the first argument to
assignment to a SSA NAME and so we end up only with the vector comparisons, but
no VEC_COND_EXPR.
Would it be possible to remove the SSA_NAME in gimplify.c when we know the
VEC_COND_EXPR is expanded to no-op?

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Interestingly it works for int[4] but fails for int[2].

typedef int T;
static const T a[2][3] = { { 1, 2, 3 }, { 4, 5, 6 } };
typedef T v2 __attribute__((vector_size(2*sizeof(T;

int
main()
{
  const T *p = &a[0][2];
  v2 x = *(const v2 *)p;
  T z = x[1];
  if (z != 4)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Value numbering stmt = vect__68.15_89 = MEM  [(double
*)vectp_xyz_sRGB.12_85];
RHS MEM  [(double *)vectp_xyz_sRGB.12_85] simplified to {
1.43080399647428694515838287770748138427734375e-1, 0.0 }
Setting value number of vect__68.15_89 to {
1.43080399647428694515838287770748138427734375e-1, 0.0 } (changed)

I guess we might be confused by the read crossing CTORs.

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
  Component|c++ |tree-optimization
   Keywords||wrong-code
   Priority|P3  |P2

[Bug c++/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Confirmed.  The i == 1 lane is different.  We're using standard interleaving
vectorization here, the innermost two loops are unrolled and rgb_cam is elided.

Note eventually we optimize the whole loop at compile-time to

   [local count: 89478486]:
  MEM  [(double *)&xyz_cam] = {
2.977897085257090884260833263397216796875e+0,
3.942117092959374139900319278240203857421875e+0 };
  MEM  [(double *)&xyz_cam + 16B] = {
4.90633710066165739553980529308319091796875e+0,
3.2918327055950977184693329036235809326171875e+0 };
  MEM  [(double *)&xyz_cam + 32B] = {
4.069328217301999832852743566036224365234375e+0,
4.84682368459998096222989261150360107421875e+0 };
  MEM  [(double *)&xyz_cam + 48B] = {
5.401563328945805752300657331943511962890625e+0,
6.22677326224005371914245188236236572265625e+0 };
  xyz_cam[2][2] = 7.051983284352143655996769717529296875e+0;

[Bug c++/96132] [11 Regression] ICE in is_really_empty_class

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|x86-64 gcc 10.1 using -O3   |[10/11 Regression] x86-64
   |leads to wrong calculation  |gcc 10.1 using -O3 leads to
   ||wrong calculation since
   ||r10-1882-g831e688af50c5f77
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-09

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-1882-g831e688af50c5f77.

[Bug target/95766] Failure to directly use vpbroadcastd for _mm_set1_epi32 when passing unsigned short

[gabravier at gmail dot com]

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

--- Comment #8 from Gabriel Ravier  ---
Well, I don't mind that the ABI may be different from LLVM, but for me the bug
was also about the fact that the code uses k registers when I'd assume they
might impact performance/code size somewhat what compared to a simple movzx
edi, di

[Bug tree-optimization/95638] [10 Regression] Legit-looking code doesn't work with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org
   Last reconfirmed||2020-07-09
  Known to fail||10.1.0
Summary|[10/11 Regression]  |[10 Regression]
   |Legit-looking code doesn't  |Legit-looking code doesn't
   |work with -O2   |work with -O2
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
  Known to work||11.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/95804] [11 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||95638
 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed - note it needs to be backported when the PR95638 fix is backported.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
[Bug 95638] [10/11 Regression] Legit-looking code doesn't work with -O2

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

[rguenth at gcc dot gnu.org]

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

Bug 95804 Summary: [11 Regression] ICE in generate_code_for_partition, at 
tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804

   What|Removed |Added

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

[Bug tree-optimization/95638] [10/11 Regression] Legit-looking code doesn't work with -O2

[rguenth at gcc dot gnu.org]

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

Bug 95804 Summary: [11 Regression] ICE in generate_code_for_partition, at 
tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804

   What|Removed |Added

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

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[rguenth at gcc dot gnu.org]

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

--- Comment #37 from Richard Biener  ---
(In reply to Martin Liška from comment #36)
> (In reply to jojo from comment #35)
> > (In reply to Martin Liška from comment #30)
> > > A possible solution can be usage of '-flinker-output=nolto-rel -r' for 
> > > huge
> > > files.
> > 
> > it's useful for splitting huge files ?
> 
> There's experiment I did:
> 
> $ time g++ -O2 /tmp/gimple-match.ii -c
> 
> real0m35.790s
> user0m35.490s
> sys0m0.268s
> 
> $ time g++ -O2 /tmp/gimple-match.ii -c -flto
> 
> real0m8.138s
> user0m7.915s
> sys0m0.202s
> 
> $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o  -r -o
> gimple-match2.o
> 
> real0m9.087s
> user1m56.028s
> sys0m3.292s
> 
> $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o  -r -o
> gimple-match2.o --param lto-partitions=8
> 
> real0m7.350s
> user0m48.548s
> sys0m0.976s
> 
> $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o  -r -o
> gimple-match2.o --param lto-partitions=4
> 
> real0m9.847s
> user0m30.462s
> sys0m0.392s
> 
> so for N==4 we get to 8+10s = 18s (compared to the original 36s). And total
> user time is 30+8, which is comparable
> to the original 36s.

The GSoC parallelism project this year is supposed to replicate this
in a cheaper way and also develop some magic to automatically trigger
it when it seems profitable.

[Bug c++/95159] ICE on aggregate template parameter with empty angle brackets

[lutztonineubert at gmail dot com]

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

--- Comment #5 from Toni Neubert  ---
I don't think this one is valid.

But the code inside the duplicated issue could be valid:

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

[Bug target/96128] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Just trace make_ssa_name ...

[Bug c++/96133] New: x86-64 gcc 10.1 using -O3 leads to wrong calculation

[heckflosse67 at gmx dot de]

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

Bug ID: 96133
   Summary: x86-64 gcc 10.1 using -O3 leads to wrong calculation
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: heckflosse67 at gmx dot de
  Target Milestone: ---

Here's a simple example which works fine in gcc up to version 9 when build
using -O3
On gcc 10 -O3, the output is different to the output of gcc 10 -O2.
The output of gcc 10 -O2 is the same as of gcc 9.3 -O3 and gcc 9.3 -O2
Using gcc 10 -O3 -fno-tree-loop-vectorize it also works fine.

```
#include 

constexpr double xyz_sRGB[3][3] = {
{0.4360747,  0.3850649, 0.1430804},
{0.2225045,  0.7168786,  0.0606169},
{0.0139322,  0.0971045,  0.7141733}
};

int main() {
double rgb_cam[3][3] = {{1.0, 2.0, 3.0}, {4.0, 5.0, 6.0}, {7.0, 8.0, 9.0}};
double xyz_cam[3][3] = {{0.0, 0.0, 0.0}, {0.0, 0.0, 0.0}, {0.0, 0.0, 0.0}};


for (int i = 0; i < 3; i++)
for (int j = 0; j < 3; j++)
for (int k = 0; k < 3; k++) {
xyz_cam[i][j] += xyz_sRGB[i][k] * rgb_cam[k][j];
}

for (int i = 0; i < 3; i++)
for (int j = 0; j < 3; j++) {
std::cout << xyz_cam[i][j] << std::endl;
} 
return 0;
}
```

[Bug c++/95159] ICE on aggregate template parameter with empty angle brackets

[lutztonineubert at gmail dot com]

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

--- Comment #4 from Toni Neubert  ---
I don't think this one is valid.

But the code inside the duplicated issue could be valid:

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

[Bug c++/96132] [11 Regression] ICE in is_really_empty_class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
   Target Milestone|--- |11.0

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
   Priority|P3  |P2

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> Created attachment 48848 [details]
> patch

statistics show it's not always a win for the overall number of processed
blocks.  stage3 of a GCC boostrap for gcc/ files shows (first number is
trunk, second is patched) counting the number of fibheap extracts:

a-conftest.c.324t.statistics 1 1
adjust-alignment.c.324t.statistics 48 47
alias.c.324t.statistics 3078 3340
alloc-pool.c.324t.statistics 46 43
asan.c.324t.statistics 3205 3022
attribs.c.324t.statistics 2093 2127
auto-inc-dec.c.324t.statistics 6 6
auto-profile.c.324t.statistics 2896 4546
bb-reorder.c.324t.statistics 3806 5965
bitmap.c.324t.statistics 2303 2276
builtins.c.324t.statistics 7263 7097
caller-save.c.324t.statistics 1076 1459
calls.c.324t.statistics 4959 6321
cc1-checksum.c.324t.statistics
cc1plus-checksum.c.324t.statistics
ccmp.c.324t.statistics 195 195
cet.c.324t.statistics 8 8
cfg.c.324t.statistics 1329 1276
cfganal.c.324t.statistics 2021 2154
cfgbuild.c.324t.statistics 880 1076
cfgcleanup.c.324t.statistics 3545 5586
cfgexpand.c.324t.statistics 8038 8337
cfghooks.c.324t.statistics 1425 1521
cfgloop.c.324t.statistics 2963 3300
cfgloopanal.c.324t.statistics 644 792
cfgloopmanip.c.324t.statistics 1961 2042
cfgrtl.c.324t.statistics 4604 5242
cgraph.c.324t.statistics 4489 4232
cgraphbuild.c.324t.statistics 377 398
cgraphclones.c.324t.statistics 1205 1173
cgraphunit.c.324t.statistics 2943 3768
collect-utils.c.324t.statistics 59 58
collect2-aix.c.324t.statistics 1 1
collect2.c.324t.statistics 766 867
combine-stack-adj.c.324t.statistics 519 760
combine.c.324t.statistics 8697 9667
compare-elim.c.324t.statistics 600 652
context.c.324t.statistics 6 6
convert.c.324t.statistics 1135 1135
coroutine-passes.cc.324t.statistics 780 908
coverage.c.324t.statistics 1328 1458
cppbuiltin.c.324t.statistics 62 62
cppdefault.c.324t.statistics 7 7
cprop.c.324t.statistics 1165 1903
cse.c.324t.statistics 5849 7881
cselib.c.324t.statistics 3037 2982
data-streamer-in.c.324t.statistics 72 63
data-streamer-out.c.324t.statistics 263 238
data-streamer.c.324t.statistics 65 71
dbgcnt.c.324t.statistics 250 320
dbxout.c.324t.statistics 2832 2652
dce.c.324t.statistics 1356 1530
ddg.c.324t.statistics 1047 1708
debug.c.324t.statistics 16 16
df-core.c.324t.statistics 1412 1534
df-problems.c.324t.statistics 3574 4339
df-scan.c.324t.statistics 3223 3431
dfp.c.324t.statistics 106 106
diagnostic-color.c.324t.statistics 120 121
diagnostic-format-json.cc.324t.statistics 93 91
diagnostic-show-locus.c.324t.statistics 1787 1759
diagnostic.c.324t.statistics 718 698
digraph.cc.324t.statistics 576 560
dojump.c.324t.statistics 1253 1144
dominance.c.324t.statistics 1447 1651
domwalk.c.324t.statistics 288 310
double-int.c.324t.statistics 535 476
driver-i386.c.324t.statistics 574 670
dse.c.324t.statistics 2719 3515
dumpfile.c.324t.statistics 1677 1693
dwarf2asm.c.324t.statistics 580 550
dwarf2cfi.c.324t.statistics 2264 2404
dwarf2out.c.324t.statistics 32574 32617
early-remat.c.324t.statistics 2373 3489
edit-context.c.324t.statistics 960 959
emit-rtl.c.324t.statistics 5075 5084
errors.c.324t.statistics 49 44
et-forest.c.324t.statistics 614 514
except.c.324t.statistics 2857 2752
explow.c.324t.statistics 778 758
expmed.c.324t.statistics 2692 2501
expr.c.324t.statistics 9552 9399
fibonacci_heap.c.324t.statistics 806 742
file-find.c.324t.statistics 75 73
file-prefix-map.c.324t.statistics 19 17
final.c.324t.statistics 2692 2895
fixed-value.c.324t.statistics 357 351
fold-const-call.c.324t.statistics 900 891
fold-const.c.324t.statistics 13221 12822
function-abi.cc.324t.statistics 202 272
function-tests.c.324t.statistics 324 324
function.c.324t.statistics 5441 5523
fwprop.c.324t.statistics 1057 1044
gcc-ar.c.324t.statistics 56 55
gcc-main.c.324t.statistics 2 2
gcc-nm.c.324t.statistics 53 52
gcc-ranlib.c.324t.statistics 53 52
gcc-rich-location.c.324t.statistics 77 73
gcc.c.324t.statistics 5953 6594
gcov-dump.c.324t.statistics 453 526
gcov-tool.c.324t.statistics 198 261
gcov.c.324t.statistics 3554 4749
gcse-common.c.324t.statistics 239 391
gcse.c.324t.statistics 2284 3321
generic-match.c.324t.statistics 47432 46970
gengtype-lex.c.324t.statistics 524 760
gengtype-parse.c.324t.statistics 597 672
gengtype-state.c.324t.statistics 2120 2317
gengtype.c.324t.statistics 2897 3544
ggc-common.c.324t.statistics 922 867
ggc-none.c.324t.statistics 11 11
ggc-page.c.324t.statistics 965 963
ggc-tests.c.324t.statistics 556 570
gimple-array-bounds.cc.324t.statistics 775 641
gimple-builder.c.324t.statistics 55 55
gimple-expr.c.324t.statistics 1067 938
gimple-fold.c.324t.statistics 6076 6045
gimple-isel.cc.324t.statistics 420 405
gimple-iterator.c.324t.statistics 447 427
gimple-laddress.c.324t.statistics 82 111
gimple-loop-interchange.cc.324t.statistics 2657 3525
gimple-loop-jam.c.324t.statistics 511 770
gimple-loop-versioning.cc.324t.statistics 1808 2744
gimple-low.c.324t.statistics 732 678
g

[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---

(In reply to Jonathan Wakely from comment #2)
> Or use unordered_map, equal_to<>> which
> should perform better.

Good idea.

> We haven't implemented http://wg21.link/p0919r3 and http://wg21.link/p1690r1
> yet, I wonder if those would help, especially if we make the internal
> helpers available pre-C++20. That could allow the range insertion to use the
> heteregenous lookup, to avoid creating temporaries. I'm not sure if that
> would be conforming though. Heterogeneous lookup is observably different,
> and not conforming in C++17.

Restricting it to a few standard types like string should not be observable.

> Adding hash::operator()(string_view) is an interesting idea for the
> standard though.

Indeed. If we want to, I think it is possible to add some overloads for when
the argument is exactly const char* or string_view, which should remain
conforming and provide a significant part of the benefits.

[Bug tree-optimization/95804] [11 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Bin Cheng :

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

commit r11-1968-gdd21b03900085c4d60bf03207ad28bcbfbc86a4b
Author: Bin Cheng 
Date:   Thu Jul 9 18:10:03 2020 +0800

Schedule reduction partition in the last.

If reduction partition's SCC is broken by runtime alias checks, force
a negative post order to it so that it will be scheduled in the last.

2020-07-09  Bin Cheng  

gcc/
PR tree-optimization/95804
* tree-loop-distribution.c (break_alias_scc_partitions): Force
negative post order to reduction partition.

gcc/testsuite/
PR tree-optimization/95804
* gcc.dg/tree-ssa/pr95804.c: New test.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

--- Comment #36 from Martin Liška  ---
(In reply to jojo from comment #35)
> (In reply to Martin Liška from comment #30)
> > A possible solution can be usage of '-flinker-output=nolto-rel -r' for huge
> > files.
> 
> it's useful for splitting huge files ?

There's experiment I did:

$ time g++ -O2 /tmp/gimple-match.ii -c

real0m35.790s
user0m35.490s
sys0m0.268s

$ time g++ -O2 /tmp/gimple-match.ii -c -flto

real0m8.138s
user0m7.915s
sys0m0.202s

$ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o  -r -o
gimple-match2.o

real0m9.087s
user1m56.028s
sys0m3.292s

$ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o  -r -o
gimple-match2.o --param lto-partitions=8

real0m7.350s
user0m48.548s
sys0m0.976s

$ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o  -r -o
gimple-match2.o --param lto-partitions=4

real0m9.847s
user0m30.462s
sys0m0.392s

so for N==4 we get to 8+10s = 18s (compared to the original 36s). And total
user time is 30+8, which is comparable
to the original 36s.

[Bug libstdc++/94936] pmr::synchronized_pool_resource crashes without -pthread

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:6b19640035d2df46758c7d31e5aab1186518e514

commit r10-8449-g6b19640035d2df46758c7d31e5aab1186518e514
Author: Jonathan Wakely 
Date:   Mon May 4 13:34:23 2020 +0100

libstdc++: Make pmr::synchronized_pool_resource work without libpthread (PR
94936)

I implicitly assumed that programs using pmr::synchronized_pool_resource
would also be using multiple threads, and so the weak symbols in
gthr-posix.h would be resolved by linking to libpthread. If that isn't
true then it crashes when trying to use pthread_key_create.

This commit makes the pool resource check __gthread_active_p() before
using thread-specific data, and just use a single set of memory pools
when there's only a single thread.

PR libstdc++/94936
* src/c++17/memory_resource.cc
(synchronized_pool_resource::_TPools):
Add comment about single-threaded behaviour.
(synchronized_pool_resource::_TPools::move_nonempty_chunks()):
Hoist
class member access out of loop.
(synchronized_pool_resource::synchronized_pool_resource())
(synchronized_pool_resource::~synchronized_pool_resource())
(synchronized_pool_resource::release()): Check __gthread_active_p
before creating and/or deleting the thread-specific data key.
(synchronized_pool_resource::_M_thread_specific_pools()): Adjust
assertions.
(synchronized_pool_resource::do_allocate(size_t, size_t)): Add fast
path for single-threaded case.
(synchronized_pool_resource::do_deallocate(void*, size_t, size_t)):
Likewise. Return if unable to find a pool that owns the allocation.
* testsuite/20_util/synchronized_pool_resource/allocate_single.cc:
New test.
* testsuite/20_util/synchronized_pool_resource/cons_single.cc: New
test.
* testsuite/20_util/synchronized_pool_resource/release_single.cc:
New
test.

(cherry picked from commit ec40967f1323069da3a5a45286f71fa4f80926df)

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #13)
> I'm testing this:
> 
> diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
> index 965247602ac..0af84a781e5 100644
> --- a/libgcc/gthr-posix.h
> +++ b/libgcc/gthr-posix.h
> @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
>  static inline __gthread_t
>  __gthread_self (void)
>  {
> +#if __GLIBC_PREREQ(2, 27)

Hmm, maybe we should just check #ifdef __GLIBC__ here, since it's available in
libc even before glibc 2.27 (it returns 0 rather than a real tid before 2.27,
but that's OK).

> +  /* See PR libstdc++/95989  */
> +  return pthread_self ();
> +#else
>return __gthrw_(pthread_self) ();
> +#endif
>  }
>  
>  static inline int
> diff --git a/libstdc++-v3/include/std/thread
> b/libstdc++-v3/include/std/thread
> index 0445ab1e319..2772dd3950e 100644
> --- a/libstdc++-v3/include/std/thread
> +++ b/libstdc++-v3/include/std/thread
> @@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  inline thread::id
>  get_id() noexcept
>  {
> -#ifdef __GLIBC__
> +#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)

And maybe we shouldn't change this check either.

If we make it depend on the glibc version then because this function is inline
a program could have two different definitions inlined if different objects
were compiled by different versions of gcc, or against different versions of
glibc. One object could inline the version returning thread::id(1) and another
could inline the version returning thread::id(__gthread_self()). This could
result in two different IDs for the main thread of a single-threaded program.
So maybe we should just stick to returning thread::id(1) for all glibc
versions.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 48848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48848&action=edit
patch

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[rjiejie at me dot com]

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

jojo  changed:

   What|Removed |Added

 CC||rjiejie at me dot com

--- Comment #35 from jojo  ---
(In reply to Martin Liška from comment #30)
> A possible solution can be usage of '-flinker-output=nolto-rel -r' for huge
> files.

it's useful for splitting huge files ?

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
As update with todays trunk 96b7f495f9269d5448822e4fc28882 I see for
not bootstrapped build of asan_interceptors.cc on x86_64 with -fno-checking:

 callgraph ipa passes   :   1.24 ( 11%)   0.11 ( 14%)   1.36 ( 11%)
 117240 kB ( 19%)
 integrated RA  :   0.47 (  4%)   0.06 (  8%)   0.35 (  3%)
  48666 kB (  8%)
 variable tracking  :   0.15 (  1%)   0.00 (  0%)   0.21 (  2%)
  14895 kB (  2%)
 var-tracking dataflow  :   1.64 ( 14%)   0.00 (  0%)   1.57 ( 13%)
158 kB (  0%)
 var-tracking emit  :   0.30 (  3%)   0.01 (  1%)   0.32 (  3%)
   9859 kB (  2%)
 TOTAL  :  11.51  0.76 12.27   
 625036 kB

so this might not be the very best example for var-tracking slowness.  I
do have a simple patch that improves it to

 variable tracking  :   0.21 (  2%)   0.00 (  0%)   0.22 (  2%)
  14895 kB (  2%)
 var-tracking dataflow  :   0.95 (  8%)   0.00 (  0%)   0.94 (  8%)
157 kB (  0%)
 var-tracking emit  :   0.31 (  3%)   0.00 (  0%)   0.37 (  3%)
   9859 kB (  2%)

though which is done by changing the vt_find_locations iteration scheme
from worklist/pending to immediately following backedges for cache locality
reasons and to avoid processing parts of the function we'd eventually have
to revisit anyway due to changed DF on the backedge destination.

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 899a5c0290d..7929b0b39eb 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -7209,22 +7209,18 @@ vt_find_locations (void)
  if (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun))
continue;

- if (bitmap_bit_p (visited, e->dest->index))
-   {
- if (!bitmap_bit_p (in_pending, e->dest->index))
-   {
- /* Send E->DEST to next round.  */
- bitmap_set_bit (in_pending, e->dest->index);
- pending->insert (bb_order[e->dest->index],
-  e->dest);
-   }
-   }
- else if (!bitmap_bit_p (in_worklist, e->dest->index))
+ if (!bitmap_bit_p (in_worklist, e->dest->index))
{
  /* Add E->DEST to current round.  */
  bitmap_set_bit (in_worklist, e->dest->index);
  worklist->insert (bb_order[e->dest->index],
e->dest);
+ /* Clear visited in case we already visited
+the block.  We're following backedges
+immediately to improve cache locality
+and avoid wasting cycles on blocks we'd
+have to re-visit eventually.  */
+ bitmap_clear_bit (visited, e->dest->index);
}
}
}


all the worklist/fibheap/visited tracking could be also simplified down
to a single worklist bitmap (not sbitmap) indexed by bb_order and
extracting elements via bitmap_first_set_bit.  But that's of course
unrelated and not part of the performance issue (the visited bitmap
can be elimiated though).

It looks like this two-worklist approach is there from the very beginning,
also the use of a fibheap.

[Bug c++/96132] [11 Regression] ICE in is_really_empty_class

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|ice in  |[11 Regression] ICE in
   |is_really_empty_class   |is_really_empty_class
   Priority|P3  |P1
   Last reconfirmed||2020-07-09
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r11-1947-g9eb7d0d76eb652caa9186766da4fe965f113b1b8.