[Bug c++/84453] New: [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[marxin at gcc dot gnu.org]

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

Bug ID: 84453
   Summary: [8 Regression] ICE in
build_type_attribute_qual_variant, at attribs.c:1166
   Product: gcc
   Version: unknown
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
  Target Milestone: ---

I see it on ppc64le cross compiler:

$ ppc64le-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/ref-qual14.C -c
-mlongcall
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/ref-qual14.C:9:44:
internal compiler error: in build_type_attribute_qual_variant, at
attribs.c:1166
 struct target_class
^
0x838d35 build_type_attribute_qual_variant(tree_node*, tree_node*, int)
.././../gcc/attribs.c:1166
0x7f55ed cp_build_type_attribute_variant(tree_node*, tree_node*)
.././../gcc/cp/tree.c:4628
0x803e29 strip_typedefs(tree_node*, bool*)
.././../gcc/cp/tree.c:1620
0x8042e0 strip_typedefs(tree_node*, bool*)
.././../gcc/cp/tree.c:1406
0x8044fd strip_typedefs(tree_node*, bool*)
.././../gcc/cp/tree.c:1421
0x7486ec canonicalize_type_argument
.././../gcc/cp/pt.c:7515
0x796383 coerce_template_parms
.././../gcc/cp/pt.c:8324
0x78b92a lookup_template_class_1
.././../gcc/cp/pt.c:8860
0x78b92a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
.././../gcc/cp/pt.c:9209
0x7d01ad finish_template_type(tree_node*, tree_node*, int)
.././../gcc/cp/semantics.c:3183
0x71fb74 cp_parser_template_id
.././../gcc/cp/parser.c:15824
0x71fd9f cp_parser_class_name
.././../gcc/cp/parser.c:22344
0x72dffe cp_parser_qualifying_entity
.././../gcc/cp/parser.c:6574
0x72dffe cp_parser_nested_name_specifier_opt
.././../gcc/cp/parser.c:6260
0x727cd5 cp_parser_class_head
.././../gcc/cp/parser.c:22832
0x727cd5 cp_parser_class_specifier_1
.././../gcc/cp/parser.c:22428
0x729ab1 cp_parser_class_specifier
.././../gcc/cp/parser.c:22742
0x729ab1 cp_parser_type_specifier
.././../gcc/cp/parser.c:16748
0x737c86 cp_parser_decl_specifier_seq
.././../gcc/cp/parser.c:13606
0x73cf25 cp_parser_single_declaration
.././../gcc/cp/parser.c:27054
Please submit a full bug report,

And I also see it on x86_64-linux-gnu, but I'll need some time to reduce a
test-case.

[Bug c++/84454] New: [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882

[marxin at gcc dot gnu.org]

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

Bug ID: 84454
   Summary: [8 Regression] ICE in invalid_nonstatic_memfn_p at
gcc/cp/typeck.c:1882
   Product: gcc
   Version: unknown
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: ---

Starting from r247842 we ICE on:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/pr67238.C 
-Wpacked -fpack-struct
‘
Segmentation fault
   return g([]{}, a...);
  ~^~~~
0xdcd60f crash_signal
../../gcc/toplev.c:325
0x850049 invalid_nonstatic_memfn_p(unsigned int, tree_node*, int)
../../gcc/cp/typeck.c:1882
0x82022e finish_decltype_type(tree_node*, bool, int)
../../gcc/cp/semantics.c:8724
0x7cbbe6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14439
0x6e3e3e dump_template_bindings
../../gcc/cp/error.c:397
0x6e3e3e dump_substitution
../../gcc/cp/error.c:1525
0x6e4a33 dump_substitution
../../gcc/cp/error.c:1673
0x6e4a33 dump_function_decl
../../gcc/cp/error.c:1681
0x6f12af decl_to_string
../../gcc/cp/error.c:3055
0x6f12af cp_printer
../../gcc/cp/error.c:4072
0x16fb9ea pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1375
0x16fc090 pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1437
0x16fc164 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/pretty-print.c:1641
0x6e2445 print_instantiation_full_context
../../gcc/cp/error.c:3458
0x6ee025 maybe_print_instantiation_context
../../gcc/cp/error.c:3606
0x6ee025 cp_diagnostic_starter
../../gcc/cp/error.c:3299
0x16eb8fa diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:985
0x16ebcbe diagnostic_impl
../../gcc/diagnostic.c:1108
0x16ebfec warning(int, char const*, ...)
../../gcc/diagnostic.c:1199
0xdbf480 finalize_record_size
../../gcc/stor-layout.c:1742

[Bug c++/84455] New: [8 Regression] ICE in build_call_a at gcc/cp/call.c:389 during error reporting

[marxin at gcc dot gnu.org]

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

Bug ID: 84455
   Summary: [8 Regression] ICE in build_call_a at
gcc/cp/call.c:389 during error reporting
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-invalid-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: ---

Starting from r251433 we ICE on:

$ g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice14.C 
--param ggc-min-heapsize=0
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice14.C:32:8:
internal compiler error: Segmentation fault
 B a;
^
0xdcd60f crash_signal
../../gcc/toplev.c:325
0x60cf31 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3245
0x60cf31 build_call_a(tree_node*, int, tree_node**)
../../gcc/cp/call.c:389
0x60f4b8 build_cxx_call(tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8654
0x614994 build_over_call
../../gcc/cp/call.c:8237
0x617e68 build_new_method_call_1
../../gcc/cp/call.c:9277
0x617e68 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:9346
0x619250 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.c:8880
0x6fda97 expand_default_init
../../gcc/cp/init.c:1889
0x6fda97 expand_aggr_init_1
../../gcc/cp/init.c:2004
0x6fe668 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.c:1744
0x69cfff build_aggr_init_full_exprs
../../gcc/cp/decl.c:6182
0x69cfff check_initializer
../../gcc/cp/decl.c:6331
0x6c58bc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7032
0x77cbb3 cp_parser_init_declarator
../../gcc/cp/parser.c:19697
0x78541c cp_parser_simple_declaration
../../gcc/cp/parser.c:13038
0x786368 cp_parser_block_declaration
../../gcc/cp/parser.c:12863
0x78b084 cp_parser_declaration
../../gcc/cp/parser.c:12761
0x78b4cb cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12637
0x78b7d0 cp_parser_translation_unit
../../gcc/cp/parser.c:4559

[Bug c++/84348] [7/8 Regression] ICE with invalid friend declaration

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Feb 19 08:49:30 2018
New Revision: 257802

URL: https://gcc.gnu.org/viewcvs?rev=257802&root=gcc&view=rev
Log:
/cp
2018-02-19  Paolo Carlini  

PR c++/84348
* decl.c (grokdeclarator): Early return error_mark_node upon
ill-formed friend declaration.

/testsuite
2018-02-19  Paolo Carlini  

PR c++/84348
* g++.dg/cpp0x/auto50.C: New.
* g++.dg/parse/friend12.C: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/auto50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/friend12.C

[Bug c++/79064] Cannot overload member function templates on type of literal

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
Also seen on arm* targets:
/gcc/testsuite/g++.dg/template/overload15.C:14:10: error: call of overloaded
'f<0>(char (*)[1])' is ambiguous
/gcc/testsuite/g++.dg/template/overload15.C:15:10: error: no matching function
for call to 'f<0>(char (*)[7])'


Unlike you, I do see the new test pass on aarch64, except if I also use
-mabi=ilp32. Is your aarch64-suse-linux-gnu configured with ilp32 by default?

[Bug c/84431] Suboptimal code for masked shifts (x86/x86-64)

[sebastian.peryt at intel dot com]

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

Sebastian Peryt  changed:

   What|Removed |Added

 CC||sebastian.peryt at intel dot 
com

--- Comment #1 from Sebastian Peryt  ---
Ruslan, can you provide which compilation options you have used to reproduce
this issue?

[Bug sanitizer/83392] FAIL: c-c++-common/ubsan/ptr-overflow-sanitization-1.c scan-tree-dump-times

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Ok so with -O the difference is in between x86_64 and i586:

i586:
Visiting statement:
p_3 = &b + 2147483649;
which is likely CONSTANT
Lattice value changed to CONSTANT &MEM[(void *)&b + 2147483649B].  Adding SSA
edges to worklist.
marking stmt to be not simulated again

x86_64:
Visiting statement:
p_3 = &b + 9223372036854775809;
which is likely CONSTANT
Lattice value changed to CONSTANT &MEM[(void *)&b + -9223372036854775807B]. 
Adding SSA edges to worklist.
marking stmt to be not simulated again

It's for reduced test-case:

#define SMAX   __PTRDIFF_MAX__

void foo(void)
{
  char *p;
  char *p2;
  char b[1];
  char c[1];

  p = b + SMAX; /* pointer overflow check is needed */
  p = b;

  p = b - SMAX; /* pointer overflow check is needed */
  p2 = p + SMAX; /* b: pointer overflow check is needed */
}

Hope it's correct, thus I'll disable cycling of optimizations.
Jakub?

[Bug c++/84348] [7 Regression] ICE with invalid friend declaration

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |invalid friend declaration  |invalid friend declaration

--- Comment #4 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-19
 Ever confirmed|0   |1

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

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-19
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
I guess it's build with:
python setup.py install

Please tell me how to use virtualenv to test it locally? Thank you.

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
On x86_64-linux-gnu:

$ cat /tmp/ice.ii
struct a {
  void b(long() __attribute__((fastcall))) {}
};

$ g++ ice.ii -m32 -c --param ggc-min-expand=0 --param ggc-min-heapsize=0
ice.ii:2:8: internal compiler error: in build_type_attribute_qual_variant, at
attribs.c:1166
   void b(long() __attribute__((fastcall))) {}
^
0x8800a5 build_type_attribute_qual_variant(tree_node*, tree_node*, int)
../../gcc/attribs.c:1166
0x83c94d cp_build_type_attribute_variant(tree_node*, tree_node*)
../../gcc/cp/tree.c:4628
0x718c28 write_type
../../gcc/cp/mangle.c:2118
0x717b46 write_type
../../gcc/cp/mangle.c:2303
0x71a564 write_method_parms
../../gcc/cp/mangle.c:2796
0x71a846 write_bare_function_type
../../gcc/cp/mangle.c:2732
0x72238c mangle_decl_string
../../gcc/cp/mangle.c:3792
0x7226f3 get_mangled_id
../../gcc/cp/mangle.c:3814
0x7226f3 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3852
0x10992f2 decl_assembler_name(tree_node*)
../../gcc/tree.c:687
0x99791f symtab_node::get_comdat_group_id()
../../gcc/cgraph.h:215
0x99791f analyze_functions
../../gcc/cgraphunit.c:1081
0x999282 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2691

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug c++/84430] [7/8 Regression] ICE with #pragma omp simd in lambda

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-19
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r239268.

[Bug debug/84457] New: [8 regression] gcc.dg/guality/pr49888.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 84457
   Summary: [8 regression] gcc.dg/guality/pr49888.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r257631 triggers this:

spawn gdb -nx -nw -quiet -batch -x pr49888.gdb ./pr49888.exe
FAIL: gcc.dg/guality/pr49888.c   -O1  line 18 !c == 1

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont
--with-cpu=silvermont

[Bug debug/84458] New: [8 regression] gcc.dg/guality/pr49888.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 84458
   Summary: [8 regression] gcc.dg/guality/pr49888.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r257631 triggers this:

spawn gdb -nx -nw -quiet -batch -x pr49888.gdb ./pr49888.exe
FAIL: gcc.dg/guality/pr49888.c   -O1  line 18 !c == 1

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont
--with-cpu=silvermont

[Bug debug/84459] New: [8 regression] gcc.dg/guality/pr49888.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 84459
   Summary: [8 regression] gcc.dg/guality/pr49888.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r257631 triggers this:

spawn gdb -nx -nw -quiet -batch -x pr49888.gdb ./pr49888.exe
FAIL: gcc.dg/guality/pr49888.c   -O1  line 18 !c == 1

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont
--with-cpu=silvermont

[Bug c++/84455] [8 Regression] ICE in build_call_a at gcc/cp/call.c:389 during error reporting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-19
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
> 
> tfft of polyhedron is aslso still regressing. Martin, perhaps you can bisect
> that one as it seems most consistent?
> 

Can't see any difference for both tfft and tfft2 benchmarks on my Haswell
machine. Can you reproduce that locally?

[Bug debug/84458] [8 regression] gcc.dg/guality/pr49888.c fail

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
dup

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

[Bug debug/84457] [8 regression] gcc.dg/guality/pr49888.c fail

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

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

--- Comment #1 from Andreas Schwab  ---
*** Bug 84458 has been marked as a duplicate of this bug. ***

[Bug debug/84459] [8 regression] gcc.dg/guality/pr49888.c fail

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
dup

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

[Bug debug/84457] [8 regression] gcc.dg/guality/pr49888.c fail

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

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

--- Comment #2 from Andreas Schwab  ---
*** Bug 84459 has been marked as a duplicate of this bug. ***

[Bug other/80589] Typing mistakes in two messages

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail|8.0 |

--- Comment #11 from Martin Liška  ---
Now should be fixed on trunk.

[Bug other/80589] Typing mistakes in two messages

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Mon Feb 19 09:54:09 2018
New Revision: 257803

URL: https://gcc.gnu.org/viewcvs?rev=257803&root=gcc&view=rev
Log:
Fix documentation typos (PR other/80589).

2018-02-19  Martin Liska  

PR other/80589
* doc/invoke.texi: Fix typo.
* params.def (PARAM_MAX_LOOP_HEADER_INSNS): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/params.def

[Bug c++/84455] [8 Regression] ICE in build_call_a at gcc/cp/call.c:389 during error reporting

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43453&action=edit
gcc8-pr84455.patch

Untested fix.  This mirrors what cp_parser_lambda_body does.

[Bug debug/84457] [8 regression] gcc.dg/guality/pr49888.c fail

[andrey.y.guskov at intel dot com]

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

--- Comment #3 from Andrey Guskov  ---
Whoops. Sorry. Kept getting an HTTP 504 from post_bug.cgi.

[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-19
 CC||jakub at gcc dot gnu.org
Version|unknown |8.0
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/67420] gfortran.dg/norm2_3.f90 FAILs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|SUSPENDED   |WAITING

--- Comment #5 from Dominique d'Humieres  ---
> Given the location of the failure, this is probably a duplicate of PR67420,
> because we use the built-in sqrtl() in NORM2. Marked as SUSPENDED for now.

Self-referencing duplicate!

Looking at the results posted at
https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00014.html this PR seems
fixed since more than a year.

[Bug tree-optimization/84452] [8 Regression] ICE in expand_simd_clones at gcc/omp-simd-clone.c:1612

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
Version|unknown |8.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Yes, introduced with r257617, will fix.

[Bug tree-optimization/84452] [8 Regression] ICE in expand_simd_clones at gcc/omp-simd-clone.c:1612

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #10 from Wilco  ---
The only solution to this is to make a hard choice between Neon and integer
registers before register allocation.

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
>From my completely ARM unaware POV, if NEON is available, it isn't a strict
requirement that NEON must never be used for this, just a matter of
preferences.  So perhaps one or two further ?s on the avoid_neon_for_64bits
alternatives to let the RA know it should prefer the GPR alternative which
already contains a single ? and therefore right now is equal preference to the
avoid_neon_for_64bits.

[Bug target/84460] New: [8 regression] gcc.target/i386/pr57193.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 84460
   Summary: [8 regression] gcc.target/i386/pr57193.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r257669 triggers this:

spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.target/i386/pr57193.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -msse2 -mno-sse3 -ffat-lto-objects -S -o
pr57193.s
PASS: gcc.target/i386/pr57193.c (test for excess errors)
FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2 (found 3 times)

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont
--with-cpu=silvermont

[Bug target/82862] [8 Regression] SPEC CPU2006 465.tonto performance regression with r253975 (up to 40% drop for particular loop)

[alexander.nesterovskiy at intel dot com]

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

--- Comment #8 from Alexander Nesterovskiy  ---
I'd say that it's not just fixed but improved with an impressive gain.

It is about +4% on HSW AVX2 and about +8% on SKX AVX512 after r257734 (compared
to r257732) for a 465.tonto SPEC rate.
Comparing to reference r253973 it is about +2% on HSW AVX2 and +18% on SKX
AVX512 (AVX512 was greatly improved in last 3 months).

[Bug c++/84461] New: [8 regression] openjdk-10 fails to build

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

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

Bug ID: 84461
   Summary: [8 regression] openjdk-10 fails to build
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---

In file included from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp:31,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/gc/shared/genCollectedHeap.hpp:28,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/gc/shared/gcLocker.hpp:29,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/runtime/interfaceSupport.hpp:28,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/prims/methodHandles.hpp:32,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/ci/ciMethod.hpp:33,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/code/debugInfoRec.hpp:30,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/ci/ciEnv.hpp:31,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/ci/ciUtilities.hpp:28,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/ci/ciNullObject.hpp:30,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/ci/ciConstant.hpp:29,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/ci/ciArray.hpp:29,
 from
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/precompiled/precompiled.hpp:35:
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/memory/metaspaceShared.cpp:
In instantiation of 'static intptr_t* CppVtableCloner::clone_vtable(const
char*, CppVtableInfo*) [with T = ConstantPool; intptr_t = long int]':
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/memory/metaspaceShared.cpp:693:3:
  required from here
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/logging/log.hpp:50:115:
error: no match for 'operator<' (operand types are '' and 'LogLevel::type')
 #define log_debug(...)   (!log_is_enabled(Debug, __VA_ARGS__))   ? (void)0 :
LogImpl::write
 
~^
/home/abuild/rpmbuild/BUILD/jdk10-107413b070b9/src/hotspot/share/memory/metaspaceShared.cpp:625:3:
note: in expansion of macro 'log_debug'
   log_debug(cds, vtables)("Copying %3d vtable entries for %s", n, name);
   ^

[Bug tree-optimization/82491] UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Thanks Richard!

Now I still see the other issue in dwarf2out:

Breakpoint 1, based_loc_descr (reg=0x751183a8, offset=...,
initialized=VAR_INIT_STATUS_INITIALIZED) at ../../gcc/dwarf2out.c:14170
warning: Source file is more recent than executable.
14170 elim = strip_offset_and_add (elim, &offset);
(gdb) c
Continuing.
../../gcc/poly-int.h:414:21: runtime error: signed integer overflow:
9223372036854775789 + 48 cannot be represented in type 'long int'
#0 0xaa9c75 in poly_int_pod<1u, long>& poly_int_pod<1u,
long>::operator+=(poly_int_pod<1u, long> const&) ../../gcc/poly-int.h:414
#1 0xaa9266 in strip_offset_and_add(rtx_def*, poly_int_pod<1u, long>*)
../../gcc/rtl.h:4340
#2 0xd4f022 in based_loc_descr ../../gcc/dwarf2out.c:14170
#3 0xd5da4c in mem_loc_descriptor(rtx_def*, machine_mode, machine_mode,
var_init_status) ../../gcc/dwarf2out.c:15643
#4 0xd65a2a in loc_descriptor ../../gcc/dwarf2out.c:16616
...

