[Bug tree-optimization/87894] New: ICE inslpeel_duplicate_current_defs_from_edges at tree-vect-loop-manip.c:984 since r265812

[marxin at gcc dot gnu.org]

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

Bug ID: 87894
   Summary: ICE inslpeel_duplicate_current_defs_from_edges at
tree-vect-loop-manip.c:984 since r265812
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Following causes a new ICE:

$ cat ice.i
int a, b, c, d;
double e;

void f(double g[][1]) {
  for (;;) {
double h;
for (; b < c; b++) {
  if (b >= 0)
;
  else if (d)
h = 2.0;
  else
h = 0.0;
  if (e)
g[a][b] = 0.0;
  g[a][b] = h;
}
  }
}

$ ./xgcc -B. ice.i -c -Ofast
during GIMPLE pass: vect
ice.i: In function ‘f’:
ice.i:4:6: internal compiler error: Segmentation fault
4 | void f(double g[][1]) {
  |  ^
0x1192692 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:325
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x857a19 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3231
0x1558ddb slpeel_duplicate_current_defs_from_edges
/home/marxin/Programming/gcc/gcc/tree-vect-loop-manip.c:984
0x1559204 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, loop*, edge_def*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop-manip.c:1074
0x155d784 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool)
/home/marxin/Programming/gcc/gcc/tree-vect-loop-manip.c:2580
0x154e144 vect_transform_loop(_loop_vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.c:8243
0x1579808 try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:965
0x1579ab0 try_vectorize_loop
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1015
0x1579c8c vectorize_loops()
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1097
0x13dd4ad execute
/home/marxin/Programming/gcc/gcc/tree-ssa-loop.c:414

[Bug target/87583] error: unrecognizable insn on ppc64le

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #4 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #3)
> It's the same problem as many other PRs.  You are using -mcpu=power8 (it is
> the default for powerpc64le), but disabling some 2.04 insns (power5+).

Works for me, so lets decrease the priority of it.

[Bug tree-optimization/87894] ICE inslpeel_duplicate_current_defs_from_edges at tree-vect-loop-manip.c:984 since r265812

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-6
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenther at suse dot de]

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

--- Comment #44 from rguenther at suse dot de  ---
On Tue, 6 Nov 2018, aoliva at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
> 
> Alexandre Oliva  changed:
> 
>What|Removed |Added
> 
>  Status|RESOLVED|REOPENED
>  Resolution|FIXED   |---
> 
> --- Comment #43 from Alexandre Oliva  ---
> native --disable-bootstrap build on x86_64-linux-gnu now fails on trunk:
> gnattools uses g++ -B../../ to link, which fails because g++ 8 does not
> understand the %@ specs.  We really shouldn't be mixing up the preinstalled
> compiler with the just-built one IMHO: it should be either g++, or ../../xg++
> -B../../ (probably with additional flags to find libstdc++, if that's needed)

So what broke this again?

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Tue Nov  6 08:09:03 2018
New Revision: 265829

URL: https://gcc.gnu.org/viewcvs?rev=265829&root=gcc&view=rev
Log:
2018-11-06  Richard Biener  

PR middle-end/18041
* simplify-rtx.c (simplify_binary_operation_1): Add pattern
matching bitfield insertion.

* gcc.target/i386/pr18041-1.c: New testcase.
* gcc.target/i386/pr18041-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr18041-1.c
trunk/gcc/testsuite/gcc.target/i386/pr18041-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/86946] ice: canonical types differ for identical types

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
It's very old, I see it also for GCC 4.8. Note that the ICE is blocking
capnproto package right now.

[Bug libstdc++/60497] unique_ptr tries to complete its type T even though it's not required to be a complete type

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
No, comment 9 still fails.

[Bug target/87893] [9 Regression] ICE in gimplify_expr, at gimplify.c:12557 on arm-linux-gnueabi

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.2.0
   Keywords|needs-bisection |
   Last reconfirmed||2018-11-06
 CC||jason at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in gimplify_expr, at|[9 Regression] ICE in
   |gimplify.c:12557 on |gimplify_expr, at
   |arm-linux-gnueabi   |gimplify.c:12557 on
   ||arm-linux-gnueabi
   Target Milestone|--- |9.0
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Started with r265788.

[Bug rtl-optimization/87895] New: ICE in purge_dead_edges, at cfgrtl.c:3246

[asolokha at gmx dot com]

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

Bug ID: 87895
   Summary: ICE in purge_dead_edges, at cfgrtl.c:3246
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, openmp
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-9.0.0-alpha20181104 snapshot (r265779), 8.2, 7.3, 6.3, 5.4, 4.9.4 all ICE
when compiling the following snippet w/ -fopenmp:

#pragma omp declare simd
int
vm (int oh)
{
  if (oh == 0)
return 0;
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181104 -fopenmp -c eyi5ymyi.c
during RTL pass: expand
eyi5ymyi.c: In function 'vm.simdclone.0':
eyi5ymyi.c:7:1: internal compiler error: in purge_dead_edges, at cfgrtl.c:3246
7 | }
  | ^
