[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Hongtao.liu  ---
(In reply to Tom de Vries from comment #12)
> (In reply to Hongtao.liu from comment #10)
> > Created attachment 49444 [details]
> > Fix invalid address for special memory constraint
> > 
> > I'm testing this patch.
> 
> Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html

Assume you are asking for when would this patch be submitted.(In reply to Tom
de Vries from comment #12)
> (In reply to Hongtao.liu from comment #10)
> > Created attachment 49444 [details]
> > Fix invalid address for special memory constraint
> > 
> > I'm testing this patch.
> 
> Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html

Related discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557143.html

[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
The patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557143.html

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

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

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

--- Comment #7 from Jim Wilson  ---
That patch is basically correct.  I would suggest using gen_lowpart instead of
gen_rtx_SUBREG as a minor cleanup.  It will do the same thing, and is shorter
and easier to read.

There is one problem here that you can't generate new pseudo registers during
register allocation, or after register allocation is complete.  So you need to
disable this optimization in this case.  You can do that by adding a check for
can_create_pseudo_p ().  This is already used explicitly in one place in
riscv_legitimize_move and implicitly in some subfunctions, and is used in the
arm.md movqi pattern.

The next part is testing the patch.  We need some correctness testing.  You can
just run the gcc testsuite for that.  And we need some code size/performance
testing.  I'd suggest compiling some code with and without the patch and check
function sizes and look for anything that got bigger with the patch, and check
to see if it is a problem.  I like to use the toolchain libraries like libc.a
and libstdc++.a since they are being built anways, but using a nice benchmark
is OK also as long as it is big enough to stress the compiler.

If the patch passes testing, then we can look at expanding the scope to handle
more modes, and also handle MEM dest in addition to REG dest.

Yes, we can discuss this Monday.

[Bug c++/97636] New: error: missing ‘PHI’ def

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97636
   Summary: error: missing ‘PHI’ def
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 49469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49469=edit
C++ source code

For the attached C++ code, with compiler flag -O3, does this:

$ /home/dcb/gcc/results/bin/gcc -c -w -O3 bug664.cc
bug664.cc: In function ‘int main()’:
bug664.cc:77:1: error: missing ‘PHI’ def
   77 | main() {
  | ^~~~
vect_b_b_6.26_26 = PHI <(8), vect_b_b_19.25_25(7)>
during GIMPLE pass: slp
bug664.cc:77:1: internal compiler error: verify_gimple failed
0xf6b14f verify_gimple_in_cfg(function*, bool)
../../trunk.git/gcc/tree-cfg.c:5461
0xe4e78c execute_function_todo(function*, void*)
../../trunk.git/gcc/passes.c:1992

The bug first seems to appear sometime between 20201027
and 20201028

[Bug libgcc/97635] binary-to-DFP conversions incorrect

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

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

--- Comment #1 from Joseph S. Myers  ---
With some analysis of the worst cases (for every possible pair of source and
target exponents) using continued fractions, it would also be possible to
determine a single precision value that is always correct for any given pair of
formats, so that computing a string to that precision will produce a correct
result and exceptions regardless of the binary and decimal rounding modes,
without any special handling of subnormals being needed.  Heuristically, that
would be roughly the precision of the decimal format that's the target of the
conversion, plus log to base 10 of the number of different values in the source
format.

[Bug libgcc/97635] New: binary-to-DFP conversions incorrect

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

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

Bug ID: 97635
   Summary: binary-to-DFP conversions incorrect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

On targets using DPD decimal floating point (tested for powerpc64le-linux-gnu,
presumably applies on s390 as well), the libgcc conversions from binary
floating point to decimal floating point, using sprintf, are not correctly
rounded.  IEEE 754 requires such conversions to be correctly rounded (using the
decimal rounding mode, not the binary rounding mode), with corresponding
exceptions (and the lowest possible decimal quantum exponent if the result is
inexact, the quantum exponent as close to 0 as possible if the result is
exact).

sprintf is used with BFP_FMT, where BFP_FMT is set to use a precision depending
on the source format.  However, that precision is the solution to a different
problem: what precision is sufficient for (to-nearest) conversion from that
binary format to decimal and back to produce the same binary value (i.e. the
precisions are the values of FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, etc.).  The
problem here isn't converting to decimal and back, it's converting correctly to
a given decimal format, where exactly one value in that format is a correct
result, and other values that round back to the same binary value are
incorrect.

For example, the test below, which fails for powerpc64le-linux-gnu, does a
conversion from float to _Decimal64.  Unsurprisingly, a 9-digit decimal value
from sprintf is not sufficient for a correctly rounded 16-digit _Decimal64
value.  Using the precision of the *target* type, not the source type, would
mostly work if sprintf is correctly rounding, except that the result needs to
be rounded according to the decimal rounding mode and sprintf for a binary
input rounds according to the binary rounding mode (and the case of "to
nearest, ties away from 0" doesn't have a corresponding binary mode, even if
you restrict attention to the IEEE decimal modes and ignore the other ones
supported on Power hardware), and also there would be problems with double
rounding and missing underflow exceptions when the result is in the subnormal
range for the decimal format (there could be problems with decimal quantum
exponents as well).

extern void abort (void);
extern void exit (int);

float f = 0.1f;

_Decimal64 d = 0.100014901161DD;
_Decimal64 dd = (_Decimal64) 0.1f;

int
main (void)
{
  /* Compile-time conversion is correct.  */
  if (dd != d)
abort ();
  /* Run-time conversion is incorrect.  */
  if ((_Decimal64) f != d)
abort ();
  exit (0);
}

[Bug c++/97479] Auto as template argument

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Resolved in GCC 11.

[Bug c++/97479] Auto as template argument

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

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

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

https://gcc.gnu.org/g:11dc4c4e137a9b48d585d7b1b146fb8404e3e1fe

commit r11-4549-g11dc4c4e137a9b48d585d7b1b146fb8404e3e1fe
Author: Marek Polacek 
Date:   Mon Oct 26 17:35:56 2020 -0400

c++: Implement CWG 625: Use of auto as template-arg [PR97479]

This patch implements CWG 625 which prohibits using auto in a template
argument.  A few tests used this construction.  Since this usage was
allowed by the Concepts TS, we only give an error in C++20.

gcc/cp/ChangeLog:

DR 625
PR c++/97479
* parser.c (cp_parser_type_id_1): Reject using auto as
a template-argument in C++20.

gcc/testsuite/ChangeLog:

DR 625
PR c++/97479
* g++.dg/cpp0x/auto3.C: Update dg-error.
* g++.dg/cpp0x/auto9.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979-2.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979-3.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979.C: Likewise.
* g++.dg/DRs/dr625.C: New test.

[Bug fortran/97589] Segementation fault when allocating coarrays.

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2020-10-29
 CC||koenigni at gcc dot gnu.org
 Ever confirmed|0   |1
 Resolution|FIXED   |---

--- Comment #2 from Thomas Koenig  ---
Correction - you were referring to a runtime error, so this is not
yet fixed.

[Bug target/97634] New: [10/11 Regression] ICE 'verify_gimple' failed on arm-linux-gnueabihf

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 97634
   Summary: [10/11 Regression] ICE 'verify_gimple' failed on
arm-linux-gnueabihf
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen building webkit2gtk with current gcc-10 branch and trunk on
arm-linux-gnueabihf:

$ cat foo.ii
class ResourceResponseBase {
  enum class Tainting { Opaque, Opaqueredirect };
  void sanitizeHTTPHeaderFieldsAccordingToTainting();
  Tainting m_tainting : 2;
};
void ResourceResponseBase::sanitizeHTTPHeaderFieldsAccordingToTainting() {
  switch (m_tainting)
  case Tainting::Opaque:
  case Tainting::Opaqueredirect:;
}

$ g++ -c -Wall -std=c++17 foo.ii
foo.ii: In member function 'void
ResourceResponseBase::sanitizeHTTPHeaderFieldsAccordingToTainting()':
foo.ii:6:6: error: type precision mismatch in switch statement
6 | void
ResourceResponseBase::sanitizeHTTPHeaderFieldsAccordingToTainting() {
  |  ^~~~
switch (_1) , case 0: , case 1: >
foo.ii:6:6: internal compiler error: 'verify_gimple' failed
0x965511 verify_gimple_in_seq(gimple*)
../../src/gcc/tree-cfg.c:5113
0x6e8acb gimplify_body(tree_node*, bool)
../../src/gcc/gimplify.c:14998
0x6e8d2b gimplify_function_tree(tree_node*)
../../src/gcc/gimplify.c:15069
0x546c1f cgraph_node::analyze()
../../src/gcc/cgraphunit.c:671
0x5493c5 analyze_functions
../../src/gcc/cgraphunit.c:1234
0x54a24f symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:2994
Please submit a full bug report,
with preprocessed source if appropriate.

configured with 

--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
--enable-checking=yes,extra,rtl
--enable-default-pie

[Bug fortran/97589] Segementation fault when allocating coarrays.

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Thomas Koenig  ---
Seems fixed by https://gcc.gnu.org/g:23856d2f29fd87edf724ade48ee30c869a3b1ea3 .

Thanks for the report!

[Bug tree-optimization/97633] New: ICE at -O3: verify_gimple failed

[su at cs dot ucdavis.edu via Gcc-bugs]

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

Bug ID: 97633
   Summary: ICE at -O3: verify_gimple failed
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201029 (experimental) [master revision
e1344fe7b6a:a1208522e1a:79991e2348a864ace6ea2bf108a7502862f1129f] (GCC) 
[509] % 
[509] % gcctk -O2 -c small.c
[510] % 
[510] % gcctk -O3 -c small.c
small.c: In function ‘g’:
small.c:11:6: error: missing ‘PHI’ def
   11 | void g () {
  |  ^
vect_j_11.9_7 = PHI <(10), _8(3)>
during GIMPLE pass: slp
small.c:11:6: internal compiler error: verify_gimple failed
0xd4c3b5 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5461
0xbfb79e execute_function_todo
../../gcc-trunk/gcc/passes.c:1992
0xbfc682 execute_todo
../../gcc-trunk/gcc/passes.c:2046
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.
[511] % 
[511] % cat small.c
extern short i (void);

struct {
  short a;
  short b;
} c;

int d, e;
static int f = 1;

void g () {
  if (e) {
if (f)
  goto L;
while (d) {
  i ();
  short j = d, k = i (), l = k;
L:
  if (!(d && e) || l)
goto L;
  c.a = j;
  c.b = k;
}
  }
}

[Bug c++/93107] unable to deduce initializer_list from function template

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed (GCC 11), thanks for the report.

[Bug c++/93107] unable to deduce initializer_list from function template

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

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

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

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

commit r11-4547-g6fb7e3c29188ab7cde0b963957caf6182536c77d
Author: Marek Polacek 
Date:   Fri Oct 16 11:00:12 2020 -0400

c++: Deducing type from initializer_list [PR93107]

In this testcase we weren't able to deduce b's type:

  template void Task() { }
  auto b = {  };

because resolve_nondeduced_context doesn't iterate on the {}'s elements.
So make sure to look into {} too.  We don't need to handle nested {}
here.

We could either tweak resolve_nondeduced_context to handle CONSTRUCTORs
or add a _ctor version, but then resolve_nondeduced_context_or_error
would need some changes too -- it'd have to check the result of a call
to r_n_c for each element.

gcc/cp/ChangeLog:

PR c++/93107
* pt.c (do_auto_deduction): Call resolve_nondeduced_context for
the elements of a { } list.

gcc/testsuite/ChangeLog:

PR c++/93107
* g++.dg/cpp0x/initlist-deduce3.C: New test.

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

fdlbxtqi  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

[Bug middle-end/89428] missing -Wstringop-overflow on a PHI with variable offset

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

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92936

--- Comment #3 from Martin Sebor  ---
See also pr92936.

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek  ---
Formatting - one space after = rather than two.
Why do you need the __gcov_test_memory variable at all?
If you want to avoid optimizing away the malloc/free pair, just make it
volatile
- char *volatile p = malloc (16); free (p); or use a memory barrier in there.
Can the function be called from multiple threads concurrently?
I guess it isn't a big deal if malloc/free pair is called in each of them once,
but perhaps it should use __atomic_load_n and __atomic_store_n for the
malloc_initialized variable?

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #17 from Martin Liška  ---
Or I may have a smarter trick: let's do dry run of malloc/free functions early
in __gcov_init. Can you please test the patch as well?

commit d80cecdb87d159f0b3a4072b6e1ef80515ad2afb
Author: Martin Liska 
Date:   Thu Oct 29 19:52:37 2020 +0100

PGO: use dry run of malloc and free functions.

diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index e53e4dc392a..dd481b48e22 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -608,12 +608,25 @@ __gcov_exit (void)
   gcov_error_exit ();
 }

+/* Test memory that forces malloc and free functions to be called early
+   so that allocate_gcov_kvp can use calloc.  Indirect call counters
+   taken from a pre-allocated array are used before that.  */
+char *__gcov_test_memory;
+
 /* Add a new object file onto the bb chain.  Invoked automatically
   when running an object file's global ctors.  */

 void
 __gcov_init (struct gcov_info *info)
 {
+  static int malloc_utilized = 0;
+  if (!malloc_utilized)
+{
+  __gcov_test_memory  = malloc (16);
+  free (__gcov_test_memory);
+  malloc_utilized = 1;
+}
+
   if (!info->version || !info->n_functions)
 return;
   if (gcov_version (info, info->version, 0))

[Bug target/97269] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427-ge94797250b403d66cb3624a594e41faf0dd76617

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug c++/97629] Difference of addresses of array elements not a constant expression

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-10-29

--- Comment #1 from Marek Polacek  ---
Confirmed.  Surprisingly, this actually worked! in GCC 5.4 and 5.5.  But I'm
unable to bisect it more.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #24 from Martin Liška  ---
(In reply to Eric Botcazou from comment #23)
> > It's a build log from OpenSUSE OBS, so it contains all that you requested.
> 
> AFAICS this log is for a native compiler:
> 
> [  131s] checking build system type... powerpc64-suse-linux-gnu
> [  131s] checking host system type... powerpc64-suse-linux-gnu
> [  131s] checking target system type... powerpc64-suse-linux-gnu
> 
> but I gather that --with-cpu=default32 somehow forces it to default to
> 32-bit, making it really powerpc-suse-linux-gnu under the hood?  Again this
> Debian-like abomination if you ask me, which probably fools the logic in
> Makefile.rtl.

@Richi, Michael: Can you please comment about what we precisely build?

[Bug lto/97508] [10 Regression] ICE: decompressed stream: Destination buffer is too small

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

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

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

https://gcc.gnu.org/g:32d16af0c4ede8d008d4360cca7c805db518166f

commit r10-8954-g32d16af0c4ede8d008d4360cca7c805db518166f
Author: Martin Liska 
Date:   Wed Oct 21 11:11:03 2020 +0200

LTO: get_section: add new argument

gcc/ChangeLog:

PR lto/97508
* langhooks.c (lhd_begin_section): Call get_section with
not_existing = true.
* output.h (get_section): Add new argument.
* varasm.c (get_section): Fail when NOT_EXISTING is true
and a section already exists.
* ipa-cp.c (ipcp_write_summary): Remove.
(ipcp_read_summary): Likewise.
* ipa-fnsummary.c (ipa_fn_summary_read): Always read jump
functions summary.
(ipa_fn_summary_write): Always stream it.

(cherry picked from commit 568de14d2e74cfdd600b8995ff6ac08c98ddef48)

[Bug lto/97508] [10 Regression] ICE: decompressed stream: Destination buffer is too small

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|10.2.0  |
  Known to work||10.2.1

--- Comment #8 from Martin Liška  ---
Fixed now.

[Bug c++/97412] [10/11 Regression] [concepts] ICE with requires requires and parameter packs

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

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

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

https://gcc.gnu.org/g:5681668765e233735b4c5e6a305e73ae1f80a328

commit r11-4544-g5681668765e233735b4c5e6a305e73ae1f80a328
Author: Patrick Palka 
Date:   Thu Oct 29 14:02:59 2020 -0400

c++: Tolerate empty initial args during normalization [PR97412]

When normalizing the constraint-expression of a nested-requirement, we
pass NULL_TREE as the initial template arguments for normalization, but
tsubst_argument_pack is not prepared to handle a NULL_TREE args vector.
This causes us to ICE when normalizing a variadic concept as part of a
nested-requirement.

This patch fixes the ICE by guarding the call to tsubst_template_args in
normalize_concept_check appropriately.  This will also enable us to
simplify many of the normalization routines to just pass NULL_TREE
(instead of a set of generic template arguments) as the initial template
arguments.

gcc/cp/ChangeLog:

PR c++/97412
* constraint.cc (normalize_concept_check): Don't call
tsubst_template_args when 'args' is NULL.

gcc/testsuite/ChangeLog:

PR c++/97412
* g++.dg/cpp2a/concepts-variadic2.C: New test.

[Bug c++/97632] unhelpful -Winit-list-lifetime warning for default-initialized object in unevaluated context

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-29

--- Comment #1 from Marek Polacek  ---
Thus:

--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2957,7 +2957,7 @@ build_new_1 (vec **placement, tree type,
tree nelts,
   return error_mark_node;
 }

-  if (is_std_init_list (elt_type))
+  if (is_std_init_list (elt_type) && !cp_unevaluated_operand)
 warning (OPT_Winit_list_lifetime,
 "% of % does not "
 "extend the lifetime of the underlying array");

[Bug c++/97632] New: unhelpful -Winit-list-lifetime warning for default-initialized object in unevaluated context

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

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

Bug ID: 97632
   Summary: unhelpful -Winit-list-lifetime warning for
default-initialized object in unevaluated context
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

// { dg-options "-std=gnu++20" }
#include 

  template
concept default_initializable =
  requires
  {
_Tp{};
(void) ::new _Tp;
  };

static_assert( default_initializable> );

GCC warns about this code:

warning: 'new' of 'initializer_list' does not extend the lifetime of the
underlying array [-Winit-list-lifetime]

I'm not sure this is very useful. Firstly, it's an unevaluated operand, so
there's no lifetime of anything here. Secondly, it's being constructed without
a new-initializer, so it's just an empty std::initializer_list, so there's no
underlying array.

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

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

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

--- Comment #4 from Jakub Jelinek  ---
No.
If it is the -Wformat-diag warning, just ignore it.  It has been added without
any attempt to resolve the warnings and warns for many things that are just
fine.

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a bug?
> Yes, it prints the opening quote, then
>   while (deref_depth-- > 0)
> pp_star (_name);
> prints some * characters and finally
>   pp_quote (_name);
> prints the closing '

Because the compiler warns about it.

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a bug?
> Yes, it prints the opening quote, then
>   while (deref_depth-- > 0)
> pp_star (_name);
> prints some * characters and finally
>   pp_quote (_name);
> prints the closing '

Shouldn't that be "\'" instead of "'"?

[Bug c++/97388] By-value function parameter changes are rolled back prior to destructor call during constant evaluation

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

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

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

https://gcc.gnu.org/g:8895443a42db4045aad8e4b42cd5dd2ad6ffa7d7

commit r11-4542-g8895443a42db4045aad8e4b42cd5dd2ad6ffa7d7
Author: Jason Merrill 
Date:   Wed Oct 28 17:30:05 2020 -0400

c++: Fix constexpr cleanup error handling.

In this testcase, the primary evaluation successfully produces 'true', and
then running one of the cleanups hits a double delete, making the whole
thing not a valid constant expression.  So we were returning 'true' wrapped
in a NOP_EXPR to indicate its non-constancy, but evaluating that again is a
perfectly acceptable constant expression, so we weren't getting the verbose
diagnostic we were looking for.

So if non_constant_p gets set other than for overflow, go back to the
original expression.

With this change, we should never hit the manifestly_const_eval test, and
the is-constant-evaluated1.C test passes without it.

gcc/cp/ChangeLog:

PR c++/97388
* constexpr.c (cxx_eval_outermost_constant_expr): Revert to
original expression if evaluation sets non_constant_p.

gcc/testsuite/ChangeLog:

PR c++/97388
* g++.dg/cpp2a/constexpr-dtor8.C: New test.

[Bug c++/97388] By-value function parameter changes are rolled back prior to destructor call during constant evaluation

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

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

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

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

commit r11-4541-g5afd90c5f36bf45291ca09ef3791f4a574e90d5d
Author: Jakub Jelinek 
Date:   Tue Oct 20 09:33:20 2020 +0200

c++: Fix constexpr dtors vs invisible ref [PR97388]

For arguments passed by invisible reference, in the IL until genericization
we have the source types on the callee side and while on the caller side
we already pass references to the actual argument slot in the caller, we
undo that in cxx_bind_parameters_in_call's
  if (TREE_ADDRESSABLE (type))
/* Undo convert_for_arg_passing work here.  */
x = convert_from_reference (x);
This works fine most of the time, except when the type also has constexpr
destructor; in that case the destructor is invoked in the caller and thus
the unsharing we do to make sure that the callee doesn't modify caller's
values is in that case undesirable, it prevents the changes done in the
callee propagating to the caller which should see them for the constexpr
dtor evaluation.

The following patch fixes that.  While it could be perhaps done for all
TREE_ADDRESSABLE types, I don't see the need to change the behavior
if there is no constexpr non-trivial dtor.

Jason: And we need to avoid memoizing the call, because a later equivalent
call also needs to modify its argument.  And we don't need to unshare
constructors when we aren't memoizing the call, because we already unshared
them when evaluating the TARGET_EXPR representing the copy-initialization
of
the argument.

2020-10-20  Jakub Jelinek  
Jason Merrill  

PR c++/97388
* constexpr.c (cxx_bind_parameters_in_call): Set non_constant_args
if the parameter type has a non-trivial destructor.
(cxx_eval_call_expression): Only unshare arguments if we're
memoizing this evaluation.

* g++.dg/cpp2a/constexpr-dtor5.C: New test.
* g++.dg/cpp2a/constexpr-dtor6.C: New test.
* g++.dg/cpp2a/constexpr-dtor7.C: New test.

[Bug c++/97566] [[no_unique_address]] causes miscompiles when mixed with EBO in constexpr context

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I particularly like that you can do this and it compiles and runs OK:

  assert(test() == 1);// works, unless optimisations enabled
  static_assert(test() == 0);


Or to make it always run OK:

#ifdef __OPTIMIZE__
  assert(test() == 0);
#else
  assert(test() == 1);
#endif
  static_assert(test() == 0);

[Bug tree-optimization/97631] [10/11 Regression] bogus "writing one too many bytes" warning for memcpy with strlen argument

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

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

--- Comment #1 from Martin Sebor  ---
While playing with the test case I added to pr97631 I noticed that when I
change the type of len to int, the warning disappears for the call to strcpy
(where it's intended) but the false positive stays for the call to memcpy. 
When I change the type to unsigned int, the warning then moves to strcpy and
disappears for memcpy.  This should get cleaned up too.

$ (set -x && cat xxx.c && gcc -DINT=int -O2 -S -Wall xxx.c && gcc
-DINT=unsigned -O2 -S -Wall xxx.c)
+ cat xxx.c
char* f (char *s)
{
  INT n = __builtin_strlen (s);
  if (n == 0)
return 0;

  char *d = __builtin_malloc (n);
  __builtin_strcpy (d, s);   // -Wstringop-overflow (good)
  return d;
}

char* g (char *s)
{
  INT n = __builtin_strlen (s);
  if (n == 0)
return 0;

  char *d = __builtin_malloc (n);
  __builtin_memcpy (d, s, n);// bogus overflow warning
  return d;
}

+ gcc -DINT=int -O2 -S -Wall xxx.c
xxx.c: In function ‘g’:
xxx.c:19:3: warning: ‘__builtin_memcpy’ writing one too many bytes into a
region of a size that depends on ‘strlen’ [-Wstringop-overflow=]
   19 |   __builtin_memcpy (d, s, n);// bogus overflow warning
  |   ^~
xxx.c:18:13: note: at offset 0 to an object with size between 1 and
18446744073709551615 allocated by ‘__builtin_malloc’ here
   18 |   char *d = __builtin_malloc (n);
  | ^~~~
+ gcc -DINT=unsigned -O2 -S -Wall xxx.c
xxx.c: In function ‘f’:
xxx.c:8:3: warning: ‘__builtin_strcpy’ writing one too many bytes into a region
of a size that depends on ‘strlen’ [-Wstringop-overflow=]
8 |   __builtin_strcpy (d, s);   // -Wstringop-overflow (good)
  |   ^~~
xxx.c:7:13: note: at offset 0 to an object with size at most 4294967295
allocated by ‘__builtin_malloc’ here
7 |   char *d = __builtin_malloc (n);
  | ^~~~

[Bug tree-optimization/97631] [10/11 Regression] bogus "writing one too many bytes" warning for memcpy with strlen argument

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||10.2.0, 11.0
   Keywords||diagnostic
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to work||9.3.0
 Blocks||88443
   Last reconfirmed||2020-10-29
Summary|bogus "writing one too many |[10/11 Regression] bogus
   |bytes" warning for memcpy   |"writing one too many
   |with strlen argument|bytes" warning for memcpy
   ||with strlen argument


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug tree-optimization/97631] New: bogus "writing one too many bytes" warning for memcpy with strlen argument

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

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

Bug ID: 97631
   Summary: bogus "writing one too many bytes" warning for memcpy
with strlen argument
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-overflow instance in f() is correct and intended but the one in
g() is neither.  It most likely crept in by mistake in r279392.  The test case
was reduced from libfido2.

$ cat xxx.c && gcc -O2 -S -Wall xxx.c
typedef __SIZE_TYPE__ size_t;

char* f (char *s)
{
  size_t n = __builtin_strlen (s);
  if (n == 0)
return 0;

  char *d = __builtin_malloc (n);
  __builtin_strcpy (d, s);   // -Wstringop-overflow (good)
  return d;
}

char* g (char *s)
{
  size_t n = __builtin_strlen (s);
  if (n == 0)
return 0;

  char *d = __builtin_malloc (n);
  __builtin_memcpy (d, s, n);// bogus overflow warning
  return d;
}

xxx.c: In function ‘f’:
xxx.c:10:3: warning: ‘__builtin_strcpy’ writing one too many bytes into a
region of a size that depends on ‘strlen’ [-Wstringop-overflow=]
   10 |   __builtin_strcpy (d, s);   // -Wstringop-overflow (good)
  |   ^~~
xxx.c:9:13: note: at offset 0 to an object allocated by ‘__builtin_malloc’ here
9 |   char *d = __builtin_malloc (n);
  | ^~~~
xxx.c: In function ‘g’:
xxx.c:21:3: warning: ‘__builtin_memcpy’ writing one too many bytes into a
region of a size that depends on ‘strlen’ [-Wstringop-overflow=]
   21 |   __builtin_memcpy (d, s, n);// bogus overflow warning
  |   ^~
xxx.c:20:13: note: at offset 0 to an object allocated by ‘__builtin_malloc’
here
   20 |   char *d = __builtin_malloc (n);
  | ^~~~

[Bug c++/95808] Can mismatch non-array new/delete with array new/delete during constant evaluation

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

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

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-29
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/97630] New: [11 Regression] SLP vectorizer leaks memory

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

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

Bug ID: 97630
   Summary: [11 Regression] SLP vectorizer leaks memory
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We currently leak all memory pointed to from SLP cycles (not the SLP nodes
themselves, but the scalar_stmts array and similar).  This is because we
manage memory by reference counting but that breaks down with cycles.

One example is gcc.dg/vect/bb-slp-57.c

[Bug c++/95808] Can mismatch non-array new/delete with array new/delete during constant evaluation

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

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

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

https://gcc.gnu.org/g:815baade9a07d361b1daa1dcfbbda2a79f3ebb52

commit r11-4538-g815baade9a07d361b1daa1dcfbbda2a79f3ebb52
Author: Jakub Jelinek 
Date:   Thu Oct 29 16:27:01 2020 +0100

c++: Diagnose constexpr delete [] new int; and delete new int[N]; [PR95808]

This patch diagnoses delete [] new int; and delete new int[1]; in constexpr
contexts by remembering
IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun)) & OVL_OP_FLAG_VEC
from the operator new and checking it at operator delete time.

2020-10-29  Jakub Jelinek  

PR c++/95808
* cp-tree.h (enum cp_tree_index): Add
CPTI_HEAP_VEC_UNINIT_IDENTIFIER
and CPTI_HEAP_VEC_IDENTIFIER.
(heap_vec_uninit_identifier, heap_vec_identifier): Define.
* decl.c (initialize_predefined_identifiers): Initialize those
identifiers.
* constexpr.c (cxx_eval_call_expression): Reject array allocations
deallocated with non-array deallocation or non-array allocations
deallocated with array deallocation.
(non_const_var_error): Handle heap_vec_uninit_identifier and
heap_vec_identifier too.
(cxx_eval_constant_expression): Handle also
heap_vec_uninit_identifier
and in that case during initialization replace it with
heap_vec_identifier.
(find_heap_var_refs): Handle heap_vec_uninit_identifier and
heap_vec_identifier too.

* g++.dg/cpp2a/constexpr-new15.C: New test.

[Bug c++/96097] ICE in dependent_type_p, at cp/pt.c:26326

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

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

--- Comment #8 from Marek Polacek  ---
Here, make_typename_type is called when tsubsting, i.e. p_t_d is 0, and it
calls dependent_scope_p with a dependent type.  We might need ++ptd/--ptd
around the call to make_typename_type.

[Bug c++/97624] ICE: in dependent_type_p, at cp/pt.c:26515

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|rejects-valid   |ice-on-valid-code
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Marek Polacek  ---
Dup.

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

[Bug c++/96097] ICE in dependent_type_p, at cp/pt.c:26326

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||eugene at hutorny dot in.ua

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

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

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

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

--- Comment #5 from Martin Sebor  ---
Right, the warning only triggers for constrained ranges (i.e., not for
VARYING).  The argument the range comes from is a PHI:

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea8105e8 precision:32 min  max
 context 
pointer_to_this >
visited var 
def_stmt num_93 = PHI 
version:93>

[Bug c++/95931] ICE in dependent_type_p, at cp/pt.c:26326

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Closing as a dup.

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

[Bug c++/96097] ICE in dependent_type_p, at cp/pt.c:26326

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

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

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

[Bug c/82272] RFE: request a warning for ( == ) etc.

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:40749db75caff2fed7b7053e0d1868feaa21bcb4

commit r11-4537-g40749db75caff2fed7b7053e0d1868feaa21bcb4
Author: Joseph Myers 
Date:   Thu Oct 29 15:05:33 2020 +

stdbool.h: Update true and false expansions for C2x

C2x has changed the expansions of the true and false macros in
 so that they have type _Bool (including in #if conditions,
i.e. an unsigned type in that context).  Use the new expansions in
GCC's  for C2x.

See bug 82272 for related discussion (but this patch does *not*
implement the warning discussed there).

Note that it's possible there may be a further change to make bool,
true and false keywords (there was support in principle for that at
the April WG14 meeting).  But currently these expansions of type _Bool
are what C2x requires and there isn't actually a paper before WG14 at
present that would introduce the new keywords.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/
2020-10-29  Joseph Myers  

* ginclude/stdbool.h [__STDC_VERSION__ > 201710L] (true, false):
Define with type _Bool.

gcc/testsuite/
2020-10-29  Joseph Myers  

* gcc.dg/c11-bool-1.c, gcc.dg/c2x-bool-1.c, gcc.dg/c99-bool-4.c:
New tests.

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|WAITING

[Bug lto/97508] [10 Regression] ICE: decompressed stream: Destination buffer is too small

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE: |[10 Regression] ICE:
   |decompressed stream:|decompressed stream:
   |Destination buffer is too   |Destination buffer is too
   |small   |small
  Known to fail|11.0|
  Known to work||11.0

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

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #16 from Martin Liška  ---
(In reply to Sergei Trofimovich from comment #15)
> allocate_gcov_kvp() gets called 89 times. Tried as:

All right, it's quite close to what we have.
So can you please test the following patch:

diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h
index 4e95c7c82ee..a899a02b765 100644
--- a/gcc/gcov-io.h
+++ b/gcc/gcov-io.h
@@ -293,7 +293,7 @@ GCOV_COUNTERS
 #define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32

 /* Number of pre-allocated gcov_kvp structures.  */
-#define GCOV_PREALLOCATED_KVP 64
+#define GCOV_PREALLOCATED_KVP 128

 /* Convert a counter index to a tag.  */
 #define GCOV_TAG_FOR_COUNTER(COUNT)\

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #15 from Sergei Trofimovich  ---
allocate_gcov_kvp() gets called 89 times. Tried as:

$ gdb --quiet --args dist/firefox/fire
fox 'data:text/html,Quitter.quit()' -profile
../../firefox-82.0/temp/tmpzhv0a26v
(gdb) break allocate_gcov_kvp
Breakpoint 1 at 0x1507b0: allocate_gcov_kvp. (4 locations)
(gdb) ignore 1 99
Will ignore next 99 crossings of breakpoint 1.
(gdb) continue
The program is not being run.
(gdb) run
^C
Thread 1 "firefox" received signal SIGINT, Interrupt.
__lll_lock_wait (futex=0x77800018, private=0) at lowlevellock.c:52
(gdb) info breakpoints
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   
breakpoint already hit 89 times
ignore next 10 hits

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

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

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

--- Comment #4 from Jakub Jelinek  ---
With the SSA_NAME_RANGE_INFO (i.e. when not using the GCC11+ ranger in the pass
or when it is done inside of the vrp passes) it matters whether there is some
SSA_NAME to stick the range to, the testcase doesn't modify the num in any way
in that if block so there is nothing to stick the [0, 9] range at.  Surprises
me it isn't just VARYING though (then the warning wouldn't trigger, right?).

[Bug other/96217] undefined reference to `_Unwind_Resume'

[legarrec.vincent at gmail dot com via Gcc-bugs]

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

--- Comment #9 from LE GARREC Vincent  ---
For the record : the bug I opened in glibc bugzilla :
https://sourceware.org/bugzilla/show_bug.cgi?id=26260

Like gcc, glibc doesn't supports -O0

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

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

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

--- Comment #3 from Martin Sebor  ---
Yes, I did mean 'if (num < 0) __builtin_unreachable ();' but as it turns out
that doesn't help in this case.  Casting to an unsigned type does and results
in the expected range [0, 9].

[Bug tree-optimization/97505] [11 Regression] ICE in extract_range_basic, at vr-values.c:1439 since r11-4130-g16e4f1ad44e3c00b8b73c9e4ade3d236ea7044a8

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #6 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/97505] [11 Regression] ICE in extract_range_basic, at vr-values.c:1439 since r11-4130-g16e4f1ad44e3c00b8b73c9e4ade3d236ea7044a8

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:054d7b9f6f6816a83dcadfdfe2532795cae04ff3

commit r11-4532-g054d7b9f6f6816a83dcadfdfe2532795cae04ff3
Author: Aldy Hernandez 
Date:   Thu Oct 22 08:39:04 2020 +0200

Selectively trap if ranger and vr-values disagree on range builtins.

The UBSAN builtins degrade into PLUS/MINUS/MULT and call
extract_range_from_binary_expr, which as the PR shows, can special
case some symbolics which the ranger doesn't currently handle.

Looking at vr_values::extract_range_builtin(), I see that every single
place where we ask for a range, we bail on non-integers (symbolics,
etc).  That is, with the exception of the UBSAN builtins.

Since this seems to be particular to UBSAN, we could still go with the
original plan of removing the duplicity in ranger vs vr-values, but
leave in the UBSAN builtin handling.  This isn't ideal, as we'd like
to remove all the common code, but I'd be willing to put up with UBSAN
duplication for the time being.

This patch disables the assert on the UBSAN builtins, while still
trapping if any other differences are found between the vr_values and
the ranger versions of builtin range handling.

As a follow-up, once Fedora can test this approach, I'll remove all
the builtin code from extract_range_builtin, with the exception of the
UBSAN stuff (renaming it to extract_range_ubsan_builtin).

Since the builtin code has proven fickle across architectures, I've
tested this with {-m32,-m64,-fsanitize=signed-integer-overflow} on
x86, ppc64le, and aarch64.  I think this should be enough.  If it
isn't, we can revert the patch, and leave the duplicate code until
the next release cycle when hopefully vr_values, evrp, and friends
will all be overhauled.

gcc/ChangeLog:

PR tree-optimization/97505
* vr-values.c (vr_values::extract_range_basic): Enable
trap again for everything except UBSAN builtins.

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
if (num < 10) __builtin_unreachable ();
certainly not, I guess you meant
if (num < 0) __builtin_unreachable ();

[Bug tree-optimization/97596] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1535 r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
sorry, yeah.
done.

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Blocks||85741
  Known to fail||10.2.0, 11.0, 9.3.0
   Last reconfirmed||2020-10-29

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 9 through 11.  The -Wformat-truncation and -Wformat-overflow
warnings rely on the range propagation engine in GCC (EVRP) to determine the
ranges of integer arguments.  The note they print shows the range they obtain
from it.  In this case the range is less than optimal.  GCC 11 adds a new range
engine (the Ranger) capable of computing more accurate ranges on demand.  The
Ranger hasn't been integrated with the strlen/sprintf pass yet but once it is,
I expect this warning to go away.  In the meantime, explicitly asserting just
before the snprintf that the argument is in the expected range avoids the
warning:

  if (num < 10) __builtin_unreachable ();
  snprintf (buf, 10, "%d", num);

as does casting the argument to an unsigned type.


Referenced Bugs:

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

[Bug tree-optimization/97596] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1535 r11-3685-gfcae5121154d1c33

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Though, we might want the testcase in the testsuite.

[Bug c++/97629] New: Difference of addresses of array elements not a constant expression

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

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

Bug ID: 97629
   Summary: Difference of addresses of array elements not a
constant expression
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

GCC rejects this valid code:

struct array
{
  int data[6];

  constexpr int* begin() { return data; }
  constexpr int* end() { return data + 6; }

  constexpr int& operator[](int n) { return data[n]; }
};


constexpr bool
test()
{
  array a{{0, 1, 2, 3, 4, 5}};

  for (auto& i : a)
if (i != ( - [0]))
  return false;
  return true;
}

static_assert(test(), "");



ce.C:23:19: error: non-constant condition for static assertion
 static_assert(test(), "");
   ^~
ce.C:23:19:   in 'constexpr' expansion of 'test()'
ce.C:18:18: error: '(int*)(& a.array::data)) + 4) - (& a.array::data[0]))
 4)' is not a constant expression
 if (i != ( - [0]))
  ^~~~

[Bug lto/97508] [10/11 Regression] ICE: decompressed stream: Destination buffer is too small

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

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

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

https://gcc.gnu.org/g:568de14d2e74cfdd600b8995ff6ac08c98ddef48

commit r11-4526-g568de14d2e74cfdd600b8995ff6ac08c98ddef48
Author: Martin Liska 
Date:   Wed Oct 21 11:11:03 2020 +0200

LTO: get_section: add new argument

gcc/ChangeLog:

PR lto/97508
* langhooks.c (lhd_begin_section): Call get_section with
not_existing = true.
* output.h (get_section): Add new argument.
* varasm.c (get_section): Fail when NOT_EXISTING is true
and a section already exists.
* ipa-cp.c (ipcp_write_summary): Remove.
(ipcp_read_summary): Likewise.
* ipa-fnsummary.c (ipa_fn_summary_read): Always read jump
functions summary.
(ipa_fn_summary_write): Always stream it.

[Bug tree-optimization/97596] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1535 r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Macleod  ---
Fixed by
commit 279a9ce9d545f65a0bb1bc4564abafabfc25f82d
Author: Jakub Jelinek 
Date:   Wed Oct 28 10:24:20 2020 +0100

wide-int: Fix up set_bit_large

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

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

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

--- Comment #4 from Martin Liška  ---
> 
> Hmm, but get_vcond_mask_icode expects the vector mode first and the
> mask mode second.  But it would be odd if that's the mistake...
> (but the patterns agree as well).
> 
> Now, the code seems to be a bit confused.  We're looking at
> 
> 
>  op0 = op0a tcode op0b;
>  lhs = op0 ? op1 : op2;
> 
> and I assume the check tries to verify we can expand both the
> compare-to-mask and the vcond_mask.  Then we need to query
> 
>   tree op0_type = TREE_TYPE (op0);
>   tree op0a_type = TREE_TYPE (op0a);
>   if (used_vec_cond_exprs >= 2
>   && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
>   != CODE_FOR_nothing)
>   && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> {
> 
> no?

Yes, the code was really bogus. I understand it now as you and there's patch
for it:

diff --git a/gcc/gimple-isel.cc b/gcc/gimple-isel.cc
index b64e31fc6fe..bba41f84ef1 100644
--- a/gcc/gimple-isel.cc
+++ b/gcc/gimple-isel.cc
@@ -158,15 +158,22 @@ gimple_expand_vec_cond_expr (gimple_stmt_iterator *gsi,
   gassign *def_stmt = dyn_cast (SSA_NAME_DEF_STMT (op0));
   if (def_stmt)
{
+ /* We process the following statements:
+op0 = op0a tcode op0b;
+lhs = op0 ? op1 : op2;
+
+where MODE is mode of the LHS.
+ */
  tcode = gimple_assign_rhs_code (def_stmt);
  op0a = gimple_assign_rhs1 (def_stmt);
  op0b = gimple_assign_rhs2 (def_stmt);

+ tree op0_type = TREE_TYPE (op0);
  tree op0a_type = TREE_TYPE (op0a);
  if (used_vec_cond_exprs >= 2
- && (get_vcond_mask_icode (mode, TYPE_MODE (op0a_type))
+ && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
  != CODE_FOR_nothing)
- && expand_vec_cmp_expr_p (op0a_type, TREE_TYPE (lhs), tcode))
+ && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
  /* Keep the SSA name and use vcond_mask.  */
  tcode = TREE_CODE (op0);


>  That would match
> 
>   if (TREE_CODE_CLASS (tcode) != tcc_comparison)
> {
>   gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0)));
>   if (get_vcond_mask_icode (mode, TYPE_MODE (TREE_TYPE (op0)))
>   != CODE_FOR_nothing)

Yes, it's expanded as a .VCOND_MASK now.

> 
> Doing that shifts the ICE elsewhere though:
> 
> during GIMPLE pass: isel
> x.c: In function 'calc_rows':
> x.c:22:1: internal compiler error: in gimple_expand_vec_cond_expr, at 
> gimple-isel.cc:204
>22 | calc_rows() {
>   | ^
> 0x17c3bd8 gimple_expand_vec_cond_expr
> /home/rguenther/src/gcc2/gcc/gimple-isel.cc:202
> 
> Now we face the situation where lhs == HImode but op0a is V16SImode
> so a VEC_COND_EXPR combining masks based on a compare.  That's
> a situation we didn't run into before the VEC_COND_EXPR splitting.

I can confirm that:

mask__258.180_254 = vect_cst__77 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
mask__581.198_1001 = VEC_COND_EXPR ;

> 
> Which means we're missing a fallback like
> 
>   if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> {
>   expand the comparison to a mask
>   turn the VEC_COND_EXPR into a mask operation,
> maskr = cmpmask ? maska : maskb;
>   becomes
> maskr = (maska & cmpmask) | (maskb & ~cmpmask);
> }
> 
> the alternative is to add vcond_mask patterns for mask value modes
> (I think vternlog can do this in one operation, there may also be
> a mask operation for this).  But that would be an enhancement
> and not require any new fallback code.
> 
> But first double-check the first point I made above.

[Bug tree-optimization/97619] error: true/false edge after a non-GIMPLE_COND in bb

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Confirmed this was the real fix.

[Bug tree-optimization/97626] [11 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10900 since r11-4428-g4a369d199bf2f34e

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

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

--- Comment #2 from Richard Biener  ---
Hmm, tricky.  vect_slp_analyze_node_operations caching breaks for SCC we enter
through different paths.  When eventually externalizing an entry to a SCC
parts of the SCC (the part optimistically considered succeeding) can end up
cached making the second visit of the SCC end prematurely as succeeding.
Which also means costing will be off in that case.

For costing I've played with the idea of sticking node cost to the node
itself.  For eliding a cycle we probably want to cache node analysis
result in the node itself (so we avoid doing the analysis multiple times)
and not have visited determine the outcome.  But then this means doing
SCC finding also for analysis.  Meh.

[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

--- Comment #5 from bin cheng  ---
(In reply to Jakub Jelinek from comment #3)
> Started with r9-4145-ga81e2c6240655f60a49c16e0d8bbfd2ba40bba51

Sorry for the breakage.  Will fix this.

[Bug tree-optimization/97628] New: format truncation false positive for O1 and mtune=nocona

[walter.gcc at wjd dot nu via Gcc-bugs]

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

Bug ID: 97628
   Summary: format truncation false positive for O1 and
mtune=nocona
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walter.gcc at wjd dot nu
  Target Milestone: ---

Created attachment 49468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49468=edit
trimmed down problem from Asterisk say.c

Per the discussion here:
https://gerrit.asterisk.org/c/asterisk/+/14501

I believe there is a bug in gcc 9 where it falsely reports:

  warning: ‘%d’ directive output may be truncated writing
between 1 and 11 bytes into a region of size 10
[-Wformat-truncation=]

See the attached example, it only triggers when:

- optimization is 1 or higher
- arch tuning is set to nocona

Example:

$ gcc -O1 -mtune=nocona -S -Wall say2.c
say2.c: In function ‘ast_say_number_full_zh’:
say2.c:37:32: warning: ‘%d’ directive output may be truncated writing between 1
and 11 bytes into a region of size 10 [-Wformat-truncation=]
   37 | snprintf(buf, 10, "%d", num);
  |^~
say2.c:37:31: note: directive argument in the range [-2147483648, 9]
...

But when omitting either -O1 or -mtune=nocona we do not get this warning.

And if you read the code, you would see that at line 37, num cannot be negative
(because it would've hit a different if-branch).

gcc version is the Ubuntu/Focal one:

$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0


Cheers,
Walter Doekes
OSSO B.V.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

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

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

--- Comment #12 from Tom de Vries  ---
(In reply to Hongtao.liu from comment #10)
> Created attachment 49444 [details]
> Fix invalid address for special memory constraint
> 
> I'm testing this patch.

Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html

[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

--- Comment #4 from Jakub Jelinek  ---
Further adjustment so that it just aborts when miscompiled.  The throw is there
only to avoid using __builtin_exit.

struct S { unsigned short x, y; } m = { 1, 0 };

__attribute__((noipa)) void
baz (int x, int y)
{
  if (x != 0 || y != 1)
__builtin_abort ();
}

__attribute__((noipa)) void
bar ()
{
  throw 1;
}

void
foo ()
{
  while (1)
{
  int a = m.x + 1;
  int b = m.y + 1;
  for (int c = 0; c < a; c++)
for (int d = 0; d < b; d++)
  baz (d, b);
  bar ();
}
}

int
main ()
{
  try
{
  foo ();
}
  catch (int)
{
}
  return 0;
}

[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r9-4145-ga81e2c6240655f60a49c16e0d8bbfd2ba40bba51

[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

--- Comment #2 from Jakub Jelinek  ---
Doesn't reproduce on the trunk since
r11-3300-g83e037364e0d6dd74d595751e8bc8c461b4cb8fa
Adjusted testcase so that it doesn't loop forever when not miscompiled and
doesn't need -fPIC either:

struct S { unsigned short x, y; } m = { 1, 0 };

__attribute__((noipa)) void
bar ()
{
  throw 1;
}

void
foo ()
{
  while (1)
{
  int a = m.x + 1;
  int b = m.y + 1;
  for (int h = 0; h < a; h++)
for (int w = 0; w < b; w++)
  __builtin_printf ("w: %d, b: %d\n", w, b);
  bar ();
}
}

int
main ()
{
  try
{
  foo ();
}
  catch (int)
{
}
  return 0;
}

[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|loop end condition missing  |[9/10/11 Regression] loop
   |- endless loop  |end condition missing -
   ||endless loop with -fPIC
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-29
  Known to fail||10.1.0, 10.2.0, 9.1.0
  Known to work||8.4.0
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |9.4

--- Comment #1 from Richard Biener  ---
Confirmed with GCC 10, triggers with -fPIC, works with plain -O2.  Odd.

[Bug tree-optimization/97626] [11 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10900 since r11-4428-g4a369d199bf2f34e

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97625] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Richard Biener  ---
Same as PR97558 (-fno-tree-dce)

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

[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f

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

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

--- Comment #4 from Richard Biener  ---
*** Bug 97625 has been marked as a duplicate of this bug. ***

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #12 from Bernd Edlinger  ---
(In reply to Bernd Edlinger from comment #11)
> (In reply to rguent...@suse.de from comment #10)
> > 
> > I failed to track down where we'd expand this to a possibly
> > unaligned mem - but is this just bogus MEM_ALIGN set?  Can we instead
> > fix that somehow?
> > 
> 
> No, this fixes the assertion in the back-end, while the first hunk
> makes the memory at least mode aligned, the MEM_ALIGN needs to
> be adjusted here, GET_MODE_ALIGNMENT (GET_MODE (x)) is a lower
> bound of the true alignment.
> 
> Also in the case of the PARM_DECLs it is possible that we take
> advantage from a MEM_ALIGN which happens to be larger than
> what's implied by TYPE_ALIGN.
> 

In case, I misunderstood the question.
set_rtl does this, but it is also called from a lot
of other places, for instance set_parm_rtl where
I did not want to change the alignment.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #10)
> On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> 
> > --- Comment #9 from Bernd Edlinger  ---
> > (In reply to rguent...@suse.de from comment #7)
> > 
> > Ah, yes, using a similar strategy as we did in r274986
> > where we aligned param_decls, I would say this
> > completely untested patch goes in the same direction:
> > 
> > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> > index f3f17d3..030d0cb 100644
> > --- a/gcc/cfgexpand.c
> > +++ b/gcc/cfgexpand.c
> > @@ -366,7 +366,18 @@ align_local_variable (tree decl, bool really_expand)
> >unsigned int align;
> > 
> >if (TREE_CODE (decl) == SSA_NAME)
> > -align = TYPE_ALIGN (TREE_TYPE (decl));
> > +{
> > +  tree type = TREE_TYPE (decl);
> > +  machine_mode mode = TYPE_MODE (type);
> > +
> > +  align = TYPE_ALIGN (type);
> > +  if (mode != BLKmode
> > + && align < GET_MODE_ALIGNMENT (mode)
> > + && ((optab_handler (movmisalign_optab, mode)
> > +  != CODE_FOR_nothing)
> > + || targetm.slow_unaligned_access (mode, align)))
> 
> I wouldn't even restrict it this way - after all if we have an
> SSA_NAME its address hasn't been exposed and thus any different
> user requested alignment isn't exposed.  Instead we can work
> to produce optimal code which means aligning according to the mode
> (that's what the RA would do when spilling the 'register').
> 

Agreed.

> Note that this would argue we could fix the types for SSA names
> upfront but there might be some complication when we have to
> adjust the underlying decl and that's a PARM_DECL.
> 

I would like to avoid changing the types to be more aligned,
just make the MEM_ALIGN larger than what the TYPE_ALIGN
requires.  Also in the case of the incoming param_decls,
the decl_rtl may reflect the true alignment of the stack,
which may be higher than required by the type.
The backend looks at the MEM_ALIGN and can in some cases
generate better code, based on the MEM_ALIGN and, it
can assert when we have a misaligned MEM_P, also based
on the value in MEM_ALIGN.

> > +   align = GET_MODE_ALIGNMENT (mode);
> > +}
> >else
> >  {
> >align = LOCAL_DECL_ALIGNMENT (decl);
> > @@ -1022,6 +1033,17 @@ expand_one_stack_var_at (tree decl, rtx base, 
> > unsigned
> > base_align,
> >  }
> > 
> >set_rtl (decl, x);
> > +
> > +  if (TREE_CODE (decl) == SSA_NAME
> > +  && GET_MODE (x) != BLKmode
> > +  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x))
> > +  && ((optab_handler (movmisalign_optab, GET_MODE (x))
> > +  != CODE_FOR_nothing)
> > + || targetm.slow_unaligned_access (GET_MODE (x), MEM_ALIGN (x
> 
> I failed to track down where we'd expand this to a possibly
> unaligned mem - but is this just bogus MEM_ALIGN set?  Can we instead
> fix that somehow?
> 

No, this fixes the assertion in the back-end, while the first hunk
makes the memory at least mode aligned, the MEM_ALIGN needs to
be adjusted here, GET_MODE_ALIGNMENT (GET_MODE (x)) is a lower
bound of the true alignment.

Also in the case of the PARM_DECLs it is possible that we take
advantage from a MEM_ALIGN which happens to be larger than
what's implied by TYPE_ALIGN.

> > +{
> > +  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <= 
> > base_align);
> > +  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
> > +}
> >  }
> > 
> >  class stack_vars_data
> > @@ -1327,13 +1349,11 @@ expand_one_stack_var_1 (tree var)
> >  {
> >tree type = TREE_TYPE (var);
> >size = tree_to_poly_uint64 (TYPE_SIZE_UNIT (type));
> > -  byte_align = TYPE_ALIGN_UNIT (type);
> >  }
> >else
> > -{
> > -  size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
> > -  byte_align = align_local_variable (var, true);
> > -}
> > +size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
> > +
> > +  byte_align = align_local_variable (var, true);
> > 
> >/* We handle highly aligned variables in expand_stack_vars.  */
> >gcc_assert (byte_align * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT);
> > 
> > 
> > > Also, when an SSA name gets a stack location, we should instead use
> > > the underlying decl for the MEM_EXPR, not the SSA name.
> > > 
> > 
> > At least the MEM_EXPRs from this test case don't do that.
> 
> Figured that.  Since we don't always have an underlying decl it's
> probably error-prone.
> 

I tried this, but it did not find anything so far:

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 3706f0a..e7e9b3d 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2196,6 +2196,7 @@ set_mem_expr (rtx mem, tree expr)
 {
   mem_attrs attrs (*get_mem_attrs (mem));
   attrs.expr = expr;
+  gcc_checking_assert (expr == NULL || TREE_CODE (expr) != SSA_NAME);
   set_mem_attrs (mem, );
 }


> > > > But isn't it possible that expand_expr_real_1
> > 

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #23 from Eric Botcazou  ---
> It's a build log from OpenSUSE OBS, so it contains all that you requested.

AFAICS this log is for a native compiler:

[  131s] checking build system type... powerpc64-suse-linux-gnu
[  131s] checking host system type... powerpc64-suse-linux-gnu
[  131s] checking target system type... powerpc64-suse-linux-gnu

but I gather that --with-cpu=default32 somehow forces it to default to 32-bit,
making it really powerpc-suse-linux-gnu under the hood?  Again this Debian-like
abomination if you ask me, which probably fools the logic in Makefile.rtl.

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
Then fixed.

[Bug c++/97627] New: loop end condition missing - endless loop

[marcin.jachu19 at gmail dot com via Gcc-bugs]

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

Bug ID: 97627
   Summary: loop end condition missing - endless loop
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.jachu19 at gmail dot com
  Target Milestone: ---

Created attachment 49467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49467=edit
cpp source file

It seems a loop end condition is missing in this example. Observed on gcc 9.x
and 10.x (all versions). 
This example may look as not much sense, but it is extracted from bigger system
to just explore the issue.

GCC version (in practice any 9.x and 10.x):
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --enable-languages=c,c++
--enable-multilib
Thread model: posix
gcc version 9.2.0 (GCC)
GNU C++17 (GCC) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8, isl version none

System type (doesn't matter, any Linux, for this example used):
centos-release-7-7.1908.0.el7.centos.x86_64

GCC compilation options:
../gcc-9.2.0/configure --enable-languages=c,c++ --enable-multilib

Test compilation options:
g++ -Wall -Wextra -fPIC -O2 -std=c++17 -o test test.cpp

Compiler output:
(none)

Source files attached, the problematic loop:

for (int h = 0; h < num_of_repeats_h; h++)
{
for (int w = 0; w < num_of_repeats_w; w++)
{
printf("w: %d, num_of_repeats_w: %d\n", w, num_of_repeats_w);
}
}

Expected behavior:
test enters to the inter loop only once, printing counter always equal 0 like:
w: 0, num_of_repeats_w: 1

Actual behavior:
the internal loop never ends, the counter reaches high numbers like:
w: 22373, num_of_repeats_w: 1

Command line
./test
Ctrl+c

More comments:
- gcc 8.x works OK on this example
- it's worth to mention, that -fwrapv option makes it working fine, but I
believe the issue just hides.
- also the -O1 option makes the difference.
- also the -fsanitize=undefined option makes the difference like:
: runtime error: execution reached an unreachable program point
but I still believe the source code is correct and the gcc causes the issue.

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #8 from Aldy Hernandez  ---
Yes.

On Thu, Oct 29, 2020, 09:47 marxin at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
>
> Martin Liška  changed:
>
>What|Removed |Added
>
> 
>  CC||marxin at gcc dot gnu.org
>
> --- Comment #7 from Martin Liška  ---
> Can it be closed as fixed?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
>

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
(In reply to Sergei Trofimovich from comment #13)
> Tried firefox-82 with LTO+PGO today on gcc-11-4428-g4a369d199bf. It gets a
> lot more forward, but still gets stuck. This time on
> free()->allocate_gcov_kvp ()->alloc() deadloc.

Hmm, that's quite unpleasant. Anyway, thanks for testing that.

> 
> The backtrace:
> 
> (gdb) bt
> #0  __lll_lock_wait (futex=0x77800018, private=0) at lowlevellock.c:52
> #1  0x77f69305 in __GI___pthread_mutex_lock (mutex=0x77800018)
> at ../nptl/pthread_mutex_lock.c:135
> #2  0x555b2151 in arena_t::MallocSmall(unsigned long, bool) ()
> #3  0x555b307c in arena_t::Malloc(unsigned long, bool) ()
> #4  0x555b41f2 in calloc ()
> #5  0x556a49ab in allocate_gcov_kvp () at
> /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/
> libgcov.h:431
> #6  gcov_topn_add_value (count=1, use_atomic=1, increment_total=1,
> value=496, counters=0x557158c0
> <__gcov3._ZL20arena_run_reg_dallocP11arena_run_tP11arena_bin_tPvm>)
> at
> /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/
> libgcov.h:477
> #7  __gcov_topn_values_profiler_body (use_atomic=1, value=496,
> counters=0x557158c0
> <__gcov3._ZL20arena_run_reg_dallocP11arena_run_tP11arena_bin_tPvm>)
> at
> /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/
> libgcov-profiler.c:103
> #8  __gcov_topn_values_profiler_atomic (counters=0x557158c0
> <__gcov3._ZL20arena_run_reg_dallocP11arena_run_tP11arena_bin_tPvm>,
> value=496)
> at
> /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/
> libgcov-profiler.c:128
> #9  0x555b1065 in arena_t::DallocSmall(arena_chunk_t*, void*,
> arena_chunk_map_t*) ()
> #10 0x555b166c in free ()
> #11 0x7fffe1b0ef1a in CollectProcessInfo(ProcessInfo&) () at
> /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/
> instrumented/dist/firefox/libxul.so
> #12 0x7fffea0afa72 in PreRecordMetaInformation() () at
> /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/
> instrumented/dist/firefox/libxul.so
> #13 0x7fffea0b28c8 in profiler_shutdown(IsFastShutdown) () at
> /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/
> instrumented/dist/firefox/libxul.so
> #14 0x7fffea7c6aa0 in XREMain::XRE_main(int, char**,
> mozilla::BootstrapConfig const&) ()
> at
> /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/
> instrumented/dist/firefox/libxul.so
> #15 0x7fffea7c7543 in XRE_main(int, char**, mozilla::BootstrapConfig
> const&) () at
> /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/
> instrumented/dist/firefox/libxul.so
> #16 0x7fffea7cfbd0 in mozilla::BootstrapImpl::XRE_main(int, char**,
> mozilla::BootstrapConfig const&) ()
> at
> /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/
> instrumented/dist/firefox/libxul.so
> #17 0x5559a370 in do_main(int, char**, char**) ()
> #18 0x555980a1 in main ()

Can you please run in gdb how many times is allocate_gcov_kvp called before
we reach the deadlock?

> 
> Worth filing a new bug, or this would be good enough?

We can stay with this PR as it contains useful discussion.

Anyway, one another fix can be usage of the suggested
__gcov_supress_malloc/__gcov_allow_malloc
that will be used in an alternative memory allocator..

[Bug tree-optimization/97626] New: [11 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10900 since r11-4428-g4a369d199bf2f34e

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

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

Bug ID: 97626
   Summary: [11 Regression] ICE in vect_transform_stmt, at
tree-vect-stmts.c:10900 since
r11-4428-g4a369d199bf2f34e
   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: ---

Reduced from gegl package:

$ cat plasma.i
struct {
  int x;
  int y;
} do_plasma_rect;

int do_plasma_context_0, do_plasma_x2, do_plasma_y2, do_plasma_plasma_depth,
do_plasma_xm, do_plasma_ym;
void gegl_buffer_set();

void do_plasma(int x1, int y1) {
  if (__builtin_expect(({
 int _g_boolean_var_;
 if (do_plasma_context_0)
   _g_boolean_var_ = 1;
 else
   _g_boolean_var_ = 0;
 _g_boolean_var_;
   }),
   0)) {
do_plasma_rect.x = x1;
do_plasma_rect.y = y1;
gegl_buffer_set();
  }
  do_plasma_xm = (x1 + do_plasma_x2) / 2;
  do_plasma_ym = (y1 + do_plasma_y2) / 2;
  if (do_plasma_plasma_depth) {
do_plasma_rect.x = do_plasma_xm;
do_plasma_rect.y = do_plasma_ym;
return;
  }
  do_plasma(do_plasma_xm, do_plasma_ym);
}

$ gcc plasma.i -c -O3
during GIMPLE pass: slp
plasma.i: In function ‘do_plasma’:
plasma.i:10:6: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:10900
   10 | void do_plasma(int x1, int y1) {
  |  ^
0x73448b vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:10900
0x104a91c vect_schedule_slp_node
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5401
0x105525d vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5602
0x1055839 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5536
0x10563b7 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5665
0x105757d vect_slp_region
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4263
0x105757d vect_slp_bbs
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4373
0x10582e4 vect_slp_function(function*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4459
0x105a196 execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1437
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97626] [11 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10900 since r11-4428-g4a369d199bf2f34e

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-29
   Target Milestone|--- |11.0
  Known to work||10.2.0
  Known to fail||11.0
 Status|UNCONFIRMED |NEW

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #22 from Martin Liška  ---
(In reply to Alexandre Oliva from comment #17)
> Created attachment 49456 [details]
> fix for riscv targets
> 
> > Still broken
> 
> Sorry, it's the first I hear of this problem on riscv.
> The fix is target-specific.  Here's one for riscv*.

I can confirm riscv* is fixed now. Thanks.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #19 from Martin Liška  ---
(In reply to Eric Botcazou from comment #16)
> > It's actually a partial cross compiler (-m32), please take a look at the
> > build log.
> 
> What's this beast exactly?  I'm afraid the build log is useless here, it
> would be better to post the configure line and the CC or CXX variables if
> any.

It's a build log from OpenSUSE OBS, so it contains all that you requested.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #21 from Martin Liška  ---
Created attachment 49466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49466=edit
Build log for ppc

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #20 from Martin Liška  ---
Created attachment 49465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49465=edit
Build log for s390x

[Bug tree-optimization/97625] New: [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f

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

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

Bug ID: 97625
   Summary: [11 Regression] ICE in
vect_slp_analyze_node_operations, at
tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
   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: ---

The following fails:

gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr58010.c -fno-tree-dce
-O3 -fno-tree-vrp -c
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr58010.c: In function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr58010.c:6:6: internal
compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.c:3559
6 | void f(void)
  |  ^
0x739727 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3559
0x1054572 vect_slp_analyze_operations(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3713
0x1035d04 vect_analyze_loop_2
/home/marxin/Programming/gcc/gcc/tree-vect-loop.c:2338
0x1035d04 vect_analyze_loop(loop*, vec_info_shared*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.c:2799
0x105c5db try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:995
0x105d099 vectorize_loops()
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97625] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
   Last reconfirmed||2020-10-29
  Known to fail||11.0
 Ever confirmed|0   |1
   Priority|P3  |P1

[Bug analyzer/97608] -Wanalyzer-malloc-leak false positive when returning p+1 instead of p

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

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

--- Comment #4 from Vincent Lefèvre  ---
Thanks. There's no longer any issue when testing GNU MPFR.

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

[Bug c++/97624] ICE: in dependent_type_p, at cp/pt.c:26515

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Keywords||rejects-valid
   Last reconfirmed||2020-10-29

--- Comment #2 from Martin Liška  ---
Confirmed, fails with -std=c++11 since at least 4.8.0.
Clang accepts the code.

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
Can it be closed as fixed?

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Why do you think it is a bug?
Yes, it prints the opening quote, then
  while (deref_depth-- > 0)
pp_star (_name);
prints some * characters and finally
  pp_quote (_name);
prints the closing '

[Bug tree-optimization/97472] [11 Regression] Another EVRP problem since r11-3685-gfcae5121154d1c33

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed with r11-4198-gca5f4666f7a9404c.

[Bug tree-optimization/97619] error: true/false edge after a non-GIMPLE_COND in bb

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Jakub Jelinek  ---
Started with r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997
Went away with r11-4482-gb626b00823af9ca9ab619fe13d1e8703a3101dab

[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

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

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

--- Comment #5 from Iain Sandoe  ---
(In reply to David Ledger from comment #4)
> @Iain Sandoe
> In terms of the standard do you think this is technically undefined
> behaviour?

no, AFAICT, it's just a regular bug in the implementation.
(it's just a question of finding resources to deal it).

[Bug tree-optimization/97619] error: true/false edge after a non-GIMPLE_COND in bb

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
   Keywords||needs-bisection
  Component|c   |tree-optimization
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Hmm, TOT doesn't reproduce but I don't know whether I actually fixed it. 
Bisection would be nice - Martin?

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> 
> --- Comment #9 from Bernd Edlinger  ---
> (In reply to rguent...@suse.de from comment #7)
> > On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> > > 
> > > --- Comment #6 from Bernd Edlinger  ---
> > > (In reply to rguent...@suse.de from comment #3)
> > > > On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > > > > --- a/gcc/emit-rtl.c
> > > > > +++ b/gcc/emit-rtl.c
> > > > > @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree 
> > > > > t, int
> > > > > objectp,
> > > > > {
> > > > >   gcc_assert (handled_component_p (t)
> > > > >   || TREE_CODE (t) == MEM_REF
> > > > > - || TREE_CODE (t) == TARGET_MEM_REF);
> > > > > + || TREE_CODE (t) == TARGET_MEM_REF
> > > > > + || TREE_CODE (t) == SSA_NAME);
> > > > 
> > > > Can you track down this?  It's a red herring to have a MEM_EXPR
> > > > that just is a SSA_NAME.
> > > > 
> > > 
> > > This happens here:
> > > 
> > >   if (MEM_P (to_rtx))
> > > {
> > >   /* If the field is at offset zero, we could have been given 
> > > the
> > >  DECL_RTX of the parent struct.  Don't munge it.  */
> > >   to_rtx = shallow_copy_rtx (to_rtx);
> > >   set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
> > >   if (volatilep)
> > > MEM_VOLATILE_P (to_rtx) = 1;
> > > }
> > > 
> > > since the patch allows the SSA_NAME to reach this block.
> > > 
> > > 
> > > > > --- a/gcc/expr.c
> > > > > +++ b/gcc/expr.c
> > > > > @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool 
> > > > > nontemporal)
> > > > >|| (TREE_CODE (to) == MEM_REF
> > > > >   && (REF_REVERSE_STORAGE_ORDER (to)
> > > > >   || mem_ref_refers_to_non_mem_p (to)))
> > > > > +  || (TREE_CODE (to) == SSA_NAME
> > > > > + && mode != BLKmode
> > > > > + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
> > > > 
> > > > But an SSA name is a register, esp. one with non-BLKmode.  And if
> > > > expanded to a stack location that stack location should better
> > > > be aligned...  or be BLKmode.  So I think the bug is elsewhere?
> > > > 
> > > 
> > > Hmm, to avoid the ICE the SSA_NAME would need a naturally
> > > aligned type, maybe replace it somehow in make_ssa_name_fn ...
> > 
> > Ah, OK - only now looked at the testcase ;)  Yes, I think for
> > registers we should ignore decl/type alignment and _always_
> > use the natural (mode) alignment.  That is,
> > 
> > static unsigned int
> > align_local_variable (tree decl, bool really_expand)
> > {
> >   unsigned int align;
> > 
> >   if (TREE_CODE (decl) == SSA_NAME)
> > align = TYPE_ALIGN (TREE_TYPE (decl));
> > 
> > should probably use GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (decl)))
> > unless it is a BLKmode var.  There's a duplicate code in
> > expand_one_stack_var_1, not sure why it special-cases SSA_NAMEs there.
> > 
> 
> Ah, yes, using a similar strategy as we did in r274986
> where we aligned param_decls, I would say this
> completely untested patch goes in the same direction:
> 
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> index f3f17d3..030d0cb 100644
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -366,7 +366,18 @@ align_local_variable (tree decl, bool really_expand)
>unsigned int align;
> 
>if (TREE_CODE (decl) == SSA_NAME)
> -align = TYPE_ALIGN (TREE_TYPE (decl));
> +{
> +  tree type = TREE_TYPE (decl);
> +  machine_mode mode = TYPE_MODE (type);
> +
> +  align = TYPE_ALIGN (type);
> +  if (mode != BLKmode
> + && align < GET_MODE_ALIGNMENT (mode)
> + && ((optab_handler (movmisalign_optab, mode)
> +  != CODE_FOR_nothing)
> + || targetm.slow_unaligned_access (mode, align)))

I wouldn't even restrict it this way - after all if we have an
SSA_NAME its address hasn't been exposed and thus any different
user requested alignment isn't exposed.  Instead we can work
to produce optimal code which means aligning according to the mode
(that's what the RA would do when spilling the 'register').

Note that this would argue we could fix the types for SSA names
upfront but there might be some complication when we have to
adjust the underlying decl and that's a PARM_DECL.

> +   align = GET_MODE_ALIGNMENT (mode);
> +}
>else
>  {
>align = LOCAL_DECL_ALIGNMENT (decl);
> @@ -1022,6 +1033,17 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned
> base_align,
>  }
> 
>set_rtl (decl, x);
> +
> +  if (TREE_CODE (decl) == SSA_NAME
> +  && GET_MODE (x) != BLKmode
> +