(gdb) p debug_rtx(elim)
(plus:DI (reg/f:DI 7 sp)
(const_int 48 [0x30]))
$2 = void
(gdb) p offset
$3 = {> = {coeffs = {9223372036854775789}}, }

Is it Jakub something we should handle? Do you have a suggestion how to do
that?

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
(In reply to Jakub Jelinek from comment #11)
> From my completely ARM unaware POV, if NEON is available, it isn't a strict
> requirement that NEON must never be used for this, just a matter of
> preferences.  So perhaps one or two further ?s on the avoid_neon_for_64bits
> alternatives to let the RA know it should prefer the GPR alternative which
> already contains a single ? and therefore right now is equal preference to
> the avoid_neon_for_64bits.

The costing model for preferencing is extremely complex and suboptimal. There
are too many bugs in it, it all appears to be written for a CISC ISA (eg. it
assumes it can just replace any register operand with a MEM at no extra cost,
even if such a pattern doesn't exist).

So hacking in some more ?'s is never going to result in good code. The issue is
also made more complex by the fact that expanding 64-bit operations after
register allocation is an extremely bad idea - see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308.

So today the choice is between generating inefficient ARM code or inefficient
Neon code... 

By making this a hard choice early on (only generate ARM, or use Neon when
beneficial) we can actually generate high quality code. I've got patches that
give huge gains and still allow a user to prefer Neon instructions with
-mneon-for-64bits.

[Bug target/84460] [8 regression] gcc.target/i386/pr57193.c fail

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
-mtune=generic will solve this.

[Bug target/84460] [8 regression] gcc.target/i386/pr57193.c fail

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
On Mon, Feb 19, 2018 at 11:30 AM, andrey.y.guskov at intel dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84460
>
> Andrey Guskov  changed:
>
>What|Removed |Added
> 
>  Target||x86_64-*-*
>  CC||uros at gcc dot gnu.org
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Martin Liška  ---
It's an invalid code:

$ gcc pr84433.c -Wall -fsanitize=undefined -g &&
UBSAN_OPTIONS="print_stacktrace=1" ./a.out 
pr84433.c: In function ‘func’:
pr84433.c:45:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^
pr84433.c:36:11: runtime error: index 15 out of bounds for type 'structA [15]'
#0 0x400d5a in func /home/marxin/Programming/testcases/pr84433.c:36
#1 0x400edb in main /home/marxin/Programming/testcases/pr84433.c:62
#2 0x76d20f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#3 0x400729 in _start (/home/marxin/Programming/testcases/a.out+0x400729)

B.int1 = 16 expected 16

$ clang pr84433.c -Wall -fsanitize=undefined -g &&
UBSAN_OPTIONS="print_stacktrace=1" ./a.out 
pr84433.c:45:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
1 warning generated.
pr84433.c:36:3: runtime error: index 15 out of bounds for type 'struct structA
[15]'
#0 0x42019a in func /home/marxin/Programming/testcases/pr84433.c:36:24
#1 0x420753 in main /home/marxin/Programming/testcases/pr84433.c:62:3
#2 0x76eb1f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#3 0x402829 in _start
/home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120

B.int1 = 16 expected 16

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #1 from Martin Liška  ---
Confirmed. Note that in GCC 8 we generate a better code:

g++ pr84436.C -O2 -c -S -o/dev/stdout

_Z3foo1E:
.LFB0:
movl%edi, %edi
movlCSWTCH.0(,%rdi,4), %eax
ret
.LFE0:
.size   _Z3foo1E, .-_Z3foo1E
.section.rodata
.align 8
.type   CSWTCH.0, @object
.size   CSWTCH.0, 12
CSWTCH.0:
.long   0
.long   1
.long   2

It's clear that it's optimization opportunity. My question is why you don't
simple do:

   enum class E
{
A = 0, B, C,
};

int foo(E e)
{
  return (int)e;
}

? Is it reduced from a bigger code base?

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

[matthijsvanduin at gmail dot com]

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

--- Comment #13 from Matthijs van Duin  ---
In case it's of interest, I did a quick benchmark of my testcase executed in a
loop on a cortex-a8:

Without neon:
12 instructions/iteration
14 cycles/iteration

With neon:
14 instructions/iteration
35.2-35.3 cycles/iteration

(This includes 4 instructions for the loop itself.)

When using neon, the majority of the time is spent in a nasty pipeline stall
for moving data from neon registers to arm registers, which takes a minimum of
20 cycles according to the cortex-a8 TRM.

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

[wilco at gcc dot gnu.org]

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

--- Comment #14 from Wilco  ---
(In reply to Matthijs van Duin from comment #13)
> In case it's of interest, I did a quick benchmark of my testcase executed in
> a loop on a cortex-a8:
> 
> Without neon:
> 12 instructions/iteration
> 14 cycles/iteration
> 
> With neon:
> 14 instructions/iteration
> 35.2-35.3 cycles/iteration
> 
> (This includes 4 instructions for the loop itself.)
> 
> When using neon, the majority of the time is spent in a nasty pipeline stall
> for moving data from neon registers to arm registers, which takes a minimum
> of 20 cycles according to the cortex-a8 TRM.

Yes on older cores it can be a bad idea to allow accidental use of Neon
instructions. The simplest workaround is to switch off Neon, just use
-mfpu=vfp.

We probably also need to block the register allocator from spilling integer
registers to the FP register file as that would have the same stall (another
thing it really seems to insist on for some odd reason). There are AArch64
patches for this that could be ported to Arm.

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

[mferoldif at gmail dot com]

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

--- Comment #2 from Mário Feroldi  ---
That code (which is just a simplified example) is generated by macros.

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

[matthijsvanduin at gmail dot com]

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

--- Comment #15 from Matthijs van Duin  ---
(In reply to Wilco from comment #14)
> Yes on older cores it can be a bad idea to allow accidental use of Neon
> instructions. The simplest workaround is to switch off Neon, just use
> -mfpu=vfp.

Sure, though that's not exactly ideal since it is very desirable for the Neon
unit to be used for single-precision floats. (9-10 cycles for add/sub in VFP,
10-12 cycles for mul in VFP, 1 cycle for two add/sub/mul ops in Neon)

[Bug c++/84449] [7/8 Regression] ICE with constexpr and deleted destructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/84429] [8 Regression] ICE capturing variable-sized array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

[wilco at gcc dot gnu.org]

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

--- Comment #16 from Wilco  ---
(In reply to Matthijs van Duin from comment #15)
> (In reply to Wilco from comment #14)
> > Yes on older cores it can be a bad idea to allow accidental use of Neon
> > instructions. The simplest workaround is to switch off Neon, just use
> > -mfpu=vfp.
> 
> Sure, though that's not exactly ideal since it is very desirable for the
> Neon unit to be used for single-precision floats. (9-10 cycles for add/sub
> in VFP, 10-12 cycles for mul in VFP, 1 cycle for two add/sub/mul ops in Neon)

That's why it's a workaround until the bug is fixed - assuming the performance
critical functions use both 64-bit integer and 32-bit fp operations, you could
benchmark both options and choose the one that works best for now.

[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug fortran/79854] diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   Severity|normal  |trivial

--- Comment #2 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #1)
> AFAICT this internal error has never triggered. If someone can come with a
> test for it, this would be nice.

In the meantime, though, I think it'd make sense just to change it to an
internal error anyways (even without a testcase), for translation purposes

[Bug tree-optimization/84419] [8 Regression] SPEC CPU2017/CPU2006 521/621, 527/627, 554/654, 445, 454, 481, 416 runfails after r256628 with march=skylake-avx512

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Created attachment 43456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43456&action=edit
Possible patch

I think the problem was that the optimisation was dropping
the alignment information, so we ended up using an aligned
rather than an unaligned access.

I don't have access to skylake hardware, but could you
try the attached patch?

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
The problem seems to be the simplifcation which gets the
string length wrong.

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug c++/84446] [8 Regression] ICE with broken lambda

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/84446] [8 Regression] ICE with broken lambda

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.0

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Target Milestone|--- |9.0
   Severity|normal  |enhancement

--- Comment #3 from Martin Liška  ---
Good, it still makes sense to do a optimization where a part of switch
statements are mapped by such identity function. Let me do it in GCC 9. I'm
planning to do more switch reorganization.

[Bug gcov-profile/83877] Make gcov accept a path to the gcda and a path to the gcno file

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
   Severity|normal  |enhancement

[Bug sanitizer/82183] gcc.dg/sancov/cmp0.c fails on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
  Known to fail||8.0

[Bug tree-optimization/82491] UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c/81272] libdecnumber/decNumber.c:6032: wrong condition ?

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Note that this is good for identity, but we could also turn a map 0->3, 1->4,
5->8 into x->x+3, or generally any map (with an unreachable default case) into
a polynomial (or some other simple function), the cost of which might be higher
or lower than the jump table. It probably isn't worth going too far in that
direction though.

[Bug c++/84462] New: internal compiler error: in output_constructor_regular_field when creating array of structs (with testcase)

[christianlupus at web dot de]

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

Bug ID: 84462
   Summary: internal compiler error: in
output_constructor_regular_field when creating array
of structs (with testcase)
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christianlupus at web dot de
  Target Milestone: ---
  Host: avr

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

To trigger the problem one needs to invocate
# avr-g++ -O0 -v -save-temps -c bug.cpp -o bug.o
on the given input file. This results in the following output:

Reading specs from /usr/lib/gcc/avr/7.3.0/device-specs/specs-avr2
COLLECT_GCC=avr-g++
Target: avr
Configured with: /build/avr-gcc/src/gcc-7-20180125/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
gcc version 7.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-O0' '-v' '-save-temps' '-c' '-o' 'bug.o'
'-specs=device-specs/specs-avr2'
/usr/lib/gcc/avr/7.3.0/cc1plus -E -quiet -v bug.cpp -mn-flash=6 -mskip-bug
-O0 -fpch-preprocess -mn-flash=6 -mskip-bug -fno-rtti -fno-enforce-eh-specs
-fno-exceptions -o bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/avr/7.3.0/../../../../avr/include/c++/7.3.0"
ignoring nonexistent directory
"/usr/lib/gcc/avr/7.3.0/../../../../avr/include/c++/7.3.0/avr"
ignoring nonexistent directory
"/usr/lib/gcc/avr/7.3.0/../../../../avr/include/c++/7.3.0/backward"
ignoring nonexistent directory
"/usr/lib/gcc/avr/7.3.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/avr/7.3.0/include
/usr/lib/gcc/avr/7.3.0/include-fixed
/usr/lib/gcc/avr/7.3.0/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-O0' '-v' '-save-temps' '-c' '-o' 'bug.o'
'-specs=device-specs/specs-avr2'
/usr/lib/gcc/avr/7.3.0/cc1plus -fpreprocessed bug.ii -mn-flash=6 -mskip-bug
-quiet -dumpbase bug.cpp -auxbase-strip bug.o -O0 -version -mn-flash=6
-mskip-bug -fno-rtti -fno-enforce-eh-specs -fno-exceptions -o bug.s
GNU C++14 (GCC) version 7.3.0 (avr)
compiled by GNU C version 7.2.1 20180116, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP

warning: MPFR header version 4.0.0 differs from library version 4.0.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.3.0 (avr)
compiled by GNU C version 7.2.1 20180116, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP

warning: MPFR header version 4.0.0 differs from library version 4.0.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1d5b2c6ab68d14352ece4d9fac25dd7b
bug.cpp:33:1: internal compiler error: in output_constructor_regular_field,
at varasm.c:5031
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


When compiling for my amd64 machine the very same error happens, so it seems
not to be a problem of the avr target.
The gcc was installed as binary version from the Archlinux main repository for
amd64.

# avr-g++ -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/7.3.0/device-specs/specs-avr2
COLLECT_GCC=avr-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/7.3.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-7-20180125/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function

[Bug debug/63572] [6/7/8 Regression] ICF breaks user debugging experience

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|6.5 |---

[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
Closing.

[Bug ipa/80277] ipa-icf overlooking functions with identical assemble and semantics

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0

[Bug c++/84462] internal compiler error: in output_constructor_regular_field when creating array of structs (with testcase)

[christianlupus at web dot de]

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

--- Comment #1 from Christian Wolf  ---
Created attachment 43459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43459&action=edit
Output of g++ during run with save-temps

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Marc Glisse from comment #4)
> Note that this is good for identity, but we could also turn a map 0->3,
> 1->4, 5->8 into x->x+3, or generally any map (with an unreachable default
> case) into a polynomial (or some other simple function), the cost of which
> might be higher or lower than the jump table. It probably isn't worth going
> too far in that direction though.

Sure, it's also described here:
https://docs.google.com/viewer?url=https%3A%2F%2Fpdfs.semanticscholar.org%2F9269%2F51f0f3e5d67d8ea2bf7b7bca4c5e7de3dafc.pdf%23page%3D103

It's a bit different as it handles situations like

switch (x)
case 16:
case 32:
...

where one should perform operation to index to have a consecutive jump table.
But it touches similar.

[Bug middle-end/59521] __builtin_expect not effective in switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
   Severity|normal  |enhancement

[Bug target/79747] Missing documentation for -malign-{jumps,label,loops,functions}= and strange value range limitation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/82405] Function not inlined for switch and suboptimal assembly is generated

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug libstdc++/84367] [C++11] std::ostringstream stops inserting after multiple call to move assignment operator

[ftingaud at gmail dot com]

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

Frederic Tingaud  changed:

   What|Removed |Added

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

--- Comment #3 from Frederic Tingaud  ---
Reopening because I reproduced with GCC 7.3. See previous comment for test
case.

[Bug fortran/48890] [F95] Wrong length of a character component of named constant derived-type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Blocks||83497

--- Comment #6 from Thomas Koenig  ---
Looks like the root cause of PR 83497.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497
[Bug 83497] [8 Regression] CPU2000 172.mgrid starts failing with r254730

[Bug c++/84445] [7/8 Regression] ICE with __builtin_launder and virtual function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/48890] [F95] Wrong length of a character component of named constant derived-type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Blocks|83497   |83823

