[Bug ipa/95336] Bad code gen omnetpp_r aarch64

[erick.oc...@theobroma-systems.com]

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

--- Comment #3 from Erick Ochoa  ---
(In reply to Erick Ochoa from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Did you try -fno-strict-aliasing?
> 
> CXX  = $(CXX_PATH) -ggdb
> TUNE_FAST= -mtune=emag -O3
> CXXOPTIMIZE  = $(TUNE_FAST) -fno-strict-aliasing
> PASS1_CFLAGS = -flto -fcommon
> PASS1_CXXFLAGS   = -flto -fcommon
> PASS1_FFLAGS = -flto -fcommon
> PASS1_LDFLAGS= -flto -fcommon -fno-strict-aliasing
> 
> I originally did not. I added it as you suggested. I added it to both the
> compiler and the linker just in case.

I forgot to mention that the problem still persists.

[Bug c++/95337] New: duplicated deprecated attribute gives incorrectly duplicated diagnostic

[nathan at gcc dot gnu.org]

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

Bug ID: 95337
   Summary: duplicated deprecated attribute gives incorrectly
duplicated diagnostic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48607=edit
yesterday, no, testcase.  That's the word

If a declaration has two (different) deprecated attributes.  We diagnose twice
(good), but use the same message both times (bad):

zathras:3>g++ -std=c++2a -c d.cc
d.cc: In function ‘void g()’:
d.cc:5:6: warning: ‘void f()’ is deprecated: dob [-Wdeprecated-declarations]
5 |   f ();
  |  ^
d.cc:1:6: note: declared here
1 | void f [[deprecated("bob")]] [[deprecated("dob")]] ();
  |  ^
d.cc:5:6: warning: ‘void f()’ is deprecated: dob [-Wdeprecated-declarations]
5 |   f ();
  |  ^
d.cc:1:6: note: declared here
1 | void f [[deprecated("bob")]] [[deprecated("dob")]] ();
  |  ^


check whether noignore has the same problem

[Bug ipa/95336] Bad code gen omnetpp_r aarch64

[erick.oc...@theobroma-systems.com]

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

--- Comment #2 from Erick Ochoa  ---
(In reply to Andrew Pinski from comment #1)
> Did you try -fno-strict-aliasing?

CXX  = $(CXX_PATH) -ggdb
TUNE_FAST= -mtune=emag -O3
CXXOPTIMIZE  = $(TUNE_FAST) -fno-strict-aliasing
PASS1_CFLAGS = -flto -fcommon
PASS1_CXXFLAGS   = -flto -fcommon
PASS1_FFLAGS = -flto -fcommon
PASS1_LDFLAGS= -flto -fcommon -fno-strict-aliasing

I originally did not. I added it as you suggested. I added it to both the
compiler and the linker just in case.

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

--- Comment #9 from Bill Seurer  ---
It looks good in a test I just ran.

[Bug middle-end/95326] GCC can not detect signed-integer-overflow correctly

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Haoxin Tu from comment #3)
> Would GCC shorten the multiple to be other types early as well? I also find
> some cases in "short" type with the same symptom. I am still testing now and
> don't know there are any cases in rest of types(such as char, int, long...)
> have the problem.

Yes and I suspect it is the same issue.  the shortening is happening in convert
before the instrumentation of the undefined sanitizer is done.

[Bug jit/95296] Segfault when trying to return a void value

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug ipa/95336] Bad code gen omnetpp_r aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Did you try -fno-strict-aliasing?

[Bug target/95285] AArch64:aarch64 medium code model proposal

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
(In reply to Bu Le from comment #0)

Also it would be much more efficient to have a relocation like this if you
wanted a 48-bit PC-relative offset:

adrpx0, bar1.2782
add x0, x0, :lo12:bar1.2782
movkx0, :high32_47:bar1.2782

[Bug jit/95296] Segfault when trying to return a void value

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-636-g6f7585deedc140667fd496b48c9fc4f7d625605c
Author: David Malcolm 
Date:   Sun May 24 18:36:36 2020 -0400

jit: check for void types [PR 95296]

PR jit/95296 reports an ICE when using libgccjit to create a local of void
type.

This patch adds checking to various API entrypoints in libgccjit.c so that
they fail gracefully with an error if the client code attempts to create
various kinds of rvalues or types involving void types.
The patch documents these and various pre-existing restrictions on types
in the API.

gcc/jit/ChangeLog:
PR jit/95296
* docs/topics/expressions.rst (Unary Operations): Document that
result_type of gcc_jit_context_new_unary_op must be a numeric type.
(Binary Operations): Likewise for gcc_jit_context_new_binary_op.
(Global variables): Document that "type" of
gcc_jit_context_new_global must be non-`void`.
* docs/topics/function-pointers.rst
(gcc_jit_context_new_function_ptr_type): Document that the
param_types must be non-void, but that return_type may be.
* docs/topics/functions.rst (Params): Document that
gcc_jit_context_new_param's type must be non-void.
(Functions): Likewise for gcc_jit_function_new_local.
* docs/topics/types.rst (gcc_jit_context_new_array_type): Document
that the type must be non-void.
(gcc_jit_context_new_field): Likewise.
* docs/_build/texinfo/Makefile: Regenerate.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* libgccjit.c (gcc_jit_context_new_array_type): Fail if
element_type is void.
(gcc_jit_context_new_field): Likewise for "type".
(gcc_jit_context_new_function_ptr_type): Likewise for each
element of param_types.
(gcc_jit_context_new_param): Likewise for "type".
(gcc_jit_context_new_global): Likewise.
(gcc_jit_function_new_local): Likewise.
(gcc_jit_type_get_aligned): Likewise.

gcc/testsuite/ChangeLog:
PR jit/95296
* jit.dg/test-error-gcc_jit_context_new_global-void-type.c: New
test.
* jit.dg/test-error-gcc_jit_function_new_local-void-type.c: New
test.
* jit.dg/test-fuzzer.c (fuzzer_init): Allow for make_random_type
to return NULL.
(get_random_type): Allow for elements in f->types to be NULL.

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546535.html

[Bug ipa/95336] New: Bad code gen omnetpp_r aarch64

[erick.oc...@theobroma-systems.com]

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

Bug ID: 95336
   Summary: Bad code gen omnetpp_r aarch64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erick.oc...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

I have been using a configuration file to compile and run CPU2017. This
configuration file worked well with gcc9, but it doesn't seem to work well with
gcc10. I am aware of the instructions outlined in "Porting to GCC 10" [0] and I
believe I have followed them. However, at least for omnetpp_r there still
seemed to be an issue. Compilation succeeded, gave several warnings (including
the following):

simulator/matchexpression.tab.cc: In function
'matchexpressionyyparse.constprop.isra':
simulator/matchexpression.tab.cc:1444:37: warning: argument 1 value
'18446744073709551615' exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
 1444 |  yymsg = (char *) YYSTACK_ALLOC (yyalloc);
  |  

and immediately segfaulted.

I used the following compiler flags:

-flto -fcommon -O3

I noticed that if I reduce the optimization level to -O2, there is no segfault.

I did a bisection from

commit f47f687a97260b1a1305cbf2d7ee3d74b2916a74
Author: Richard Biener 
Date:   Thu Apr 25 17:58:56 2019 +

to:

commit 4945b4c2c8628bdd61b348ea5bd1f9b72537a36e (HEAD)
Author: Martin Liska 
Date:   Tue May 26 09:01:41 2020 +0200

and I found that the following commit may have introduced the error:

commit ff6686d2e5f797d6c6a36ad14a7084bc1dc350e4
Author: Martin Jambor 
Date:   Fri Sep 20 00:25:04 2019 +0200

I am not sure if this is a known issue or if I'm doing something wrong. 

This is the latest GCC version that I know reproduces the error:

[eochoa@osprey1 ~]$ $HOME/code/gcc-inst/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/eochoa/code/gcc-inst/bin/gcc
COLLECT_LTO_WRAPPER=/home/eochoa/code/gcc-inst/libexec/gcc/aarch64-unknown-linux-gnu/11.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /home/eochoa/code/gcc/configure --disable-bootstrap
--disable-libsanitizer --enable-__cxa_atexit --enable-shared
--disable-libsanitizer --enable-languages=c,c++,fortran --enable-lto
--enable-gold --enable-linker-build-id --with-cpu-emag
--prefix=/home/eochoa/code/gcc-inst/
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200526 (experimental) (GCC)

[0] https://gcc.gnu.org/gcc-10/porting_to.html

[Bug target/94812] ppc incorrect mffs-based emulation of mffsl

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Alexandre Oliva  ---
Fixed

[Bug target/94812] ppc incorrect mffs-based emulation of mffsl

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Alexandre Oliva
:

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

commit r9-8625-gcd8cc299de624a764a5dcbcd7fb031a6b3e6b855
Author: Alexandre Oliva 
Date:   Tue May 26 11:28:42 2020 -0300

[rs6000] fix mffsl emulation

The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going
through the motions, but not storing the result in the given
operands[0]; it rather modifies operands[0] without effect.  It also
creates a DImode pseudo that it doesn't use, overwriting subregs
instead.

The patch below fixes all of these, the indentation and a typo.


I'm concerned about several issues in the mffsl testcase.  First, I
don't see that comparing the values as doubles rather than as long
longs is desirable.  These are FPSCR bitfields, not FP numbers.  I
understand mffs et al use double because they output to FP registers,
and the bit patterns are subnormal FP numbers, so it works, but given
the need for bit masking of at least one side, I'm changing the
compare to long longs.

Another issue with the test is that, if the compare fails, it calls
mffsl again to print the value, as if it would yield the same result.
But part of the FPSCR that mffsl (emulated with mffs or not) copies to
the output FP register is the FPCC, so the fcmpu used to compare the
result of the first mffsl will modify FPSCR and thus the result of the
second mffsl call.  After changing the compare, this is no longer the
case, but I still think it's better to make absolutely sure what we
print is what we compared.

Yet another issue is that the test assumed the mffs bits that are not
to be extracted by mffsl to be already zero, instead of masking them
out explicitly.  This is not about the mffs emulation in the mffsl
implementation, but about the mffs use in the test proper.  The bits
appear to be zero indeed, as the bits left out are for sticky
exceptions, but there are reserved parts of FPSCR that might turn out
to be set in the future, so we're better off masking them out
explicitly, otherwise those bits could cause the compare to fail.

If some future mffsl is changed so that it copies additional nonzero
bits, the test will fail, and then we'll have a chance to adjust it
and the emulation.


gcc/ChangeLog:

PR target/94812
* config/rs6000/rs6000.md (rs6000_mffsl): Copy result to
output operand in emulation.  Don't overwrite pseudos.

gcc/testsuite/ChangeLog:

PR target/94812
* gcc.target/powerpc/test_mffsl.c: Call mffsl only once.
Reinterpret the doubles as long longs for compares.  Mask out
mffs bits that are not expected from mffsl.

(cherry picked from commit 50714f45eeaf315a0b55d3db3de3bf8df8e94b04)

[Bug tree-optimization/95335] New: [11 Regression] ICE in vectorizable_scan_store at gcc/tree-vect-stmts.c:7164 since r11-615-gdc0c0196340f7ac5

[marxin at gcc dot gnu.org]

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

Bug ID: 95335
   Summary: [11 Regression] ICE in vectorizable_scan_store at
gcc/tree-vect-stmts.c:7164 since
r11-615-gdc0c0196340f7ac5
   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: ---

One more for Richi, it's reduced from blender:

$ cat math.i
float *a;
float b;
void
fn1(float p1[][3]) {
  float c, d, e, f;
  f = a[1] * a[1] * d;
  b = a[1] * a[2] * d;
  p1[1][1] = f + c;
  p1[1][2] = b + e;
}

$ gcc -Ofast math.i -c -march=znver1
during GIMPLE pass: slp
math.i: In function 'fn1':
math.i:4:1: internal compiler error: in operator[], at vec.h:867
4 | fn1(float p1[][3]) {
  | ^~~
0x75c330 vec::operator[](unsigned int)
/home/marxin/Programming/gcc/gcc/vec.h:867
0x75c330 vec::operator[](unsigned int)
/home/marxin/Programming/gcc/gcc/vec.h:1433
0x760a50 vec::operator[](unsigned int)
/home/marxin/Programming/gcc/gcc/tree.h:3419
0x760a50 vectorizable_scan_store
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:7164
0x760a50 vectorizable_store
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:7773
0x10a91fe vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:11200
0x10d0448 vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4235
0x10d9482 vect_schedule_slp(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4359
0x10dc47c vect_slp_bb_region
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3318
0x10dc47c vect_slp_bb(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3441
0x10dde2f execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1320
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/95335] [11 Regression] ICE in vectorizable_scan_store at gcc/tree-vect-stmts.c:7164 since r11-615-gdc0c0196340f7ac5

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #14 from Patrick Palka  ---
Fixed for GCC 11.

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |major
 CC||rguenth at gcc dot gnu.org

--- Comment #21 from Richard Biener  ---
This comes up repeatedly :/

[Bug target/95285] AArch64:aarch64 medium code model proposal

[wilco at gcc dot gnu.org]

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

--- Comment #4 from Wilco  ---
(In reply to Bu Le from comment #3)
> (In reply to Wilco from comment #2)
> 
> > Is the main usage scenario huge arrays? If so, these could easily be
> > allocated via malloc at startup rather than using bss. It means an extra
> > indirection in some cases (to load the pointer), but it should be much more
> > efficient than using a large code model with all the overheads.
> 
> Thanks for the reply. 
> 
> The large array is just used to construct the test case. It is not a
> neccessary condition for this scenario. The common scenario is that the
> symbol is too far away for small code model to reach it, which cloud also
> result from large amount of small arrays, structures, etc. Meanwhile, the
> large code model is able to reach the symbol but can not be position
> independent, which cause the problem. 
> 
> Besides, the code in CESM is quiet complicated to reconstruct with malloc,
> which is also not an acceptable option for my customer.
> 
> Clear enough for your concern?

Well the question is whether we're talking about more than 4GB of code or more
than 4GB of data. With >4GB code you're indeed stuck with the large model. With
data it is feasible to automatically use malloc for arrays when larger than a
certain size, so there is no need to change the application at all. Something
like that could be the default in the small model so that you don't have any
extra overhead unless you have huge arrays. Making the threshold configurable
means you can tune it for a specific application.

[Bug tree-optimization/95273] [11 regression] many ICEs after r11-564

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Most cases seem to be fixed now, gcc.dg/vect/pr33369.c was also reported as
PR95327, testing fix for that.

cc1-cross testing of quite some produce excess errors (missing target libc
headers...).  Still closing as fixed now, please re-open if any FAILs remain.

[Bug tree-optimization/95327] [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3655

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/95327] [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3655

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-634-g1d72079ba3a370d6751953312f0de76d1a1c555d
Author: Richard Biener 
Date:   Tue May 26 09:47:26 2020 +0200

tree-optimization/95327 - fix another vectorizable_shift const SLP op

This fixes another case where we fail to set the type on a SLP
constant operand in vectorizable_shift.

2020-05-26  Richard Biener  

PR tree-optimization/95327
* tree-vect-stmts.c (vectorizable_shift): Compute op1_vectype
when we are not using a scalar shift.

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

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
Attempting to work around this by using views::common like so

   auto view3 = view1 | std::views::transform([] (int i) { return i + 3;})
| std::views::common;
   /* ... */
   std::ranges::cbegin(view3) == std::ranges::end(view3);

instead results is a compilation failure in stl_iterator.h:

/home/patrick/code/gcc/libstdc++-v3/include/bits/stl_iterator.h:1772:27: error:
‘_Common_iter_proxy’ was not declared in this scope; did you mean
‘std::__detail::_Common_iter_proxy’? 1772 |  return
_Common_iter_proxy(*_M_it);
  | ~~^~~~ 
   
| std::__detail::_Common_iter_proxy
   
   
/home/patrick/code/gcc/libstdc++-v3/include/bits/stl_iterator.h:1572:13: note:
‘std::__detail::_Common_iter_proxy’ declared here

[Bug target/95285] AArch64:aarch64 medium code model proposal

[bule1 at huawei dot com]

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

--- Comment #3 from Bu Le  ---
(In reply to Wilco from comment #2)

> Is the main usage scenario huge arrays? If so, these could easily be
> allocated via malloc at startup rather than using bss. It means an extra
> indirection in some cases (to load the pointer), but it should be much more
> efficient than using a large code model with all the overheads.

Thanks for the reply. 

The large array is just used to construct the test case. It is not a neccessary
condition for this scenario. The common scenario is that the symbol is too far
away for small code model to reach it, which cloud also result from large
amount of small arrays, structures, etc. Meanwhile, the large code model is
able to reach the symbol but can not be position independent, which cause the
problem. 

Besides, the code in CESM is quiet complicated to reconstruct with malloc,
which is also not an acceptable option for my customer.

Clear enough for your concern?

[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 48606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48606=edit
gcc11-pr95328.patch

Untested fix.

[Bug middle-end/88780] [8/9/10/11 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length

[arjan.van.vught at gmail dot com]

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

Arjan van Vught  changed:

   What|Removed |Added

 CC||arjan.van.vught at gmail dot 
com

--- Comment #5 from Arjan van Vught  ---
(In reply to Pei JIA from comment #4)
> gcc 9.3 in Ubuntu 20.04, this bug comes back

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04 LTS
Release:20.04
Codename:   focal

gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This code:
strncpy(m_SourceName, pSourceName, E131_SOURCE_NAME_LENGTH - 1);
m_SourceName[E131_SOURCE_NAME_LENGTH - 1] = '\0';

gives:

g++ -DNDEBUG -D_TIME_STAMP_YEAR_=2020 -D_TIME_STAMP_MONTH_=5
-D_TIME_STAMP_DAY_=26  -I./include -I../lib-hal/include -I../lib-debug/include
-I../lib-lightset/include -I../lib-properties/include -I../lib-hal/include
-I../lib-network/include -O2 -Wall -Werror -Wextra -Wpedantic -Wunused
-Wsign-conversion  -fno-rtti -fno-exceptions -fno-unwind-tables
-Wnon-virtual-dtor -Wuseless-cast -Wold-style-cast -std=c++11 -c
src/e131bridge.cpp -o build_linux/src/e131bridge.o
In file included from /usr/include/string.h:495,
 from src/e131bridge.cpp:29:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘void E131Bridge::SetSourceName(const char*)’ at
src/e131bridge.cpp:159:9,
inlined from ‘E131Bridge::E131Bridge()’ at src/e131bridge.cpp:88:15,
inlined from ‘E131Bridge::E131Bridge()’ at src/e131bridge.cpp:51:1:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: error: ‘char*
__builtin_strncpy(char*, const char*, long unsigned int)’ output may be
truncated copying 63 bytes from a string of length 63
[-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
(__dest));
  |  ^~


Workaround:

#if (__GNUC__ > 8)
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wstringop-truncation"
#endif
strncpy(m_SourceName, pSourceName, E131_SOURCE_NAME_LENGTH - 1);
m_SourceName[E131_SOURCE_NAME_LENGTH - 1] = '\0';
#if (__GNUC__ > 8)
# pragma GCC diagnostic pop
#endif

[Bug gcov-profile/95332] gcov-tool merge："not a gcov data file"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

I support the patch, do you have a copyright agreement and can you send the
patch to the GCC patches mailing list?

One small nit I noticed:
/home/marxin/Programming/gcc/gcc/../libgcc/libgcov-util.c: In function
‘gcov_info* read_gcda_file(const char*)’:
/home/marxin/Programming/gcc/gcc/../libgcc/libgcov-util.c:264:12: warning:
unused variable ‘magic’ [-Wunused-variable]
  264 |   unsigned magic, version;
  |^

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

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Adding this to transform_view::_Sentinel fixes it:

  friend constexpr bool
  operator==(const _Iterator& __x, const _Sentinel& __y)
  requires (!_Const)
  { return _Sentinel(__y).__equal(__x); }

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

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
There's an implicit conversion from sentinel to sentinel, but that
would only happen if the operator== had been found, and since it's a hidden
friend it can't be found unless one of the operands is already sentinel.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-26
   Keywords||rejects-valid

--- Comment #1 from Jonathan Wakely  ---
I think it's a defect in the standard, the sentinel for transform_view can only
be compared to iterators of the same constness:

  friend constexpr bool
  operator==(const _Iterator<_Const>& __x, const _Sentinel& __y)
  { return __y.__equal(__x); }

I think it should work though.

[Bug target/95285] AArch64:aarch64 medium code model proposal

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
(In reply to Bu Le from comment #0)
> Created attachment 48584 [details]
> proposed patch
> 
> I would like to propose an implementation of the medium code model in
> aarch64. A prototype is attached, passed bootstrap and the regression test.
> 
> Mcmodel = medium is a missing code model in aarch64 architecture, which is
> supported in x86. This code model describes a situation that some small data
> is relocated by small code model while large data is relocated by large code
> model. The official statement about medium code model in x86 ABI file page
> 34 URL : https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf
> 
> The key difference between x86 and aarch64 is that x86 can use lea+movabs
> instruction to implement a dynamic relocatable large code model. Currently,
> large code model in AArch64 relocate the symbol using ldr instruction, which
> can only be static linked. However, the small code mode use adrp + ldr
> instruction, which can be dynamic linked. Therefore, the medium code model
> cannot be implemented directly by simply setting a threshold. As a result a
> dynamic reloadable large code model is needed first for a functional medium
> code model.
> 
> I met this problem when compiling CESM, which is a climate forecast software
> that widely used in hpc field. In some configure case, when the manipulating
> large arrays, the large code model with dynamic relocation is needed. The
> following case is abstract from CESM for this scenario.
> 
> program main
>  common/baz/a,b,c
>  real a,b,c
>  b = 1.0
>  call foo()
>  print*, b
>  end
> 
>  subroutine foo()
>  common/baz/a,b,c
>  real a,b,c
> 
>  integer, parameter :: nx = 1024
>  integer, parameter :: ny = 1024
>  integer, parameter :: nz = 1024
>  integer, parameter :: nf = 1
>  real :: bar(nf,nx*ny*nz)
>  real :: bar1(nf,nx*ny*nz)
>  bar = 0.0
>  bar1 =0.0
>  b = bar(1,1024*1024*100)
>  b = bar1(1,1)
> 
>  return
>  end
> 
> compile with -mcmodel=small -fPIC will give following error due to the
> access of bar1 array
> test.f90:(.text+0x28): relocation truncated to fit:
> R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> test.f90:(.text+0x6c): relocation truncated to fit:
> R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> 
> compile with -mcmodel=large -fPIC will give unsupported error:
> f951: sorry, unimplemented: code model ‘large’ with ‘-fPIC’
> 
> As discussed in the beginning, to tackle this problem we have to solve the
> static large code model problem. My solution here is to use
> R_AARCH64_MOVW_PREL_Gx group relocation with instructions to calculate the
> current PC value.
> 
> Before change (mcmodel=small) :
> adrpx0, bar1.2782
> add x0, x0, :lo12:bar1.2782
> 
> After change:(mcmodel = medium proposed):
> movzx0, :prel_g3:bar1.2782
> movk  x0, :prel_g2_nc:bar1.2782
> movk  x0, :prel_g1_nc:bar1.2782
> movk  x0, :prel_g0_nc:bar1.2782
> adr   x1, .
> sub   x1, x1, 0x4
> add   x0, x0, x1
> 
> The first 4 movk instruction will calculate the offset between bar1 and the
> last movk instruction in 64-bits, which fulfil the requirement of large code
> model(64-bit relocation).
> The adr+sub instruction will calculate the pc-address of the last movk
> instruction. By adding the offset with the PC address, bar1 can be
> dynamically located.
> 
> Because this relocation is time consuming, a threshold is set to classify
> the size of the data to be relocated, like x86. The default value of the
> threshold is set to 65536, which is max relocation capability of small code
> model.
> This implementation will also need to amend the linker in binutils so that
> the4 movk can calculated the same pc-offset of the last movk instruction.
> 
> The good side of this implementation is that it can use existed relocation
> type to prototype a medium code model.
> 
> The drawback of this implementation also exists. 
> For start, these 4movk instructions and the adr instruction must be combined
> in this order. No other instruction should insert in between the sequence,
> which will leads to mistake symbol address. This might impede the insn
> schedule optimizations. 
> Secondly, the linker need to make the change correspondingly so that every
> mov instruction calculate the same pc-offset. For example, in my
> implementation, the fisrt movz instruction will need to add 12 to the result
> of ":prel_g3:bar1.2782" to make up the pc-offset.   
> 
> I haven't figure out a suitable solution for these problems yet. You are
> most welcomed to leave your suggestions regarding these issues.

Is the main usage scenario huge arrays? If so, these could easily be allocated
via malloc at startup rather than using bss. It means an extra indirection in
some cases (to load 

[Bug c++/95334] GCC detect missing signed-integer-overflow when add "const"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
My guess is that G++ folds the constants early and the overflow happens at
compile time, so is never seen by UBsan.

[Bug c++/95334] New: GCC detect missing signed-integer-overflow when add "const"

[haoxintu at gmail dot com]

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

Bug ID: 95334
   Summary: GCC detect missing signed-integer-overflow when add
"const"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code test1.cc

#include 
#include 

wchar_t g_wchar = 0;
int g_int = -1975564288;
int l_int = -1227761344;

int main () {
g_wchar = l_int + g_int;
std::cout << g_wchar << std::endl;
std::cout << "WCHAR_MIN = " << WCHAR_MIN << std::endl;
std::cout << "WCHAR_MAX = " << WCHAR_MAX << std::endl;
return 0;
}

GCC can detect UB correctly

$g++ -w -fsanitize=signed-integer-overflow ; ./a.out
test1.cc:9:21: runtime error: signed integer overflow: -1227761344 +
-1975564288 cannot be represented in type 'int'
1091641664
WCHAR_MIN = -2147483648
WCHAR_MAX = 2147483647

But in this case test2.cc add "const" for int
#include 
#include 

wchar_t g_wchar = 0;
const int g_int = -1975564288;
const int l_int = -1227761344;

int main () {
g_wchar = l_int + g_int;
std::cout << g_wchar << std::endl;
std::cout << "WCHAR_MIN = " << WCHAR_MIN << std::endl;
std::cout << "WCHAR_MAX = " << WCHAR_MAX << std::endl;
return 0;
}

GCC detect nothing.

$g++ -w -fsanitize=signed-integer-overflow test2.cc; ./a.out
1091641664
WCHAR_MIN = -2147483648
WCHAR_MAX = 2147483647

My g++ version

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

I have tested them in recent GCC versions including GCC-8, GCC-9, GCC-10, they
have the same symptom as well.

I also test them in clang-trunk, above two testcases can be detected as "signed
integer overflow".

[Bug c/95329] fmaxf(inf, nan) does not always work

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

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

[Bug c/95329] fmaxf(inf, nan) does not always work

[florian at schanda dot org.uk]

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

--- Comment #3 from Florian Schanda  ---
I have created https://sourceware.org/bugzilla/show_bug.cgi?id=26045

[Bug other/95316] Offload compilation fails when not all offload compilers are installed that were configured

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
I see it as a usage regression, because suddenly a developer using the nxptx
offloading gets an error message about an unrelated offload compiler that
didn't exist before.

[Bug middle-end/95326] GCC can not detect signed-integer-overflow correctly

[haoxintu at gmail dot com]

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

--- Comment #3 from Haoxin Tu  ---
Would GCC shorten the multiple to be other types early as well? I also find
some cases in "short" type with the same symptom. I am still testing now and
don't know there are any cases in rest of types(such as char, int, long...)
have the problem.

By the way, should I file a new bug report when I found another type (for
example,int) that GCC can not detect the signed-integer-overflow UB issues?

[Bug c/95329] fmaxf(inf, nan) does not always work

[florian at schanda dot org.uk]

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

--- Comment #2 from Florian Schanda  ---
Cool, thanks for the pointer to their bug tracker. I'll bother them instead ;)

[Bug bootstrap/95333] New: [11 Regression] error: number of counters in profile data for function ‘exp_attr__find_stream_subprogram’ does not match its profile data (counter ‘arcs’, expected 230 and h

[marxin at gcc dot gnu.org]

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

Bug ID: 95333
   Summary: [11 Regression] error: number of counters in profile
data for function ‘exp_attr__find_stream_subprogram’
does not match its profile data (counter ‘arcs’,
expected 230 and have 210) [-Werror=coverage-mismatch]
since r11-200-gdb4062a0cbe00ce4075a4d7f68a2ff
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

Since the revision I see bootstrap failure:

$ ../configure --enable-languages=c,c++,lto,ada --disable-multilib
--disable-libsanitizer --disable-werror --with-build-config=bootstrap-lto-lean
&& time make -j128 STAGE1_CFLAGS="-O2 -g" profiledbootstrap

...
cp doc/gcc.1 doc/g++.1
../../gcc/ada/libgnat/s-rident.ads: In function
‘exp_attr__find_stream_subprogram’:
../../gcc/ada/exp_attr.adb:7930:4: error: number of counters in profile data
for function ‘exp_attr__find_stream_subprogram’ does not match its profile data
(counter ‘arcs’, expected 230 and have 210) [-Werror=coverage-mismatch]
../../gcc/ada/exp_attr.adb:7930:4: error: the control flow of function
‘exp_attr__find_stream_subprogram’ does not match its profile data (counter
‘time_profiler’) [-Werror=coverage-mismatch]
gnat1: some warnings being treated as errors
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:138: ada/exp_attr.o]
Error 1
make[3]: *** Waiting for unfinished jobs
../../gcc/ada/libgnat/s-rident.ads: In function ‘exp_ch3__stream_operation_ok’:
../../gcc/ada/exp_ch3.adb:10727:4: error: number of counters in profile data
for function ‘exp_ch3__stream_operation_ok’ does not match its profile data
(counter ‘arcs’, expected 66 and have 65) [-Werror=coverage-mismatch]
../../gcc/ada/exp_ch3.adb:10727:4: error: the control flow of function
‘exp_ch3__stream_operation_ok’ does not match its profile data (counter
‘time_profiler’) [-Werror=coverage-mismatch]
../../gcc/ada/libgnat/s-rident.ads: In function ‘exp_ch3__predef_deep_spec’:
../../gcc/ada/exp_ch3.adb:10254:4: error: number of counters in profile data
for function ‘exp_ch3__predef_deep_spec’ does not match its profile data
(counter ‘arcs’, expected 28 and have 27) [-Werror=coverage-mismatch]
../../gcc/ada/exp_ch3.adb:10254:4: error: the control flow of function
‘exp_ch3__predef_deep_spec’ does not match its profile data (counter
‘time_profiler’) [-Werror=coverage-mismatch]
gnat1: some warnings being treated as errors
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:138: ada/exp_ch3.o]
Error 1
../../gcc/ada/libgnat/s-rident.ads: In function
‘sem_attr__analyze_attribute__check_stream_attribute.79’:
../../gcc/ada/sem_attr.adb:2330:7: error: number of counters in profile data
for function ‘sem_attr__analyze_attribute__check_stream_attribute.79’ does not
match its profile data (counter ‘arcs’, expected 74 and have 73)
[-Werror=coverage-mismatch]
../../gcc/ada/sem_attr.adb:2330:7: error: the control flow of function
‘sem_attr__analyze_attribute__check_stream_attribute.79’ does not match its
profile data (counter ‘time_profiler’) [-Werror=coverage-mismatch]
gnat1: some warnings being treated as errors
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:140: ada/sem_attr.o]
Error 1
rm gcov.pod fsf-funding.pod lto-dump.pod gfdl.pod gpl.pod cpp.pod gcc.pod
gcov-dump.pod gcov-tool.pod
make[3]: Leaving directory '/home/mliska/Programming/gcc/objdir/gcc'
make[2]: *** [Makefile:4988: all-stagefeedback-gcc] Error 2
make[2]: Leaving directory '/home/mliska/Programming/gcc/objdir'
make[1]: *** [Makefile:24692: stagefeedback-bubble] Error 2
make[1]: Leaving directory '/home/mliska/Programming/gcc/objdir'
make: *** [Makefile:24712: profiledbootstrap] Error 2

[Bug gcov-profile/95332] New: gcov-tool merge："not a gcov data file"

[dongjianqiang2 at huawei dot com]

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

Bug ID: 95332
   Summary: gcov-tool merge："not a gcov data file"
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dongjianqiang2 at huawei dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48605=edit
a patch for gcov-tool.

when I invoke gcov-tool merge dir1 dir2 where dir1 and dir2 are the directories
containing the .gcda files which I intend to combine, I am confronted with
"./test.gcda:not a gcov data file" errors for each file in dir1. After studying
the libgcov code, I have figured out it's an endianness issue. I'm using a
cross compiler --build=x86_64-suse-linux --host=x86_64-suse-linux
--target=aarch64_be-linux-gnu, gcov-tool cannot merge the coverage data
generated by big endian machine. here is patch to fix it. pls review.

[Bug c/95329] fmaxf(inf, nan) does not always work

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I believe this is a glibc bug rather than gcc.  This is without optimizations
and the library function in libm is called in both cases and giving different
results based on whether it is -inf, nan(0x2cba7e) or -inf, nan(0x40).
glibc has a different bug tracker though, so you need to file it there
(sourceware.org/bugzilla).
If you compile with -O2, you'll get -inf in both cases (in that case no library
call is done and it is folded by gcc).

[Bug fortran/95331] Unlimited polymorphic arrays have wrong bounds

[jrfsousa at gmail dot com]

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

--- Comment #1 from José Rui Faustino de Sousa  ---
Created attachment 48604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48604=edit
Fortran code demonstrating problems.

Somehow the testcase was left behind...

[Bug fortran/95331] New: Unlimited polymorphic arrays have wrong bounds

[jrfsousa at gmail dot com]

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

Bug ID: 95331
   Summary: Unlimited polymorphic arrays have wrong bounds
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Hi All!

Unlimited polymorphic (class(*)) arrays have wrong bounds.

Tested with:

GNU Fortran (GCC) 9.3.1 20200518
GNU Fortran (GCC) 10.1.1 20200518
GNU Fortran (GCC) 11.0.0 20200518 (experimental)

Thank you very much.

Best regards,
José Rui

[Bug middle-end/95315] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-382-g7a50e7087567cffb

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 48603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48603=edit
gcc11-pr95315.patch

Untested fix.

[Bug c++/95330] Unneeded -Wmissing-braces warning when initialising std::array

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
(In reply to Szőts Ákos from comment #0)
> According to cppreference.com [1] it's not necessary to use the second level
> of braces since CWG 1270 [2] from C++11 on.

CWG 1270 is not relevant here (you have misinterpreted what cppreference says).
As the DR says, brace elision before DR 1270 only applied in declarations of
the form T x = { a }, which is exactly the form you're using. So your code was
always valid, and was always accepted by GCC long before DR 1270.

So DR 1270 changes where brace elision is allowed, but doesn't affect your
example.

The GCC warning is telling you that you're relying on brace elision, which is
true. The extra braces aren't *required* but the warning doesn't say they're
required.

(In reply to Szőts Ákos from comment #0)
> The same message occurs when you initialise in either way:
>   * std::array a = {1, 2, 3};
>   * std::array a{1, 2, 3};

DR 1270 *does* apply to the second form (which is what cppreference says), it
makes it valid by allowing brace elision there. But that doesn't change that
you're relying on brace elision, which is what the warning tells you.

So the warning is still correct.

However, this is a recurring complaint from users and it's probably worth
making the diagnostic smarter. Clang has an "IdiomaticStdArrayInitDoesNotWarn"
test for this case:

https://github.com/llvm/llvm-project/blob/8aaabadeced32a1cd959a5b1524b9c927e82bcc0/clang/test/SemaCXX/aggregate-initialization.cpp#L155

It looks like they don't give a -Wmissing-braces warning when the number of
initializers is correct, but one level of braces around the entire list is
missing (which is the common case for std::array initialization). They still
warn if braces are elided from something like {{1, 2, 3}, 0}.

I think a reasonable heuristic is to suppress the warning if no initializers
occur outside the elided braces. So don't warn if {a,b,c} is used instead of
{{a,b,c}} but do warn if it's used instead of {{a,b},c} or {a,{b,c}}.

The text of the clang warning might also be less likely to confuse, as it says
"suggest braces around ..." rather than "missing braces around ...".

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[jrfsousa at gmail dot com]

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

--- Comment #9 from José Rui Faustino de Sousa  ---
Hi All,

Still present in:

GNU Fortran (GCC) 9.3.1 20200525
GNU Fortran (GCC) 10.1.1 20200525
GNU Fortran (GCC) 11.0.0 20200525 (experimental)

Thank you very much.

Best regards,
José Rui

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

 CC||jrfsousa at gmail dot com

--- Comment #8 from José Rui Faustino de Sousa  ---
Created attachment 48602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48602=edit
New test case

[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"

[stefaan.deroeck at gmail dot com]

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

--- Comment #1 from Stefaan De Roeck  ---
During further development, I nevertheless did find a shorter snippet to
reproduce the issue:

template 
struct Data
{
  int a, b;
};
template 
void func()
{
  auto [a, b] = Data();
}
int main() { func(); }

If there were a way to disable this specific warning(/error), that would help
too...

[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #43 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alexandre Oliva
:

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

commit r10-8186-gb425be2c4c6763436d63543501c6762ae031e43c
Author: Alexandre Oliva 
Date:   Wed May 13 05:21:42 2020 -0300

x86-vxworks malloc aligns to 8 bytes like solaris

Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128.  This patch enables
on x86-vxworks the same memory_resource workaround used for x86-solaris.

The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and
xfailing the test; extend those to x86-vxworks as well, and remove the
check for char-aligned requested allocation to be aligned like
max_align_t.  With that change, the test passes on x86-vxworks; I'm
guessing that's the same reason for the test not to pass on
x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm
tentatively removing the xfail.


for libstdc++-v3/ChangeLog

PR libstdc++/77691
* include/experimental/memory_resource
(__resource_adaptor_imp::do_allocate): Handle max_align_t on
x86-vxworks as on x86-solaris.
(__resource_adaptor_imp::do_deallocate): Likewise.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Drop xfail.
(BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris.
(test03): Drop max-align test for char-aligned alloc.

(cherry picked from commit 883246530f1bb10d854f455e1c3d55b93675690a)

[Bug c++/95305] Same code takes ~1/4 to 1/7th the time to compile under clang++.

[gcc-bugs at hussar dot me.uk]

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

--- Comment #5 from Jason  ---
(In reply to Jason from comment #4)
> (In reply to Richard Biener from comment #3)
> > Can you attach a "representativ" (maybe the worst?) compilation unit in
> > preprocessed form?
> 
> Compressed, the preprocessed translation unit in question is just too large
> to upload, but the compressed file may be downloaded from
> "http://research.ma.cx/mit_exchanges_performance.cpp.o.lzma;.

When extracted it is about 15Mb.

[Bug tree-optimization/95273] [11 regression] many ICEs after r11-564

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
   ||aarch64 arm

--- Comment #4 from Christophe Lyon  ---
If that helps:

on aarch64:
gcc.dg/vshift-5.c (internal compiler error)

on arm-linux-gnueabihf (--with-fpu neon-fp16):
gcc.dg/pr48616.c (internal compiler error)
gcc.dg/pr86179.c (internal compiler error)
gcc.dg/torture/pr66856-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
gcc.dg/torture/pr66856-1.c   -O3 -g  (internal compiler error)
gcc.dg/torture/pr66856-2.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
gcc.dg/torture/pr66856-2.c   -O3 -g  (internal compiler error)
gcc.dg/torture/pr93428.c   -O1  (internal compiler error)
gcc.dg/torture/pr93428.c   -O2  (internal compiler error)
gcc.dg/torture/pr93428.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
gcc.dg/torture/pr93428.c   -O3 -g  (internal compiler error)
gcc.dg/torture/pr93428.c   -Os  (internal compiler error)
gcc.dg/vect/bb-slp-over-widen-1.c (internal compiler error)
gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects (internal
compiler error)
gcc.dg/vect/bb-slp-over-widen-2.c (internal compiler error)
gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects (internal
compiler error)
gcc.dg/vect/pr33369.c (internal compiler error)
gcc.dg/vect/pr33369.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr33953.c (internal compiler error)
gcc.dg/vect/pr33953.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr46049.c (internal compiler error)
gcc.dg/vect/pr46049.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr46126.c (internal compiler error)
gcc.dg/vect/pr46126.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr51581-3.c (internal compiler error)
gcc.dg/vect/pr51581-3.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr51581-4.c (internal compiler error)
gcc.dg/vect/pr51581-4.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/slp-36.c (internal compiler error)
gcc.dg/vect/slp-36.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/slp-multitypes-13.c (internal compiler error)
gcc.dg/vect/slp-multitypes-13.c -flto -ffat-lto-objects (internal compiler
error)
gcc.dg/vect/vect-avg-15.c (internal compiler error)
gcc.dg/vect/vect-avg-15.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/vect-avg-16.c (internal compiler error)
gcc.dg/vect/vect-avg-16.c -flto -ffat-lto-objects (internal compiler error)
gcc.target/arm/pr53636.c (internal compiler error)

[Bug c++/95305] Same code takes ~1/4 to 1/7th the time to compile under clang++.

[gcc-bugs at hussar dot me.uk]

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

--- Comment #4 from Jason  ---
(In reply to Richard Biener from comment #3)
> Can you attach a "representativ" (maybe the worst?) compilation unit in
> preprocessed form?

Compressed, the preprocessed translation unit in question is just too large to
upload, but the compressed file may be downloaded from
"http://research.ma.cx/mit_exchanges_performance.cpp.o.lzma;.

[Bug c++/95330] New: Unneeded -Wmissing-braces warning when initialising std::array

[szotsaki at gmail dot com]

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

Bug ID: 95330
   Summary: Unneeded -Wmissing-braces warning when initialising
std::array
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: szotsaki at gmail dot com
  Target Milestone: ---

Example code:

#include 
int main() {
const volatile std::array a = {1, 2, 3};
return 0;
}

Compile with "-std=c++17 -Wmissing-braces" and the following warning is shown:

t.cpp: In function ‘int main()’:
t.cpp:3:48: warning: missing braces around initializer for
‘std::__array_traits::_Type’ {aka ‘int [3]’} [-Wmissing-braces]
3 |  const volatile std::array a = {1, 2, 3};
  |^

The same message occurs when you initialise in either way:
  * std::array a = {1, 2, 3};
  * std::array a{1, 2, 3};

According to cppreference.com [1] it's not necessary to use the second level of
braces since CWG 1270 [2] from C++11 on.

clang does not warn for the same line of code.

[1]: https://en.cppreference.com/w/cpp/container/array 
[2]: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1270

[Bug c/95329] New: fmaxf(inf, nan) does not always work

[florian at schanda dot org.uk]

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

Bug ID: 95329
   Summary: fmaxf(inf, nan) does not always work
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florian at schanda dot org.uk
  Target Milestone: ---

Created attachment 48601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48601=edit
Reduced testcase of the fmaxf issue

I've been creating some floating point benchmarks for SMT-LIB. I have noticed
that gcc (or something else) does not produce the same result in some specific
examples. I am on amd64 Debian, but I've also reproduced this on a recent amd64
Ubuntu. Below is a reduced test-case showing this:

#include 
#include 
#include 
#include 

int main()
{
  uint32_t bv = 0x7FACBA7E;
  // (0  0101100101110100110)

  float a, b;
  a = -INFINITY;
  memcpy(, , 4);

  printf("max(%f, %f) = %f\n", a, b, fmaxf(a, b));

  b = NAN;
  printf("max(%f, %f) = %f\n", a, b, fmaxf(a, b));
}

When compiling and running this program you get:

max(-inf, nan) = nan
max(-inf, nan) = -inf

I've tried with both:
  gcc bug.c -lm
and
  gcc -std=c99 -frounding-math -fsignaling-nans -ffp-contract=off -mfma
-mno-fma4 -pedantic -Wall -W -msse2 -mfpmath=sse -fstrict-aliasing bug.c -lm


However, IEEE-754 says that max(something not NaN, NaN) should get you the
thing that is not NaN. With the built-in constant it works, but with my
hand-crafted NaN it does not.

I've also tried replacing fmaxf by __builtin_fmaxf, with no success.


I also realise this likely may not be a gcc bug, but something deeper down in
libm or elsewhere. I do note that with clang-9 this works though. However I
suspect you guys will know where exactly this report needs to go to.

[Bug c/92773] [8/9/10/11 Regression] GCC compilation with big array / header is infinite

[szotsaki at gmail dot com]

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

Szőts Ákos  changed:

   What|Removed |Added

 CC||szotsaki at gmail dot com

--- Comment #12 from Szőts Ákos  ---
Might be a duplicate of Bug 85402? Though this one is better researched.

[Bug other/95316] Offload compilation fails when not all offload compilers are installed that were configured

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Last reconfirmed||2020-05-26
Summary|[10 Regression] binary  |Offload compilation fails
   |built with -fopenacc fails  |when not all offload
   |to run when not all offload |compilers are installed
   |compilers are installed |that were configured
   |that were configured|

--- Comment #1 from Thomas Schwinge  ---
So the report is not "binary built with -fopenacc fails to run when [...]" but
rather "compilation with -fopenacc fails when [...]"?  And, same for '-fopenmp'
for OpenMP 'target' offloading?  So I'm changing the Summary to: "Offload
compilation fails when [...]".  (Please adjust if I've misunderstood.)

I don't think this is a regression: wouldn't you've gotten the same behavior
already before GCC 10 added GCN offloading, for example, when you had built GCC
with '--enable-offload-targets=nvptx-none' but then didn't have the nvptx
offloading compiler installed?  I'm thus removing the "regression" tag. 
(Please put it back if I've misunderstood.)


I agree that the current driver (?) behavior is not ideal.  I suppose the
default offload targets configuration (unless overridden by '-foffload') should
be made so that if an offload compiler is not present, it is silently skipped. 
That is, without printing a warning (as has been suggested), as that would
produce a lot of noise.  If an offload target has been explicitly requested via
'-foffload=[target]', then that should result in a hard error, of course, if
the respective offload compiler is not available.

[Bug c++/95319] [10/11 Regression] Regression from gcc9.3 when inserting into a vector with an initializer list. Error: a GNU-style designated initializer for class

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-6388-ge98ebda074bf8fc5.

Reduced test-case:

$ cat pr95319.ii
namespace std {
template  class initializer_list {
  int *_M_array;
  unsigned long _M_len;
};
template  struct A { typedef int _Type[_Nm]; };
template  struct B { typename A<_Nm>::_Type _M_elems; };
class C {
public:
  void insert(int, B<3>);
  void insert(int, initializer_list>);
};
} // namespace std
int a;
int
main() {
  using ArrayVector = std::C;
  auto b = ArrayVector();
  b.insert(a, {{2}});
  return 0;
}

[Bug c++/95328] New: structured binding of template type inside template function is reported as "incomplete class type"

[stefaan.deroeck at gmail dot com]

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

Bug ID: 95328
   Summary: structured binding of template type inside template
function is reported as "incomplete class type"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefaan.deroeck at gmail dot com
  Target Milestone: ---

A structured binding assignment of a template type inside a template function
seems to be reported as "incomplete class type". 

Compiling below code apparently produces the warning (and thus failure with
-Werror) on all applicable GCC versions (gcc-7 segfaults, gcc-8 and up
including 11 reports the warning). Clang and intel compilers compile this
without warnings. 

This is the minimal code with which I can reproduce the issue. Removal of any
of the templating, or replacing the return type of makeData() by "auto", gets
rid of the warning. 

compilation flags: -std=c++17 -Werror

Reported error:
: In function 'void func()':
:14:8: error: structured binding refers to incomplete class type
'Data' [-Werror]
   14 |   auto [a, b] = makeData();
  |^~
cc1plus: all warnings being treated as errors



Code:
template 
struct Data
{
  int a, b;
};
template 
Data makeData()
{
  return Data();
}
template 
void func()
{
  auto [a, b] = makeData();
}
int main() { func(); }

[Bug c++/95317] [8/9/10/11 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Reduced test-case:

cat pr95317.ii
template  void fn1() {
  [](auto) {
enum { VALUE };
VALUE;
  };
}
main() { fn1; }

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-629-gf1f862aec2c3b93dbd6adfc35b0e1b6034e59c21
Author: Jakub Jelinek 
Date:   Tue May 26 09:35:21 2020 +0200

openmp: Ensure copy ctor for composite distribute parallel for class
iterators is instantiated [PR95197]

During gimplification omp_finish_clause langhook is called in several
places
to add the language specific info to the clause like what default/copy
ctors,
dtors and assignment operators should be used.

Unfortunately, if it refers to some not yet instantiated method, during
gimplification it is too late and the methods will not be instantiated
anymore.  For other cases, the genericizer has code to detect those and
instantiate whatever is needed, this change adds the same for
distribute parallel for class iterators where we under the hood need
a copy constructor for the iterator to implement it.

2020-05-26  Jakub Jelinek  

PR c++/95197
* gimplify.c (find_combined_omp_for): Move to omp-general.c.
* omp-general.h (find_combined_omp_for): Declare.
* omp-general.c: Include tree-iterator.h.
(find_combined_omp_for): New function, moved from gimplify.c.

* cp-gimplify.c: Include omp-general.h.
(cp_genericize_r) : For class iteration
variables in composite distribute parallel for, instantiate copy
ctor of their types.

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Possible patch:

diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 288e3c0f4c6..6441ab30c8b 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -591,7 +591,7 @@ local_tree_p (tree t)
 Only work hard for main variants;
 variant types will inherit locality.  */
   return TYPE_MAIN_VARIANT (t) == t
-&& odr_type_p (t) && type_with_linkage_p (t)
+&& in_lto_p && odr_type_p (t) && type_with_linkage_p (t)
 && type_in_anonymous_namespace_p (t);
 default:
   return false;

[Bug c++/95317] [8/9/10/11 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-26
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-2720-gf44a8dd56f5bfbd0.

[Bug tree-optimization/95327] [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3655

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/95315] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-382-g7a50e7087567cffb

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Known to fail||11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-26
 Ever confirmed|0   |1
  Known to work||10.1.0
Summary|[11 Regression] ICE:|[11 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |lookup_page_table_entry)|lookup_page_table_entry)
   ||since
   ||r11-382-g7a50e7087567cffb

--- Comment #1 from Martin Liška  ---
Started with r11-382-g7a50e7087567cffb.

[Bug jit/95325] Support 128-bit integers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Version|10.0|11.0

[Bug c++/95319] [10/11 Regression] Regression from gcc9.3 when inserting into a vector with an initializer list. Error: a GNU-style designated initializer for class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||10.1.0
Summary|Regression from gcc9.3 when |[10/11 Regression]
   |inserting into a vector |Regression from gcc9.3 when
   |with an initializer list.   |inserting into a vector
   |Error: a GNU-style  |with an initializer list.
   |designated initializer for  |Error: a GNU-style
   |class   |designated initializer for
   ||class
   Target Milestone|--- |10.2
  Known to work||9.3.0

[Bug c++/95317] [8/9/10/11 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |8.5
  Known to work||6.5.0
Summary|[7 regression] ICE on valid |[8/9/10/11 Regression] ICE
   |C++14 code, in tsubst_copy, |on valid C++14 code, in
   |at cp/pt.c:15649|tsubst_copy, at
   ||cp/pt.c:15649

[Bug other/95316] [10 Regression] binary built with -fopenacc fails to run when not all offload compilers are installed that were configured

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |10.2
   Keywords||openacc, openmp

[Bug tree-optimization/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Martin Liška  ---
Fixed on master with r11-609-g4acca1c0635dfa43.

[Bug middle-end/95326] GCC can not detect signed-integer-overflow correctly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Last reconfirmed||2020-05-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
The problem is GCC is shortening the multiple to be unsigned short early on.
That is doing:
long tt;
tt = l_volatile_uchar - l_var_short % g_const_uint * l_var_long;
l_var_short = tt;


Shows the issue.

[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Oops, autocorrect.

s/yesterday/testcase/

[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Not important for me. I don't remember where the yesterday came from.

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[luoxhu at gcc dot gnu.org]

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

--- Comment #10 from luoxhu at gcc dot gnu.org ---
In expand, Power8 will emit two register permute instructions to byte swap the
contents by rs6000_emit_le_vsx_move.

P9:
5: NOTE_INSN_BASIC_BLOCK 2
2: r129:TF=%1:TF
3: r130:TF=%3:TF
4: NOTE_INSN_FUNCTION_BEG
7: r117:DF=unspec[r129:TF,0] 70
8: r131:V2DF=r121:V2DF
9: r133:DF=vec_select(r131:V2DF,parallel)
   10: r131:V2DF=vec_concat(r117:DF,r133:DF)
   11: r122:V2DF=r131:V2DF
   12: r118:DF=unspec[r129:TF,0x1] 70
   13: r119:DF=unspec[r130:TF,0] 70
   14: r134:V2DF=r124:V2DF
   15: r136:DF=vec_select(r134:V2DF,parallel)
   16: r134:V2DF=vec_concat(r119:DF,r136:DF)
   17: r125:V2DF=r134:V2DF
   18: r120:DF=unspec[r130:TF,0x1] 70
   19: r137:V2DF=r122:V2DF
   20: r139:DF=vec_select(r137:V2DF,parallel)
   21: r137:V2DF=vec_concat(r139:DF,r118:DF)
   22: [r112:DI]=r137:V2DF
   23: r140:V2DF=r125:V2DF
   24: r142:DF=vec_select(r140:V2DF,parallel)
   25: r140:V2DF=vec_concat(r142:DF,r120:DF)
   26: [r112:DI+0x10]=r140:V2DF
   27: r143:V4SI=[r112:DI]
   28: r144:V4SI=[r112:DI+0x10]
   29: r127:V4SI=r143:V4SI
   30: r128:V4SI=r144:V4SI
   34: %2:V4SI=r127:V4SI
   35: %3:V4SI=r128:V4SI
   36: use %2:V4SI
   37: use %3:V4SI

P8:
5: NOTE_INSN_BASIC_BLOCK 2
2: r129:TF=%1:TF
3: r130:TF=%3:TF
4: NOTE_INSN_FUNCTION_BEG
7: r117:DF=unspec[r129:TF,0] 70
8: r131:V2DF=r121:V2DF
9: r133:DF=vec_select(r131:V2DF,parallel)
   10: r131:V2DF=vec_concat(r117:DF,r133:DF)
   11: r122:V2DF=r131:V2DF
   12: r118:DF=unspec[r129:TF,0x1] 70
   13: r119:DF=unspec[r130:TF,0] 70
   14: r134:V2DF=r124:V2DF
   15: r136:DF=vec_select(r134:V2DF,parallel)
   16: r134:V2DF=vec_concat(r119:DF,r136:DF)
   17: r125:V2DF=r134:V2DF
   18: r120:DF=unspec[r130:TF,0x1] 70
   19: r137:V2DF=r122:V2DF
   20: r139:DF=vec_select(r137:V2DF,parallel)
   21: r137:V2DF=vec_concat(r139:DF,r118:DF)
   22: r140:V2DF=vec_select(r137:V2DF,parallel)
   23: [r112:DI]=vec_select(r140:V2DF,parallel)
   24: r141:V2DF=r125:V2DF
   25: r143:DF=vec_select(r141:V2DF,parallel)
   26: r141:V2DF=vec_concat(r143:DF,r120:DF)
   27: r144:V2DF=vec_select(r141:V2DF,parallel)
   28: [r112:DI+0x10]=vec_select(r144:V2DF,parallel)
   29: r146:V4SI=vec_select([r112:DI],parallel)
   30: r145:V4SI=vec_select(r146:V4SI,parallel)
   31: r148:V4SI=vec_select([r112:DI+0x10],parallel)
   32: r147:V4SI=vec_select(r148:V4SI,parallel)
   33: r127:V4SI=r145:V4SI
   34: r128:V4SI=r147:V4SI
   38: %2:V4SI=r127:V4SI
   39: %3:V4SI=r128:V4SI
   40: use %2:V4SI
   41: use %3:V4SI

Difference starts from #22. Power8 will emit two vec_select instructions for
stack store/load operations. But power9 needs only one.

[Bug tree-optimization/95327] New: [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3655

[marxin at gcc dot gnu.org]

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

Bug ID: 95327
   Summary: [11 Regression] ICE in vect_get_constant_vectors, at
tree-vect-slp.c:3655
   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: ---
  Host: x86_64-linux-gnu
Target: ppc64-linux-gnu

I see the following ICE:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33369.c
-mpower9-vector -O3 -c
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33369.c: In function
‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33369.c:12:1: internal
compiler error: in vect_get_constant_vectors, at tree-vect-slp.c:3655
   12 | f (POINT * ptBuf)
  | ^
0x152b405 vect_get_constant_vectors
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3655
0x152bfbf vect_get_slp_defs(vec_info*, _slp_tree*, vec, va_heap, vl_ptr>*, unsigned int)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3887
0x14c0380 vect_get_vec_defs(vec_info*, tree_node*, tree_node*, _stmt_vec_info*,
vec*, vec*,
_slp_tree*)
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.c:1636
0x14d0405 vectorizable_shift
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.c:5894
0x14e359b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.c:11176
0x152d23f vect_schedule_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4235
0x152ca59 vect_schedule_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4127
0x152d843 vect_schedule_slp(vec_info*)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4359
0x150a989 vect_transform_loop(_loop_vec_info*, gimple*)
/home/marxin/Programming/gcc2/gcc/tree-vect-loop.c:8753
0x153639c try_vectorize_loop_1
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:988
0x1536638 try_vectorize_loop
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1044
0x1536812 vectorize_loops()
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1125
0x13aa111 execute
/home/marxin/Programming/gcc2/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.