[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer

[jakub at gcc dot gnu.org]

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

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

[Bug other/92274] New: 'make' fails when objdir and srcdir paths contain spaces

[heiko at hexco dot de]

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

Bug ID: 92274
   Summary: 'make' fails when objdir and srcdir paths contain
spaces
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: heiko at hexco dot de
  Target Milestone: ---

When compiling gcc 9.2.0 on Ubuntu 18.04, I have to use a base path that
contains spaces.

"configure --enable-checking=all,extra" has worked, but during make
bash complains about "No such file or directory".

'/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build' is the directory
i created next to the toplevel directory gcc-9.2.0.

Seems there is some quoting missing. The problem should be easily reproducable.

make gives

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
/bin/bash: line 0: test: /media/heiko/TOSHIBA: binary operator expected
make[2]: Entering directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
make[3]: Entering directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
rm -f stage_current
make[3]: Leaving directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
make[2]: Leaving directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
make[2]: Entering directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
Configuring stage 1 in ./intl
/bin/bash: /media/heiko/TOSHIBA: No such file or directory
Makefile:6382: recipe for target 'configure-stage1-intl' failed
make[2]: *** [configure-stage1-intl] Error 127
make[2]: Leaving directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
Makefile:24054: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/media/heiko/TOSHIBA EXT/Heikos/debug_gcc/build'
Makefile:993: recipe for target 'all' failed
make: *** [all] Error 2



I suggest, you use a base directory with spaces as one of your test settings.

Thanks and best regards,
Heiko Eißfeldt

[Bug bootstrap/11776] configure from path with spaces does not work

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||heiko at hexco dot de

--- Comment #4 from Andrew Pinski  ---
*** Bug 92274 has been marked as a duplicate of this bug. ***

[Bug bootstrap/92274] 'make' fails when objdir and srcdir paths contain spaces

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 11776.  It was decided it was too hard to fix because shell
scripting is hard that way :).

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