--- Comment #7 from Thomas Koenig  ---
Of course, I meant 83823.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497
[Bug 83497] [8 Regression] CPU2000 172.mgrid starts failing with r254730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83823
[Bug 83823] [8 Regression] Character length issues with PACK()

[Bug target/45996] -falign-functions=X does not work

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-19
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
Andrew should we document that or should I just close it as invalid. What do
you think?

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[nsz at gcc dot gnu.org]

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

--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #3)
> I can't reproduce on gcc116.fsffrance.org.  The assembler completes in less
> than a second for both -gno-inline-points and without.
> 
> aldyh@gcc116:~/bld/t/gcc$ ./xg++ -B. -g -O -fPIC -shared -fno-rtti -time
> poly-int-07_plugin.ii
> # cc1plus 107.13 0.29
> # as 0.93 0.06
> 

are you sure your gas has .loc view support? (gcc config disables it if there
is no support)

with same preprocessed source i get

# cc1plus 166.26 0.72
# as 89.16 0.24
# collect2 0.19 0.05

i'm not sure why cc1plus time got much slower compared to my earlier runs.
the asm is about 31MB and 1.9M lines, i don't think gas can process it in < 1s.

[Bug c++/84435] -Wliteral-suffix warns on a using-directive

[mferoldif at gmail dot com]

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