0x5dd3b1 purge_dead_edges(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfgrtl.c:3246
0x144f5d4 find_bb_boundaries
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfgbuild.c:589
0x144f5d4 find_many_sub_basic_blocks(simple_bitmap_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfgbuild.c:672
0x8a53d1 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfgexpand.c:651

[Bug tree-optimization/87896] New: ICE in verify_flow_info failed

[marxin at gcc dot gnu.org]

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

Bug ID: 87896
   Summary: ICE in verify_flow_info failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---

Following causes ICE:

$ cat table.i
int a;

void f();
int e();

void b() {
  int c = 1;
  for (; c <= 3;) {
int d = e() && !0;
switch (c)
case 1:
  if (d)
  case 2:
  case 3:
f();
if (a)
  c++;
  }
}

$ gcc table.i -c -O2
table.i: In function ‘b’:
table.i:19:1: error: wrong amount of branch edges after conditional jump in bb
10
   19 | }
  | ^
table.i:19:1: error: wrong number of branch edges after unconditional jump in
bb 9
during RTL pass: outof_cfglayout
table.i:19:1: internal compiler error: verify_flow_info failed
0x8d3f2b verify_flow_info()
../../gcc/cfghooks.c:265
0x8ed7e9 checking_verify_flow_info
../../gcc/cfghooks.h:198
0x8ed7e9 cfg_layout_finalize()
../../gcc/cfgrtl.c:4350
0x8ed971 execute
../../gcc/cfgrtl.c:3606

Started on trunk with r264491.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #45 from Eric Botcazou  ---
> native --disable-bootstrap build on x86_64-linux-gnu now fails on trunk:
> gnattools uses g++ -B../../ to link, which fails because g++ 8 does not
> understand the %@ specs.  We really shouldn't be mixing up the preinstalled
> compiler with the just-built one IMHO: it should be either g++, or
> ../../xg++ -B../../ (probably with additional flags to find libstdc++, if
> that's needed)

OK, let's just revert everything, the cure is clear worse than the disease.

[Bug tree-optimization/87896] [9 Regression] ICE in verify_flow_info failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|ICE in verify_flow_info |[9 Regression] ICE in
   |failed  |verify_flow_info failed
  Known to fail||7.3.1, 9.0

--- Comment #1 from Martin Liška  ---
Apparently also tip of GCC 7 is affected (but neither of GCC 7.x releases).

[Bug bootstrap/87891] problems with building cross GCC for target powerpc64-darwin from powerpc-darwin

[dougmencken at gmail dot com]

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

--- Comment #9 from Douglas Mencken  ---
(In reply to self from comment 8)
> I found that I can add to configure line
> 
> AS_FOR_TARGET=as \
> AR_FOR_TARGET=ar \
> LD_FOR_TARGET=ld \
> NM_FOR_TARGET=nm \
> RANLIB_FOR_TARGET=ranlib \
> LIPO_FOR_TARGET=lipo \
> STRIP_FOR_TARGET=strip \
> OBJDUMP_FOR_TARGET=objdump

But this does not work, doesn’t change anything, thus again I need to manually
edit ORIGINAL_AS_FOR_TARGET="as" ORIGINAL_LD_FOR_TARGET="ld" inside gcc/as and
gcc/collect-ld

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

[rguenth at gcc dot gnu.org]

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

Bug 18041 Summary: OR of two single-bit bitfields is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18041

   What|Removed |Added

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

[Bug middle-end/81161] poor code concatenating bitfields

[rguenth at gcc dot gnu.org]

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

Bug 18041 Summary: OR of two single-bit bitfields is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18041

   What|Removed |Added

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

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #46 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov  6 08:42:56 2018
New Revision: 265830

URL: https://gcc.gnu.org/viewcvs?rev=265830&root=gcc&view=rev
Log:
PR ada/81878
Revert
2018-10-29  Tamar Christina  

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.

2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #47 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov  6 08:43:10 2018
New Revision: 265831

URL: https://gcc.gnu.org/viewcvs?rev=265831&root=gcc&view=rev
Log:
PR ada/81878
Revert
2018-11-02  Tamar Christina  

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.

2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
branches/gcc-8-branch/gnattools/ChangeLog
branches/gcc-8-branch/gnattools/Makefile.in

[Bug c++/87897] New: [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[marxin at gcc dot gnu.org]

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

Bug ID: 87897
   Summary: [9 Regression] ICE in maybe_constant_value, at
cp/constexpr.c:5255 since r265788
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Following causes ICE:

$ cat parser2.ii
struct a {
} typedef b;
a const c = b();

$ g++ parser2.ii -c
parser2.ii:3:15: internal compiler error: in maybe_constant_value, at
cp/constexpr.c:5255
3 | a const c = b();
  |   ^
0x5f719b maybe_constant_value(tree_node*, tree_node*)
../../gcc/cp/constexpr.c:5251
0xa2187c store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:825
0x8b334d check_initializer
../../gcc/cp/decl.c:6486
0x8cb79c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7162
0x96776b cp_parser_init_declarator
../../gcc/cp/parser.c:20033
0x96f203 cp_parser_simple_declaration
../../gcc/cp/parser.c:13219
0x974262 cp_parser_declaration
../../gcc/cp/parser.c:12916
0x974a0c cp_parser_translation_unit
../../gcc/cp/parser.c:4668
0x974a0c c_parse_file()
../../gcc/cp/parser.c:39266
0xa77000 c_common_parse_file()
../../gcc/c-family/c-opts.c:1150

[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Probably a related issue: PR87814.
Nathan can you please take a look?

[Bug tree-optimization/87894] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges at tree-vect-loop-manip.c:984 since r265812

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
*** Bug 87894 has been marked as a duplicate of this bug. ***

[Bug target/87583] error: unrecognizable insn on ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P4  |P2

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
  Known to work||8.2.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #2 from Martin Liška  ---
Richi please take a look at the duplicate, there's a reduced test-case.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

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

--- Comment #48 from Tamar Christina  ---
But doesn't reverting everything will bring it back to the state it was before,
in that `--disable-bootstrap` is still broken.

So it seems we have two seemingly incompatible behaviors.
the fix for `--disable-bootstrap` breaks any and all Windows build variants.
the simple fix for Windows support seems to break --disable-bootstrap on Linux
again.

A proper fix is needed here, would changing the way gnatlink receives it's
arguments be acceptable? Not quoting them would solve the problem for both
platforms along with Richard's original patch.

[Bug tree-optimization/87896] [9 Regression] ICE in verify_flow_info failed

[marxin at gcc dot gnu.org]

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

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

$ cat generic.i
enum { a, b, c } d;
e;
static f(h) {
  int count;
  for (;;) {
int g = 0;
while (count--) {
  if (e)
continue;
  g = 1;
  break;
}
switch (h) {
case a:
  if (g == 0)
f(b);
case c:
  d != 0;
}
  }
}
i() { f(a); }

[Bug middle-end/87886] ICE in format_helper, at real.h:227

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I've long said that the FE using built-in annotated decls with improper
prototype is a bug...

That said, generic-match.c uses get_call_combined_fn which probably
should do what gimple_call_combined_fn does - verify types "appropriately".

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #49 from Eric Botcazou  ---
> But doesn't reverting everything will bring it back to the state it was
> before, in that `--disable-bootstrap` is still broken.

No, --disable-bootstrap alone works fine, see the subject of the PR.

> A proper fix is needed here, would changing the way gnatlink receives it's
> arguments be acceptable? Not quoting them would solve the problem for both
> platforms along with Richard's original patch.

No, I don't think that we want this kind of earthquakes in gnatlink.

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Testing fix.

[Bug middle-end/87886] ICE in format_helper, at real.h:227

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> I've long said that the FE using built-in annotated decls with improper
> prototype is a bug...
> 
> That said, generic-match.c uses get_call_combined_fn which probably
> should do what gimple_call_combined_fn does - verify types "appropriately".

I'm afraid that it wouldn't help in this case, because I think
gimple_call_combined_fn compares the passed argument types against
TYPE_ARG_TYPES of the type of the fndecl; that matches here unfortunately.  We
would need to compare against the canonical builtin's signature (i.e.
builtin_decl_explicit (fncode)).

[Bug rtl-optimization/87895] ICE in purge_dead_edges, at cfgrtl.c:3246

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
And compiling the testcase w/ -O1 -fopenmp yeilds:

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181104 -O1 -fopenmp -c i5qefyvy.c
during GIMPLE pass: local-pure-const
i5qefyvy.c: In function 'vm.simdclone.0':
i5qefyvy.c:3:1: internal compiler error: Segmentation fault
3 | vm (int oh)
  | ^~
0xcce03f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/toplev.c:325
0x74d3b3 bool is_a_helper::test(gimple*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/gimple.h:1188
0x74d3b3 bool is_a(gimple*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/is-a.h:187
0x74d3b3 greturn* dyn_cast(gimple*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/is-a.h:224
0x74d3b3 malloc_candidate_p
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/ipa-pure-const.c:977
0x15323d6 analyze_function
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/ipa-pure-const.c:1115
0x153584c execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/ipa-pure-const.c:2095

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |9.0

[Bug other/82857] libbacktrace: please support binaries stripped with dwz -m (following the .gnu_debugaltlink)

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Created attachment 44962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44962&action=edit
WIP patch, handles DW_FORM_GNU_strp_alt

With this patch, the test-case from comment 1 passes:
...
Non-stripped
1
Stripped
0
Stripped with debuglink
1
Stripped with debuglink to compressed with objcopy
1
Stripped with debuglink to compressed with dwz
1
Stripped with debuglink to compressed with dwz -m
1
...

In more detail, we get the backtrace with function name 'main', and the full
path for bt.c:
...
0x400eff main
/data/gcc_versions/devel/bt.c:20
0x7fe303fcaf49 __libc_start_main
../csu/libc-start.c:308
0x400da9 ???
../sysdeps/x86_64/start.S:120
0x ???
???:0
...

[Bug bootstrap/87891] problems with building cross GCC for target powerpc64-darwin from powerpc-darwin

[dougmencken at gmail dot com]

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

--- Comment #10 from Douglas Mencken  ---
And this one is beyond my understanding

/bin/sh ../../../gcc-8.2.0/libgcc/../mkinstalldirs .
/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/bin/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/ -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/include -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/sys-include-O2 
-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -mmacosx-version-min=10.5 -pipe -Wa,-force_cpusubtype_ALL
-mmacosx-version-min=10.4 -fno-common -mlong-double-128 -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -dynamiclib
-nodefaultlibs -install_name
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/libgcc_s.1.dylib
-single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map
-compatibility_version 1 -current_version 1.0 -g -O2 -B./ _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o
_floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o
_fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o
_fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _floattidf_s.o
_floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o
_floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o
_udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o darwin-tramp_s.o
darwin-64_s.o darwin-fpsave_s.o darwin-gpsave_s.o darwin-world_s.o
ibm-ldouble_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o darwin-fallback_s.o
emutls_s.o libgcc.a -lc
MLIBS=`/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/bin/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/ -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/include -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/sys-include   
--print-multi-lib | sed -e 's/;.*$//'` ; \
for mlib in $MLIBS ; do \
  cp ../${mlib}/libgcc/${mlib}/libgcc_s.dylib  \
./libgcc_s.1.dylib_T_${mlib} || exit 1 ; \
done
powerpc64-unknown-darwin-lipo -output libgcc_s.1.dylib \
  -create libgcc_s.1.dylib_T*
rm libgcc_s.1.dylib_T*
MLIBS=`/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/bin/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/ -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/include -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/sys-include   
--print-multi-lib | sed -e 's/;.*$//'` ; \
for mlib in $MLIBS ; do \
  powerpc64-unknown-darwin-strip -o libgcc_ext.10.4.dylib_T${mlib} \
-R ../../../gcc-8.2.0/libgcc/config/rs6000/libgcc-darwin.10.4.ver
-c -urx \
../${mlib}/libgcc/${mlib}/libgcc_s.dylib || exit 1 ; \
done
powerpc64-unknown-darwin-strip: symbols names listed in:
../../../gcc-8.2.0/libgcc/config/rs6000/libgcc-darwin.10.4.ver not in:
/Volumes/hfsplushd/Development/gcc-toolchain/_build/powerpc64-unknown-darwin/libgcc/libgcc_s.dylib
__Unwind_Backtrace
__Unwind_DeleteException
__Unwind_FindEnclosingFunction
__Unwind_Find_FDE
__Unwind_ForcedUnwind
__Unwind_GetCFA
__Unwind_GetDataRelBase
__Unwind_GetGR
__Unwind_GetIP
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
__Unwind_RaiseException
__Unwind_Resume
__Unwind_Resume_or_Rethrow
__Unwind_SetGR
__Unwind_SetIP
___absvdi2
___absvsi2
___addvdi3
___addvsi3
___ashldi3
___ashrdi3
___clear_cache
___clzdi2
___clzsi2
___cmpdi2
___ctzdi2
___ctzsi2
___deregister_frame
___deregister_frame_in

[Bug bootstrap/87891] problems with building cross GCC for target powerpc64-darwin from powerpc-darwin

[dougmencken at gmail dot com]

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

--- Comment #11 from Douglas Mencken  ---
That’s what I did

sudo ln -s /usr/bin/as /usr/bin/powerpc64-unknown-darwin-as

sudo ln -s /usr/bin/ld /usr/bin/powerpc64-unknown-darwin-ld

sudo ln -s /usr/bin/ar /usr/bin/powerpc64-unknown-darwin-ar

sudo rm /usr/bin/powerpc64-unknown-darwin-ranlib
sudo cat << EOF > /usr/bin/powerpc64-unknown-darwin-ranlib
#!/bin/sh
exec ranlib \${1+"\$@"}
EOF
sudo chmod +x /usr/bin/powerpc64-unknown-darwin-ranlib

sudo ln -s /usr/bin/lipo /usr/bin/powerpc64-unknown-darwin-lipo

sudo ln -s /usr/bin/strip /usr/bin/powerpc64-unknown-darwin-strip


nano gcc/as
ORIGINAL_AS_FOR_TARGET="as"

nano gcc/collect-ld
ORIGINAL_LD_FOR_TARGET="ld"


ln -s /usr/include/sys ./gcc/include/sys
ln -s /usr/include/machine ./gcc/include/machine
ln -s /usr/include/mach ./gcc/include/mach
ln -s /usr/include/ppc ./gcc/include/ppc
ln -s /usr/include/unistd.h ./gcc/include/unistd.h
ln -s /usr/include/_types.h ./gcc/include/_types.h

ln -s /usr/include/stdlib.h ./gcc/include/stdlib.h
ln -s /usr/include/available.h ./gcc/include/available.h
ln -s /usr/include/alloca.h ./gcc/include/alloca.h

ln -s /usr/include/pthread.h ./gcc/include/pthread.h
ln -s /usr/include/pthread_impl.h ./gcc/include/pthread_impl.h
ln -s /usr/include/sched.h ./gcc/include/sched.h
ln -s /usr/include/time.h ./gcc/include/time.h
ln -s /usr/include/_structs.h ./gcc/include/_structs.h

ln -s /usr/include/string.h ./gcc/include/string.h

mv gcc/include/stdint.h gcc/include/stdint.h.gcc
ln -s /usr/include/stdint.h ./gcc/include/stdint.h

ln -s /usr/include/signal.h ./gcc/include/signal.h

ln -s /usr/include/dlfcn.h ./gcc/include/dlfcn.h

ln -s /usr/include/AvailabilityMacros.h ./gcc/include/AvailabilityMacros.h

ln -s /usr/include/mach-o ./gcc/include/mach-o
ln -s /usr/include/architecture ./gcc/include/architecture
ln -s /usr/include/libkern ./gcc/include/libkern

[Bug tree-optimization/87898] New: [8/9 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:961

[asolokha at gmx dot com]

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

Bug ID: 87898
   Summary: [8/9 Regression] ICE in
separate_decls_in_region_debug, at tree-parloops.c:961
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-9.0.0-alpha20181104 snapshot (r265779) ICEs when compiling the following
snippet w/ -O1 -floop-parallelize-all -fopenmp -ftree-parallelize-loops=2
-fvar-tracking-assignments:

#pragma omp declare simd
void
h0 (int re)
{
  re = 0;
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181104 -O1 -floop-parallelize-all
-fopenmp -ftree-parallelize-loops=2 -fvar-tracking-assignments -c i5qefyvy.c
during GIMPLE pass: parloops
i5qefyvy.c: In function 'h0.simdclone.0':
i5qefyvy.c:3:1: internal compiler error: in separate_decls_in_region_debug, at
tree-parloops.c:961
3 | h0 (int re)
  | ^~
0xd7d8c7 separate_decls_in_region_debug
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-parloops.c:961
0xd7d8c7 separate_decls_in_region
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-parloops.c:1378
0xd7eb3b gen_parallel_loop
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-parloops.c:2455
0xd80a3b parallelize_loops
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-parloops.c:3417
0xd81c2d execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-parloops.c:3499
0xd81c2d execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-parloops.c:3478

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

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

--- Comment #50 from Alexandre Oliva  ---
Do we want lang_requires="c c++" in ada's config-lang.in, then?

[Bug tree-optimization/87896] [9 Regression] ICE in verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Looks like a latent issue?  We have EDGE_IGNORE set on edges so

  if ((e->flags & ~(EDGE_DFS_BACK
| EDGE_CAN_FALLTHRU
| EDGE_IRREDUCIBLE_LOOP
| EDGE_LOOP_EXIT
| EDGE_CROSSING
| EDGE_PRESERVE)) == 0)
n_branch++;

doesn't count them.  The flag is set by
vr-values.c:simplify_switch_using_ranges
but never reset.

/* An edge we should ignore.  It should be entirely local to
   passes.  ie, it is never set on any edge upon the completion
   of any pass.  */
DEF_EDGE_FLAG(IGNORE, 17)

We could clear the flag in vr_values::~vr_values, but not sure if that's
the best thing to do.  VRP and DOM could do that as well.  tree-vrp.c
used to clear EDGE_IGNORE but the issue must be that we somehow _do_
thread (and copy) those edges?!

That is, we seem to look at EDGE_IGNORE only in thread_outgoing_edges but
appearantly not on all edges included in a threading path?  As said edges
marked this way are determined to be never executed.

Jeff?

[Bug tree-optimization/85787] malloc_candidate_p fails to detect malloc attribute on nested phis

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
Should this PR be closed now?

[Bug rtl-optimization/87895] [7/8/9 Regression] ICE in purge_dead_edges, at cfgrtl.c:3246

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4
Summary|ICE in purge_dead_edges, at |[7/8/9 Regression] ICE in
   |cfgrtl.c:3246   |purge_dead_edges, at
   ||cfgrtl.c:3246

[Bug tree-optimization/83648] missing -Wsuggest-attribute=malloc on a trivial malloc-like function

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
Should this PR be closed now?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

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

--- Comment #51 from Alexandre Oliva  ---
for native builds, I mean.  hmm, I wonder if we can test for a native build in
config-lang.in...

[Bug rtl-optimization/87874] [8/9 Regression] ICE in simplify_subreg, at simplify-rtx.c:6396

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00332.html

[Bug tree-optimization/87898] [8/9 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:961

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Well, obviously the profile-consistency checking requires up-to-date IL but
that cannot be ensured before TODO of a pass was run.  So I'm not sure why it
is
run twice?

  if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))
check_profile_consistency (pass->static_pass_number, 0, true);

  /* Run post-pass cleanup and verification.  */
  execute_todo (todo_after | pass->todo_flags_finish | TODO_verify_il);
  if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))
check_profile_consistency (pass->static_pass_number, 1, true);

docs say

/* Do profile consistency book-keeping for the pass with static number INDEX.
   If SUBPASS is zero, we run _before_ the pass, and if SUBPASS is one, then
   we run _after_ the pass.  RUN is true if the pass really runs, or FALSE

but the first call above isn't before the pass, it is before the TODO of
the pass?!

That is, the following fixes the ICE and placement according to docs.

Honza?

diff --git a/gcc/passes.c b/gcc/passes.c
index d838d909941..4d600eeb7b9 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -2163,15 +2163,15 @@ execute_one_ipa_transform_pass (struct cgraph_node
*node,
   if (pass->tv_id != TV_NONE)
 timevar_push (pass->tv_id);

+  if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))
+check_profile_consistency (pass->static_pass_number, 0, true);
+
   /* Run pre-pass verification.  */
   execute_todo (ipa_pass->function_transform_todo_flags_start);

   /* Do it!  */
   todo_after = ipa_pass->function_transform (node);

-  if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))
-check_profile_consistency (pass->static_pass_number, 0, true);
-
   /* Run post-pass cleanup and verification.  */
   execute_todo (todo_after);
   verify_interpass_invariants ();
@@ -2417,6 +2417,9 @@ execute_one_pass (opt_pass *pass)
   if (pass->tv_id != TV_NONE)
 timevar_push (pass->tv_id);

+  if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))
+check_profile_consistency (pass->static_pass_number, 0, true);
+
   /* Run pre-pass verification.  */
   execute_todo (pass->todo_flags_start);

@@ -2461,9 +2464,6 @@ execute_one_pass (opt_pass *pass)

   do_per_function (update_properties_after_pass, pass);

-  if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))
-check_profile_consistency (pass->static_pass_number, 0, true);
-
   /* Run post-pass cleanup and verification.  */
   execute_todo (todo_after | pass->todo_flags_finish | TODO_verify_il);
   if (profile_report && cfun && (cfun->curr_properties & PROP_cfg))

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #52 from Eric Botcazou  ---
> for native builds, I mean.  hmm, I wonder if we can test for a native build
> in config-lang.in...