[Bug testsuite/92127] [10 regression] gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails after r276645 on power7

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
(In reply to Richard Biener from comment #2)
> I suggest to make the test less dependent on unrolling by placing
> 
> #pragma GCC unroll 0
> 
> before the inner loop which is likely unrolled now.  I wonder whether
> the test tests profitability of outer loop vectorization (likely
> not profitable)?  I see rs6000 adjusts unroll parameters as well.

Confirmed that the inner loop is completely unrolled after the suspected
commit. I checked the dump details, the test is to test the inner loop
profitable or not, the outer loop vectorization fail far ahead of profit
determination.

/home/linkw/gcc/gcc-git-base/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c:18:20:
missed:   versioning for alias required: can't determine dependence between *_7
and *_11
consider run-time aliasing test between *_7 and *_11
/home/linkw/gcc/gcc-git-base/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c:18:20:
missed:   runtime alias check not supported for outer loop.
/home/linkw/gcc/gcc-git-base/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c:13:4:
missed:  bad data dependence.
/home/linkw/gcc/gcc-git-base/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c:13:4:
missed: couldn't vectorize loop

[Bug modula2/92148] gm2: race condition building gm2 on trunk

[gaiusmod2 at gmail dot com]

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

--- Comment #1 from Gaius Mulley  ---
is this still true?  As I've git pushed a number of dependency fixes to the
master branch (in gm2/Make-lang.in).  It built with make -j 24 on amd64 debian
stretch.

[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-30
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug tree-optimization/92275] New: [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[marxin at gcc dot gnu.org]

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

Bug ID: 92275
   Summary: [10 Regression] ICE: error: definition in block 11
does not dominate use in block 15 since r277566
   Product: gcc
   Version: 10.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
  Target Milestone: ---

Following code snippet is reduced from 527.cam4_r SPEC 2017 benchmark:

$ cat ice.i
unsigned long a, c;
int *b, *b2;
long d;

void fn1() {
  for (; b < b2; b++)
d += *b * c;
  d *= a;
}

$ gcc -O3 -march=znver2 ice.i -c
ice.i: In function ‘fn1’:
ice.i:5:6: error: definition in block 11 does not dominate use in block 15
5 | void fn1() {
  |  ^~~
for SSA_NAME: _92 in statement:
prephitmp_51 = PHI <_92(15), _52(8)>
PHI argument
_92
for PHI node
prephitmp_51 = PHI <_92(15), _52(8)>
during GIMPLE pass: vect
ice.i:5:6: internal compiler error: verify_ssa failed
0xfe7b6e verify_ssa(bool, bool)
/home/marxin/Programming/gcc/gcc/tree-ssa.c:1208
0xcedfa5 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1990
0xceec4e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/92276] New: Embedded __attribute__ ((optimize("unroll-loops"))) is not working together with '__attribute__ ((__always_inline__))'

[Lijian.Zhang at arm dot com]

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

Bug ID: 92276
   Summary: Embedded __attribute__ ((optimize("unroll-loops"))) is
not working together with '__attribute__
((__always_inline__))'
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Lijian.Zhang at arm dot com
  Target Milestone: ---

Dear experts,
I'm trying to use '__attribute__ ((optimize("unroll-loops")))' to apply
automatic loop unrolling to a static-line function with __attribute__
((__always_inline__)).
But the loop is not unrolled from the assembly output. The compiling command is
'gcc -march=armv8-a+crc -O2 -W -Wall -mtune=cortex-a72 unroll.c -S'. 

However, if I apply -funroll-loops option to the compiling process, i.e.,
compile with command 'gcc -march=armv8-a+crc -O2 -W -Wall -mtune=cortex-a72
-funroll-loops unroll.c -S'. I can see loop is unrolled from the assembly
output.

And if I compile without -funroll-loops option, and if '__attribute__
((__always_inline__))' is commented out, '__attribute__ ((__always_inline__))'
is also taking effect.

So it seems those two attribute parameters are not working together, which
seems to be unreasonable to me. I want some functions to be inlined and also
the loops inside those functions unrolled automatically, as the loop iteration
number is fixed.

lijian@net-arm-d05-08:~/C/unroll$ gcc --version
gcc (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
Copyright (C) 2018 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.

lijian@net-arm-d05-08:~/C/unroll$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/";
SUPPORT_URL="https://help.ubuntu.com/";
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

lijian@net-arm-d05-08:~/C/unroll$ gcc -march=armv8-a+crc -O2 -W -Wall
-mtune=cortex-a72 unroll.c -S

lijian@net-arm-d05-08:~/C/unroll$ lscpu
Architecture:aarch64
Byte Order:  Little Endian
CPU(s):  64
On-line CPU(s) list: 0-63
Thread(s) per core:  1
Core(s) per socket:  32
Socket(s):   2
NUMA node(s):4
Vendor ID:   ARM
Model:   2
Model name:  Cortex-A72
Stepping:r0p2
BogoMIPS:100.00
L1d cache:   32K
L1i cache:   48K
L2 cache:1024K
L3 cache:16384K
NUMA node0 CPU(s):   0-15
NUMA node1 CPU(s):   16-31
NUMA node2 CPU(s):   32-47
NUMA node3 CPU(s):   48-63
Flags:   fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid



#include 
#include 
#include 

static inline __attribute__ ((__always_inline__))
__attribute__ ((optimize("unroll-loops")))
unsigned int clib_crc32c (unsigned int v, unsigned char * s, int len)
{
  for (; len >= 8; len -= 8, s += 8)
v = __crc32cd (v, *((unsigned long *) s));

  for (; len >= 4; len -= 4, s += 4)
v = __crc32cw (v, *((unsigned int *) s));

  for (; len >= 2; len -= 2, s += 2)
v = __crc32ch (v, *((unsigned short *) s));

  for (; len >= 1; len -= 1, s += 1)
v = __crc32cb (v, *((unsigned char *) s));

  return v;
}

int main (int argc, char *argv[])
{
unsigned char s[40] = {argc, 0, argc, 0};
unsigned char ss[32] = {argc, 0, argc, 0, argc, 0};
unsigned int v = 0xbeefdead, vv = 0xdeadbeef;
int len = strtol (argv[1], NULL, 10);

for (int i = 0; i < len; i++) {
v = clib_crc32c (v, s, 40);
vv = clib_crc32c (vv, ss, 32);
}

printf ("%8X\n", v);
printf ("%8X\n", vv);
return 0;
}

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

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

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

gcc-bugs at marehr dot dialup.fu-berlin.de changed:

   What|Removed |Added

 CC||gcc-bugs at marehr dot 
dialup.fu-b
   ||erlin.de

--- Comment #6 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
```c++

#include 

template  struct is_swappable_with;

template )>
using iter_reference_t_ = R;

template  using iter_reference_t = iter_reference_t_;
template 
std::enable_if_t<
is_swappable_with, iter_reference_t>::value>
operator00;

```

Another one, reduced from range-v3.

[Bug c/92276] Embedded __attribute__ ((optimize("unroll-loops"))) is not working together with '__attribute__ ((__always_inline__))'

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Instead of trying to force the compiler to unroll with -funroll-loops you can
use #pragma GCC unroll N on individual loops instead.

The attributes should not conflict in any way.

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-10/msg01839.ht
   ||ml

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
I posted a patch last week but just realised I forgot to link to it here.
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01839.html

[Bug c/92276] Embedded __attribute__ ((optimize("unroll-loops"))) is not working together with '__attribute__ ((__always_inline__))'

[Lijian.Zhang at arm dot com]

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

--- Comment #2 from Lijian Zhang  ---
(In reply to Richard Biener from comment #1)
> Instead of trying to force the compiler to unroll with -funroll-loops you can
> use #pragma GCC unroll N on individual loops instead.
> 
> The attributes should not conflict in any way.

Sorry, I made a mistake that in my case '__attribute__
((optimize("unroll-loops")))' should be used for the caller, not the callee.
#pragma GCC optimize ("unroll-loops") is also working.
Thanks for your suggestion!

/
#include 
#include 
#include 

static inline __attribute__ ((__always_inline__))
unsigned int clib_crc32c (unsigned int v, unsigned char * s, int len)
{
  for (; len >= 8; len -= 8, s += 8)
v = __crc32cd (v, *((unsigned long *) s));

  for (; len >= 4; len -= 4, s += 4)
v = __crc32cw (v, *((unsigned int *) s));

  for (; len >= 2; len -= 2, s += 2)
v = __crc32ch (v, *((unsigned short *) s));

  for (; len >= 1; len -= 1, s += 1)
v = __crc32cb (v, *((unsigned char *) s));

  return v;
}

__attribute__ ((optimize("unroll-loops")))
int main (int argc, char *argv[])
{
unsigned char s[40] = {argc, 0, argc, 0};
unsigned char ss[32] = {argc, 0, argc, 0, argc, 0};
unsigned int v = 0xbeefdead, vv = 0xdeadbeef;
int len = strtol (argv[1], NULL, 10);

v = clib_crc32c (v, s, 40);
vv = clib_crc32c (vv, ss, 32);

printf ("%8X\n", v);
printf ("%8X\n", vv);
return 0;
}

[Bug c/92276] Embedded __attribute__ ((optimize("unroll-loops"))) is not working together with '__attribute__ ((__always_inline__))'

[Lijian.Zhang at arm dot com]

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

Lijian Zhang  changed:

   What|Removed |Added

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

--- Comment #3 from Lijian Zhang  ---
In my case, the callee is defined with '__attribute__ ((__always_inline__))',
and I want to apply automatic loop unrolling. The '__attribute__
((optimize("unroll-loops")))' has to be added for the caller, not the callee.

[Bug fortran/92277] New: ICE with assumed rank

[jrfsousa at gmail dot com]

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

Bug ID: 92277
   Summary: ICE with assumed rank
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 47129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47129&action=edit
Code triggering ICE

Hi all!

Internal compiler error with assumed rank arguments.

GNU Fortran (GCC) 10.0.0 20191028 (experimental)

Not present in GNU Fortran (GCC) 9.1.0

Command line:

gfortran -c ./arr.f90

Compiler output:

./arr.f90:19:0:

   19 | call arr_set_c(this)
  | 
internal compiler error: tree check: expected tree that contains ‘decl common’
structure, have ‘indirect_ref’ in gfc_conv_gfc_desc_to_cfi_desc, at
fortran/trans-expr.c:5261
0x6f65d5 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc-trunk/gcc/tree.c:10099
0x5ff3be contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.h:3381
0x5ff3be gfc_conv_gfc_desc_to_cfi_desc
../../gcc-trunk/gcc/fortran/trans-expr.c:5261
0x8b04d2 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-trunk/gcc/fortran/trans-expr.c:6153
0x8ead27 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/fortran/trans-stmt.c:406
0x86e1db trans_code
../../gcc-trunk/gcc/fortran/trans.c:1920
0x89bbce gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6791
0x8721f1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:2250
0x81b5e5 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6263
0x81b5e5 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6515
0x86b11f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:208
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Thank you very much.

Best regards,
José Rui

[Bug c/92276] Embedded __attribute__ ((optimize("unroll-loops"))) is not working together with '__attribute__ ((__always_inline__))'

[Lijian.Zhang at arm dot com]

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

--- Comment #4 from Lijian Zhang  ---
(In reply to Richard Biener from comment #1)
> Instead of trying to force the compiler to unroll with -funroll-loops you can
> use #pragma GCC unroll N on individual loops instead.
> 
> The attributes should not conflict in any way.

Hi Richard,
Does it make sense to you that '__attribute__ ((optimize("unroll-loops")))' has
to be moved ahead of the caller, if the callee is defined with '__attribute__
((__always_inline__))'?

Thanks.

[Bug ipa/92278] New: [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616

[dimhen at gmail dot com]

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

Bug ID: 92278
   Summary: [10 regression] LTO ICE
ipa_get_ith_polymorhic_call_context ipa-prop.h:616
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r277460 PASS
r277486 FAIL as PR92242
r277504 FAIL
r277576 FAIL

$ cat a.i
typedef enum a b;
unsigned f2(b *, int);

void f1(void* i, void* j) {
  (void) i;
  (void) j;
  f2(0, 0);
}

$ cat b.i
typedef unsigned (*c)(void *, void *);
typedef struct {
  c d;
} e;

unsigned f1(void *, void *);
static const e f[] = {{f1}};

const e *foo() { return f; }

$ cat c.i
int g(int, int, int, unsigned char *, int);
void a(void *, void *);

typedef struct {
  int b;
} c;
typedef struct {
  c d;
} e;

static int h(unsigned char *i, int j, int *k, int l) {
  int ae = j;
  j = ae;
  g(0, 0, 0, i, 0);
  if (l)
a(k, 0);
  return 0;
}
static int am(void) { return 0; }
static int ar(c *i) {
  int as = i->b;
  h(0, as, 0, 0);
  return 0;
}
unsigned f2(e *i, int j) {
  (void) j;
  am();
  ar(&i->d);
  return 0;
}

$ cat x.ver
{ global:
foo;
local: *; };

$ gcc -fpreprocessed -O2 -flto -c a.i b.i c.i

$ gcc -flto -fPIC -DPIC -shared a.o b.o c.o -Wl,-version-script -Wl,x.ver -o
libx.so
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xdd458f crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0xbef32b ipa_get_ith_polymorhic_call_context
/home/dimhen/src/gcc_current/gcc/ipa-prop.h:616
0xbef32b update_jump_functions_after_inlining
/home/dimhen/src/gcc_current/gcc/ipa-prop.c:2671
0xbf00e3 propagate_info_to_inlined_callees
/home/dimhen/src/gcc_current/gcc/ipa-prop.c:3555
0x16f7a8c inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:488
0x16f13b2 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x16f13b2 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x16f13b2 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/local/binutils_current/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
We run into

  tree guard_arg = find_guard_arg (loop, epilog, update_phi);
  /* If the var is live after loop but not a reduction, we simply
 use the old arg.  */
  if (!guard_arg)
guard_arg = old_arg;

which means we failed to generate a LC PHI for the LIVE stmt during
peeling.  Then epilogue creation simply does

  /* Find the loop-closed-use at the loop exit of the original scalar
 result.  (The reduction result is expected to have two immediate uses,
 one at the latch block, and one at the loop exit).  For double
 reductions we are looking for exit phis of the outer loop.  */
  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, scalar_dest)
{

but doesn't do any dominance sanity checks that it found a valid PHI
(it simply assumes LC SSA is correct).

[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'm bisecting that right now...

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 30 09:21:09 2019
New Revision: 277603

URL: https://gcc.gnu.org/viewcvs?rev=277603&root=gcc&view=rev
Log:
2019-10-30  Richard Biener  

PR tree-optimization/65930
* tree-vect-loop.c (vect_is_simple_reduction): For reduction
chains also allow a leading and trailing conversion.
* tree-vect-slp.c (vect_get_and_check_slp_defs): Handle
intermediate reduction chains.
(vect_analyze_slp_instance): Likewise.  Build a SLP
node for a trailing conversion manually.

* gcc.dg/vect/pr65930-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65930-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c

[Bug libstdc++/92272] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-30
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Yes, there is still work to do.

The concept is correct, the problem is the __normal_iterator type.

[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||hubicka at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Also started with r277484, so probably a DUP of PR92254?

[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #3 from Jan Hubicka  ---
Since there is no -O0 code here involved I am not sure why the summary gone
missing.  We probably should debug that. I think my today patch silences the
ICE however.

Martin, do you have any idea?

[Bug ipa/92254] [10 regression] ICE LTO in inline_small_functions, at ipa-inline.c:2000

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #3 from Jan Hubicka  ---
Similarly here. It seems like previoulsy latent bug showing up now.

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Martin Liška from comment #2)
> Created attachment 46775 [details]
> Reduced source files
> 
> $ gcc -c -flto 5.i -o 5.o && c++ -O2 -flto=16 -shared -o zynaddsubfx 1.ii
> 2.ii 3.ii 4.ii 5.o
> ...
> 1.ii: In member function ‘activeDesc’:
> 1.ii:37:31: error: invalid conversion in gimple call
>37 | NotePool::constActiveDescIter NotePool::activeDesc() const {
>   |   ^
> struct constActiveDescIter
> 
> struct activeDescIter
> 
> # .MEM_4 = VDEF <.MEM_3(D)>
> retval.0 = activeDesc (this_2(D)); [tail call]
> during GIMPLE pass: fixup_cfg
> 1.ii:37:31: internal compiler error: verify_gimple failed
> 0xcd4991 verify_gimple_in_cfg(function*, bool)
>   /home/marxin/Programming/gcc/gcc/tree-cfg.c:5427
> 0xbb3cef execute_function_todo
>   /home/marxin/Programming/gcc/gcc/passes.c:1983
> 0xbb4a9e execute_todo
>   /home/marxin/Programming/gcc/gcc/passes.c:2037
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make: *** [/tmp/cc4IuhNp.mk:5: /tmp/zynaddsubfx.Q6TfM0.ltrans1.ltrans.o]
> Error 1
> make: *** Waiting for unfinished jobs
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status

This issue is gone since r276416.

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
probably just need -fno-inline-functions and --param inline-insns-auto-O2= to reproduce again?

Honza

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to David Binderman from comment #7)
> After much slow reduction, the reduced C++ source code seems
> to be
> 
> class b;
> struct c {
>   using aj = b *;
> };
> struct d {
>   using aj = c::aj;
> };
> struct f {
>   using aj = d::aj;
> };
> template  f::aj ap(ao);
> template  class g {
> public:
>   aq begin();
>   aq end();
> };
> class av {
> public:
>   virtual int *aw(unsigned long);
> };
> template  struct h {
>   long ba;
>   av bb;
>   void bc() { ba = long((&bb->*ay)(1)); }
> };
> using bd = h;
> class b {
>   struct i {
> bd bf;
> void bg() { bf.bc(); }
>   };
> 
> public:
>   using bh = int *;
>   using bi = g;
>   i bj;
>   bi bases() { bj.bg(); }
> };
> class j {
>   virtual bool bl(const int *, unsigned, int, int, int);
> };
> class k : j {
>   bool bl(const int *l, unsigned, int, int, int) {
> auto e = ap(l);
> for (int a : e->bases())
>   ;
>   }
> };
> void bp() { k(); }

This is dup of PR92201 which is fixed now.

[Bug fortran/92277] [10 Regression] ICE with assumed rank in gfc_conv_gfc_desc_to_cfi_desc

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
Summary|ICE with assumed rank   |[10 Regression] ICE with
   ||assumed rank in
   ||gfc_conv_gfc_desc_to_cfi_de
   ||sc
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
The problem is the check in gfc_conv_gfc_desc_to_cfi_desc:

  if (type && DECL_ARTIFICIAL (parmse->expr)
  && type != gfc_get_element_type (TREE_TYPE (parmse->expr)))

As parmse->expr is "*this" – i.e. we have an "indirect_ref" to "parm_decl
this";
the actual decl is at "TREE_OPERAND (parmse->expr, 0)".

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Jan Hubicka from comment #10)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
> probably just need -fno-inline-functions and --param
> inline-insns-auto-O2= to reproduce again?
> 
> Honza

Apparently I can't reproduce that again :/

[Bug tree-optimization/92262] [10 Regression] ICE: verify_gimple failed (error: incorrect sharing of tree nodes)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Oct 30 09:52:01 2019
New Revision: 277605

URL: https://gcc.gnu.org/viewcvs?rev=277605&root=gcc&view=rev
Log:
PR tree-optimization/92262
* tree-ssa-loop-ivopts.c (get_debug_computation_at): Don't unshare
ubase or cbase here.
(remove_unused_ivs): Unshare comp before using it.

* g++.dg/opt/pr92262.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr92262.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug lto/92279] New: [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[marxin at gcc dot gnu.org]

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

Bug ID: 92279
   Summary: [10 Regression] ICE in error: non-trivial conversion
in 'constructor' since r276416
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE in godot project:

thirdparty/bullet/LinearMath/btConvexHullComputer.cpp: In function
'_ZN20btConvexHullInternal14getOrientationEPKNS_4EdgeES2_RKNS_7Point32ES5_.part.0':
thirdparty/bullet/LinearMath/btConvexHullComputer.cpp:1399:35: error:
non-trivial conversion in 'constructor'
 1399 | btConvexHullInternal::Orientation
btConvexHullInternal::getOrientation(const Edge* prev, const Edge* next, const
Point32& s, const Point32& t)
  |   ^
struct Point64
struct Point64
# .MEM_100 = VDEF <.MEM_37(D)>
n ={v} {CLOBBER};
thirdparty/bullet/LinearMath/btConvexHullComputer.cpp:1399:35: error:
non-trivial conversion in 'constructor'
struct Point64
struct Point64
# .MEM_104 = VDEF <.MEM_46>
m ={v} {CLOBBER};
during GIMPLE pass: fixup_cfg
thirdparty/bullet/LinearMath/btConvexHullComputer.cpp:1399:35: internal
compiler error: verify_gimple failed
0xd025b1 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5427
0xbe02df execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1983
0xbe108e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037

It will take me some time to reduce it. So I would like to see first PR91576
fixed.

[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
 CC||hubicka at gcc dot gnu.org
  Known to work||9.2.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91576
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Martin Liška from comment #3)
> Created attachment 46781 [details]
> Test-case #2
> 
> Since the same revision I see similar error:
> 
> $ g++ -flto -O2 *.ii 
> 1.ii:14:3: warning: type ‘struct differential3’ violates the C++ One
> Definition Rule [-Wodr]
>14 | } differential3;
>   |   ^
> 2.ii:17:3: note: a different type is defined in another translation unit
>17 | } differential3;
>   |   ^
> 1.ii:12:5: note: the first difference of corresponding definitions is field
> ‘dx’
>12 |   A dx;
>   | ^
> 2.ii:15:5: note: a field of same name but different type is defined in
> another translation unit
>15 |   A dx;
>   | ^
> 1.ii:1:33: note: type name ‘A’ should match type name ‘ccl::A’
> 1 | struct __attribute__((aligned)) A {};
>   | ^
> 2.ii:2:33: note: the incompatible type is defined here
> 2 | struct __attribute__((aligned)) A {
>   | ^
> 1.ii:15:8: warning: type ‘struct C’ violates the C++ One Definition Rule
> [-Wodr]
>15 | struct C {
>   |^
> 2.ii:18:8: note: a different type is defined in another translation unit
>18 | struct C {
>   |^
> 1.ii:16:5: note: the first difference of corresponding definitions is field
> ‘P’
>16 |   A P;
>   | ^
> 2.ii:19:5: note: a field of same name but different type is defined in
> another translation unit
>19 |   A P;
>   | ^
> 1.ii:1:33: note: type name ‘A’ should match type name ‘ccl::A’
> 1 | struct __attribute__((aligned)) A {};
>   | ^
> 2.ii:2:33: note: the incompatible type is defined here
> 2 | struct __attribute__((aligned)) A {
>   | ^
> 1.ii:3:8: warning: type ‘struct B’ violates the C++ One Definition Rule
> [-Wodr]
> 3 | struct B {
>   |^
> 2.ii:6:8: note: a different type is defined in another translation unit
> 6 | struct B {
>   |^
> 1.ii:4:5: note: the first difference of corresponding definitions is field
> ‘diffuse’
> 4 |   A diffuse;
>   | ^
> 2.ii:7:5: note: a field of same name but different type is defined in
> another translation unit
> 7 |   A diffuse;
>   | ^
> 1.ii:1:33: note: type name ‘A’ should match type name ‘ccl::A’
> 1 | struct __attribute__((aligned)) A {};
>   | ^
> 2.ii:2:33: note: the incompatible type is defined here
> 2 | struct __attribute__((aligned)) A {
>   | ^
> lto1: error: ‘TYPE_CANONICAL’ is not compatible
>   size  bitsizetype> constant 17664>
> unit-size  sizetype> constant 2208>
> user align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fbd73a87498
> fields  type  PathState>
> BLK
> size 
> unit-size 
> align:32 warn_if_not_align:0 symtab:0 alias-set -1
> structural-equality domain >
> nonlocal BLK 1.ii:47:13 size 
> unit-size 
> align:32 warn_if_not_align:0 offset_align 128
> offset 
> bit-offset  context
> 
> chain  0x7fbd73c955e8 int>
> nonlocal SI 1.ii:48:7
> size 
> unit-size 
> align:32 warn_if_not_align:0 offset_align 128 offset
>  bit-offset 
> context  chain
> >> context  ccl>>
>   size  bitsizetype> constant 17664>
> unit-size  sizetype> constant 2208>
> user align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fbd73a87498
> fields  type  PathState>
> BLK
> size 
> unit-size 
> align:32 warn_if_not_align:0 symtab:0 alias-set -1
> structural-equality domain >
> nonlocal BLK 2.ii:50:13 size 
> unit-size 
> align:32 warn_if_not_align:0 offset_align 128
> offset 
> bit-offset  context
> 
> chain  0x7fbd73c955e8 int>
> nonlocal SI 2.ii:51:7
> size 
> unit-size 
> align:32 warn_if_not_align:0 offset_align 128 offset
>  bit-offset 
> context  chain
> >> context  ccl>
> pointer_to_this >
> lto1: internal compiler error: ‘verify_type’ failed
> 0xf5a148 verify_type(tree_node const*)
>   ../../gcc/tree.c:14775
> 0x7ec407 lto_fixup_state
>   ../../gcc/lto/lto-common.c:2582
> 0x7f6f84 lto_fixup_decls
>   ../../gcc/lto/lto-common.c:2613
> 0x7f6f84 read_cgraph_and_symbols(unsigned int, char const**)
>   ../../gcc/lto/lto-common.c:2848
> 0x7dd692 lto_main()
>   ../../gcc/lto/lto.c:616
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> lto-wrapper: fatal error: g++ returned 1 exit status
> compilation terminated.
> /usr/bin/

[Bug target/92280] New: [10 regression] gcc.target/i386/pr83008.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 92280
   Summary: [10 regression] gcc.target/i386/pr83008.c FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*

Between 20191028 (r277527) and 20191029 (r277579), the
gcc.target/i386/pr83008.c
regressed:

+FAIL: gcc.target/i386/pr83008.c scan-assembler-not vmovdq(a|u)(32|64)

I'm seeing it for 32 and 64-bit Solaris/x86, happens on other x86 targets, too.

[Bug target/92280] [10 regression] gcc.target/i386/pr83008.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug lto/88220] LTO ICE with GNU inline and alias's

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Wed Oct 30 10:38:52 2019
New Revision: 277607

URL: https://gcc.gnu.org/viewcvs?rev=277607&root=gcc&view=rev
Log:
Use symtab_node::order in LTO sections with body.

2019-10-30  Martin Liska  

PR lto/91393
PR lto/88220
* cgraph.c (cgraph_node::get_create): Overwrite node->order
from a first_clone in order to get proper LTO section
in LTO stream.
(cgraph_node::get_untransformed_body):
Use lto_get_section_data where symtab_node::order
must be provided.
* cgraphclones.c (cgraph_node::find_replacement):
Update also symbol order.
* ipa-fnsummary.c (ipa_fn_summary_read):
Use new function lto_get_summary_section_data.
* ipa-hsa.c (ipa_hsa_read_summary): Likewise.
* ipa-icf.c (sem_item_optimizer::read_summary):
Likewise.
* ipa-prop.c (ipa_prop_read_jump_functions):
Likewise.
(ipcp_read_transformation_summaries): Likewise.
* ipa-sra.c (ipa_sra_read_summary): Likewise.
* lto-cgraph.c (input_node): Add also order_base.
(input_varpool_node): Likewise.
(input_cgraph_1): Assign the order_base.
(input_cgraph_opt_summary): Use new lto_get_summary_section_data.
* lto-opts.c (lto_write_options): Pass new argument.
* lto-section-in.c (lto_get_section_data): Add new argumente order.
(lto_get_summary_section_data): New.
(lto_get_raw_section_data): Add order argument.
(lto_create_simple_input_block): Likewise.
* lto-section-out.c (lto_destroy_simple_output_block):
Likewise.
* lto-streamer-in.c (lto_input_toplevel_asms):
Use lto_get_summary_section_data.
(lto_input_mode_table): Likewise.
* lto-streamer-out.c (produce_asm): Pass symtab_node::order.
(lto_output_toplevel_asms): Pass new argument.
(copy_function_or_variable): Likewise.
(produce_lto_section):Likewise.
(produce_symtab): Likewise.
(lto_write_mode_table): Likewise.
(produce_asm_for_decls): Likewise.
* lto-streamer.c (lto_get_section_name): Concat symbol name
and symbol order.
* lto-streamer.h (lto_get_section_data): Add order argument.
(lto_get_summary_section_data): New.
(lto_get_raw_section_data): Add order argument.
(lto_get_section_name): Likewise.
* varpool.c (varpool_node::get_constructor): Pass order argument.
2019-10-30  Martin Liska  

PR lto/91393
PR lto/88220
* lto-common.c (lto_file_finalize): Use lto_get_summary_section_data.
(get_section_data): Add order argument.
2019-10-30  Martin Liska  

PR lto/91393
PR lto/88220
* gcc.dg/lto/pr91393_0.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr91393_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraphclones.c
trunk/gcc/ipa-fnsummary.c
trunk/gcc/ipa-hsa.c
trunk/gcc/ipa-icf.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-sra.c
trunk/gcc/lto-cgraph.c
trunk/gcc/lto-opts.c
trunk/gcc/lto-section-in.c
trunk/gcc/lto-section-out.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/lto-streamer.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c

[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Author: marxin
Date: Wed Oct 30 10:38:52 2019
New Revision: 277607

URL: https://gcc.gnu.org/viewcvs?rev=277607&root=gcc&view=rev
Log:
Use symtab_node::order in LTO sections with body.

2019-10-30  Martin Liska  

PR lto/91393
PR lto/88220
* cgraph.c (cgraph_node::get_create): Overwrite node->order
from a first_clone in order to get proper LTO section
in LTO stream.
(cgraph_node::get_untransformed_body):
Use lto_get_section_data where symtab_node::order
must be provided.
* cgraphclones.c (cgraph_node::find_replacement):
Update also symbol order.
* ipa-fnsummary.c (ipa_fn_summary_read):
Use new function lto_get_summary_section_data.
* ipa-hsa.c (ipa_hsa_read_summary): Likewise.
* ipa-icf.c (sem_item_optimizer::read_summary):
Likewise.
* ipa-prop.c (ipa_prop_read_jump_functions):
Likewise.
(ipcp_read_transformation_summaries): Likewise.
* ipa-sra.c (ipa_sra_read_summary): Likewise.
* lto-cgraph.c (input_node): Add also order_base.
(input_varpool_node): Likewise.
(input_cgraph_1): Assign the order_base.
(input_cgraph_opt_summary): Use new lto_get_summary_section_data.
* lto-opts.c (lto_write_options): Pass new argument.
* lto-section-in.c (lto_get_section_data): Add new argumente order.
(lto_get_summary_section_data): New.
(lto_get_raw_section_data): Add order argument.
(lto_create_simple_input_block): Likewise.
* lto-section-out.c (lto_destroy_simple_output_block):
Likewise.
* lto-streamer-in.c (lto_input_toplevel_asms):
Use lto_get_summary_section_data.
(lto_input_mode_table): Likewise.
* lto-streamer-out.c (produce_asm): Pass symtab_node::order.
(lto_output_toplevel_asms): Pass new argument.
(copy_function_or_variable): Likewise.
(produce_lto_section):Likewise.
(produce_symtab): Likewise.
(lto_write_mode_table): Likewise.
(produce_asm_for_decls): Likewise.
* lto-streamer.c (lto_get_section_name): Concat symbol name
and symbol order.
* lto-streamer.h (lto_get_section_data): Add order argument.
(lto_get_summary_section_data): New.
(lto_get_raw_section_data): Add order argument.
(lto_get_section_name): Likewise.
* varpool.c (varpool_node::get_constructor): Pass order argument.
2019-10-30  Martin Liska  

PR lto/91393
PR lto/88220
* lto-common.c (lto_file_finalize): Use lto_get_summary_section_data.
(get_section_data): Add order argument.
2019-10-30  Martin Liska  

PR lto/91393
PR lto/88220
* gcc.dg/lto/pr91393_0.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr91393_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraphclones.c
trunk/gcc/ipa-fnsummary.c
trunk/gcc/ipa-hsa.c
trunk/gcc/ipa-icf.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-sra.c
trunk/gcc/lto-cgraph.c
trunk/gcc/lto-opts.c
trunk/gcc/lto-section-in.c
trunk/gcc/lto-section-out.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/lto-streamer.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c

[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
Fixed on trunk.

[Bug lto/88220] LTO ICE with GNU inline and alias's

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug target/92269] Profiling (-p) does not work on H8

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
It's very legacy code.
David is it you who wrote the code?

[Bug tree-optimization/92262] [10 Regression] ICE: verify_gimple failed (error: incorrect sharing of tree nodes)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
I also see this problem while trying to build file libgfortran/caf/single.c 
with compiler flag -O3 on revision 277600.

I'll have a go at a workaround of using -O2 on the bootstrap.

I suspect a useful weekly sanity check would be a bootstrap with
-O3 over c,c++ and fortran.

Martin's code snippet compiles fine with revision 277550 and -O3,
so the new problem looks recent.

[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Yes, as mentioned in the bug title, it started with r277566.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #32 from Richard Biener  ---
Fixed for GCC 10.

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

[rguenth at gcc dot gnu.org]

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

Bug 65930 Summary: Reduction with sign-change not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

   What|Removed |Added

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

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

[rguenth at gcc dot gnu.org]

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

Bug 65930 Summary: Reduction with sign-change not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

   What|Removed |Added

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

[Bug target/92280] [10 regression] gcc.target/i386/pr83008.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed, probably escaped my testing.  The testcase has

  for (int i = 0; i < 4; i++)
{
  int t0 = tmp[0][i] + tmp[1][i];
  int t1 = tmp[0][i] - tmp[1][i];
  int t2 = tmp[2][i] + tmp[3][i];
  int t3 = tmp[2][i] - tmp[3][i];
  a0 = t0 + t2;
  a2 = t0 - t2; 
  a1 = t1 + t3; 
  a3 = t1 - t3;
  sum += (a0) + (a1) + (a2) + (a3);
}

which is now vectorized.

[Bug rtl-optimization/92281] New: Inconsistent canonicalization of (minus (minus A B) C)

[rearnsha at gcc dot gnu.org]

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

Bug ID: 92281
   Summary: Inconsistent canonicalization of (minus (minus A B) C)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
CC: segher at kernel dot crashing.org
  Target Milestone: ---

Here are two combine attempts from a simple testcase:

arm-none-eabi-gcc -O2 -marm -mcpu=arm7tdmi

typedef unsigned long long t64;

t64 f1(t64 a, t64 b) { return a + ~b; }

Trying 19 -> 8:
   19: r119:SI=r127:SI
  REG_DEAD r127:SI
8: r125:SI=r119:SI-ltu(cc:CC,0)-r121:SI
  REG_DEAD r121:SI
  REG_DEAD r119:SI
  REG_DEAD cc:CC
Failed to match this instruction:
(set (reg:SI 125 [+4 ])
(minus:SI (minus:SI (reg:SI 127)
(reg:SI 121 [ b+4 ]))
(ltu:SI (reg:CC 100 cc)
(const_int 0 [0]

Trying 21 -> 8:
   21: r121:SI=r129:SI
  REG_DEAD r129:SI
8: r125:SI=r119:SI-ltu(cc:CC,0)-r121:SI
  REG_DEAD r121:SI
  REG_DEAD r119:SI
  REG_DEAD cc:CC
Successfully matched this instruction:
(set (reg:SI 125 [+4 ])
(minus:SI (minus:SI (reg:SI 119 [ a+4 ])
(ltu:SI (reg:CC 100 cc)
(const_int 0 [0])))
(reg:SI 129)))

These are mathematically equivalent, but because we do not produce consistent
RTL for them we need two patterns if we are to match both alternatives.

I think both should be canonicalized with the LTU inside the inner MINUS
expression, but I wouldn't mind if the other were chosen, as long as we were
consistent.

[Bug target/92280] [10 regression] gcc.target/i386/pr83008.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||sergey.shalnov at intel dot com

--- Comment #2 from Richard Biener  ---
Sergey, your testcase now fails again.  I think there's two changes occuring,
first we now vectorize the store to tmp[] from the first loop during
basic-block vectorization as

  _586 = {_148, _142, _145, _139, _54, _58, _56, _60};
  _588 = {_211, _217, _214, _220, _292, _298, _295, _301};
  MEM  [(unsigned int *)&tmp] = _588;
  MEM  [(unsigned int *)&tmp + 32B] = _586;

then we vectorize the second reduction loop after the fix for PR65930
which then allows us to elide 'tmp' still visible in GIMPLE as

  vect__63.9_392 = MEM  [(unsigned int *)&tmp];
  vect__64.12_388 = MEM  [(unsigned int *)&tmp + 16B];
  vect__67.19_380 = MEM  [(unsigned int *)&tmp + 32B];
  vect__68.22_376 = MEM  [(unsigned int *)&tmp + 48B];

so assembly has unvectorized first loop and then those latter vectors built
via two times

vmovd   %esi, %xmm3
vmovd   %esi, %xmm2
vmovd   %r11d, %xmm5
vmovd   %r15d, %xmm6
vpinsrd $1, %r13d, %xmm2, %xmm4
vpinsrd $1, %r14d, %xmm3, %xmm7
vpinsrd $1, %ebx, %xmm5, %xmm1
vpinsrd $1, %r9d, %xmm6, %xmm0
vpunpcklqdq %xmm1, %xmm0, %xmm8
vpunpcklqdq %xmm4, %xmm7, %xmm9
vinserti128 $0x1, %xmm9, %ymm8, %ymm10

note for the combined fix of PR65930 I see a 7% performance improvement
for 525.x264_r on Haswell.

I think the original complaint in PR83008 was vectorization of the first
loop which still does not happen, so the testcase needs adjustment?

There's also still GIMPLE improvements possible in eliding 'tmp' before
RTL expansion.

[Bug tree-optimization/92282] New: gimple for (a + ~b) is harder to optimize in RTL when types are unsigned

[rearnsha at gcc dot gnu.org]

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

Bug ID: 92282
   Summary: gimple for (a + ~b) is harder to optimize in RTL when
types are unsigned
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
  Target Milestone: ---

Given:

t f1(t a, t b) { return a + ~b; }

if t is of type int64_t, then the gimple produced is


  _1 = ~b_2(D);
  _4 = _1 + a_3(D);

Which on Arm can then easily optimize into a 3 instruction sequence

MVN  R2, R2
ADDS R0, R0, R2
SBC  R1, R1, R3

(because on Arm, SBC = Rn - Rm - ~C == Rn + ~Rm + C)

But if the type is changed to uint64_t, then the gimple is transformed into

  _1 = a_2(D) - b_3(D);
  _4 = _1 + 18446744073709551615;

Which is almost impossible for the back-end to optimize back into the optimal
sequence.  The result is that we end up with two carry-propagating subtract
operations instead of one and less parallelism in the overall sequence as the
bit-wise invert can operate in parallel on any super-scalar architecture.

Note that the same problem likely exists on 64-bit architectures if t is
uint128_t.

[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #23 from Iain Sandoe  ---
fixed on open branches

[Bug target/65342] [7/8 Regression] powerpc-darwin9 m64 code-gen error exposed by r210201

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #35 from Iain Sandoe  ---
fixed on open branches

[Bug target/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #9 from Iain Sandoe  ---
fixed on open branches

[Bug tree-optimization/92283] New: [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[marxin at gcc dot gnu.org]

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

Bug ID: 92283
   Summary: [10 Regression] 454.calculix miscomparison since
r276645 with -O2 -march=znver2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-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
Blocks: 26163
  Target Milestone: ---

Happens probably also on -march=znver1. The miscomparison looks as follows:

*** Miscompare of hyperviscoplastic.dat; for details see
   
/home/marxin/Programming/cpu2006/benchspec/CPU2006/454.calculix/run/run_peak_ref_amd64-m64-mine.0002/hyperviscoplastic.dat.mis
0004:  1  4.8405E-02  3.2704E-03 -9.0528E-02
   1  4.8406E-02  3.2744E-03 -9.0528E-02
   ^
0005:  2  4.7540E-02  4.7758E-03 -9.0477E-02
   2  4.7541E-02  4.7797E-03 -9.0476E-02
   ^
0006:  3  5.7701E-02  1.7385E-02 -8.9680E-02
   3  5.7701E-02  1.7389E-02 -8.9679E-02
   ^
0007:  4  5.8515E-02  1.6408E-02 -8.9846E-02
   4  5.8515E-02  1.6412E-02 -8.9845E-02
   ^
0008:  5  4.9013E-02  4.4863E-03 -7.1472E-02
   5  4.9013E-02  4.4890E-03 -7.1472E-02
   ^
0009:  6  4.8327E-02  6.3389E-03 -7.1369E-02
   6  4.8327E-02  6.3416E-03 -7.1368E-02
   ^
0010:  7  5.8090E-02  1.5335E-02 -6.9866E-02
   7  5.8091E-02  1.5337E-02 -6.9866E-02
   ^
0011:  8  5.8660E-02  1.4022E-02 -7.0121E-02
   8  5.8661E-02  1.4024E-02 -7.0120E-02
   ^
0012:  9  4.7972E-02  4.0228E-03 -9.0502E-02
   9  4.7973E-02  4.0267E-03 -9.0501E-02
   ^
0013: 10  5.2460E-02  1.1227E-02 -9.0329E-02
  10  5.2461E-02  1.1232E-02 -9.0328E-02
   ^


Referenced Bugs:

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

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
  Known to work||9.2.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
I'm going to take a look what's different with the revision..

[Bug fortran/92284] New: Subroutine with bind(c) attribute causing varied problems

[jrfsousa at gmail dot com]

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

Bug ID: 92284
   Summary: Subroutine with bind(c) attribute causing varied
problems
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 47130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47130&action=edit
Code demonstrating problems.

Hi all!

Code attached causes various problems in both 9.1.0 and 10.0.0 including ICE on
9.1.0.

The problems reported vary depending on the array having the allocatable or
pointer attributes.

-Wmaybe-uninitialized reports uninitialized internal variables -fcheck=*
changes which.

When it runs the error is:

At line 26 of file ./arr.f90
Fortran runtime error: Index '1' of dimension 1 of array 'this' above upper
bound of 0

Error termination. Backtrace:
#0  0x401051 in arr_set
at ./arr.f90:26
#1  0x4011c5 in arr_p
at ./arr.f90:11
#2  0x40147c in main
at ./arr.f90:14

Thank you very much.

Best regards,
José Rui

[Bug libstdc++/92285] New: Layout of istreambuf_iterator subobject depends on -std mode

[redi at gcc dot gnu.org]

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

Bug ID: 92285
   Summary: Layout of istreambuf_iterator subobject depends on
-std mode
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The fix for PR 50336 (r178713) makes this program depend on the -std mode:

#include 
#include 

struct I : std::iterator
{ };

struct J : I, std::istreambuf_iterator
{ };

int main()
{
  std::cout << sizeof(J) << '\n';
}

For C++98 it prints 24 but for other modes it prints 16. The reason is
that std::istreambuf_iterator has a different base class:

  template
class istreambuf_iterator
: public iterator= 201103L
// LWG 445.
  _CharT>
#else
  _CharT&>
#endif

This affects layout because std::iterator is an empty class, so 
whether the two base classes can share the same address depends on
what istreambuf_iterator's base class is.

This isn't a disaster, because in practice it is probably very rare 
for a type to have two std::iterator subobjects that could have the
same address. But technically it's still an ABI incompatibility 
between C++98 and C++11/14/17 modes.

The solution is to make istreambuf_iterator always have the same base
class, but then conditionally override the reference member:

  template
class istreambuf_iterator
: public iterator
{ 
public:
  using reference = ???;

Now the base class will always be the same, and so won't change layout
when __cplusplus changes.

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Apparently quite some files are different with the revision:

CalculiX.o
beamsections.o
cycsymmods.o
e_c3d.o
e_c3d_rhs.o
e_c3d_th.o
el.o
envtemp.o
extrapolate.o
gen3delem.o
incplas.o
linel.o
mastruct.o
matdata_co.o
matdata_he.o
materialdata.o
nonlinmpc.o
norshell.o
onf.o
planempc.o
radflowload.o
rectcyl.o
results.o
rubber.o
shape10tet.o
shape15w.o
shape20h.o
shape3tri.o
shape4q.o
shape4tet.o
shape6tri.o
shape6w.o
shape8h.o
shape8q.o
shellsections.o
solidsections.o
spooles.o
straightmpc.o
tempload.o
umat_aniso_creep.o
umat_aniso_plas.o
umat_elastic_fiber.o
umat_single_crystal.o
umpc_mean_rot.o

[Bug target/92280] [10 regression] gcc.target/i386/pr83008.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||law at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> Sergey, your testcase now fails again.  I think there's two changes occuring,
> first we now vectorize the store to tmp[] from the first loop during
> basic-block vectorization as
> 
>   _586 = {_148, _142, _145, _139, _54, _58, _56, _60};
>   _588 = {_211, _217, _214, _220, _292, _298, _295, _301};
>   MEM  [(unsigned int *)&tmp] = _588;
>   MEM  [(unsigned int *)&tmp + 32B] = _586;
> 
> then we vectorize the second reduction loop after the fix for PR65930
> which then allows us to elide 'tmp' still visible in GIMPLE as
> 
>   vect__63.9_392 = MEM  [(unsigned int *)&tmp];
>   vect__64.12_388 = MEM  [(unsigned int *)&tmp +
> 16B];
>   vect__67.19_380 = MEM  [(unsigned int *)&tmp +
> 32B];
>   vect__68.22_376 = MEM  [(unsigned int *)&tmp +
> 48B];
> 
> so assembly has unvectorized first loop and then those latter vectors built
> via two times
> 
> vmovd   %esi, %xmm3
> vmovd   %esi, %xmm2
> vmovd   %r11d, %xmm5
> vmovd   %r15d, %xmm6
> vpinsrd $1, %r13d, %xmm2, %xmm4
> vpinsrd $1, %r14d, %xmm3, %xmm7
> vpinsrd $1, %ebx, %xmm5, %xmm1
> vpinsrd $1, %r9d, %xmm6, %xmm0
> vpunpcklqdq %xmm1, %xmm0, %xmm8
> vpunpcklqdq %xmm4, %xmm7, %xmm9
> vinserti128 $0x1, %xmm9, %ymm8, %ymm10
> 
> note for the combined fix of PR65930 I see a 7% performance improvement
> for 525.x264_r on Haswell.
> 
> I think the original complaint in PR83008 was vectorization of the first
> loop which still does not happen, so the testcase needs adjustment?
> 
> There's also still GIMPLE improvements possible in eliding 'tmp' before
> RTL expansion.

Which VN can already do - it's just it doesn't have a global enough view
to decide profitability and so I chickened out enabling that.  Enabling
generates _much_ better code though, 73 lines of assembly compared to 264.
I guess it's as usual that RTL elimination of stack isn't very good.

That said, VN already computes the partial loads to { 148, _142, _145, _139 }
and would insert those CTORs in place of the loads, making the stores and
the AVX512 CTOR dead.  But that's obviously only profitable if the stores
and the CTOR end up being dead, otherwise we risk doing redundant
vector construction where cheap loads from memory would be possible.
The alternative way expressing it via sub-vector extraction is similarly
on the boundary of profitable plus we're happily simplifying that to a
redundant CTOR.

We currently do not elide 'tmp' because it doesn't fit a single register
so it is stack memory on RTL.  There CSE doesn't manage to simplify
this but combine manages to elide the loads but even postreload DSE cannot
elide the stack store for some reason.  That looks odd to me.  Moving
DSE2 up after combine helps a lot here.  I would guess since combine
can eliminate loads we definitely lack another DSE pass - alternatively
moving DSE1 down after combine might be another option, guess it's
there where it is because unrolling can expose dse/dce opportunities
though I don't see any CSE after unroll.

So shortest pass motion that helps this case:

Index: gcc/passes.def
===
--- gcc/passes.def  (revision 277608)
+++ gcc/passes.def  (working copy)
@@ -432,12 +432,12 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_web);
   NEXT_PASS (pass_rtl_cprop);
   NEXT_PASS (pass_cse2);
-  NEXT_PASS (pass_rtl_dse1);
   NEXT_PASS (pass_rtl_fwprop_addr);
   NEXT_PASS (pass_inc_dec);
   NEXT_PASS (pass_initialize_regs);
   NEXT_PASS (pass_ud_rtl_dce);
   NEXT_PASS (pass_combine);
+  NEXT_PASS (pass_rtl_dse1);
   NEXT_PASS (pass_if_after_combine);
   NEXT_PASS (pass_jump_after_combine);
   NEXT_PASS (pass_partition_blocks);

[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #3)
> Martin, do you have any idea?

Yes, the jump functions are thrown away at stream-in time because 
e->possibly_call_in_translation_unit_p returns false in:

static void
ipa_read_edge_info (class lto_input_block *ib,
class data_in *data_in,
struct cgraph_edge *e, bool prevails)
{
  int count = streamer_read_uhwi (ib);
  bool contexts_computed = count & 1;

  count /= 2;
  if (!count)
return;
  if (prevails && e->possibly_call_in_translation_unit_p ())
{

[Bug c/92276] Embedded __attribute__ ((optimize("unroll-loops"))) is not working together with '__attribute__ ((__always_inline__))'

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Lijian Zhang from comment #4)
> (In reply to Richard Biener from comment #1)
> > Instead of trying to force the compiler to unroll with -funroll-loops you 
> > can
> > use #pragma GCC unroll N on individual loops instead.
> > 
> > The attributes should not conflict in any way.
> 
> Hi Richard,
> Does it make sense to you that '__attribute__ ((optimize("unroll-loops")))'
> has to be moved ahead of the caller, if the callee is defined with
> '__attribute__ ((__always_inline__))'?

Those attributes apply to a function so once the callee is inlined what
matters is the callers attribute.  So yes.

[Bug fortran/92277] [10 Regression] ICE with assumed rank in gfc_conv_gfc_desc_to_cfi_desc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |10.0

[Bug libstdc++/92285] Layout of istreambuf_iterator subobject depends on -std mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Known to work||4.6.4
  Known to fail||4.7.0

--- Comment #1 from Richard Biener  ---
Ugh.  I hope we can keep the "new" ABI for the default std though?  That means
breaking it also for -std=c++98?

Or simply document this defect :/

"Works" in 4.6.4 as far as I can see, broken starting with 4.7.

[Bug c/92286] New: Possible improvement for -Wduplicated-cond warning

[marxin at gcc dot gnu.org]

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

Bug ID: 92286
   Summary: Possible improvement for -Wduplicated-cond warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

We can possibly improve the warning for:

cat main2.c
int global;
int foo();

int main2(int argc, char **argv)
{
  if (argc == 1)
foo ();
  else if (argc == 2) {
global += 1;
  }
  else if (argc == 3)
  {
foo ();
foo ();
  }
  else if (argc >= 1 && argc <= 2)
  {
foo ();
  }

  global -= 12;
  return 0;
}

where (argc >= 1 && argc <= 2) condition is already covered.

[Bug ipa/92234] [10 Regression] ICE verify_gimple failed (profiled lto) on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
On i686-linux with what configure options?

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #3 from Richard Biener  ---
Ugh.  ISTR calculix has some precision issues.

[Bug c/92286] Possible improvement for -Wduplicated-cond warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Maybe the warning could use make_range / merge_ranges that
warn_logical_operator uses?

[Bug middle-end/92231] [9/10 Regression] ICE in gimple_fold_stmt_to_constant_1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Indeed, started with r263880.  Let me have a look.

[Bug target/92269] Profiling (-p) does not work on H8

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
That is the other "dje", Doug Evans, who originally worked at Cygnus.  Jeff is
the current maintainer of the H8 port.

[Bug modula2/92148] gm2: race condition building gm2 on trunk

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
I will check with the next upload

[Bug middle-end/92282] gimple for (a + ~b) is harder to optimize in RTL when types are unsigned

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
  Component|tree-optimization   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
This is fold-const.c split_tree/associate_trees at work.

  else if (TREE_CODE (in) == BIT_NOT_EXPR
   && code == PLUS_EXPR)
{
  /* -1 - X is folded to ~X, undo that here.  Do _not_ do this
 when IN is constant.  */
  *litp = build_minus_one_cst (type);
  *minus_varp = TREE_OPERAND (in, 0);

In the end we want to help optimizing ~A - 1.  Might be possible to reject
the specific simplification (if no constant was eliminated or the constant
got "large") in the caller of associate_trees.

[Bug middle-end/92282] gimple for (a + ~b) is harder to optimize in RTL when types are unsigned

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Btw, x86 manages to generate

movq%rdi, %r9
movq%rsi, %r8
movq%r9, %rsi
movq%r8, %rdi
subq%rdx, %rsi
sbbq%rcx, %rdi
movq%rsi, %rax
movq%rdi, %rdx
addq$-1, %rax
adcq$-1, %rdx
ret

for the unsigned int128 case vs

movq%rdx, %r8
movq%rdi, %r9
notq%rcx
notq%r8
movq%rcx, %rdx
movq%r8, %rax
addq%r9, %rax
adcq%rsi, %rdx
ret

for the signed.

[Bug bootstrap/11776] configure from path with spaces does not work

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57076,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=28466

--- Comment #5 from Eric Gallager  ---
Other characters whose use in pathnames can break builds:

'@' (bug 57076)
':' (bug 28466)

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Though with -O2 we should produce "exact" FP math (and vectorization is off).
So maybe we hit a latent issue after the extra unrolling from the rev. in
question.

[Bug libstdc++/92285] Layout of istreambuf_iterator subobject depends on -std mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-30
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #1)
> Ugh.  I hope we can keep the "new" ABI for the default std though?  That
> means
> breaking it also for -std=c++98?

Yes, see https://gcc.gnu.org/ml/libstdc++/2019-10/msg00129.html for additional
discussion of the options and what breaks with each one.

As I said there, I would prefer to keep the default std unchanged, even though
that breaks c++98.

> Or simply document this defect :/

Yes, and I'll be adding it to https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
too.

> "Works" in 4.6.4 as far as I can see, broken starting with 4.7.

Yeah.

[Bug ipa/92234] [10 Regression] ICE verify_gimple failed (profiled lto) on s390x-linux-gnu

[doko at debian dot org]

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

--- Comment #4 from Matthias Klose  ---
 --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --with-gcc-major-version-only
 --program-prefix=
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --enable-bootstrap
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-vtable-verify
 --enable-plugin
 --with-system-zlib
 --with-target-system-zlib=auto
 --enable-objc-gc=auto
 --enable-targets=all
 --enable-multiarch
 --disable-werror
 --with-arch-32=i686
 --with-multilib-list=m32,m64,mx32
 --enable-multilib
 --with-tune=generic
 --enable-checking=yes
 --build=i686-linux-gnu
 --host=i686-linux-gnu
 --target=i686-linux-gnu
 --with-build-config=bootstrap-lto-lean
 --enable-link-mutex

[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 30 13:52:27 2019
New Revision: 277621

URL: https://gcc.gnu.org/viewcvs?rev=277621&root=gcc&view=rev
Log:
2019-10-30  Richard Biener  

PR tree-optimization/92275
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
Copy all loop-closed PHIs.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr92275.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop-manip.c

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So the problematic file is results.f. If I use code from the previous revision
for the file, there is no miscomparison.

Now I'll bisect which loop is causing the miscompilation. Optimized dumps
differ quite significantly.

[Bug c++/79274] FAIL: g++.dg/tls/pr77285-2.C -std=c++11 scan-assembler _ZTH4var1B3tag

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,*-*-d
   ||arwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
 CC||iains at gcc dot gnu.org
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,*-*-d
   ||arwin*
   Target Milestone|--- |7.5
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
the test was changed to require tls_native (from gcc 9+).

I see the same issue on Darwin on gcc8/7

when you say "Think this is a result of emutls." - you mean that hppa is also
(Darwin does) using emuTLS?

AFAIR, [with emuTLS] there's no proper init of global TLS vars when they are in
a different TU from the one referencing - which is what the
_ZTH4/_ZTW4var1B3tag symbols are about.

(It's on my [very long] TODO to see if there's a way of doing the same thing
for emuTLS - that is done for the native case).

I'd say we just need to back-port the require native_tls [or xfail] to the
earlier branches (if that's permitted).

[Bug target/89346] Unnecessary EVEX encoding

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #1 from Peter Cordes  ---
Still present in pre10.0.0 trunk 20191022.  We pessimize vmovdqu/a in AVX2
intrinsics and autovectorization with -march=skylake-avx512 (and arch=native on
such machines)

It seems only VMOVDQU/A load/store/register-copy instructions are affected; we
get AVX2 VEX vpxor instead of AVX512VL EVEX vpxord for xor-zeroing, and
non-zeroing XOR.  (And most other instructions have the same mnemonic for VEX
and EVEX, like vpaddd.  This includes FP moves like VMOVUPS/PD)

(https://godbolt.org/z/TEvWiU for example)

The good options are: 

* use VEX whenever possible instead of AVX512VL to save code-size.  (2 or 3
byte prefix instead of 4-byte EVEX)

* Avoid the need for vzeroupper by using only x/y/zmm16..31.  (Still has a
max-turbo penalty so -mprefer-vector-width=256 is still appropriate for code
that doesn't spend a lot of time in vectorized loops.)

 This might be appropriate for very simple functions / blocks that only have a
few SIMD instructions before the next vzeroupper would be needed.  (e.g.
copying or zeroing some memory); could be competitive on code-size as well as
saving the 4-uop instruction.

 VEX instructions can't access x/y/zmm16..31 so this forces an EVEX encoding
for everything involving the vector (and rules out using AVX2 and earlier
instructions, which may be a problem for KNL without AVX512VL unless we narrow
to 128-bit in an XMM reg)



(citation for not needing vzeroupper if y/zmm0..15 aren't written explicitly:
https://stackoverflow.com/questions/58568514/does-skylake-need-vzeroupper-for-turbo-clocks-to-recover-after-a-512-bit-instruc
- it's even safe to do

vpxor xmm0,xmm0,xmm0
vpcmpeqb  k0, zmm0, [rdi]

without vzeroupper.  Although that will reduce max turbo *temporarily* because
it's a 512-bit uop.

Or more frequently useful: to zero some memory with vpxor xmm zeroing and YMM
stores.

[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
See https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02139.html for a possible
fix.

[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[rguenth at gcc dot gnu.org]

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

Bug 92275 Summary: [10 Regression] ICE: error: definition in block 11 does not 
dominate use in block 15 since r277566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275

   What|Removed |Added

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

[Bug target/92287] New: Mismatches in the calling convention for zero sized types

[gonzalobg88 at gmail dot com]

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

Bug ID: 92287
   Summary: Mismatches in the calling convention for zero sized
types
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonzalobg88 at gmail dot com
  Target Milestone: ---

Consider this code:

struct foo {};
int id_foo(struct foo bar, int x) {
return x;
}
int id(int x) {
return x;
}

This link shows the assembly generated for MSP430, MIPS64el, PPC32 and PPC64
(https://godbolt.org/z/yOCJ-z), reproduced here for completeness:

;; MIPS64:
id_foo:
j   $31
move$2,$4

id:
j   $31
move$2,$4

;; MSP430:
id_foo:
MOV.W   R13, R12
RET
id:
RET

;; POWERPC64LE
id_foo:
blr
.long 0
.byte 0,0,0,0,0,0,0,0
id:
blr
.long 0
.byte 0,0,0,0,0,0,0,0

;; POWERPC
id_foo:
mr 3,4
blr
id:
blr


Notice how MSP430 and POWERPC passes ZSTs in the calling convention, while
MIPS64 and POWERPC64LE ignore them. 

I can't find an ABI specification document for the MSP430 and POWERPC targets,
so I was wondering whether this is 
a bug in the GCC implementation of the ABI for these targets. And if not, then
why do these targets care
about passing zero-sized types in their calling convention? Is this documented
anywhere?

(Note: other targets might be affected as well)

[Bug c++/79274] FAIL: g++.dg/tls/pr77285-2.C -std=c++11 scan-assembler _ZTH4var1B3tag

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2019-10-30 10:12 a.m., iains at gcc dot gnu.org wrote:
> when you say "Think this is a result of emutls." - you mean that hppa is also
> (Darwin does) using emuTLS?
hppa uses emutls on hpux.

[Bug tree-optimization/92288] [10 Regression] 502.gcc_r ICE with -O3 -march=skylake -fno-checking since r277621

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-30
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug tree-optimization/92288] New: [10 Regression] 502.gcc_r ICE with -O3 -march=skylake -fno-checking since r277621

[marxin at gcc dot gnu.org]

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

Bug ID: 92288
   Summary: [10 Regression] 502.gcc_r ICE with -O3 -march=skylake
-fno-checking since r277621
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-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
Blocks: 26163
  Target Milestone: ---

Before the revision there was a checking assert (that I disabled with
-fno-checking).

Can reproduce with test size:
runcpu --config=spec2017 --size=test --iterations=1  --no-reportable -I 
--action=run   --tune=peak 502.gcc_r -D

Contents of t1.opts-O3_-finline-limit_5.err

t1.c:2:5: warning: conflicting types for built-in function 'printf'
t1.c: In function 'main':
t1.c:9:1: benchmark internal error: in ?, at df-scan.c:1573
The 502.gcc_r benchmark binary 'cpugcc_r' has encountered an internal error.
It is possible that there is an error in the benchmark 502.gcc_r
source code, but it is more likely that your compiler
has mis-optimized or otherwise generated bad code for
the benchmark.  You might try reducing the optimization
level; see your compiler documentation.
If you think the error is in the benchmark source code, see
   www.spec.org/cpu2017/Docs/techsupport.html


Referenced Bugs:

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

[Bug middle-end/92231] [9/10 Regression] ICE in gimple_fold_stmt_to_constant_1

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47131&action=edit
gcc10-pr92231.patch

Untested fix.

[Bug c++/92289] New: Worse "control reaches end of non-void function" diagnostic with undefined sanitizer

[TonyELewis at hotmail dot com]

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

Bug ID: 92289
   Summary: Worse "control reaches end of non-void function"
diagnostic with undefined sanitizer
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TonyELewis at hotmail dot com
  Target Milestone: ---

When I use Godbolt's GCC (9.2 or trunk ("10.0.0 20191022 (experimental)")) to
compile:


~~~
void throw_sum( int a, int b ) { throw a + b; }

#define THROW_WITH_LINE_NUM_ADDED( x ) throw_sum( x, __LINE__ )

bool f( const bool &prm_val ) {
   if ( prm_val ) { return true; }

   THROW_WITH_LINE_NUM_ADDED( 0 );
}
~~~


...with `-Werror` I get a helpful warning (promoted to error):


~~~
: In function 'bool f(const bool&)':

:9:1: error: control reaches end of non-void function
[-Werror=return-type]

9 | }

  | ^

cc1plus: all warnings being treated as errors

Compiler returned: 1
~~~


...but if I turn on UBSan (ie change the options to `-Werror
-fsanitize=undefined`), I get:


~~~
: In function 'bool f(const bool&)':

:3:49: error: control reaches end of non-void function
[-Werror=return-type]

3 | #define THROW_WITH_LINE_NUM_ADDED( x ) throw_sum( x, __LINE__ )

  |~^~~

:8:4: note: in expansion of macro 'THROW_WITH_LINE_NUM_ADDED'

8 |THROW_WITH_LINE_NUM_ADDED( 0 );

  |^

cc1plus: all warnings being treated as errors

Compiler returned: 1
~~~


...which I think is much less helpful. I don't think that enabling runtime
sanitizer checks should reduce the quality of the compiler's diagnostics.


Thanks very much to all who work on GCC.

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 47132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47132&action=edit
Debugging patch

With the attached patch (and r276645) run succeeds.
If you change s/counter < 2/counter < 1/ then it fails.
Can you please Richi reproduce that locally?

[Bug c++/92289] Worse "control reaches end of non-void function" diagnostic with undefined sanitizer

[TonyELewis at hotmail dot com]

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

--- Comment #1 from Tony E Lewis  ---
Sorry: I should have said...

Even the original warning isn't ideal because the compiler has enough
information to know that all paths through f() either return a value or throw.
So I don't think it should warn at all really. But if it is going to warn, I
don't think its diagnostics should degrade when UBSan is enabled.

[Bug target/92287] Mismatches in the calling convention for zero sized types

[jozefl.gcc at gmail dot com]

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

 CC||jozefl.gcc at gmail dot com

--- Comment #1 from Jozef Lawrynowicz  ---
I can only speak for msp430, but there's no problem with that generated
assembly. Structures and unions are always passed by reference.

R12:R15 are the argument registers, and the return value starts in R12.

[Bug c/92290] New: Inconsistent -Warray-bounds warning

[sirl at gcc dot gnu.org]

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

Bug ID: 92290
   Summary: Inconsistent -Warray-bounds warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47133&action=edit
testcase

The attached creduced testcases recently started to warn differently in trunk
(9 and earlier don't warn) depending on variable signedness. But I believe the
possible range of the loop counter values should be the same.

int a, b;
unsigned short t1 (void)
{
  int j;
  unsigned short pu = 0;
  unsigned int p[6] = { 0 };
  unsigned int v;
  for (j = 0; j < 1234; j++)
{
  v = a;
  if (((v >> 16) & 7) > 0)
{
  int i;
  b = p[0];
  for (i = 0; i < 6 - (int) ((v >> 16) & 0x07); i++)
p[i] = p[i + ((v >> 16) & 0x07)];
}
  pu >>= (int) ((v >> 16) & 0x07) * 2;
}
  return pu;
}


Compiled with -O2 -Warray-bounds, GCC trunk@277601 warns like this:

testcase.c: In function 't1':
testcase.c:17:14: warning: array subscript 6 is above array bounds of 'unsigned
int[6]' [\-Warray-bounds=\]
   17 |  p[i] = p[i + ((v >> 16) & 0x07)];
  | ~^~~~
testcase.c:7:16: note: while referencing ?p?
7 |   unsigned int p[6] = { 0 };
  |^

t2() is a slight modification with re-arranged loop condition and gives the
same warning.
t3() uses an unsigned loop variable and doesn't warn, which seems the correct
behaviour to me.

[Bug target/92287] Mismatches in the calling convention for zero sized types

[gonzalobg88 at gmail dot com]

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

--- Comment #2 from gnzlbg  ---
> I can only speak for msp430, but there's no problem with that generated 
> assembly. Structures and unions are always passed by reference.

I suppose that by this you mean that the current behavior is "by design", is
that correct ?

If so, could you explain the rationale of this design or point me to the ABI
specification document or rationale for it ?

[Bug bootstrap/92274] 'make' fails when objdir and srcdir paths contain spaces

[heiko at hexco dot de]

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

--- Comment #2 from Heiko Eißfeldt  ---
As I see it, there are multiple issues with the current approach.

1. Since absolute paths (as opposed to relative paths) are used, one cannot
move the configured source tree to some other location and use it there.

2. Some problematic character [@: ] in the base directory path can screw up the
whole setup, so it is a bit fragile. 

3. The documentation (https://gcc.gnu.org/install/configure.html) does not
mention this requirement.

4. The size of the generated Makefile is well above 900 kilobytes, making an
analysis to fix the original issue unnecessary difficult.

IMHO there are better structured alternatives available (for example the schily
build system from schilytools (sourceforge)).

Thanks, Heiko

[Bug libstdc++/92272] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jwakely at redhat dot com  |
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #3 from Jonathan Wakely  ---
Fixed.

[Bug libstdc++/92272] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 30 15:48:11 2019
New Revision: 277629

URL: https://gcc.gnu.org/viewcvs?rev=277629&root=gcc&view=rev
Log:
Apply C++20 changes to various iterator types

This ensures that __normal_iterator satisfies the
contiguous_iterator concept, by defining the iterator_concept member
type.

Also update vector's iterators, reverse_iterator,
istreambuf_iterator and ostreambuf_iterator to meet the C++20
requirements.

PR libstdc++/92272
* include/bits/stl_bvector.h (_Bit_iterator::pointer)
(_Bit_const_iterator::pointer): Define as void for C++20.
* include/bits/stl_iterator.h (reverse_iterator::operator->()): Add
constraints for C++20.
(__normal_iterator::iterator_concept): Define for C++20.
* include/bits/streambuf_iterator.h (istreambuf_iterator::pointer):
Define as void for C++20.
(ostreambuf_iterator::difference_type): Define as ptrdiff_t for C++20.
(ostreambuf_iterator::ostreambuf_iterator()): Add default constructor
for C++20.
* testsuite/23_containers/vector/bool/iterator_c++20.cc: New test.
* testsuite/24_iterators/bidirectional/concept.cc: New test.
* testsuite/24_iterators/bidirectional/tag.cc: New test.
* testsuite/24_iterators/contiguous/concept.cc: New test.
* testsuite/24_iterators/contiguous/tag.cc: New test.
* testsuite/24_iterators/forward/concept.cc: New test.
* testsuite/24_iterators/forward/tag.cc: New test.
* testsuite/24_iterators/input/concept.cc: New test.
* testsuite/24_iterators/input/tag.cc: New test.
* testsuite/24_iterators/istreambuf_iterator/requirements/typedefs.cc:
New test.
* testsuite/24_iterators/ostreambuf_iterator/requirements/typedefs.cc:
New test.
* testsuite/24_iterators/output/concept.cc: New test.
* testsuite/24_iterators/output/tag.cc: New test.
* testsuite/24_iterators/random_access/concept.cc: New test.
* testsuite/24_iterators/random_access/tag.cc: New test.
* testsuite/24_iterators/range_operations/advance_debug_neg.cc: New
test.
* testsuite/24_iterators/random_access_iterator/26020.cc: Move to ...
* testsuite/24_iterators/operations/26020.cc: ... here.
* testsuite/24_iterators/random_access_iterator/
string_vector_iterators.cc: Move to ...
* testsuite/24_iterators/random_access/string_vector_iterators.cc: ...
here.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/bool/iterator_c++20.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/contiguous/concept.cc
trunk/libstdc++-v3/testsuite/24_iterators/bidirectional/
trunk/libstdc++-v3/testsuite/24_iterators/bidirectional/concept.cc
trunk/libstdc++-v3/testsuite/24_iterators/bidirectional/tag.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc
trunk/libstdc++-v3/testsuite/24_iterators/forward/
trunk/libstdc++-v3/testsuite/24_iterators/forward/concept.cc
trunk/libstdc++-v3/testsuite/24_iterators/forward/tag.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc
trunk/libstdc++-v3/testsuite/24_iterators/input/
trunk/libstdc++-v3/testsuite/24_iterators/input/concept.cc
trunk/libstdc++-v3/testsuite/24_iterators/input/tag.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc
trunk/libstdc++-v3/testsuite/24_iterators/operations/26020.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc
trunk/libstdc++-v3/testsuite/24_iterators/output/
trunk/libstdc++-v3/testsuite/24_iterators/output/concept.cc
trunk/libstdc++-v3/testsuite/24_iterators/output/tag.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc
trunk/libstdc++-v3/testsuite/24_iterators/random_access/
trunk/libstdc++-v3/testsuite/24_iterators/random_access/concept.cc
   
trunk/libstdc++-v3/testsuite/24_iterators/random_access/string_vector_iterators.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/string_vector_iterators.cc
trunk/libstdc++-v3/testsuite/24_iterators/random_access/tag.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/contiguous/concept.cc
   
trunk/libstdc++-v3/testsuite/24_iterators/range_operations/advance_debug_neg.cc
  - copied, changed from r277628,
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc
Removed:
trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/

[Bug c/92230] Proposal to have builtin underflow detection function

[arieltorti14 at gmail dot com]

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

Ariel Torti  changed:

   What|Removed |Added

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

--- Comment #2 from Ariel Torti  ---
You got it right, I accidentally used the signed version and got confused by
the result.

[Bug target/92287] Mismatches in the calling convention for zero sized types

[jozefl.gcc at gmail dot com]

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

--- Comment #3 from Jozef Lawrynowicz  ---
(In reply to gnzlbg from comment #2)
> > I can only speak for msp430, but there's no problem with that generated 
> > assembly. Structures and unions are always passed by reference.
> 
> I suppose that by this you mean that the current behavior is "by design", is
> that correct ?
> 
> If so, could you explain the rationale of this design or point me to the ABI
> specification document or rationale for it ?

I was just considering from an MSP430 point of view, that if the struct can
have an address (it looks like it can, even though it has zero size), then that
assembly is correct. I'm afraid I don't have any specific insight into how GCC 
generically handles zero sized structs beyond that though.

The MSP430 ABI is here: http://www.ti.com/lit/an/slaa534/slaa534.pdf
Although confusingly that document is wrong regarding passing structures and
unions by reference. As I mentioned before, structures and unions are always
passed by reference, regardless of size.

[Bug target/92291] New: Non-optimal code generated for H8

[mti-1 at tillenius dot com]

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

Bug ID: 92291
   Summary: Non-optimal code generated for H8
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mti-1 at tillenius dot com
  Target Milestone: ---

I am using a cross compiler for Renesas H8S. In a few places it generates
really bad code. Given the following program:


struct s {
char a, b;
char c[11];
} x[2];

void test(int n)
{
struct s *sp = &x[n];

sp->a = 1;
sp->b = 1;
}

I would expect that the pointer "sp" is calculated once and reused to access
the fields "a" and "b". But instead the pointer is recalculated for each
access. This generates a lot of extra code, including calls to __mulhi3. I have
tested with gcc 8.2 and 9.2 and with different optimization levels (-O1, -O2,
-Os) all with the same result. With -O0 "sp" is only calculated once and kept
as a variable on the stack but the rest of the code is not as good as it could
be.
---
Using built-in specs.
COLLECT_GCC=h8300-none-elf-gcc
Target: h8300-none-elf
Configured with: /home/mti/abs/arm-none-eabi-gcc/h8/src/gcc-9.2.0/configure
--target=h8300-none-elf --prefix=/usr --with-native-system-header-dir=/include
--libexecdir=/usr/lib --enable-languages=c,c++ --enable-plugins
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-libstdcxx --disable-nls --disable-shared --disable-threads
--disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib --without-headers
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=rmprofile
Thread model: single
gcc version 9.2.0 (Arch Repository) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-S' '-Wall'
 /usr/lib/gcc/h8300-none-elf/9.2.0/cc1 -E -quiet -v test.c -Wall -O1
-fpch-preprocess -o test.i
ignoring nonexistent directory
"/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/h8300-none-elf/9.2.0/include
 /usr/lib/gcc/h8300-none-elf/9.2.0/include-fixed
 /usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-S' '-Wall'
 /usr/lib/gcc/h8300-none-elf/9.2.0/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -auxbase test -O1 -Wall -version -o test.s
GNU C17 (Arch Repository) version 9.2.0 (h8300-none-elf)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Arch Repository) version 9.2.0 (h8300-none-elf)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 67bb4ca8e2b97056926c3ecedb8a3eae
COMPILER_PATH=/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/:/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/:/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/bin/
LIBRARY_PATH=/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-S' '-Wall'