--- Comment #1 from Mário Feroldi  ---
Note that the following `foo`'s variant doesn't make the warning go away:

int foo(E e)
{
(e == E::A || e == E::B || e == E::C) ? void() :
__builtin_unreachable();
switch (e)
{
case E::A: return 0;
case E::B: return 1;
case E::C: return 2;
}
}

[Bug c++/84445] [7/8 Regression] ICE with __builtin_launder and virtual function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.4

[Bug gcov-profile/45582] gcda file names collision when profiling

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84435] -Wliteral-suffix warns on a using-directive

[mferoldif at gmail dot com]

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

--- Comment #2 from Mário Feroldi  ---
I'm really sorry for the mess up (previous comment wasn't meant to be posted on
this issue); could someone delete it?

[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning and is ignored

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Chris Hall from comment #11)
> FWIW:  __attribute__((aligned(32))) works nicely for functions.

You are right, that works fine! It should be equal to use

#pragma GCC optimize "align-functions=128"

or the corresponding attribute.


> 
> Generally there is little to be gained from aligning all loops/jumps/labels
> in a given function or group of functions.
> 
> Further, when code alignment issues bite, there is no guarantee that the
> solution is to align all loops/jumps/labels in the same way.
> 
> So, it would be nice to be able to apply __attribute__((aligned(n))) to
> loops and/or labels... and perhaps to blocks.  That way, precise alignment
> could be applied precisely where it matters.
> 
> I have been doing some detailed timing of relatively small operations, which
> of course involves a loop to do the operation being timed many times.  If
> the timing loop is not 32-byte aligned, the timings I get are not stable.

Such fine grained control would be nice, but it's very problematic to track
such information from a front-end to back-end where the real alignment happens.

[Bug c++/84444] ICE with __builtin_launder and cast

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||nathan at acm dot org

--- Comment #2 from Paolo Carlini  ---
Let's add Nathan, then.

[Bug c++/84463] New: Supposedly-incompliant "error: '* key0' is not a constant expression"

[sergey.ignatchenko at ithare dot com]

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

Bug ID: 84463
   Summary: Supposedly-incompliant "error: '* key0' is not a
constant expression"
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergey.ignatchenko at ithare dot com
  Target Milestone: ---

== COMPILER ==

root@ubuntu-gcc7:~/ithare/kscope/test/nix# g++ --version
g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

== CODE 

#include 
#include 

struct chacha_tv {
const char *desc;
const uint8_t key[32];
const uint8_t iv[8];
const size_t len;
const unsigned char out[512];
};

static constexpr chacha_tv chacha_test_vectors[] = {
{
"TC1: All zero key and IV",
{
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
},
{
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
},
64,
{
0x76, 0xb8, 0xe0, 0xad, 0xa0, 0xf1, 0x3d, 0x90,
0x40, 0x5d, 0x6a, 0xe5, 0x53, 0x86, 0xbd, 0x28,
0xbd, 0xd2, 0x19, 0xb8, 0xa0, 0x8d, 0xed, 0x1a,
0xa8, 0x36, 0xef, 0xcc, 0x8b, 0x77, 0x0d, 0xc7,
0xda, 0x41, 0x59, 0x7c, 0x51, 0x57, 0x48, 0x8d,
0x77, 0x24, 0xe0, 0x3f, 0xb8, 0xd8, 0x4a, 0x37,
0x6a, 0x43, 0xb8, 0xf4, 0x15, 0x18, 0xa1, 0x1c,
0xc3, 0x87, 0xb6, 0x69, 0xb2, 0xee, 0x65, 0x86,
},
},
};

constexpr int
KSCOPE_CT_Chacha_set_key_iv2(const uint8_t* key0, int keybits /*128 or 256*/,
const uint8_t iv0[8], const uint8_t counter0[8]) {
uint8_t c = key0[0];
return 0;
}

constexpr static const chacha_tv* tv = &chacha_test_vectors[0];
constexpr static const int k = tv->key[0];
constexpr static uint8_t kk[3] = {0,1,2};
constexpr static int x0 =
KSCOPE_CT_Chacha_set_key_iv2(chacha_test_vectors[0].key,256,tv->iv,nullptr);//OK
constexpr static int x1 =
KSCOPE_CT_Chacha_set_key_iv2(kk,256,tv->iv,nullptr);//OK
constexpr static int x2 =
KSCOPE_CT_Chacha_set_key_iv2(tv->key,256,tv->iv,nullptr);

== PROBLEM 

When trying to compile the code above with GCC 7.2, the following error is
generated:
../chachatest.cpp:50:55:   in constexpr expansion of
'KSCOPE_CT_Chacha_set_key_i
v2(((const uint8_t*)(((const uint8_t (*)[32])tv) + 8)), 256, ((const
uint8_t*)((
(const uint8_t (*)[8])tv) + 40)), 0)'
../chachatest.cpp:41:27: error: '* key0' is not a constant expression
 uint8_t c = key0[0];

Expected behaviour is to acknowledge that key0 is an 'address constant
expression' in a sense of 5.19 (at least my humble reading of the standard says
that it is), and to allow the code to be compiled. Notes:
- note that both x0 and x1 compile ok
- both Clang and MSVC seem to agree it is an 'address constant expression' and
don't complain.