Yes, that would be ideal.

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
The patch makes sense to me. I am not sure why it was run after pass but before
cleanups originally... Seems like a bug.

[Bug rtl-optimization/87895] [7/8/9 Regression] ICE in purge_dead_edges, at cfgrtl.c:3246

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
And another one, apparently:

#pragma omp declare simd
int
vm (int *ty, int oh)
{
  if ((oh == 0) ? (*ty = 0) : *ty)
return 0;
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181104 -O1 -fopenmp -c logpnyyb.c
logpnyyb.c: In function 'vm.simdclone.0':
logpnyyb.c:3:1: error: fallthru to exit from bb 10
3 | vm (int *ty, int oh)
  | ^~
during GIMPLE pass: dom
logpnyyb.c:3:1: internal compiler error: verify_flow_info failed
0x8a889a verify_flow_info()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfghooks.c:265
0xd1d674 checking_verify_flow_info
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfghooks.h:198
0xd1d674 cleanup_tree_cfg_noloop
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-cfgcleanup.c:938
0xd1d674 cleanup_tree_cfg()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-cfgcleanup.c:989
0xbec05c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/passes.c:1878
0xbecece execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/passes.c:1979

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
OK, I now recall. The intend was really to have three values 
- profile before pass was run (which you can see from stats of previous
  pass)
- profile after pass was run
- profile after cleanups

This is somewhat useful because, say for CCP one can see how much code
sped up just by removing some calculation and how much it was affected
by subsequent unreacable code removal.  If we can't calculate the middle
value safely, we can just drop it.

Honza

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
One more test-case:

$ cat ice.ii
struct c {
  int b;
};
struct e : c {
  constexpr e() : c{} {}
};
using d = e;
const int &a((2, d{}).b);

$ g++ ice.ii -c
ice.ii:8:24: internal compiler error: in build_target_expr_with_type, at
cp/tree.c:793
8 | const int &a((2, d{}).b);
  |^
0x67a78d build_target_expr_with_type(tree_node*, tree_node*, int)
../../gcc/cp/tree.c:793
0x887963 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5110
0x88accc maybe_constant_init_1
../../gcc/cp/constexpr.c:5371
0x859d10 set_up_extended_ref_temp
../../gcc/cp/call.c:11144
0x859d10 extend_ref_init_temps_1
../../gcc/cp/call.c:11304
0xa217f7 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:815
0x8b334d check_initializer
../../gcc/cp/decl.c:6486
0x8cb79c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7162
0x96776b cp_parser_init_declarator
../../gcc/cp/parser.c:20033
0x96f203 cp_parser_simple_declaration
../../gcc/cp/parser.c:13219
0x974262 cp_parser_declaration
../../gcc/cp/parser.c:12916
0x974a0c cp_parser_translation_unit
../../gcc/cp/parser.c:4668
0x974a0c c_parse_file()
../../gcc/cp/parser.c:39266
0xa77000 c_common_parse_file()
../../gcc/c-family/c-opts.c:1150

[Bug tree-optimization/85787] malloc_candidate_p fails to detect malloc attribute on nested phis

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Nov  6 10:22:05 2018
New Revision: 265832

URL: https://gcc.gnu.org/viewcvs?rev=265832&root=gcc&view=rev
Log:
S/390: Fix PR87723

gcc/ChangeLog:

2018-11-06  Andreas Krebbel  

PR target/87723
* config/s390/s390.md ("*rsbg_di_rotl"): Remove mode
attributes for operands 3 and 4.

gcc/testsuite/ChangeLog:

2018-11-06  Andreas Krebbel  

PR target/87723
* gcc.target/s390/pr87723.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr87723.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Nov  6 10:23:30 2018
New Revision: 265833

URL: https://gcc.gnu.org/viewcvs?rev=265833&root=gcc&view=rev
Log:
2018-11-06  Richard Biener  

PR tree-optimization/87889
* tree-vect-loop-manip.c (slpeel_duplicate_current_defs_from_edges):
Do nothing if old and new arg are the same

* gcc.dg/pr87894.c: New testcase.

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

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
First, I have tested the patch at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892
with the test in pr40196 comment 9 without seeing any problem.
So it seems that the problem has been introduced/uncovered by the subsequent
changes.

Second, I see the ICE for two quite different reduced tests:

module m
  character (:), allocatable :: str
  type :: mytype
character(6) :: str
  end type
end module

  use m

  type(mytype) :: der

  str = "abcd"

!  if (str%kind .ne. kind (str)) stop 6
  if (der%str%len .ne. len (der%str)) stop 7
end

for which the ICE is also seen for the commented line, and

  complex, parameter :: zc = ( 99.0, 199.0 )
  REAL, parameter :: rc = zc%re
  REAL, parameter :: ic = zc%im

end

for which the two lines 'REAL, parameter' are needed to trigger the ICE.

Compiling these tests with an instrumented compiler gives:

=
==75699==ERROR: AddressSanitizer: heap-use-after-free on address 0x617045d8
at pc 0x00010015620e bp 0x7ffeefbfccf0 sp 0x7ffeefbfcce8
READ of size 8 at 0x617045d8 thread T0
#0 0x10015620d in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1943
#1 0x1001528fb in gfc_simplify_expr(gfc_expr*, int) expr.c:2064
#2 0x100369fe7 in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2287
#3 0x1003765a8 in gfc_match_rvalue(gfc_expr**) primary.c:3429
#4 0x10025a96b in match_primary(gfc_expr**) matchexp.c:157
#5 0x10025abfa in match_level_1(gfc_expr**) matchexp.c:211
#6 0x10025af6b in match_mult_operand(gfc_expr**) matchexp.c:264
#7 0x10025b7ac in match_add_operand(gfc_expr**) matchexp.c:351
#8 0x10025c1ba in match_level_2(gfc_expr**) matchexp.c:480
#9 0x10025c726 in match_level_3(gfc_expr**) matchexp.c:547
#10 0x10025cb9f in match_level_4(gfc_expr**) matchexp.c:593
#11 0x10025d9d5 in match_and_operand(gfc_expr**) matchexp.c:693
#12 0x10025dca8 in match_or_operand(gfc_expr**) matchexp.c:718
#13 0x10025e10d in match_equiv_operand(gfc_expr**) matchexp.c:761
#14 0x10025e57b in match_level_5(gfc_expr**) matchexp.c:806
#15 0x10025a48f in gfc_match_expr(gfc_expr**) matchexp.c:865
#16 0x10015adb1 in gfc_match_init_expr(gfc_expr**) expr.c:2987
#17 0x1000f6516 in variable_decl(int) decl.c:2715
#18 0x1000f77f3 in gfc_match_data_decl() decl.c:5926
#19 0x100330018 in match_word(char const*, match (*)(), locus*) parse.c:65
#20 0x10033c950 in decode_statement() parse.c:376
#21 0x10033eef6 in next_free() parse.c:1234
#22 0x10033f8cb in next_statement() parse.c:1466
#23 0x100345fab in parse_spec(gfc_statement) parse.c:3858
#24 0x10034cbfa in parse_progunit(gfc_statement) parse.c:5671
#25 0x10034f8de in gfc_parse_file() parse.c:6259
#26 0x100522fbf in gfc_be_parse_file() f95-lang.c:204
#27 0x10611cde8 in compile_file() toplev.c:455
#28 0x1061284a3 in do_compile() toplev.c:2172
#29 0x10915f5d7 in toplev::main(int, char**) toplev.c:2307
#30 0x1095b359c in main main.c:39
#31 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

0x617045d8 is located 728 bytes inside of 736-byte region
[0x61704300,0x617045e0)
freed by thread T0 here:
#0 0x158cb18e0 in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x10012e5f7 in gfc_free_ref_list(gfc_ref*) expr.c:599
#2 0x10012ecef in free_expr0(gfc_expr*) expr.c:505
#3 0x10012f0d0 in gfc_replace_expr(gfc_expr*, gfc_expr*) expr.c:616
#4 0x10015601c in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1970
#5 0x1001528fb in gfc_simplify_expr(gfc_expr*, int) expr.c:2064
#6 0x100369fe7 in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2287
#7 0x1003765a8 in gfc_match_rvalue(gfc_expr**) primary.c:3429
#8 0x10025a96b in match_primary(gfc_expr**) matchexp.c:157
#9 0x10025abfa in match_level_1(gfc_expr**) matchexp.c:211
#10 0x10025af6b in match_mult_operand(gfc_expr**) matchexp.c:264
#11 0x10025b7ac in match_add_operand(gfc_expr**) matchexp.c:351
#12 0x10025c1ba in match_level_2(gfc_expr**) matchexp.c:480
#13 0x10025c726 in match_level_3(gfc_expr**) matchexp.c:547
#14 0x10025cb9f in match_level_4(gfc_expr**) matchexp.c:593
#15 0x10025d9d5 in match_and_operand(gfc_expr**) matchexp.c:693
#16 0x10025dca8 in match_or_operand(gfc_expr**) matchexp.c:718
#17 0x10025e10d in match_equiv_operand(gfc_expr**) matchexp.c:761
#18 0x10025e57b in match_level_5(gfc_expr**) matchexp.c:806
#19 0x10025a48f in gfc_match_expr(gfc_expr**) matchexp.c:865
#20 0x1

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Author: ro
Date: Tue Nov  6 10:42:05 2018
New Revision: 265836

URL: https://gcc.gnu.org/viewcvs?rev=265836&root=gcc&view=rev
Log:
Cherry-pick Solaris sanitizer fixes (PR sanitizer/80953)

PR sanitizer/80953
* sanitizer_common/sanitizer_internal_defs.h,
sanitizer_common/sanitizer_platform_limits_solaris.h,
sanitizer_common/sanitizer_procmaps_solaris.cc,
sanitizer_common/sanitizer_solaris.cc: Cherry-pick compiler-rt
revision 346153.
* sanitizer_common/sanitizer_stacktrace.h,
sanitizer_common/sanitizer_stacktrace_sparc.cc: Cherry-pick
compiler-rt revision 346155.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.h
trunk/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cc
trunk/libsanitizer/sanitizer_common/sanitizer_solaris.cc
trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.h
trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cc

[Bug middle-end/87899] New: [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[renlin at gcc dot gnu.org]

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

Bug ID: 87899
   Summary: [9 regression]r264897 cause mis-compiled native
arm-linux-gnueabihf toolchain
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: renlin at gcc dot gnu.org
  Target Milestone: ---

since r264897, native arm-linux-gnueabihf toolchain has been mis-compiled.
Somehow, it survives boostrap.

It ICEs when compiling a lot of test cases. They fail with similar message.
For example:

./gcc/cc1 ~/gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c  -O3
 test main
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
  Streaming LTO
   
Assembling
functions:
  testduring GIMPLE pass: ldist

gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c: In function ‘test’:
gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c:9:1: internal compiler
error: Segmentation fault
9 | test (void)
  | ^~~~
0x5c3a37 crash_signal
../../gcc/gcc/toplev.c:325
0x63ef6b inchash::hash::add(void const*, unsigned int)
../../gcc/gcc/inchash.h:100
0x63ef6b inchash::hash::add_ptr(void const*)
../../gcc/gcc/inchash.h:94
0x63ef6b ddr_hasher::hash(data_dependence_relation const*)
../../gcc/gcc/tree-loop-distribution.c:143
0x63ef6b hash_table::find_slot(data_dependence_relation* const&, insert_option)
../../gcc/gcc/hash-table.h:414
0x63ef6b get_data_dependence
../../gcc/gcc/tree-loop-distribution.c:1184
0x63f2bd data_dep_in_cycle_p
../../gcc/gcc/tree-loop-distribution.c:1210
0x63f2bd update_type_for_merge
../../gcc/gcc/tree-loop-distribution.c:1255
0x64064b build_rdg_partition_for_vertex
../../gcc/gcc/tree-loop-distribution.c:1302
0x64064b rdg_build_partitions
../../gcc/gcc/tree-loop-distribution.c:1754
0x64064b distribute_loop
../../gcc/gcc/tree-loop-distribution.c:2795
0x642299 execute
../../gcc/gcc/tree-loop-distribution.c:3133
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  ---
Author: ro
Date: Tue Nov  6 10:49:34 2018
New Revision: 265837

URL: https://gcc.gnu.org/viewcvs?rev=265837&root=gcc&view=rev
Log:
Enable libsanitizer on Solaris (PR sanitizer/80953)

gcc:
PR sanitizer/80953
* config/sol2.h (ASAN_CC1_SPEC): Define.
(LD_WHOLE_ARCHIVE_OPTION): Define.
(LD_NO_WHOLE_ARCHIVE_OPTION): Define.
(ASAN_REJECT_SPEC): Provide default.
(LIBASAN_EARLY_SPEC): Define.
(LIBTSAN_EARLY_SPEC): Define.
(LIBLSAN_EARLY_SPEC): Define.
* config/i386/sol2.h (CC1_SPEC): Redefine.
(ASAN_REJECT_SPEC): Define.

* config/sparc/sparc.c (sparc_asan_shadow_offset): Declare.
(TARGET_ASAN_SHADOW_OFFSET): Define.
(sparc_asan_shadow_offset): New function.
* config/sparc/sol2.h (CC1_SPEC): Append ASAN_CC1_SPEC.
(ASAN_REJECT_SPEC): Define.

gcc/testsuite:
PR sanitizer/80953
* c-c++-common/asan/alloca_loop_unpoisoning.c: Require alloca
support.
(foo): Use __builtin_alloca.

libsanitizer:
PR sanitizer/80953
* configure.tgt (sparc*-*-solaris2.11*): Enable.
(x86_64-*-solaris2.11* | i?86-*-solaris2.11*): Enable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sol2.h
trunk/gcc/config/sol2.h
trunk/gcc/config/sparc/sol2.h
trunk/gcc/config/sparc/sparc.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/configure.tgt

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-11/msg00337.ht
   ||ml
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #10 from Rainer Orth  ---
Fixed for 9.0.

[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|8.0 |9.0
   Target Milestone|--- |9.0

[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #23 from Rainer Orth  ---
(In reply to Eric Gallager from comment #22)
> (In reply to Rainer Orth from comment #8)
> > Fixed for 4.8.0.
> 
> Rainer, do you want to remain the assignee for this? It was reopened for a
> different platform than you originally opened it for... Although, then again:
> 
> (In reply to Jason Merrill from comment #18)
> > Author: jason
> > Date: Wed Mar  6 15:34:11 2013
> > New Revision: 196493
> > 
> > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196493
> > Log:
> > PR debug/53363
> > * g++.dg/debug/dwarf2/thunk1.C: Skip on darwin.
> > 
> > Modified:
> > trunk/gcc/testsuite/ChangeLog
> > trunk/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
> 
> ...did this fix it? If so we can just close it and it won't matter who the
> assignee is.

I don't see any failure of this test on any target, so it can be closed.

Thanks for looking after this.

  Rainer

[Bug d/87865] gdc doesn't build unless assert is marked noreturn

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Iain Buclaw  ---
> It required removing all system includes from all dmd frontend sources, but I
> think this OK now.  I have verified that gcc_assert() is being called now
> instead of assert().

I've now been able to build gdc/d21 on sparc-sun-solaris2.10 and
i386-pc-solaris2.10 without issues.

Thanks for fixing this.

Rainer

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #4 from Martin Liška  ---
Let me finish that based on what was discussed on IRC:

 dead BBs can have bogus IL,
 for example propagators do not bother to update IL in such blocks but
release SSA names that are otherwise propagated out
 but actual BB removal is left to CFG cleanup because that knows how to
properly do that
 hmm, that is not very pretty but I guess we could just drop the middle
value.
 one can modify the code to account only reachable BBs but that would
give simliar values as doing accounting after cfgcleanup.
 so that would mean moving both calls after TODO?
 just completely dropping the first call and the first accounted number
would be OK I guess
 if it can't be computed safely, that is.
 but the docs say theres two phases - so it isn't really two phases?!
 we can also elide the first call if TODO_cfg_cleanup
 but then there isn't any cleanup and the first call is pointless
 why does it use estimate_num_insns rather than just counting stmts?
 well, the statistics was originally intended to help judging if, say,
re-running fre for third time is useful
 it's about profile after all?
 because you can do FDO build and then you get number of much the code
has similified after every pass
 OK, but then that's the after-TODO value that is interesting
 estimate_num_insns is used to estimate runtime of the program
 it also accounts profile mismatches.  The two runs was really done to
have idea how much the pass itself mangled the profile and how much the profile
was beaten during the cfg cleanups the pass invoked
 having only the second value is OK
 if calculating first meaningfully is a trouble.
 so we can look at the profile only in the first pass and the size/time
in the second?
 yes, that would work, too.
 anyway, I leave the PR to somebody else ;)
 I can look into it next week.
 works for me
 I wanted to discuss a bit the pointers.  So my understanding is that
C++ has rvalue and normal referneces.

[Bug tree-optimization/87900] New: malloc + memse to calloc doesn't work for aggregate initialization

[rguenth at gcc dot gnu.org]

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

Bug ID: 87900
   Summary: malloc + memse to calloc doesn't work for aggregate
initialization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

struct S { int a[1024]; };
struct S *foo ()
{
  struct S *p = (struct S *)__builtin_malloc (sizeof (struct S));
  *p = (struct S){};
  return p;
}

is not transformed to calloc, it only works when doing

  __builtin_memset (p, 0, sizeof (struct S));

the strlen pass is doing this transform (also DSEing zero-inits after calloc).

[Bug tree-optimization/87901] New: partial DSE of memset doesn't work for other kind of stores

[rguenth at gcc dot gnu.org]

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

Bug ID: 87901
   Summary: partial DSE of memset doesn't work for other kind of
stores
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When transforming the memsets in tree-ssa/ssa-dse-25.c to = {} and = 0 inits
the DSE pass no longer knows how to trim them.

Similarly for

int i;
void foo ()
{
  i = 0;
  *((short *)&i + sizeof (int) - sizeof (short)) = 1;
}

[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #27563|0   |1
is obsolete||

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

Updated patch.  There are the expected missing warnings plus the two missed
optimizations noted by the bugs this now depends on.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #29 from Richard Biener  ---
On the original testcase I now get

> ./f951  -quiet -Ofast t.f90 -march=core-avx2 -fopt-info-vec 
t.f90:157:0: optimized: loop vectorized using 32 byte vectors
t.f90:158:0: optimized: basic block part vectorized using 32 byte vectors

the non-reduced testcase still doesn't see any vectorization.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-06
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's mainline bug, I'll report that.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://github.com/google/s
   ||anitizers/issues/1019

--- Comment #2 from Martin Liška  ---
Reported upstream.

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-6
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
In general we have issues with warnings when sanitizers are used.
Martin: What about notifying users that one should not combine sanitizers and
warnings? It's becoming a very common issue.

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Martin Liška  ---
Richi can you please assign that?

[Bug rtl-optimization/87902] New: [9 Regression] Shrink-wrapping multiple conditions

[iii at linux dot ibm.com]

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

Bug ID: 87902
   Summary: [9 Regression] Shrink-wrapping multiple conditions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iii at linux dot ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
Target: s390x-linux-gnu

I've noticed that r265830 fails to shrink-wrap multiple early returns in
gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c, while r264877 managed to
do so just fine.

After reload we end up with the following code for those conditions:

;; basic block 2
(note 5 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 3 5 2 2 NOTE_INSN_FUNCTION_BEG)
(insn 2 3 7 2 (set (reg/v:DI 12 %r12 [orig:63 aD.2191+-4 ] [63])
(reg:DI 2 %r2 [72]))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":14:1 1269 {*movdi_64}
 (nil))
(insn 7 2 8 2 (set (reg:CCZ 33 %cc)
(compare:CCZ (reg:SI 12 %r12 [orig:63 aD.2191 ] [63])
(const_int 42 [0x2a])))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":17:6 1232 {*cmpsi_cct}
 (nil))
(jump_insn 8 7 9 2 (set (pc)
(if_then_else (eq (reg:CCZ 33 %cc)
(const_int 0 [0]))
(label_ref:DI 33)
(pc))) "gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":17:6
1896 {*cjump_64}
 (int_list:REG_BR_PROB 225163668 (nil))
 -> 33)

;; basic block 3
(note 9 8 12 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 12 9 13 3 (set (reg:CCS 33 %cc)
(compare:CCS (reg:SI 12 %r12 [orig:63 aD.2191 ] [63])
(const_int 0 [0])))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":20:3 1222
{*tstsi_cconly2}
 (nil))
(jump_insn 13 12 14 3 (set (pc)
(if_then_else (le (reg:CCS 33 %cc)
(const_int 0 [0]))
(label_ref:DI 33)
(pc))) "gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":20:3
1896 {*cjump_64}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 33)

Note that comparisons use a copy in caller-saved %r12, and not %r2.  Then,
prepare_shrink_wrap () successfully propagates it to basic block 2. Basic block
3 is not affected - this seems to be by design, since prepare_shrink_wrap ()
only concerns itself with the first basic block.

In the past reload used to eliminate the copy and use %r2 directly in both
comparisons, but this seems to be no longer the case.

[Bug target/87903] New: Documentation for __builtin_cpu_supports and __builtin_cpu_is is not complete

[marxin at gcc dot gnu.org]

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

Bug ID: 87903
   Summary: Documentation for __builtin_cpu_supports and
__builtin_cpu_is is not complete
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

As seen here:
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions

there are missing values for both of these options.

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #79 from Richard Biener  ---
On the GCC 8 branch with -g -O0 (x86_64-linux) I get

 TOTAL  :   9.59  0.49 10.09   
 551543 kB
10.53user 0.55system 0:11.08elapsed 99%CPU (0avgtext+0avgdata
1230908maxresident)k
0inputs+68384outputs (0major+379474minor)pagefaults 0swaps

On trunk with mem-stats the biggest offender is (as reported)

df_scan mw_reg  alloc-pool.h:487 (df_scan_alloc)   
  1136 0 :  0.0%  483M   38M: 92.4%  32

going up to -Ofast makes compile-time explode again.  For the reduced testcase
it's still inlining and PTA:

 ipa inlining heuristics:  41.55 ( 36%)   0.01 (  1%)  41.60 ( 36%)
   6333 kB (  2%)
 alias stmt walking :  14.73 ( 13%)   0.14 ( 18%)  14.98 ( 13%)
164 kB (  0%)
 tree PTA   :  37.93 ( 33%)   0.23 ( 30%)  38.16 ( 33%)
  31921 kB (  8%)
 TOTAL  : 115.67  0.77116.52   
 411925 kB
115.83user 0.81system 1:56.71elapsed 99%CPU (0avgtext+0avgdata
1034364maxresident)k
1624inputs+12624outputs (1major+308881minor)pagefaults 0swaps

trunk seems to behave similar:

 ipa inlining heuristics:  53.74 ( 41%)   0.02 (  2%)  53.75 ( 40%)
   5428 kB (  1%)
 alias stmt walking :  14.98 ( 11%)   0.19 ( 23%)  15.16 ( 11%)
165 kB (  0%)
 tree PTA   :  39.70 ( 30%)   0.24 ( 29%)  39.92 ( 30%)
  31896 kB (  8%)
 TOTAL  : 132.01  0.83132.85   
 407617 kB
132.01user 0.86system 2:12.88elapsed 99%CPU (0avgtext+0avgdata
1034096maxresident)k
0inputs+8224outputs (0major+301553minor)pagefaults 0swaps

flat perf profile:

Samples: 510K of event 'instructions:p', Event count (approx.): 715615147320
Overhead   Samples  Command  Shared Object Symbol   
   8.08% 95243  f951 f951  [.] bitmap_ior_into
   7.21% 25966  f951 f951  [.] sreal::operator*
   5.43% 19353  f951 f951  [.]
hash_table

[Bug target/87903] Documentation for __builtin_cpu_supports and __builtin_cpu_is is not complete

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-06
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Current values one can see in code:

  const arch_names_table[] =
{
  {"amd", M_AMD},
  {"intel", M_INTEL},
  {"atom", M_INTEL_BONNELL},
  {"slm", M_INTEL_SILVERMONT},
  {"core2", M_INTEL_CORE2},
  {"corei7", M_INTEL_COREI7},
  {"nehalem", M_INTEL_COREI7_NEHALEM},
  {"westmere", M_INTEL_COREI7_WESTMERE},
  {"sandybridge", M_INTEL_COREI7_SANDYBRIDGE},
  {"ivybridge", M_INTEL_COREI7_IVYBRIDGE},
  {"haswell", M_INTEL_COREI7_HASWELL},
  {"broadwell", M_INTEL_COREI7_BROADWELL},
  {"skylake", M_INTEL_COREI7_SKYLAKE},
  {"skylake-avx512", M_INTEL_COREI7_SKYLAKE_AVX512},
  {"cannonlake", M_INTEL_COREI7_CANNONLAKE},
  {"icelake-client", M_INTEL_COREI7_ICELAKE_CLIENT},
  {"icelake-server", M_INTEL_COREI7_ICELAKE_SERVER},
  {"bonnell", M_INTEL_BONNELL},
  {"silvermont", M_INTEL_SILVERMONT},
  {"goldmont", M_INTEL_GOLDMONT},
  {"goldmont-plus", M_INTEL_GOLDMONT_PLUS},
  {"tremont", M_INTEL_TREMONT},
  {"knl", M_INTEL_KNL},
  {"knm", M_INTEL_KNM},
  {"amdfam10h", M_AMDFAM10H},
  {"barcelona", M_AMDFAM10H_BARCELONA},
  {"shanghai", M_AMDFAM10H_SHANGHAI},
  {"istanbul", M_AMDFAM10H_ISTANBUL},
  {"btver1", M_AMD_BTVER1},  
  {"amdfam15h", M_AMDFAM15H},
  {"bdver1", M_AMDFAM15H_BDVER1},
  {"bdver2", M_AMDFAM15H_BDVER2},
  {"bdver3", M_AMDFAM15H_BDVER3},
  {"bdver4", M_AMDFAM15H_BDVER4},
  {"btver2", M_AMD_BTVER2},
  {"amdfam17h", M_AMDFAM17H},
  {"znver1", M_AMDFAM17H_ZNVER1},
  {"znver2", M_AMDFAM17H_ZNVER2},
};

  const isa_names_table[] =
{
  {"cmov",F_CMOV},
  {"mmx", F_MMX},
  {"popcnt",  F_POPCNT},
  {"sse", F_SSE},
  {"sse2",F_SSE2},
  {"sse3",F_SSE3},
  {"ssse3",   F_SSSE3},
  {"sse4a",   F_SSE4_A},
  {"sse4.1",  F_SSE4_1},
  {"sse4.2",  F_SSE4_2},
  {"avx", F_AVX},
  {"fma4",F_FMA4},
  {"xop", F_XOP},
  {"fma", F_FMA},
  {"avx2",F_AVX2},
  {"avx512f", F_AVX512F},
  {"bmi", F_BMI},
  {"bmi2",F_BMI2},
  {"aes", F_AES},
  {"pclmul",  F_PCLMUL},
  {"avx512vl",F_AVX512VL},
  {"avx512bw",F_AVX512BW},
  {"avx512dq",F_AVX512DQ},
  {"avx512cd",F_AVX512CD},
  {"avx512er",F_AVX512ER},
  {"avx512pf",F_AVX512PF},
  {"avx512vbmi",F_AVX512VBMI},
  {"avx512ifma",F_AVX512IFMA},
  {"avx5124vnniw",F_AVX5124VNNIW},
  {"avx5124fmaps",F_AVX5124FMAPS},
  {"avx512vpopcntdq",F_AVX512VPOPCNTDQ},
  {"avx512vbmi2", F_AVX512VBMI2},
  {"gfni", F_GFNI},
  {"vpclmulqdq", F_VPCLMULQDQ},
  {"avx512vnni", F_AVX512VNNI},
  {"avx512bitalg", F_AVX512BITALG}
};

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[hubicka at ucw dot cz]

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

--- Comment #80 from Jan Hubicka  ---
> 
> flat perf profile:
> 
> Samples: 510K of event 'instructions:p', Event count (approx.): 715615147320  
>   
> Overhead   Samples  Command  Shared Object Symbol 
>   
>8.08% 95243  f951 f951  [.] bitmap_ior_into
>7.21% 25966  f951 f951  [.] sreal::operator*
>5.43% 19353  f951 f951  [.]
> hash_table5.20% 23167  f951 f951  [.] get_ref_base_and_extent
>4.93% 17947  f951 f951  [.]
> profile_count::to_sreal_s
>4.37% 15865  f951 f951  [.] sreal::operator/
>3.45% 30532  f951 f951  [.] bitmap_set_bit
>3.41% 12159  f951 f951  [.]
> hash_table3.08% 11034  f951 f951  [.] default_binds_local_p_3
>3.08% 11146  f951 f951  [.]
> hash_table2.21%  7877  f951 f951  [.]
> want_inline_small_functio
>1.93%  6874  f951 f951  [.] edge_badness
>1.87%  6675  f951 f951  [.]
> compute_inlined_call_time
> 
> the ipa_fn_summary hash and edge_growth_cache / call_summary hashes are
> oddly on top of the profile...

Yep, this is because they used to be arrays indexed by symbol UIDs which
Martin converted to hash tables.  Inliner happily calls summary_get each
time it needs the summary.  I have some patches to speed this up which I
will push out after the type changes (while they add bit of extra
functionality by teaching ipa-predicates abou value range I hope they
are OK for early stage3).

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
So the suggested assert is bogus.  But indeed the issue is that
vect_create_new_slp_node eventually uses .create (0) which does nothing
and then splice does

template
inline void
vec::splice (const vec &src)
{
  if (src.m_vec)
m_vec->splice (*(src.m_vec));
}

which for m_vec == NULL is doing the reported.  I guess replacing
if (src.m_vec) with if (src.length ()) would fix this.

diff --git a/gcc/vec.h b/gcc/vec.h
index f8c039754d2..407269c5ad3 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1688,7 +1688,7 @@ template
 inline void
 vec::splice (const vec &src)
 {
-  if (src.m_vec)
+  if (src.length ())
 m_vec->splice (*(src.m_vec));
 }

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[rguenther at suse dot de]

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

--- Comment #81 from rguenther at suse dot de  ---
On Tue, 6 Nov 2018, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
> 
> --- Comment #80 from Jan Hubicka  ---
> > 
> > flat perf profile:
> > 
> > Samples: 510K of event 'instructions:p', Event count (approx.): 
> > 715615147320
> > Overhead   Samples  Command  Shared Object Symbol   
> > 
> >8.08% 95243  f951 f951  [.] bitmap_ior_into
> >7.21% 25966  f951 f951  [.] sreal::operator*
> >5.43% 19353  f951 f951  [.]
> > hash_table >5.20% 23167  f951 f951  [.] 
> > get_ref_base_and_extent
> >4.93% 17947  f951 f951  [.]
> > profile_count::to_sreal_s
> >4.37% 15865  f951 f951  [.] sreal::operator/
> >3.45% 30532  f951 f951  [.] bitmap_set_bit
> >3.41% 12159  f951 f951  [.]
> > hash_table >3.08% 11034  f951 f951  [.] 
> > default_binds_local_p_3
> >3.08% 11146  f951 f951  [.]
> > hash_table >2.21%  7877  f951 f951  [.]
> > want_inline_small_functio
> >1.93%  6874  f951 f951  [.] edge_badness
> >1.87%  6675  f951 f951  [.]
> > compute_inlined_call_time
> > 
> > the ipa_fn_summary hash and edge_growth_cache / call_summary hashes are
> > oddly on top of the profile...
> 
> Yep, this is because they used to be arrays indexed by symbol UIDs which
> Martin converted to hash tables.  Inliner happily calls summary_get each
> time it needs the summary.  I have some patches to speed this up which I
> will push out after the type changes (while they add bit of extra
> functionality by teaching ipa-predicates abou value range I hope they
> are OK for early stage3).

Awww.  I guess with no longer re-using UIDs we then get bad hashing
behavior as well :/  I hope the hash function is _not_ simply the UID?

[Bug target/87762] [9 Regression] extract_constrain_insn, at recog.c:2206 on s390x

[iii at gcc dot gnu.org]

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

--- Comment #3 from iii at gcc dot gnu.org ---
Author: iii
Date: Tue Nov  6 13:20:21 2018
New Revision: 265844

URL: https://gcc.gnu.org/viewcvs?rev=265844&root=gcc&view=rev
Log:
S/390: Introduce relative_long attribute

In order to properly fix PR87762, we need to distinguish between
instructions which support relative addressing and instructions which
don't.  We could check whether the existing "type" attribute is equal to
"larl", but there are notable exceptions (lrl, for example), and
changing them makes scheduling worse on z10.  We could also check
whether the existing "op_type" attribute is equal to "RIL-b" or "RIL-c".
However, adding a new attribute provides more flexibility, since we
don't depend idiosyncrasies which might be introduced into PoP in the
future.

gcc/ChangeLog:

2018-11-06  Ilya Leoshkevich  

PR target/87762
* config/s390/s390.md: Add relative_long attribute.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[hubicka at ucw dot cz]

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

--- Comment #82 from Jan Hubicka  ---
> > Yep, this is because they used to be arrays indexed by symbol UIDs which
> > Martin converted to hash tables.  Inliner happily calls summary_get each
> > time it needs the summary.  I have some patches to speed this up which I
> > will push out after the type changes (while they add bit of extra
> > functionality by teaching ipa-predicates abou value range I hope they
> > are OK for early stage3).
> 
> Awww.  I guess with no longer re-using UIDs we then get bad hashing
> behavior as well :/  I hope the hash function is _not_ simply the UID?

Yep, UID reuse was there precisely to make the arrays reasonably
compact.  hash is int_hash which IMO returns simply uid.

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/87896] [9 Regression] ICE in verify_flow_info failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail|7.3.1   |

--- Comment #4 from Martin Liška  ---
(In reply to Martin Liška from comment #1)
> Apparently also tip of GCC 7 is affected (but neither of GCC 7.x releases).

This is not true, I had wrongly built binary for it.

[Bug c++/87904] New: [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[marxin at gcc dot gnu.org]

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

Bug ID: 87904
   Summary: [9 Regression] ICE in lookup_mark, at cp/tree.c:2322
since r265679
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

Reduced test-case:

$ cat filer.ii
struct a {};
namespace {
void operator<<(a, int) {};
}
struct b {
  friend a &operator<<(a &, const b &);
};
using ::operator<<;
void operator<<(a, b);

a &operator<<(a &c, const b &) {
  c << 123;
}

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[stsp at users dot sourceforge.net]

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

--- Comment #2 from Stas Sergeev  ---
(In reply to Martin Liška from comment #1)
> In general we have issues with warnings when sanitizers are used.
More than that.
You also have a compile-time errors now!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
Which is completely unacceptable IMHO.

> Martin: What about notifying users that one should not combine sanitizers
> and warnings? It's becoming a very common issue.
Could you please clarify?
Do you mean, -Wall should not have been used
together with -fsanitize?
Also I wonder how do you mean to notify users,
and why not to fix the code instead.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Liška  ---
So it looks mainline is not interested in fixing support for 10 years old
glibc. I'm also not planning to fix that.

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
> diff --git a/gcc/vec.h b/gcc/vec.h
> index f8c039754d2..407269c5ad3 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1688,7 +1688,7 @@ template
>  inline void
>  vec::splice (const vec &src)
>  {
> -  if (src.m_vec)
> +  if (src.length ())
>  m_vec->splice (*(src.m_vec));
>  }

I can confirm that ubsan GCC is not happy and no run-time error is reported.

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #1)
> In general we have issues with warnings when sanitizers are used.
> Martin: What about notifying users that one should not combine sanitizers
> and warnings? It's becoming a very common issue.

We don't have issues with most of the warnings, the problems are mainly with
late warnings, FE warnings are mostly ok.  There are issues e.g. with warnings
that rely on VRP where the extra runtime checks added for sanitization will
cause fewer optimizations.  This case is I guess about thread jumping on the
NULL pointer checks.

[Bug lto/87905] New: structures in two different cpp source files with same name get flagged by ODR warning

[shentino at gmail dot com]

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

Bug ID: 87905
   Summary: structures in two different cpp source files with same
name get flagged by ODR warning
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shentino at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44964&action=edit
demonstrates the problem

This only happens when I enable -flto

Note in the test package that neither struct is exposed to the other
translation unit.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #4 from Jakub Jelinek  ---
While upstream is careless, we shouldn't be.
You can look e.g. at libgomp/config/linux/affinity.c for how to handle older
glibcs that don't define CPU_COUNT, or CPU_*_S, etc.

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[shentino at gmail dot com]

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

--- Comment #1 from Raymond Jennings  ---
just do g++ -flto *.cpp

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #5 from Martin Liška  ---
Ok, sorry for bailing that too early..

[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
so I looked a little more at this.

As Rainer points out, the libsupc++ implementation does not provide
cxa_rethrow_primary_exception whereas the libc++-abi.dylib has it.

For the macOS implementations of libstdc.6.dylib and libc++.dylib the symbols
from libc++-abi are forwarded via the presented library.  For the GCC
implementation of libstdc++.dylib, the libsupc++ implementation is statically
linked into the library.

So - it seems that the build for libsanitiser is either resolving those symbols
accidentally from the /usr/lib/libstdc++.dylib (or has been constructed to
permit them to be unresolved at link time)

 - first case seems a build bug
 - second case they should be guarded by a check for presence at runtime (IIRC
there are already an number of symbols that are guarded this way).

Longer term:
1. we could add the cxa_rethrow_primary_exception to libsupc++ (will talk to
Jonathan about the implications of this)

2. We could split libstdc++ from libsupc++ on Darwin and have the option to
build the library on top of libc++abi (forwarding the symbols as the installed
system library does).

 - this is analogous to the need to forward to the unwinder implementation
which must always be provided by the shared /usr/lib/system impl on Darwin.

It's not 100% clear at the moment if there's state in the abi lib that would
mandate that action anyway.

At the Cauldron I talked to Jonathan about potentially doing this split, and he
didn't at that point have any objection.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Hints from Jakub:

 marxin: just look at libgomp sources, I have all kinds of stuff there
 jakub: ok, then let me fix that 
 marxin: sysconf(_SC_NPROCESSORS_ONLN) is a good fallback if the
affinity doesn't work
 note even the version they wrote is of course incorrect
 it will not work on machines where the cpuset is very large
 jakub: due to buffer(4096); ?
 marxin: cpu_set_t is fixed size
 marxin: newer glibcs provide APIs where one specifies the size
 jakub: ok
 marxin: if they don't want to use sysconf because it allocates memory,
then can read /proc/cpuinfo themselves
 jakub: they read /sys/devices/system/cpu instead
 marxin: they do that on android only; /sys is newer than /proc though
 marxin: in any case, CPU_COUNT, if missing, can be easily written using
__builtin_popcountl in a loop, see libgomp/config/linux/proc.c
(gomp_cpuset_popcount)
 but that assumption that sched_getaffinity will succeed is bogus, it
might fail because it isn't implemented, or may fail because the cpu_set_t is
too small
 marxin: then you can of course allocate using their allocators
something bigger and retry
 marxin: see also gomp_init_num_threads in the same file; while you
might avoid the sysconf if they don't want to call it at start, start with
cpu_set_t size
 thanks for hints
 just note that libgomp is GPL and libsanitizer is not, so copy'n'paste
is not allowed

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
> 
> Note in the test package that neither struct is exposed to the other
> translation unit.

But it's violation of C++ ODR and as LTO compilation unit is entire program,
you then introduce violation.

[Bug lto/87906] New: [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[marxin at gcc dot gnu.org]

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

Bug ID: 87906
   Summary: [9 Regression] ICE in tree check: expected block, have
function_decl in block_ultimate_origin, at
tree.c:12326 since r264734
   Product: gcc
   Version: 9.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: ---

Following 2 files cause an ICE:

$ cat 1.ii
namespace com {
namespace sun {
namespace star {}
} // namespace sun
} // namespace com
namespace a = com::sun::star;
namespace com {
namespace sun {
namespace star {
namespace uno {
class b {
public:
  ~b();
};
class c {
  b e;
};
class RuntimeException : c {};
} // namespace uno
} // namespace star
} // namespace sun
} // namespace com
template  void d(int) { throw a::uno::RuntimeException(); }
int f;
void g() { d(f); }

$ cat 2.ii
namespace com {
namespace sun {
namespace star {
namespace uno {
class a {
public:
  ~a();
};
class b {
  a c;
};
class RuntimeException : b {};
} // namespace uno
class C : uno::RuntimeException {};
} // namespace star
} // namespace sun
} // namespace com
using com::sun::star::C;
using com::sun::star::uno::RuntimeException;
void d() { throw RuntimeException(); }
void e() { C(); }

$ g++ [12].ii -O -shared -fPIC -flto
1.ii:11:7: warning: type ‘struct b’ violates the C++ One Definition Rule
[-Wodr]
   11 | class b {
  |   ^
1.ii:11:7: note: a different type is defined in another translation unit
2.ii:10:5: note: the first difference of corresponding definitions is field ‘c’
   10 |   a c;
  | ^
1.ii:11:7: note: a type with different number of fields is defined in another
translation unit
   11 | class b {
  |   ^
1.ii:18:7: warning: type ‘struct RuntimeException’ violates the C++ One
Definition Rule [-Wodr]
   18 | class RuntimeException : c {};
  |   ^
1.ii:18:7: note: a type with different bases is defined in another translation
unit
during GIMPLE pass: optimized
2.ii: In function ‘e’:
2.ii:21:6: internal compiler error: tree check: expected block, have
function_decl in block_ultimate_origin, at tree.c:12326
   21 | void e() { C(); }
  |  ^
0x7d56a6 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9544
0x7dca31 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3118
0x7dca31 block_ultimate_origin(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:12324
0x184709b inlined_polymorphic_ctor_dtor_block_p(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/ipa-polymorphic-call.c:516
0x2a06f91 remove_unused_scope_block_p
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:420
0x2a074a5 remove_unused_scope_block_p
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:516
0x2a074a5 remove_unused_scope_block_p
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:516
0x2a0f17e remove_unused_locals()
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:896
0x1e65964 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1920
0x1e6709e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:1996

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-6
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug d/87866] gdc fails to compile minimal test

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Iain Buclaw  ---
> I backported a fix from the D sources so it should no longer segfault at 
> least.

It doesn't indeed.

> From what I can see, it should pick up the object.d source correctly.
>
> -nostdinc -I /vol/gcc/src/hg/trunk/local/libphobos/libdruntime 
>
> Unless it really isn't in the -I path.

I've found what's going on:

When d-incpath.dd (add_globalpaths) calls into Filename::canonicalName
(path), path is set correctly to the d21 -I arg:

81const char *target = FileName::canonicalName (path);
(gdb) p path
$7 = 0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime"

(gdb) s
0x0833cea6 in FileName::canonicalName (
name=0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime")
at /vol/gcc/src/hg/trunk/local/gcc/d/dmd/root/filename.c:616
616 return realpath(name, NULL);
(gdb) n
83if (target == NULL || !FileName::exists (target))
(gdb) p target
$8 = 0x0

However, canonicalPath returns with NULL.  I traced this to realpath(3C)
on Solaris 10 behaving differently, as explained in the man page:

 bolic  links.  The  generated  pathname is stored as a null-
 terminated string, up  to  a  maximum  of  {PATH_MAX}  bytes
 (defined  in  limits.h(3HEAD)),  in the buffer pointed to by
 resolved_name.

RETURN VALUES
 On successful completion, realpath() returns  a  pointer  to
 the  resolved  name.   Otherwise,  realpath() returns a null
 pointer and sets errno to indicate the error, and  the  con-
 tents  of the buffer pointed to by resolved_name are left in
 an indeterminate state.

Unlike e.g. the Solaris 11.4 version, realpath doesn't allocate a buffer
on it's own if the second arg is NULL, but given that it couldn't store
the real path, returned NULL to indicate that failure.

Rainer

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[iii at linux dot ibm.com]

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

--- Comment #1 from Ilya Leoshkevich  ---
Bisect points to r265398: combine: Do not combine moves from hard
registers.

I wonder what would be the best place to fix this?  I was thinking about
making shrink-wrapping try harder by not limiting the processing to the
first basic block.