[Bug c++/90101] [P0732] Error using non-type template parameter in a template template argument

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jul 19 06:52:47 2019
New Revision: 273591

URL: https://gcc.gnu.org/viewcvs?rev=273591&root=gcc&view=rev
Log:
PR c++/90098 - partial specialization and class non-type parms.

A non-type template parameter of class type used in an expression has
const-qualified type; the pt.c hunks deal with this difference from the
unqualified type of the parameter declaration.  WAhen we use such a
parameter as an argument to another template, we don't want to confuse
things by copying it, we should pass it straight through.  And we might as
well skip copying other classes in constant evaluation context in a
template, too; we'll get the copy semantics at instantiation time.

PR c++/90099
PR c++/90101
* call.c (build_converted_constant_expr_internal): Don't copy.
* pt.c (process_partial_specialization): Allow VIEW_CONVERT_EXPR
around class non-type parameter.
(unify) [TEMPLATE_PARM_INDEX]: Ignore cv-quals.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class18.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/pt.c

[Bug c++/90099] [P0732] Partial specialization of a class template with variadic parameter pack fails after adding non-type template parameter

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Fri Jul 19 06:52:47 2019
New Revision: 273591

URL: https://gcc.gnu.org/viewcvs?rev=273591&root=gcc&view=rev
Log:
PR c++/90098 - partial specialization and class non-type parms.

A non-type template parameter of class type used in an expression has
const-qualified type; the pt.c hunks deal with this difference from the
unqualified type of the parameter declaration.  WAhen we use such a
parameter as an argument to another template, we don't want to confuse
things by copying it, we should pass it straight through.  And we might as
well skip copying other classes in constant evaluation context in a
template, too; we'll get the copy semantics at instantiation time.

PR c++/90099
PR c++/90101
* call.c (build_converted_constant_expr_internal): Don't copy.
* pt.c (process_partial_specialization): Allow VIEW_CONVERT_EXPR
around class non-type parameter.
(unify) [TEMPLATE_PARM_INDEX]: Ignore cv-quals.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class18.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/pt.c

[Bug middle-end/91205] -fstack-protector-strong -D_FORTIFY_SOURCE=2 breaks tftpd

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
_FORTIFY_SOURCE=1 checks for all covered functions just whether they don't
overflow whole objects, while _FORTIFY_SOURCE=2 goes for a subset of functions
(e.g. those str*/stp* but not mem*) further and requires that they don't cross
structure field boundaries, say for
  struct S { char s[4]; char t[4]; } s;
  memcpy (s.s, "abcdefg", 8); // ok
  strcpy (s.s, "abcdefg"); // invalid
The only valid field that can go beyond end of the structure is flexible array
member, which is b in struct T { int a; char b[]; };, but GCC goes beyond that,
and allows [0], or even [23] as the last array in the structure, and handles I
believe even the union case you have in #c2, but it certainly isn't allowing
e.g. to cross from element to element of a multi-dimensional array or your #c0
case.

[Bug c++/90098] [P0732] Partial specialization of a class template with variadic parameter pack fails

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Fri Jul 19 06:52:47 2019
New Revision: 273591

URL: https://gcc.gnu.org/viewcvs?rev=273591&root=gcc&view=rev
Log:
PR c++/90098 - partial specialization and class non-type parms.

A non-type template parameter of class type used in an expression has
const-qualified type; the pt.c hunks deal with this difference from the
unqualified type of the parameter declaration.  WAhen we use such a
parameter as an argument to another template, we don't want to confuse
things by copying it, we should pass it straight through.  And we might as
well skip copying other classes in constant evaluation context in a
template, too; we'll get the copy semantics at instantiation time.

PR c++/90099
PR c++/90101
* call.c (build_converted_constant_expr_internal): Don't copy.
* pt.c (process_partial_specialization): Allow VIEW_CONVERT_EXPR
around class non-type parameter.
(unify) [TEMPLATE_PARM_INDEX]: Ignore cv-quals.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class18.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/pt.c

[Bug other/91197] [8,9 regression] alignment test program used in perl does not work with -O2 anymore

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(U32*)(buf + i)

Is undefined behavior since buf+i will mostly be unaligned.

NOTE most likely is unrolling the loop and changing the code from crashing to
something which will not crash.  That is valid thing to do as it was undefined
beforehand.

[Bug other/91197] [8,9 regression] alignment test program used in perl does not work with -O2 anymore

[eb at emlix dot com]

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

--- Comment #3 from Rolf Eike Beer  ---
It returns the alignment rather than printing. 4 is the correct return code.

[Bug other/91197] [8,9 regression] alignment test program used in perl does not work with -O2 anymore

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-07-19
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Not sure what this progam wants to test but I see it passing (exit code zero,
no prints).

Why is returning 0 wrong?

[Bug libstdc++/91210] Segmentation fault in random.tcc when compiling GCC 9.1 on linux powerpc(ppc) 64

[m.marko08154711 at gmail dot com]

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

--- Comment #2 from Martin Marko  ---
I am using the versions provided by ./contrib/download_prerequisites and build
them with gcc, is there anything in particular to look for?

[Bug middle-end/91205] -fstack-protector-strong -D_FORTIFY_SOURCE=2 breaks tftpd

[ricardo at ribalda dot com]

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

--- Comment #3 from Ricardo Ribalda  ---
(and thanks for your fast response  :) )

[Bug middle-end/91205] -fstack-protector-strong -D_FORTIFY_SOURCE=2 breaks tftpd

[ricardo at ribalda dot com]

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

--- Comment #2 from Ricardo Ribalda  ---
Hi Jakub

I can agree that I do not like the code style and I have already send a patch
for that.

On the other hand is a bit frustrating that mangling a bit the struct, or using
memcpy is enough to make it work.:


#include 
#include 

struct  tftphdr {
short   th_opcode;  /* packet type */
union {
chartu_padding[3];  /* sizeof() compat */

char tu_data[0];/* data or error string */

} __attribute__ ((__packed__)) th_u1;
} __attribute__ ((__packed__));

static char buf[512];

int main(int argc, char* argv[])
{
struct tftphdr *tp;

tp = (struct tftphdr *) buf;
strcpy(tp->th_u1.tu_data, "Hello world");

fprintf(stdout, "Code works %s!\n", tp->th_u1.tu_data);

return 0;
}

[Bug libstdc++/91210] Segmentation fault in random.tcc when compiling GCC 9.1 on linux powerpc(ppc) 64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>const size_t __log2r = std::log(__r) / std::log(2.0L);

This usually means the GMP/MPFR you are using is buggy.

[Bug libstdc++/91210] New: Segmentation fault in random.tcc when compiling GCC 9.1 on linux powerpc(ppc) 64

[m.marko08154711 at gmail dot com]

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

Bug ID: 91210
   Summary: Segmentation fault in random.tcc when compiling GCC
9.1 on linux powerpc(ppc) 64
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.marko08154711 at gmail dot com
  Target Milestone: ---

Created attachment 46611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46611&action=edit
config.log

The following error occurs during compilation of GCC 9.1:

---
make[5]: Entering directory
`/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include'
mkdir -p ./powerpc64-unknown-linux-gnu/bits/stdc++.h.gch
mkdir -p ./powerpc64-unknown-linux-gnu/bits/stdc++.h.gch
/opt/build/gcc/deploy/gcc-9.1.0/host-powerpc64-unknown-linux-gnu/gcc/xgcc
-shared-libgcc
-B/opt/build/gcc/deploy/gcc-9.1.0/host-powerpc64-unknown-linux-gnu/gcc
-nostdinc++
-L/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/bin/
-B/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/lib/ -isystem
/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/include -isystem
/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/sys-include  
-fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE 
-I/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/opt/build/gcc/deploy/gcc-9.1.0/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/opt/build/gcc/deploy/gcc-9.1.0/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
/opt/build/gcc/deploy/gcc-9.1.0/host-powerpc64-unknown-linux-gnu/gcc/xgcc
-shared-libgcc
-B/opt/build/gcc/deploy/gcc-9.1.0/host-powerpc64-unknown-linux-gnu/gcc
-nostdinc++
-L/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/bin/
-B/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/lib/ -isystem
/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/include -isystem
/opt/gcc-9.1.0-visibility/powerpc64-unknown-linux-gnu/sys-include  
-fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE 
-I/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/opt/build/gcc/deploy/gcc-9.1.0/libstdc++-v3/libsupc++  -O2 -g
/opt/build/gcc/deploy/gcc-9.1.0/libstdc++-v3/include/precompiled/stdc++.h -o
powerpc64-unknown-linux-gnu/bits/stdc++.h.gch/O2g.gch
In file included from
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/random:51,
 from
/opt/build/gcc/deploy/gcc-9.1.0/libstdc++-v3/include/precompiled/stdc++.h:108:
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:
In function ‘_RealType
std::generate_canonical(_UniformRandomNumberGenerator&)’:
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3328:54:
  in ‘constexpr’ expansion of ‘std::log(2.0e+0l)’
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3328:44:
internal compiler error: Segmentation fault
 3328 |   const size_t __log2r = std::log(__r) / std::log(2.0L);
  |  ~~^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [powerpc64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch]
Error 1
make[5]: *** Waiting for unfinished jobs
In file included from
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/random:51,
 from
/opt/build/gcc/deploy/gcc-9.1.0/libstdc++-v3/include/precompiled/stdc++.h:108:
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:
In function ‘_RealType
std::generate_canonical(_UniformRandomNumberGenerator&)’:
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3328:54:
  in ‘constexpr’ expansion of ‘std::log(2.0e+0l)’
/opt/build/gcc/deploy/gcc-9.1.0/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3328:44:
internal compiler error: Segmentation fa

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[egallager at gcc dot gnu.org]

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

--- Comment #13 from Eric Gallager  ---
(In reply to Marek Polacek from comment #11)
> Np.  It's certainly something I'd love to see fixed :/.  Hopefully the next
> stage1.

It's a new stage1

[Bug other/79543] Inappropriate "ld --version" checking

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eric Gallager from comment #2)
> > (In reply to Thomas Schwinge from comment #1)
> > > .
> > 
> > This link doesn't work for me.
> 
> Wait never mind now it does

archive dot org link in case it dies again: 
http://web.archive.org/web/20181019042404/https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg175904.html

[Bug other/91209] gm2 bootstrap comparison failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-07-19
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Are you sure this is not a GM2 issue?

[Bug other/91209] New: gm2 bootstrap comparison failure

[doko at debian dot org]

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

Bug ID: 91209
   Summary: gm2 bootstrap comparison failure
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk r273586 on x86_64-linux-gnu (and gm2 trunk):

gcc/gm2/gm2-compiler-boot/M2Version.o differs
make[4]: *** [Makefile:26909: compare] Error 1
make[4]: Leaving directory
'/home/packages/gcc/snap/gcc-snapshot-20190719/build'

[Bug objc/91208] New: [10 Regression] bootstrap comparison failure for objc and obj-c++

[doko at debian dot org]

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

Bug ID: 91208
   Summary: [10 Regression] bootstrap comparison failure for objc
and obj-c++
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk r273586 on x86_64-linux-gnu:

make[5]: Leaving directory
'/home/packages/gcc/snap/gcc-snapshot-20190719/build'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!

[Bug tree-optimization/91207] New: Wrong code with -O3

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 91207
   Summary: Wrong code with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC produces wrong code with -O3.

Reproducer:

#include 

long long a;
int b[92][32];
unsigned int c, d;

void e(long long *f, int p2) { *f = p2; }

int main() {
  for (int i = 6; i <= 20; d = i++)
for (int j = 6; j <= 91; j++) {
  for (int k = 16; k <= 31;k++)
b[j][k] ^= 7;
  c *= d;
}

  for (int i = 0; i < 21; ++i)
for (int j = 0; j < 32; ++j)
  e(&a, b[i][j]);

  printf("%llu\n", a);
}

Error:
>$ gcc -O0 repr.c ; ./a.out
7
>$ gcc -O3 repr.c ; ./a.out
0

GCC version is 10.0.0 (Revision: 273580)

[Bug c++/90100] [P0732] Cannot write a type-trait matching non-type class template parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/90099] [P0732] Partial specialization of a class template with variadic parameter pack fails after adding non-type template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-18
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/90098] [P0732] Partial specialization of a class template with variadic parameter pack fails

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/91204] [10 Regression] ICE in expand_expr_real_2, at expr.c:9215 with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
--- gcc/optabs.c.jj 2019-07-15 10:53:10.743205405 +0200
+++ gcc/optabs.c2019-07-19 00:38:20.271852242 +0200
@@ -2972,6 +2972,17 @@ expand_unop (machine_mode mode, optab un
   return target;
 }

+  /* Emit ~op0 as op0 ^ -1.  */
+  if (unoptab == one_cmpl_optab
+  && (SCALAR_INT_MODE_P (mode) || GET_MODE_CLASS (mode) ==
MODE_VECTOR_INT)
+  && optab_handler (xor_optab, mode) != CODE_FOR_nothing)
+{
+  temp = expand_binop (mode, xor_optab, op0, CONSTM1_RTX (mode),
+  target, unsignedp, OPTAB_DIRECT);
+  if (temp)
+   return temp;
+}
+
   if (optab_to_code (unoptab) == NEG)
 {
   /* Try negating floating point values by flipping the sign bit.  */

seems to work for me.  Or of course something similar can be done in
config/i386/mmx.md, basically copy the sse.md one_cmpl2 pattern to mmx.md
with TARGET_MMX_WITH_SSE and MMXMODEI iterator.

[Bug tree-optimization/91204] [10 Regression] ICE in expand_expr_real_2, at expr.c:9215 with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The vectorizer vectorizes the loop using 8-byte vectors, but then match.pd
during forwprop4 optimizes:
-  vect__6.17_46 = _52 ^ vect__1.12_39;
-  vect__7.18_47 = vect__6.17_46 & vect__1.12_39;
+  _27 = ~_52;
+  vect__7.18_47 = _27 & vect__1.12_39;
using the:
/* Fold (X & Y) ^ Y and (X ^ Y) & Y as ~X & Y.  */
(for opo (bit_and bit_xor)
 opi (bit_xor bit_and)
 (simplify
  (opo:c (opi:cs @0 @1) @1)
  (bit_and (bit_not @0) @1)))
rule, but does that without checking whether the one_cmpl optab is available
for the vector mode, and that is done after vector lowering.
The options I see are, either add some optab checking to match.pd patterns when
working on vector types, at least when post vector lowering, or simply ensure
that all backends have one_cmpl expanders for modes for which they have xor
instructions, or teach the expander to fallback to using xor if they need
one_cmpl optab which isn't available and xor is.  The last one seems like the
best option to me.

[Bug c++/90101] [P0732] Error using non-type template parameter in a template template argument

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/91204] [10 Regression] ICE in expand_expr_real_2, at expr.c:9215 with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-18
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ICE in expand_expr_real_2,  |[10 Regression] ICE in
   |at expr.c:9215 with -O3 |expand_expr_real_2, at
   ||expr.c:9215 with -O3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r272711.

[Bug middle-end/91205] -fstack-protector-strong -D_FORTIFY_SOURCE=2 breaks tftpd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
This is simply not valid under -D_FORTIFY_SOURCE=2.  Either use =1, or change
the code.

[Bug c/91206] -Wformat doesn't warn for %hd with char parameter

[ndesaulniers at google dot com]

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

--- Comment #2 from Nick Desaulniers  ---
Ah, I did file a bug for this in LLVM's issue tracker:
https://bugs.llvm.org/show_bug.cgi?id=41467

[Bug c/91206] -Wformat doesn't warn for %hd with char parameter

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I think GCC is correct as anything shorting than int is prompted to int when
passing via varags.  So %hd will print the int argument as a short.  This is
valid C code.  Maybe there should be a -Wformat=999 for this case but it seems
to be too noisy :).

[Bug c/91206] New: -Wformat doesn't warn for %hd with char parameter

[ndesaulniers at google dot com]

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

Bug ID: 91206
   Summary: -Wformat doesn't warn for %hd with char parameter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
  Target Milestone: ---

The linux kernel currently disables -Wformat when built with Clang (see
scripts/Makefile.extrawarn).

When looking into why the warning was disabled, I noticed that Clang and GCC
differ slightly in behavior, which leads to a warning spew when building the
kernel with Clang.

Testing out the specific cases of using different size types with different
format flags, I think I found the difference.

It seems that both compilers warn for modifiers to %d (%hhd, %hd, %ld, %lld)
when passed smaller parameters.

Specifically, it seems that GCC does not warn in the case:

char x = 0;
printf("%hd", x);

with -Wformat, but Clang does, and there are a lot of cases in the Linux kernel
that print char's via %hd.

Specifically, Clang would warn for the above:
warning: format specifies type 'short' but the argument has type 'char'
[-Wformat]

printf("%hd", x);

~~~   ^

%hhd

I think GCC should warn in this case as well, and we should clean up the issues
in the Linux kernel, but today it's hard to get patches accepted without having
to explain this subtly to kernel developers.

But if we disagree, I'm happy to collect more feedback for the Clang developers
if maybe Clang should not be warning for this case?

See also:
https://godbolt.org/z/qeuFoh
https://github.com/ClangBuiltLinux/linux/issues/378

[Bug c/91205] New: -fstack-protector-strong -D_FORTIFY_SOURCE=2 breaks tftpd

[ricardo at ribalda dot com]

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

Bug ID: 91205
   Summary: -fstack-protector-strong -D_FORTIFY_SOURCE=2 breaks
tftpd
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ricardo at ribalda dot com
  Target Milestone: ---

Current GNU inetutils tftpd breaks at runtime with current gcc (also tested
with 8.3).

The code throws a:

*** buffer overflow detected ***: 
Aborted

on its error path. The error seems to be due to the way the arpa/tftp.h headers
are handled.

The simplest testcase that I have managed to craft is:

//compile with: CFLAGS=-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security -O2
#include 
#include 

struct  tftphdr {
short   th_opcode;  /* packet type */
union {
chartu_padding[3];  /* sizeof() compat */
struct {
char tu_data[0];/* data or error string */
} __attribute__ ((__packed__)) th_u2;
} __attribute__ ((__packed__)) th_u1;
} __attribute__ ((__packed__));

static char buf[512];

int main(int argc, char* argv[])
{
struct tftphdr *tp;

tp = (struct tftphdr *) buf;
strcpy(tp->th_u1.th_u2.tu_data, "Hello world");

fprintf(stdout, "Code works!\n");

return 0;
}


Although this other testcase is closer to the original source:

#include 
#include 
#include 
#include 


/* Some systems define PKTSIZE in .  */
#ifndef PKTSIZE
#define PKTSIZE SEGSIZE+4
#endif


static char buf[PKTSIZE];

struct errmsg
{
  int e_code;
  const char *e_msg;
} errmsgs[] =
  {
{EUNDEF, "Undefined error code"},
{ENOTFOUND, "File not found"},
{EACCESS, "Access violation"},
{ENOSPACE, "Disk full or allocation exceeded"},
{EBADOP, "Illegal TFTP operation"},
{EBADID, "Unknown transfer ID"},
{EEXISTS, "File already exists"},
{ENOUSER, "No such user"},
{-1, 0}
  };


static void nak (int error)
{
register struct tftphdr *tp;
int length;
register struct errmsg *pe = &errmsgs[error];

tp = (struct tftphdr *) buf;
tp->th_opcode = htons ((unsigned short) ERROR);
tp->th_code = htons (pe->e_code);
strcpy(tp->th_msg, pe->e_msg);
length = strlen (pe->e_msg);
length += 5;
}

int main(int argc, char* argv[])
{
int i;

for (i=0;i<8;i++)
nak(i);

fprintf(stdout, "Code works!\n");

return 0;
}


Replacing strcpy with memcpy solves the issue. A patch has been sent to
inetutils. https://www.mail-archive.com/bug-inetutils@gnu.org/msg03036.html

[Bug target/91202] Unnecessary promotion of shift operands

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #1)
> >does not need its operand to be promoted to int on targets that have shift 
> >instruction 
> 
> Yes it does as that is what C says it does ...

The standard also says that all narrow operations have to be promoted to int,
but we live just fine with:

unsigned char
bar (unsigned char a, unsigned char b)
{
  return a + b;
}

that dumps to:

--cut here--
bar (unsigned char a, unsigned char b)
{
  unsigned char _3;

   [local count: 1073741824]:
  _3 = a_1(D) + b_2(D);
  return _3;

}
--cut here--

I fail to see the difference...

[Bug tree-optimization/91201] [7~9 Regression] SIMD not generated for horizontal sum of bytes in array

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
We unroll the loop (-fdisable-tree-cunrolli) and SLP does not handle
reductions.

[Bug tree-optimization/91204] New: ICE in expand_expr_real_2, at expr.c:9215 with -O3

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 91204
   Summary: ICE in expand_expr_real_2, at expr.c:9215 with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC fails with ICE in expand_expr_real_2, at expr.c:9215.

Reproducer:

int a, b;
extern int c[];
void d() {
  for (int e = 6; e <= a; e++)
c[e] &= b ^ c[e] ^ c[e - 2];
}

Error:
>$ gcc -c -O3 small.c
during RTL pass: expand
small.c: In function ‘d’:
small.c:5:10: internal compiler error: in expand_expr_real_2, at expr.c:9215
5 | c[e] &= b ^ c[e] ^ c[e - 2];
  |  ^~
0x8c9408 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/gcc/expr.c:9215
0x8d0532 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/gcc/expr.c:9948
0x8dac5e expand_expr
/gcc/expr.h:281
0x8dac5e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/gcc/expr.c:7878
0x8c829d expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/gcc/expr.c:9738
0x796a60 expand_gimple_stmt_1
/gcc/cfgexpand.c:3814
0x796a60 expand_gimple_stmt
/gcc/cfgexpand.c:3875
0x79da4f expand_gimple_basic_block
/gcc/cfgexpand.c:5915
0x7a027e execute
/gcc/cfgexpand.c:6538

GCC version is 10.0.0 (rev. 273556)

[Bug sanitizer/91203] New: __asan_set_error_report_callback has no effect on leak messages

[diane2332 at gmail dot com]

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

Bug ID: 91203
   Summary: __asan_set_error_report_callback has no effect on leak
messages
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: diane2332 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I can capture ASan error messages with a function set in 

  __asan_set_error_report_callback

Unfortunately this does nothing for any messages coming from LeakSanitizer,
even though it is included in -fsanitize=address. This is a serious problem
because the large code that I'm working on redirects stderr to /dev/null, so it
took a while to even realize that there must be some leaks in this code. Yes we
can set LSAN_OPTIONS to log_path=..., but what we really want to do is to be
able to capture the leak errors just like we are capturing the buffer overflow
messages and redirect them to internal handlers.

First of all, this must be documented.

Second it would be really awesome to have LeakSanitizer call the callback
function set in __asan_set_error_report_callback. If this doesn't make sense
for LSan, please provide __lsan_set_error_report_callback instead.

I can attach a code sample, but it's pretty easy to create one.

[Bug target/91202] Unnecessary promotion of shift operands

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
>does not need its operand to be promoted to int on targets that have shift 
>instruction 

Yes it does as that is what C says it does ...

[Bug c/91202] New: Unnecessary promotion of shift operands

[ubizjak at gmail dot com]

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

Bug ID: 91202
   Summary: Unnecessary promotion of shift operands
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
unsigned char
foo (unsigned char a, unsigned char b)
{
  return a >> b;
}
--cut here--

does not need its operand to be promoted to int on targets that have shift
instruction in QI and HI mode.

Currently, gcc compiles the testcase (-O2) via _.original:

--cut here--
;; Function foo (null)
;; enabled by -tree-original


{
  return (unsigned char) ((int) a >> (int) b);
}
--cut here--

and ._optimized:

;; Function foo (foo, funcdef_no=0, decl_uid=1907, cgraph_uid=1,
symbol_order=0)

--cut here--
foo (unsigned char a, unsigned char b)
{
  int _1;
  int _2;
  int _3;
  unsigned char _6;

   [local count: 1073741824]:
  _1 = (int) a_4(D);
  _2 = (int) b_5(D);
  _3 = _1 >> _2;
  _6 = (unsigned char) _3;
  return _6;

}
--cut here--

to:
movzbl  %dil, %eax
movl%esi, %ecx
sarl%cl, %eax
ret

However, on targets that provide QImode shift, the above code could be emitted
as:

movzbl  %dil, %eax
movl%esi, %ecx
shrb%cl, %al
ret

This optimization would help the following testcase:

--cut here--
struct S1
{
  unsigned char val;
  unsigned char pad1;
  unsigned short pad2;
};

struct S1
test_shrb (struct S1 a, unsigned char b)
{
  a.val >>= b;

  return a;
}
--cut here--

that currently compiles to:

movzbl  %dil, %edx
movl%esi, %ecx
movl%edi, %eax
sarl%cl, %edx
movb%dl, %al
ret

but after PR91188 was fixed, the testcase could be compiled with the proposed
optimization to:

movl%edi, %eax
movl%esi, %ecx
shrb%cl, %al
ret

Please note that MSVC v19.21 implements the proposed optimization and
generates:

movzx   eax, cl
movzx   ecx, dl
shr al, cl
ret 0

[Bug target/91188] strict_low_part operations do not work

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jul 18 17:17:31 2019
New Revision: 273578

URL: https://gcc.gnu.org/viewcvs?rev=273578&root=gcc&view=rev
Log:
PR target/91188
* config/i386/i386.md (*addqi_1_slp): Use register_operand predicate
for operand 0.  Do not use (match_dup) to match operand 1 with
operand 0.  Add check in insn constraint that either input operand
matches operand 0.  Use SWI12 mode iterator to also handle
HImode operands.
(*and_1_slp): Ditto.
(*qi_1_slp): Ditto.
(*sub_1_slp): Use register_operand predicate for operand 0.
Do not use (match_dup) to match operand 1 with operand 0.  Add
check in insn constraint that operand 1 matches operand 0.
Use SWI12 mode iterator to also handle HImode operands.
(*ashl3_1_slp): Ditto.
(*3_1_slp): Ditto.
(*3_1_slp): Ditto.

testsuite/ChangeLog:

PR target/91188
* gcc.target/i386/pr91188-1a.c: New test.
* gcc.target/i386/pr91188-1b.c: Ditto.
* gcc.target/i386/pr91188-1c.c: Ditto.
* gcc.target/i386/pr91188-2a.c: Ditto.
* gcc.target/i386/pr91188-2b.c: Ditto.
* gcc.target/i386/pr91188-2c.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr91188-1a.c
trunk/gcc/testsuite/gcc.target/i386/pr91188-1b.c
trunk/gcc/testsuite/gcc.target/i386/pr91188-1c.c
trunk/gcc/testsuite/gcc.target/i386/pr91188-2a.c
trunk/gcc/testsuite/gcc.target/i386/pr91188-2b.c
trunk/gcc/testsuite/gcc.target/i386/pr91188-2c.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/90317] [7/8/9] ICE for arm sha1h and wrong optimisations on sha1h/c/m/p

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
Summary|[7/8/9/10] ICE for arm  |[7/8/9] ICE for arm sha1h
   |sha1h and wrong |and wrong optimisations on
   |optimisations on|sha1h/c/m/p
   |sha1h/c/m/p |

--- Comment #3 from Wilco  ---
Fixed on trunk so far

[Bug tree-optimization/91201] New: [7~9 Regression] SIMD not generated for horizontal sum of bytes in array

[bisqwit at iki dot fi]

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

Bug ID: 91201
   Summary: [7~9 Regression] SIMD not generated for horizontal sum
of bytes in array
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

For this code —

typedef unsigned long long E;
const unsigned D = 2;
E bytes[D];
unsigned char sum() 
{
E b[D]{};
//#pragma omp simd
for(unsigned n=0; n> 32);
temp += (temp >> 16);
temp += (temp >> 8);
b[n] = temp;
}
E result = 0;
//#pragma omp simd
for(unsigned n=0; nhttps://godbolt.org/z/azkXiL

[Bug target/90317] [7/8/9/10] ICE for arm sha1h and wrong optimisations on sha1h/c/m/p

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jul 18 15:42:13 2019
New Revision: 273574

URL: https://gcc.gnu.org/viewcvs?rev=273574&root=gcc&view=rev
Log:
[patch1/2][arm][PR90317]: fix sha1 patterns

This patch fixes:

1) Ice message thrown when using the crypto_sha1h intrinsic due to
incompatible mode used for zero_extend. Removed zero extend as it is
not a good choice for vector modes and using an equivalent single
mode like TI (128bits) instead of V4SI produces extra instructions
making it inefficient.

This affects gcc version 8 and above.

2) Incorrect combine optimizations made due to vec_select usage
in the sha1 patterns on arm. The patterns should only combine
a vec select within a sha1h instruction when the lane is 0.

This affects gcc version 5 and above.

- Fixed by explicitly declaring the valid const int for such
optimizations. For cases when the lane is not 0, the vector
lane selection now occurs in a e.g. vmov instruction prior
to sha1h.

- Updated the sha1h testcases on arm to check for additional
cases with custom vector lane selection.

The intrinsic functions for the sha1 patterns have also been
simplified which seems to eliminate extra vmovs like:
- vmov.i32 q8, #0.


2019-07-18  Sylvia Taylor  

PR target/90317
* config/arm/arm_neon.h
(vsha1h_u32): Refactor.
(vsha1cq_u32): Likewise.
(vsha1pq_u32): Likewise.
(vsha1mq_u32): Likewise.
* config/arm/crypto.md:
(crypto_sha1h): Remove zero extend, correct vec select.
(crypto_sha1c): Correct vec select.
(crypto_sha1m): Likewise.
(crypto_sha1p): Likewise.

* gcc.target/arm/crypto-vsha1cq_u32.c (foo): Change return type to
uint32_t.
(GET_LANE, TEST_SHA1C_VEC_SELECT): New.
* gcc.target/arm/crypto-vsha1h_u32.c (foo): Change return type to
uint32_t.
(GET_LANE, TEST_SHA1H_VEC_SELECT): New.
* gcc.target/arm/crypto-vsha1mq_u32.c (foo): Change return type to
uint32_t.
(GET_LANE, TEST_SHA1M_VEC_SELECT): New.
* gcc.target/arm/crypto-vsha1pq_u32.c (foo): Change return type to
uint32_t.
(GET_LANE, TEST_SHA1P_VEC_SELECT): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm_neon.h
trunk/gcc/config/arm/crypto.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c
trunk/gcc/testsuite/gcc.target/arm/crypto-vsha1h_u32.c
trunk/gcc/testsuite/gcc.target/arm/crypto-vsha1mq_u32.c
trunk/gcc/testsuite/gcc.target/arm/crypto-vsha1pq_u32.c

[Bug tree-optimization/91200] New: ICE on valid code at -O1: verify_ssa failed

[su at cs dot ucdavis.edu]

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

Bug ID: 91200
   Summary: ICE on valid code at -O1: verify_ssa failed
   Product: gcc
   Version: unknown
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: ---

It appears to be a recent regression.

[512] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/suz/software/gcctk/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --disable-multilib
--enable-languages=c,c++,lto --prefix=/home/suz/software/gcctk/gcc-trunk
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190718 (experimental) [trunk revision 273570] (GCC) 
[513] % 
[513] % gcctk -O0 small.c
[514] % gcc-9.1.0 -O1 small.c
[515] % 
[515] % gcctk -O1 small.c
small.c: In function ‘main’:
small.c:6:5: error: definition in block 4 does not dominate use in block 3
6 | int main ()
  | ^~~~
for SSA_NAME: i_20 in statement:
# VUSE <.MEM_13>
cstore_6 = MEM  [(void *)&h][i_20];
during GIMPLE pass: cselim
small.c:6:5: internal compiler error: verify_ssa failed
0xed1acb verify_ssa(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa.c:1208
0xb861d7 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1970
0xb87102 execute_todo
../../gcc-source-trunk/gcc/passes.c:2017
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.
[516] % 


---


int printf (const char *, ...);

char a;
int b, c, **d;

int main ()
{
  int f = -128, *g, *h[2] = {0, 0}, i;
  printf("0");
  if (a)
{
  while (f > a) {
int *j = &i;
*j |= 0;
  }
  h[i] = &c;
}
  if (h[1])
{
  int **k = &g;
  *k = &f;
  while (i)
{
  int **l[] = {&g};
}
  int **m = &g;
  *d = *m = &b;
}
  return 0;
}

[Bug c/91199] New: In -fexcess-precision=standard mode, the warning “floating constant truncated to zero” is misleading

[pascal_cuoq at hotmail dot com]

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

Bug ID: 91199
   Summary: In -fexcess-precision=standard mode, the warning
“floating constant truncated to zero” is misleading
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

Consider the following program:

#include 
#include 

#define MY_HUGE_VALF 0x1.0p255f

float f;

int main(void) {
  f = 0x1.0p-255f * MY_HUGE_VALF;
  printf("%d, %f\n", (int)FLT_EVAL_METHOD, f);
}

When compiled with -O -fexcess-precision=standard -mfpmath=387 and executed,
this program prints “2, 1.00”, which indicates that neither factor is 0 and
neither is +inf.
Compiler Explorer link: https://gcc.godbolt.org/z/RA_tDw

This all corresponds exactly to the C standard [1] and Joseph Myers's post [2]
introducing the option -fexcess-precision=standard, but please look at the
warnings emitted during compilation:

:9:3: warning: floating constant truncated to zero [-Woverflow]

:9:3: warning: floating constant exceeds range of 'float' [-Woverflow]

The second warning, about MY_HUGE_VALF, is not wrong, and probably corresponds
to an aspect of the program that should be brought to the attention of the
developer.

The first warning is wrong: it implies that 0x1.0p-255f will be interpreted as
0 by the compiler, while it (correctly) isn't.

I would suggest to make the first warning more like the second one, along the
lines of “floating constant underflows range of 'float'”.

[1] https://port70.net/~nsz/c/c11/n1570.html#5.2.4.2.2p9
[2] https://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html

[Bug tree-optimization/91198] GCC not generating AVX-512 compress/expand instructions

[moritz.kreutzer at siemens dot com]

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

--- Comment #2 from Moritz Kreutzer  ---
Sure, I should have said that I'm talking about auto vectorization. I'm aware
that we could use intrinsics, but of course that'll always be our last resort
for obvious reasons.

[Bug tree-optimization/91198] GCC not generating AVX-512 compress/expand instructions

[ams at gcc dot gnu.org]

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

--- Comment #1 from Andrew Stubbs  ---
I don't believe GCC detects that operation automatically.

It does support the instruction via intrinsics (builtin functions that
correspond to low-level machine features). You should investigate
"__builtin_ia32_compressstoresf512_mask" and friends.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
With

Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 273567)
+++ gcc/config/i386/i386.md (working copy)
@@ -17681,6 +17681,23 @@ (define_insn "3"
(set_attr "type" "sseadd")
(set_attr "mode" "")])

+(define_expand "smaxsi3"
+ [(set (match_operand:SI 0 "register_operand")
+   (smax:SI
+(match_operand:SI 1 "register_operand")
+   (match_operand:SI 2 "register_operand")))]
+ ""
+{
+  rtx vop1 = gen_reg_rtx (V4SImode);
+  rtx vop2 = gen_reg_rtx (V4SImode);
+  emit_insn (gen_vec_setv4si_0 (vop1, CONST0_RTX (V4SImode), operands[1]));
+  emit_insn (gen_vec_setv4si_0 (vop2, CONST0_RTX (V4SImode), operands[2]));
+  rtx tem = gen_reg_rtx (V4SImode);
+  emit_insn (gen_smaxv4si3 (tem, vop1, vop2));
+  emit_move_insn (operands[0], lowpart_subreg (SImode, tem, V4SImode));
+  DONE;
+})
+
 ;; These versions of the min/max patterns implement exactly the operations
 ;;   min = (op1 < op2 ? op1 : op2)
 ;;   max = (!(op1 < op2) ? op1 : op2)


we generate

.L3:
addl(%rdx,%r8,4), %r9d
movl(%rcx,%r8,4), %eax
addl(%rsi,%r8,4), %eax
vmovd   %r9d, %xmm1
vmovd   %eax, %xmm0
movq%r8, %rax
vpmaxsd %xmm1, %xmm0, %xmm0
vinsertps   $0xe, %xmm0, %xmm0, %xmm0
vpmaxsd %xmm2, %xmm0, %xmm0
vmovd   %xmm0, 4(%rdi,%r8,4)
vmovd   %xmm0, %r9d
incq%r8
cmpq%rax, %r10
jne .L3

so we manage to catch the store as well but somehow

(insn:TI 35 27 37 4 (set (reg:V4SI 20 xmm0 [114])
(vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 20 xmm0 [107]))
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1]))) 2740 {vec_setv4si_0}
 (nil))

fails to be elided.  Maybe vec_setv4si_0 isn't the optimal representation
choice.  Ah, of course the zeros might end up invalidated by the earlier
max...  we can't say in RTL that we actually do not care about the
upper bits - can we?

Anyhow, while the above would fix the regression on Haswell we'd degrade
on Zen and in more isolated cmov cases it's clearly not going to be a win
as well.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jiangning.liu@amperecomputi
   ||ng.com, law at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r273449.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Testcase for the loop in question:

void foo (int *dc, int *mc, int *tpdd, int *tpmd, int M)
{
  int sc;
  int k;
  for (k = 1; k <= M; k++)
{
  dc[k] = dc[k-1] + tpdd[k-1];
  if ((sc = mc[k-1] + tpmd[k-1]) > dc[k]) dc[k] = sc;
  if (dc[k] < -987654321) dc[k] = -987654321;
}
}

[Bug other/91197] [8,9 regression] alignment test program used in perl does not work with -O2 anymore

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
You are relying on undefined behaviour.

[Bug tree-optimization/91198] New: GCC not generating AVX-512 compress/expand instructions

[moritz.kreutzer at siemens dot com]

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

Bug ID: 91198
   Summary: GCC not generating AVX-512 compress/expand
instructions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz.kreutzer at siemens dot com
  Target Milestone: ---

We have a simple loop to select values based on a condition from one array and
store the selected values contiguously in a second array:


https://godbolt.org/z/T7UXXD

float const threshold = 0.5; 
int o = 0;
for (int i = 0; i < size; ++i) {
  if (input[i] < threshold) {
output[o] = input[i];
o++;
  } 
}


It seems like GCC is not able to generate AVX-512 assembly using vcompressps
instructions for this code. The same holds true for the orthogonal pattern
(expansion using vexpandps). Is this a missed optimization in GCC or is there
another issue in the example code which prevents vectorization?

[Bug other/91197] New: [8,9 regression] alignment test program used in perl does not work with -O2 anymore

[eb at emlix dot com]

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

Bug ID: 91197
   Summary: [8,9 regression] alignment test program used in perl
does not work with -O2 anymore
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eb at emlix dot com
  Target Milestone: ---

The story is in https://bugs.gentoo.org/676062 and especially
https://rt.perl.org/Public/Bug/Display.html?id=133495

This test program, taken from the above perl bug, incorrectly returns 0 when
built with -O2 on gcc 8.3 and 9.1, but is fine with 7.3 and probably everything
before. Building with -g only makes things work:

#include 
#define I_STDLIB
#ifdef I_STDLIB
#include 
#endif
#define U32 unsigned long
#define BYTEORDER 0x4321
#define U8 unsigned char
#include 
#ifdef SIGBUS
void bletch(int s) { exit(4); }
#endif
int main() {
#if BYTEORDER == 0x1234 || BYTEORDER == 0x4321
volatile U8 buf[8];
volatile U32 *up;
int i;

if (sizeof(U32) != 4) {
printf("sizeof(U32) is not 4, but %d\n", sizeof(U32));
exit(1);
}

fflush(stdout);

#ifdef SIGBUS
signal(SIGBUS, bletch);
#endif

buf[0] = 0;
buf[1] = 0;
buf[2] = 0;
buf[3] = 1;
buf[4] = 0;
buf[5] = 0;
buf[6] = 0;
buf[7] = 1;

for (i = 0; i < 4; i++) {
up = (U32*)(buf + i);
if (! ((*up == 1 << (8*i)) ||   /* big-endian */
   (*up == 1 << (8*(3-i)))  /* little-endian */
  )
   )
{
printf("read failed (%x)\n", *up);
exit(2);
}
}

/* write test */
for (i = 0; i < 4; i++) {
up = (U32*)(buf + i);
*up = 0xBeef;
if (*up != 0xBeef) {
printf("write failed (%x)\n", *up);
exit(3);
}
}

exit(0);
#else
printf("1\n");
exit(1);
#endif
return 0;
}

[Bug libstdc++/91170] [9/10 Regression] Crash in pdns resolver

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
In the end the issue may have been caused by building with LTO.

[Bug ipa/91194] A suspicious condition in recursive_inlining

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Indeed, looks like (quite unfortunate) typo.  I will test patch.

[Bug fortran/91196] Interface generated for proc with VALUE,OPTIONAL misses hidden is-present argument

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
The problem is trans-type.c's
   gfc_get_function_type()
which handles hidden strings but not the hidden is-present status of
VALUE,OPTIONAL.

[Bug ipa/91194] A suspicious condition in recursive_inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-18
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Looks like so.  Honza?

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-18
 Blocks||24639
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The uninit predicate analysis definitely doesn't handle the connection between
num == 0 and !m1.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
On Skylake (Coffeelake actually) with the same binary (built for Haswell), the
improvement is down to 5%.

On Haswell, when I just replace the second conditional move like

vmovd  %ebx, %xmm12
.p2align 4,,10
.p2align 3
.L34:
...
cmpl%eax, %esi
cmovge  %esi, %eax
movl%ecx, %esi
#   cmpl%ebx, %eax
#   cmovl   %ebx, %eax
vmovd   %eax, %xmm10
vpmaxsd %xmm12, %xmm10, %xmm10
vmovd   %xmm10, %eax
movl%eax, -4(%r13,%rcx,4)
...

this doesn't make a difference.  Replacing both, like

movl-8(%r8,%rcx,4), %esi
addl-8(%rdx,%rcx,4), %esi
#   cmpl%eax, %esi
#   cmovge  %esi, %eax
vmovd   %eax, %xmm10
vmovd   %esi, %xmm11
vpmaxsd %xmm11, %xmm10, %xmm10
movl%ecx, %esi
#   cmpl%ebx, %eax
#   cmovl   %ebx, %eax
vpmaxsd %xmm12, %xmm10, %xmm10
vmovd   %xmm10, %eax
movl%eax, -4(%r13,%rcx,4)

makes runtime improve to within 1% of fixing the regression.
I guess that's the best a insn-localized "fix" (provide a smax pattern for
SImode) would get to here.  As expected on Zen this localized "fix" is a loss
(additional 11% regression, tested same Haswell tuned binary) while
the full SSE variant is also a lot faster - 35% so compared to the code
with two cmovs and 17% compared to the good r272921 code.

So it seems important to avoid crossing the gpr/xmm domain here.  When
I go through the stack for all three GPR<->XMM moves the situation
gets even (much) worse.

Overall this means enhancing STV to seed itself on conditional moves
that match max/min _and_ that can avoid GPR <-> XMM moves would be quite
a big win here.

[Bug fortran/91196] Interface generated for proc with VALUE,OPTIONAL misses hidden is-present argument

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Cross ref: The issue came up at:
https://gcc.gnu.org/ml/fortran/2019-07/msg00055.html

Actually, at least the 'static' line only appears for 'containes' procedures.

If they are generated ('gfc_generate_contained_functions'), there is a call to
'create_function_arglist'.

In that call, it starts with (in trans-decl.c):
2386  fndecl = sym->backend_decl;

And if one dumps that three, one has:
  arg-types 
  chain >>>

Namely, the hidden argument is missing. However, later in that function
(create_function_arglist), one has:
   hidden_arglist = chainon (hidden_arglist, tmp);
...
arglist = chainon (arglist, hidden_arglist);
  DECL_ARGUMENTS (fndecl) = arglist;


My feeling is that the 'static' line is generated based on the original
backend_decl - while the update comes later - too late.


NOTE: For a dummy argument
   character(len=6), value, optional :: x
the hidden argument is added. (Although, in this case, the hidden argument is
not needed as the string length has to be fixed.)

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #30 from Richard Earnshaw  ---
Makes sense.  I'm going to wait now until Joseph gets back and has had a chance
to comment.

[Bug fortran/91196] New: Interface generated for proc with VALUE,OPTIONAL misses hidden is-present argument

[burnus at gcc dot gnu.org]

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

Bug ID: 91196
   Summary: Interface generated for proc with VALUE,OPTIONAL
misses hidden is-present argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Cf. PR fortran/35203 for the original implementation.

The following code generates the procedure definition - note the last two
arguments:

  foo (void * x, integer(kind=4)[1] * y, integer(kind=4) * z, integer(kind=4)
z2, logical(kind=1) _z2)


In the main program, the interface / prototype is declared, but it lacks the
hidden logical argument:

  static logical(kind=1) foo (void *, integer(kind=4)[1] *, integer(kind=4) *,
integer(kind=4));


NOTE: The call does have the additional argument:
  is_present = foo (c_ptr.0, &y, 0B, 0, 0);


Example Fortran code - "z2" is the argument of interest.

  use iso_c_binding
  implicit none
  logical(kind=c_bool) :: is_present
  integer :: y(1)
  y(1) = 5
  is_present = foo(c_null_ptr, y)
contains
  logical(kind=c_bool) function foo(x, y, z, z2)
type(c_ptr), value :: x ! Matches a C 'void *' pointer
integer, target :: y(1)
integer, optional :: z
integer, value, optional :: z2

foo = present(z2)
  end function foo
end

[Bug target/86753] [9/10 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
To give a few more details:

void
f1 (int *x, int *y, int *z)
{
  for (int i = 0; i < 100; ++i)
x[i] = y[i] ? z[i] : 10;
}

produces:

ptrue   p3.s, all
...
.L3:
ld1wz0.s, p2/z, [x1, x3, lsl 2]
cmpne   p1.s, p3/z, z0.s, #0
cmpne   p0.s, p2/z, z0.s, #0
ld1wz0.s, p0/z, [x2, x3, lsl 2]
sel z0.s, p1, z0.s, z1.s
st1wz0.s, p2, [x0, x3, lsl 2]
incwx3
whilelo p2.s, w3, w4
b.any   .L3

where the select is fed by an unpredicated comparison while the
masked load is (and in general needs to be, although not in this
case) fed by a predicated comparison.

The gimple output of the vectoriser is:

  mask__35.10_54 = vect__4.9_52 != vect_cst__53;
  vec_mask_and_57 = mask__35.10_54 & loop_mask_51;
  vect_iftmp.13_58 = .MASK_LOAD (vectp_z.11_55, 4B, vec_mask_and_57);
  vect_iftmp.14_61 = VEC_COND_EXPR ;

I think when vectorising VEC_COND_EXPR , we should check
whether T is ultimately conditional on C, either via a masked load
or a conditional internal function.  If so, we should reuse the same
condition for the VEC_COND_EXPR too (which for SVE means using the
condition with the loop mask applied).

Alternatively, we could just keep a hash of available vector conditions
that have been used in masked loads or conditional internal functions,
and try to reuse them when vectorising VEC_COND_EXPRs (without checking
T and E specifically).  That might be simpler.

Either way, the end goal would be to use vec_mask_and_57 in the
VEC_COND_EXPR.

For:

  void
  f2 (int *x, int *y, int *z, int fallback)
  {
for (int i = 0; i < 100; ++i)
  x[i] = y[i] ? z[i] : fallback;
  }

we instead put the masked load in the "else" of the VEC_COND_EXPR:

  mask__36.49_55 = vect__4.48_53 != vect_cst__54;
  vec_mask_and_58 = mask__36.49_55 & loop_mask_52;
  vect_iftmp.52_59 = .MASK_LOAD (vectp_z.50_56, 4B, vec_mask_and_58);
  vect_iftmp.53_62 = VEC_COND_EXPR ;

so we'd need to check that case too, and invert the VEC_COND_EXPR
condition where necessary.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
One could in some awkward way also rewrite the loop to use integer SSE (so
we have access to min/max), relying on zero-filling scalar moves into %xmm
and then using vector integer operations.  Need to split the loads from
the arithmetic for that of course.  With that IACA is more happy (14 uops
for Haswell, throughput 3.5 cycles vs. 4 before).  But this is quite
aggressive "STV".

vmovd  %eax, %xmm10
vmovd  %ebx, %xmm12
.p2align 4,,10
.p2align 3
.L34:
#   addl-8(%r9,%rcx,4), %eax
vmovd   -8(%r9,%rcx,4), %xmm13
vpaddd  %xmm13, %xmm10, %xmm10
#   movl%eax, -4(%r13,%rcx,4)
vmovd   %xmm10, -4(%r13,%rcx,4)
#   movl-8(%r8,%rcx,4), %esi
vmovd   -8(%r8,%rcx,4), %xmm11
#   addl-8(%rdx,%rcx,4), %esi
vmovd   -8(%rdx,%rcx,4), %xmm13
vpaddd  %xmm13, %xmm11, %xmm11
#   cmpl%eax, %esi
#   cmovge  %esi, %eax
vpmaxsd %xmm11, %xmm10, %xmm10
movl%ecx, %esi
#   cmpl%ebx, %eax
#   cmovl   %ebx, %eax
vpmaxsd %xmm12, %xmm10, %xmm10
#   movl%eax, -4(%r13,%rcx,4)
vmovd   %xmm10, -4(%r13,%rcx,4)
incq%rcx
cmpq%rcx, %rdi
jne .L34

Interesting fact is that doing this _improves_ 456.hmmer 9% beyond fixing
the original regression...!

Note I carefully avoided crossing integer/vector boundaries and thus didn't
try to just do the max operation in the vector domain.  At least on AMD
CPUs moving data between integer and FP/vector is slow (IIRC Intel doesn't
care).  With AVX512 can we even do vpadd %eax, %xmm0, %xmm0 (don't care
if %eax is splat or just in lane zero) - IIRC there was support for
'scalar' operands on some ops.

The above experiment also clearly shows integer max/min operations are
desperately missing and cmp + cmov or cmp + branch + move isn't a good
substitute.

Now - isn't STV supposed to handle exactly cases like this?  Well, it
seems it only looks for TImode operations.

Note ICC when tuning for Haswell produces exactly the code we are producing
now (which is slow):

..B1.80:# Preds ..B1.80 ..B1.79
# Execution count [1.25e+01]
movl  4(%r15,%rdi,4), %eax  #146.10
movl  4(%rsi,%rdi,4), %edx  #147.12
addl  4(%r13,%rdi,4), %eax  #146.19
addl  4(%r11,%rdi,4), %edx  #147.20
cmpl  %edx, %eax#149.2
cmovge%eax, %edx#149.2
addl  4(%rbx,%rdi,4), %edx  #148.2
cmpl  $-987654321, %edx #149.2
cmovl %r14d, %edx   #149.2
movl  %edx, 4(%r8,%rdi,4)   #149.26
incq  %rdi  #133.5
cmpq  %rcx, %rdi#133.5
jb..B1.80   # Prob 82%  #133.5

it everywhere uses cmov quite aggressively it seems...

[Bug rtl-optimization/91137] [7/8/9/10 Regression] Wrong code with -O3

[amker at gcc dot gnu.org]

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

--- Comment #10 from bin cheng  ---
Author: amker
Date: Thu Jul 18 08:38:09 2019
New Revision: 273570

URL: https://gcc.gnu.org/viewcvs?rev=273570&root=gcc&view=rev
Log:
PR tree-optimization/91137
* tree-ssa-loop-ivopts.c (struct ivopts_data): New field.
(tree_ssa_iv_optimize_init, alloc_iv, tree_ssa_iv_optimize_finalize):
Init, use and fini the above new field.
(determine_base_object_1): New function.
(determine_base_object): Reimplement using walk_tree.

gcc/testsuite
PR tree-optimization/91137
* gcc.c-torture/execute/pr91137.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr91137.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug target/53633] __attribute__((naked)) should disable -Wreturn-type

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Jul 18 08:22:50 2019
New Revision: 273568

URL: https://gcc.gnu.org/viewcvs?rev=273568&root=gcc&view=rev
Log:
Fix -Wreturn-type for static naked functions in C

This patch extends the fix for PR53633 to include static functions,
which were giving a bogus -Wreturn-type warning for C but not for C++.

2019-07-18  Richard Sandiford  

gcc/c/
PR c/53633
* c-decl.c (finish_function): Check targetm.warn_func_return
before issuing a -Wreturn-type warning.

gcc/testsuite/
* c-c++-common/pr53633-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr53633-2.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/91195] New: [10 regression] incorrect may be used uninitialized smw (272711, 273474]

[dimhen at gmail dot com]

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

Bug ID: 91195
   Summary: [10 regression] incorrect may be used uninitialized
smw (272711, 273474]
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r272711 PASS
r273474 FAIL
r273563 FAIL

$ ~/arch-gcc/gcc_272711/bin/gcc -Werror=maybe-uninitialized -O2 -c x.c -DFOUR
$ ~/arch-gcc/gcc_273474/bin/gcc -Werror=maybe-uninitialized -O2 -c x.c
$ ~/arch-gcc/gcc_273474/bin/gcc -Werror=maybe-uninitialized -O2 -c x.c -DFOUR
x.c: In function ‘foo’:
x.c:15:13: error: ‘Msg[0]’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   15 |  Msg[num++] = m1;
  |  ~~~^~~~
cc1: some warnings being treated as errors

$ cat x.c
int f(char*);

#if defined FOUR
#define FOR_UP_LIMIT 4 // FAIL
#else
#define FOR_UP_LIMIT 3 // PASS
#endif

void foo(char *m1, char* m2)
{
char* Msg[2];
int num = 0;

if(m1)
Msg[num++] = m1;
if(m2)
Msg[num++] = m2;

for (int j = 0; j < FOR_UP_LIMIT; j++) 
switch (j) {
case 0:
if(num == 0 || f(Msg[0]) )
break;
}
}

[Bug middle-end/91190] [10 Regression] ICE on valid code: in hashtab_chk_error, at hash-table.c:137

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-18
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ICE on valid code: in   |[10 Regression] ICE on
   |hashtab_chk_error, at   |valid code: in
   |hash-table.c:137|hashtab_chk_error, at
   ||hash-table.c:137
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The bug is that offset_address etc. do:
  update_temp_slot_address (XEXP (memref, 0), new_rtx);
  new_rtx = change_address_1 (memref, VOIDmode, new_rtx, 1, false);
where the first call inserts new_rtx
(plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int 1599984 [0x16345785d890]))
into a hash table but then change_address_1 modifies that in place when trying
to legitimize that address into:
(plus:DI (reg/f:DI 77 virtual-stack-vars)
(reg:DI 134))
and as that is a different rtx, it has a different hash value, but nothing
removes it from the hash table and reinserts with a new hash, so when we later
try to add that new expression into the hash table with the correct hash, we
run into the hash checking, because there is something equal to it with
different hash.

The following seems to fix it, not sure we can do something better:

--- gcc/function.c.jj   2019-07-10 15:52:56.785588326 +0200
+++ gcc/function.c  2019-07-18 09:40:40.172869182 +0200
@@ -704,7 +704,7 @@ static void
 insert_temp_slot_address (rtx address, class temp_slot *temp_slot)
 {
   struct temp_slot_address_entry *t = ggc_alloc ();
-  t->address = address;
+  t->address = copy_rtx (address);
   t->temp_slot = temp_slot;
   t->hash = temp_slot_address_compute_hash (t);
   *temp_slot_address_table->find_slot_with_hash (t, t->hash, INSERT) = t;

[Bug tree-optimization/91191] vrp and boolean arguments

[rguenth at gcc dot gnu.org]

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

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

[Bug tree-optimization/91191] vrp and boolean arguments

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-18
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The issue is that VRP doesn't handle the way we optimize the union punning:

   :
  _6 = VIEW_CONVERT_EXPR(b_4(D));
  if (_6 > 1)

if we decide to rely on appropriate sign/zero-extending of sub-size precision
entities (otherwise we'd have simplified the VIEW_CONVERT to a simple
conversion) the attached fixes the missed optimzation.

[Bug c/91193] [8/9/10 regression] ICE on invalid: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956

[dimhen at gmail dot com]

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

--- Comment #3 from Dmitry G. Dyachenko  ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think this is a regression?
> /usr/src/gcc-test/obj/gcc/cc1.9 pr91193.c
>  a
> 
> pr91193.c:2: error: ‘a’ redeclared as different kind of symbol
> pr91193.c:1: error: previous declaration of ‘a’ was here
> pr91193.c: In function ‘a’:
> pr91193.c:2: internal compiler error: tree check: expected class ‘type’,
> have ‘declaration’ (function_decl) in grokdeclarator, at c-decl.c:3788
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> 
> I don't have anything older than r9.
> 
> And slightly cleaner
> typedef int a;
> void a() a b;
> also ICEs.

You are right. Sounds like not a regression.
Sorry

[Bug c/91193] [8/9/10 regression] ICE on invalid: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Actually, I have some 3.2 version and that ICEs too (branched in 2002):
pr91193.c:2: `a' redeclared as different kind of symbol