[Bug debug/68771] Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition

[zerolo at gmail dot com]

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

--- Comment #2 from Daniel Vollmer  ---
I'm having even more trouble to get this to work using a current gcc-7
(Homebrew GCC 7.3.0) 7.3.0.


First, I see some warnings in step 1) of the form

ld: warning: direct access in function
'__GLOBAL__sub_I_65535_0_Preprocessor.cpp.lto_priv.322' from file
'/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccm0fMqG.ltrans3.ltrans.o'
to global weak symbol
'__ZZN5Eigen8internal20manage_caching_sizesENS_6ActionEPlS2_E13m_l2CacheSize'
from file
'/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccm0fMqG.ltrans18.ltrans.o'
means the weak symbol cannot be overridden at runtime. This was likely caused
by different translation units being compiled with different visibility
settings.

even though visibility settings should be identical AFAICT.


The real blocker is exiting the binary (more accurately: Python extension) in
step 2) as it seems to hang (hanging for about 5mins now, for a profile run
that took 30secs) in

Call graph:
2508 Thread_3830138   DispatchQueue_1: com.apple.main-thread  (serial)
+ 2507 start  (in libdyld.dylib) + 8  [0x7fff772d111c]
+ ! 2507 exit  (in libsystem_c.dylib) + 55  [0x7fff7737e362]
+ !   2507 __cxa_finalize_ranges  (in libsystem_c.dylib) + 351 
[0x7fff7737e051]
+ ! 2507 dyld::runAllStaticTerminators(void*)  (in dyld) + 64 
[0x10d65a613]
+ !   2507 __gcov_exit  (in libFlucs.dylib) + 146  [0x110a54062] 
libgcov-driver.c:871
+ ! 919 gcov_do_dump  (in libFlucs.dylib) + 310,262,... 
[0x110a52c66,0x110a52c36,...]  libgcov-driver.c:171
+ ! 595 gcov_do_dump  (in libFlucs.dylib) + 277,391,... 
[0x110a52c45,0x110a52cb7,...]  libgcov-driver.c:167
+ ! 520 gcov_do_dump  (in libFlucs.dylib) + 274,322,... 
[0x110a52c42,0x110a52c72,...]  libgcov-driver.c:173
+ ! 205 gcov_do_dump  (in libFlucs.dylib) + 377,259,... 
[0x110a52ca9,0x110a52c33,...]  libgcov-driver.c:172
+ ! 96 gcov_do_dump  (in libFlucs.dylib) + 432,470,... 
[0x110a52ce0,0x110a52d06,...]  libgcov-driver.c:332
+ ! 66 gcov_do_dump  (in libFlucs.dylib) + 439,436 
[0x110a52ce7,0x110a52ce4]  libgcov-driver.c:334
+ ! 44 gcov_do_dump  (in libFlucs.dylib) + 493,227,... 
[0x110a52d1d,0x110a52c13,...]  libgcov-driver.c:316
+ ! 28 gcov_do_dump  (in libFlucs.dylib) + 442  [0x110a52cea] 
libgcov-driver.c:335
+ ! 13 gcov_do_dump  (in libFlucs.dylib) + 351,366 
[0x110a52c8f,0x110a52c9e]  libgcov-driver.c:329
+ ! 7 gcov_do_dump  (in libFlucs.dylib) + 293  [0x110a52c55] 
libgcov-driver.c:317
+ ! 5 gcov_do_dump  (in libFlucs.dylib) + 482,484 
[0x110a52d12,0x110a52d14]  libgcov-driver.c:309
+ ! 4 gcov_do_dump  (in libFlucs.dylib) + 77  [0x110a52b7d] 
libgcov-driver.c:302
+ ! : 4 strlen  (in libsystem_c.dylib) + 14  [0x7fff7732142e]
+ ! 3 gcov_do_dump  (in libFlucs.dylib) + 224  [0x110a52c10] 
libgcov-driver.c:311
+ ! 1 gcov_do_dump  (in libFlucs.dylib) + 234  [0x110a52c1a] 
libgcov-driver.c:313
+ ! 1 gcov_do_dump  (in libFlucs.dylib) + 345  [0x110a52c89] 
libgcov-driver.c:325

So unfortunately I cannot even get to step 3) to repo the hot / cold section
issue.

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[mferoldif at gmail dot com]

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

Mário Feroldi  changed:

   What|Removed |Added

 CC||mferoldif at gmail dot com

--- Comment #9 from Mário Feroldi  ---
Note that this version of `f1` doesn't prevent the warning. I wonder why?

  enum E { E1 };
  static inline int f1(enum E e) {
  (e == E1) ? void() : __builtin_unreachable(); // *
  switch (e) {
  case E1: return 1;
  }
  }
  int main () {
  f1(E1);
  return 0;
  }

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[acsawdey at gcc dot gnu.org]

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

--- Comment #5 from acsawdey at gcc dot gnu.org ---
Very interesting ... the return can be added and the problem still exists.
However changing the size of the array sA to be >= 16 makes the problem go
away. Why is that?

[Bug c++/84441] [6/7/8 Regression] Internal compiler error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
struct A;
struct B { using C = int *; template  using D = A; };
struct F : B { struct G { typedef D h; }; };
struct I {
  struct J { J (F::C, A &); F::C k; } l;
  F::G::h &foo ();
  I (I &&) : l (0, foo ()) {}
};
struct N { I o; int e; };
N bar ();
struct E : N { E () : N (0 ? bar () : bar ()) {} };