pr91193.c:1: previous declaration of `a'
pr91193.c:2: confused by earlier errors, bailing out

[Bug c/91193] [8/9/10 regression] ICE on invalid: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Why do you think this is a regression?
/usr/src/gcc-test/obj/gcc/cc1.9 pr91193.c
 a

pr91193.c:2: error: ‘a’ redeclared as different kind of symbol
pr91193.c:1: error: previous declaration of ‘a’ was here
pr91193.c: In function ‘a’:
pr91193.c:2: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (function_decl) in grokdeclarator, at c-decl.c:3788
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

I don't have anything older than r9.

And slightly cleaner
typedef int a;
void a() a b;
also ICEs.

[Bug preprocessor/91192] [9/10 regression] non-deterministic ICE on invalid

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |9.2
Summary|[9 regression]  |[9/10 regression]
   |non-deterministic ICE on|non-deterministic ICE on
   |invalid |invalid

[Bug ipa/91194] New: A suspicious condition in recursive_inlining

[fxue at os dot amperecomputing.com]

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

Bug ID: 91194
   Summary: A suspicious condition in recursive_inlining
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

A piece of code n recursive_inlining()/ipa-inline.c:

  while (!heap.empty ())
{
  struct cgraph_edge *curr = heap.extract_min ();
  struct cgraph_node *cnode, *dest = curr->callee;

  if (!can_inline_edge_p (curr, true)
  || can_inline_edge_by_limits_p (curr, true))
continue;

The second condition does not seem be logical, should it be
"!can_inline_edge_by_limits_p (curr, true)"?

[Bug c/91193] [8 regression] ICE on invalid: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |8.4