void
baz ()
{
  E ();
}

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to acsawdey from comment #5)
> Very interesting ... the return can be added and the problem still exists.
> However changing the size of the array sA to be >= 16 makes the problem go
> away. Why is that?

Because there are 2 undefined behaviors: the missing return and access to array
which is out of bounds.

[Bug debug/84457] [8 regression] gcc.dg/guality/pr49888.c fail

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #4 from Volker Reichelt  ---
Hopefully this was the last duplicate ;-)

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

[Bug debug/84456] New: [8 regression] gcc.dg/guality/pr49888.c fail

[reichelt at gcc dot gnu.org]

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

Bug ID: 84456
   Summary: [8 regression] gcc.dg/guality/pr49888.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r257631 triggers this:

spawn gdb -nx -nw -quiet -batch -x pr49888.gdb ./pr49888.exe
FAIL: gcc.dg/guality/pr49888.c   -O1  line 18 !c == 1

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont
--with-cpu=silvermont

--- Comment #1 from Volker Reichelt  ---
*** Bug 84457 has been marked as a duplicate of this bug. ***

[Bug c++/84441] [6/7/8 Regression] Internal compiler error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Further reduced:
int &foo ();
struct A { struct B { B (int *, int &); int *b; } a; A (A &&) : a (0, foo ())
{} };
struct C { A c; int d; };
C bar ();
struct D : C { D () : C (0 ? bar () : bar ()) {} };
D d;

The problem is when expanding this_2(D)->D.2434 = bar ();, where both lhs and
rhs
have TREE_ADDRESSABLE type, but type of bar () return value is C, which has
128-bit size, and type of the lhs - COMPONENT_REF - is also C, 128-bit, but its
second operand is a 96-bit FIELD_DECL instead (C without the padding at the
end).

When using C (bar ()) instead of C (0 ? bar () : bar ()) it compiles fine, but
in that case bar () is not called with the COMPONENT_REF with 96-bit FIELD_DECL
on lhs, but instead a C temporary that is later on copy constructed into the
96-bit FIELD_DECL.  So, it feels more like a C++ FE bug than something the
expansion needs to handle, but I could be wrong.

[Bug c/82323] circular ifunc attribute on a function definition silently accepted

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
I've noticed that C++ FE can handle the problem #1:

./xg++ -B. ~/Programming/testcases/pr82323.c
/home/marxin/Programming/testcases/pr82323.c:2:1: error: ‘int foo()’ defined
both normally and as ‘ifunc’ attribute
 foo (void) { return 0; }
 ^~~

I tried to look at the and I'm leaving this PR to somebody more skilled with
FE.

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
As it's fixed on GCC-7 and currect trunk, can we Jakub close that?

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[acsawdey at gcc dot gnu.org]

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

--- Comment #7 from acsawdey at gcc dot gnu.org ---
Created attachment 43462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43462&action=edit
revised test case

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
I haven't heard any answer to #c16 whether it actually helped the kernel or
not.

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[acsawdey at gcc dot gnu.org]

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

--- Comment #8 from acsawdey at gcc dot gnu.org ---
It looks like both gcc 7 and 8 assume that the statement 

  ptrA->sA[ptrB->int1].zt = parm1;

will only be executed 14+1 times because of the declaration sA[15].

However gcc 7 assumes the whole loop will only execute that number of times:

Statement ptrA_14(D)->sA[ptrB__int1_lsm.11_22].zt = _34;
 is executed at most 14 (bounded by 14) + 1 times in loop 1.
Analyzing # of iterations of loop 1
  exit condition [15, + , 4294967295] != 0
  bounds on difference of bases: -15 ... -15
  result:
# of iterations 15, bounded by 15
Loop 1 iterates 15 times.
Loop 1 iterates at most 14 times.
Loop 1 likely iterates at most 14 times.
Analyzing # of iterations of loop 1
  exit condition [15, + , 4294967295] != 0
  bounds on difference of bases: -15 ... -15
  result:
# of iterations 15, bounded by 15
Removed pointless exit: if (ivtmp_24 != 0)

were gcc8 does not:

Statement ptrA_13(D)->sA[ptrB__int1_lsm.5_22].zt = _20;
 is executed at most 14 (bounded by 14) + 1 times in loop 1.
Analyzing # of iterations of loop 1
  exit condition [15, + , 4294967295] != 0
  bounds on difference of bases: -15 ... -15
  result:
# of iterations 15, bounded by 15
Loop 1 iterates 15 times.
Loop 1 iterates at most 15 times.
Loop 1 likely iterates at most 15 times.

Neither gcc 7 nor 8 produce any warnings for the revised test case with -Wall.