[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||segher at gcc dot gnu.org
  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #2 from Segher Boessenkool  ---
Mine.

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Mon Oct 29 07:36:45 2018
New Revision: 265582

URL: https://gcc.gnu.org/viewcvs?rev=265582&root=gcc&view=rev
Log:
combine: Fix various shortcomings in make_more_copies (PR87701, PR87780)

This rewrites most of make_more_copies, in the process fixing a few PRs
and some other bugs, and working around a few target problems.  Certain
notes turn out to actually change the meaning of the RTL, so we cannot
drop them; and i386 takes subregs of hard regs.


PR rtl-optimization/87701
PR rtl-optimization/87780
* combine.c (make_more_copies): Rewrite.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Mon Oct 29 07:36:45 2018
New Revision: 265582

URL: https://gcc.gnu.org/viewcvs?rev=265582&root=gcc&view=rev
Log:
combine: Fix various shortcomings in make_more_copies (PR87701, PR87780)

This rewrites most of make_more_copies, in the process fixing a few PRs
and some other bugs, and working around a few target problems.  Certain
notes turn out to actually change the meaning of the RTL, so we cannot
drop them; and i386 takes subregs of hard regs.


PR rtl-optimization/87701
PR rtl-optimization/87780
* combine.c (make_more_copies): Rewrite.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed.

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
Fixed.

[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled

[rvdv at vandewiele dot com]

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

--- Comment #5 from rvdv at vandewiele dot com ---
Created attachment 44916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44916&action=edit
assembly output 7.3.0

This is the assembly output i get with 7.3.0 (and as early as 6.1.0)
I have tried it with 8.1.0 and then I get the same output as you did. 
So it seems like it was fixed in 8.1.0

[Bug c++/87781] New: template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier

[ensadc at mailnesia dot com]

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

Bug ID: 87781
   Summary: template disambiguator not after `::`, `.` or `->` is
incorrectly accepted in an elaborated-type-specifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://wandbox.org/permlink/97lV1nw6gMGSDOct

template class A;

class template A *p;

GCC allows this with no warning or error. Both clang and MSVC reject this.

[Bug tree-optimization/87776] [9 Regression] Compile time hog during RPO VN

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started to be slow with r264241.

[Bug fortran/87782] New: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'[9 Regression]

[marxin at gcc dot gnu.org]

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

Bug ID: 87782
   Summary: runtime error: load of value 1818451807, which is not
a valid value for type 'expr_t'[9 Regression]
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

It's a recent regression I believe. Using ubsan compiler one can see:

$ UBSAN_OPTIONS=print_stacktrace=1 gcc
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/testsuite/gfortran.dg/deferred_character_23.f90
../../gcc/fortran/frontend-passes.c:660:46: runtime error: load of value
1818451807, which is not a valid value for type 'expr_t'
#0 0xf0a979 in constant_string_length
../../gcc/fortran/frontend-passes.c:660
#1 0xf0c907 in create_var ../../gcc/fortran/frontend-passes.c:823
#2 0xf07b5c in realloc_string_callback
../../gcc/fortran/frontend-passes.c:299
#3 0xf32069 in gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*,
void*), int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5073
#4 0xf149e2 in realloc_strings ../../gcc/fortran/frontend-passes.c:1517
#5 0xf14b4c in realloc_strings ../../gcc/fortran/frontend-passes.c:1522
#6 0xf0709f in gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:179
#7 0xbb8898 in gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16736
#8 0xae429f in gfc_parse_file() ../../gcc/fortran/parse.c:6266
#9 0xc59435 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
#10 0x2444c25 in compile_file ../../gcc/toplev.c:455
#11 0x244da89 in do_compile ../../gcc/toplev.c:2172
#12 0x244e1cf in toplev::main(int, char**) ../../gcc/toplev.c:2307
#13 0x4971b0e in main ../../gcc/main.c:39
#14 0x7608cfea in __libc_start_main ../csu/libc-start.c:308
#15 0x8669a9 in _start
(/home/marxin/bin/gcc2/lib/gcc/x86_64-pc-linux-gnu/9.0.0/f951+0x8669a9)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c++/87783] New: `class A;` is incorrectly accepted at namespace or class scope

[ensadc at mailnesia dot com]

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

Bug ID: 87783
   Summary: `class A;` is incorrectly accepted at namespace
or class scope
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://wandbox.org/permlink/L5JYCDnEfKmftRlr

template class A {};

class A;

Both Clang and MSVC appear to treat `class A;` as an invalid explicit
template specialization. GCC does the same at block scope, but incorrectly
accepts this declaration at namespace or class scope.

[Bug libstdc++/87784] New: A bug in tr2::dynamic_bitset::find_first

[yusemru at gmail dot com]

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

Bug ID: 87784
   Summary: A bug in tr2::dynamic_bitset::find_first
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yusemru at gmail dot com
  Target Milestone: ---

Created attachment 44917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44917&action=edit
source code

Consider the following code:

#include 
#include 

using namespace std;
using namespace tr2;

int main() {
dynamic_bitset b;
b.push_back(0);
b.push_back(1);
dynamic_bitset a;
a.push_back(0);
a.push_back(0);
cout << b.find_first() << ' ' << a.find_first() << endl;
return 0;
}

On my machine it prints 2 2, which is clearly wrong.
I'm using GCC 8.1.1 on Arch Linux x86-64

[Bug tree-optimization/87785] New: [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[marxin at gcc dot gnu.org]

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

Bug ID: 87785
   Summary: [9 Regression] ICE in dr_misalignment, at
tree-vectorizer.h:1245 on 454.calculix with -Ofast and
-flto
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

I see following ICE on a Haswell machine:

during GIMPLE pass: vect
SPOOLES/SubMtx/src/SubMtx_solve.c: In function 'SubMtx_solve':
SPOOLES/SubMtx/src/SubMtx_solve.c:45:1: internal compiler error: in
dr_misalignment, at tree-vectorizer.h:1245
   45 | SubMtx_solve (
  | ^
0x783bf2 dr_misalignment(dr_vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vectorizer.h:1245
0x784cf4 dr_misalignment(dr_vec_info*)
/home/marxin/Programming/gcc/gcc/tree.h:3232
0x784cf4 aligned_access_p
/home/marxin/Programming/gcc/gcc/tree-vectorizer.h:1263
0x784cf4 vect_supportable_dr_alignment(dr_vec_info*, bool)
/home/marxin/Programming/gcc/gcc/tree-vect-data-refs.c:6324
0xe85f6d vect_get_load_cost(_stmt_vec_info*, int, bool, unsigned int*, unsigned
int*, vec*, vec*, bool)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:1231
0xe9f21d vect_model_load_cost
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:1205
0xe9f21d vectorizable_load
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:7595
0xea3ab2 vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*,
vec*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:9568
0xecc346 vect_slp_analyze_node_operations_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2457
0xecc346 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2504
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xed09ae vect_slp_analyze_operations(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2536
0xed3371 vect_slp_analyze_bb_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2844
0xed3371 vect_slp_bb(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2931
0xed87c9 try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:926


Referenced Bugs:

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

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Target Milestone|--- |9.0
Summary|[9.0 Regression] aarch64|[9 Regression] aarch64
   |target testcases fail after |target testcases fail after
   |r265398 |r265398

[Bug c++/87768] [8/9 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||7.3.1
   Target Milestone|--- |8.3
Summary|ICE in  |[8/9 Regression] ICE in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:19002 when using|cp/pt.c:19002 when using
   |concepts|concepts

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 CC||rguenth at gcc dot gnu.org
  Known to work||8.2.0
 Ever confirmed|0   |1
  Known to fail||9.0

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

[Bug c++/87770] [8/9 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|ICE in  |[8/9 Regression] ICE in
   |type_dependent_expression_p |type_dependent_expression_p
   |, at cp/pt.c:25230  |, at cp/pt.c:25230

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Please provide a testcase - usually preprocessed source, commandline-options
with -v appended.  See https://gcc.gnu.org/bugs.html

Note that GCC 5 and 6 are no longer supported so you need to update to GCC 7 or
newer.

[Bug debug/87772] Crash with variadic template, constexpr constructor for templated non-literal type, using declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
  Component|c++ |debug
 Ever confirmed|0   |1
  Known to fail||7.3.1, 8.2.1, 9.0

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC 7 fails the same way, GCC 6 doesn't like the testcase.

> g++-8 t.ii -std=c++17 -g -B /abuild/rguenther/gcc8-g/gcc
main.cpp: In instantiation of ‘struct
Parser, 1>, 1> >’:
main.cpp:24:53:   required from here
main.cpp:16:8: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in equate_type_number_to_die, at dwarf2out.c:5773
0x164f511 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/space/rguenther/src/svn/gcc-8-branch/gcc/tree.c:9384
0x848ea8 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/space/rguenther/src/svn/gcc-8-branch/gcc/tree.h:3262
0xd4bc9b equate_type_number_to_die
/space/rguenther/src/svn/gcc-8-branch/gcc/dwarf2out.c:5773
0xd8099e gen_typedef_die
/space/rguenther/src/svn/gcc-8-branch/gcc/dwarf2out.c:25197
0xd83ad7 gen_decl_die
/space/rguenther/src/svn/gcc-8-branch/gcc/dwarf2out.c:26215

[Bug c++/87786] New: Failed to mangle sizeof...(ArgPack) with template-alias captured arguments

[xecycle at gmail dot com]

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

Bug ID: 87786
   Summary: Failed to mangle sizeof...(ArgPack) with
template-alias captured arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xecycle at gmail dot com
  Target Milestone: ---

Reproducing code (at https://godbolt.org/z/dbqZu7):

```
#include 

double g(int);

template 
struct M {};

template 
using make_M = M;

template 
auto f(T&&... x)
  -> make_M
{
  using _noop = int[];
  (void)_noop { ((void)x, 0)... };
  return {};
}

auto m = f(12, 34);
```

It fails to compile with versions >= 7.  At first it looks like a regression;
but it probably is not.  It's more like an incomplete attempt (in 7.x) to fix a
previous mangling bug.  6.x and earlier does compile, but the mangled output
used "sz" instead of "sP"; gcc/cp/mangle.c on trunk actually contains a line
`write_string ("sP");`, but seems it did not reach there in this example.

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c/87779] Extremely large expression causes segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
Version|unknown |8.2.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It simply runs out of stack (recursing).  Raising the process stack limit with
ulimit -s unlimited makes it work quickly:

> /usr/bin/time gcc-8 t.c
0.22user 0.18system 0:00.40elapsed 99%CPU (0avgtext+0avgdata
352956maxresident)k
0inputs+960outputs (0major+89197minor)pagefaults 0swaps


(gdb) bt
#0  0x01d72282 in LINEMAPS_MACRO_LOWEST_LOCATION (set=0x77fef000)
at
/space/rguenther/src/svn/gcc-8-branch/gcc/../libcpp/include/line-map.h:1004
#1  0x01d95d9e in linemap_location_from_macro_expansion_p (
set=0x77fef000, location=19837408)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:1256
#2  0x01d954a1 in linemap_lookup (set=0x77fef000, line=19837408)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:946
#3  0x01d94104 in pure_location_p (set=0x77fef000, loc=19837408)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:310
#4  0x01d93bd8 in get_combined_adhoc_loc (set=0x77fef000, 
locus=19837408, src_range=..., data=0x0)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:177
#5  0x013d7e99 in COMBINE_LOCATION_DATA (set=0x77fef000, 
loc=19837408, src_range=..., block=0x0)
at
/space/rguenther/src/svn/gcc-8-branch/gcc/../libcpp/include/line-map.h:1054
#6  0x01d9269a in _cpp_lex_direct (pfile=0x2ba35a0)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/lex.c:3161
#7  0x01d9106f in _cpp_lex_token (pfile=0x2ba35a0)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/lex.c:2597
#8  0x01d9c6ad in cpp_get_token_1 (pfile=0x2ba35a0, 
location=0x768871ec)
--Type  for more, q to quit, c to continue without paging--
at /space/rguenther/src/svn/gcc-8-branch/libcpp/macro.c:2718
#9  0x01d9caf7 in cpp_get_token_with_location (pfile=0x2ba35a0, 
loc=0x768871ec)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/macro.c:2904
#10 0x0092be5a in c_lex_with_flags (value=0x768871f0, 
loc=0x768871ec, cpp_flags=0x768871f8 "", lex_flags=0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c-family/c-lex.c:403
#11 0x0088fbe4 in c_lex_one_token (parser=0x768871e0, 
token=0x768871e8)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:251
#12 0x00890014 in c_parser_peek_token (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:435
#13 0x0089f512 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7209
#14 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#15 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#16 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#17 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#18 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
--Type  for more, q to quit, c to continue without paging--
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#19 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#20 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#21 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#22 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
...
#41908 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
#41909 0x0089d3ae in c_parser_binary_expression (
parser=0x768871e0, after=0x0, omp_atomic_lhs=0x0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:6907
#41910 0x0089cb4d in c_parser_conditional_expression (
parser=0x768871e0, after=0x0, omp_atomic_lhs=0x0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:6645
...

I guess it's not easy to avoid this given the structure of the parser.

We are already trying to raise the stack limit to 64MB via stack_limit_increase
().  Maybe we should try r

[Bug fortran/87782] [9 Regression] runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.0

[Bug libstdc++/87787] New: [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[marxin at gcc dot gnu.org]

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

Bug ID: 87787
   Summary: [9 Regression] runtime error: null pointer passed as
argument 2, which is declared to never be null
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
  Target Milestone: ---

Would be also a recent regression. I see following for ubsan-bootstrapped
compiler:

$ make check RUNTESTFLAGS="gcov.exp=gcov-pr86536.c"
...

Creating 'gcov-pr86536.c.gcov'
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:907:24:
runtime error: null pointer passed as argument 2, which is declared to never be
null
#0 0x460a82 in std::enable_if::value, char const**>::type std::__relocate_a_1(char const**, char const**, char const**, std::allocator&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:907
#1 0x460a82 in char const** std::__relocate_a >(char const**, char const**, char const**,
std::allocator&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:938
#2 0x460a82 in void std::vector
>::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, char const*&&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:464
#3 0x41dae9 in void std::vector
>::emplace_back(char const*&&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:122
#4 0x41dae9 in std::vector
>::push_back(char const*&&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1164
#5 0x41dae9 in output_lines ../../gcc/gcov.c:2973
#6 0x4229a7 in output_gcov_file ../../gcc/gcov.c:1284
#7 0x4229a7 in generate_results ../../gcc/gcov.c:1389
#8 0x40e4f9 in main ../../gcc/gcov.c:813
#9 0x7ffa344f9724 in __libc_start_main (/lib64/libc.so.6+0x20724)
#10 0x410248 in _start
(/home/mliska/Programming/gcc/objdir/gcc/gcov+0x410248)

It's about pushing a 'const char *' into a vector, I hope the usage is fine in
gcov.c. Jonathan can you please take a look?

[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-10-29
  Known to work||8.2.0
 Blocks||63426
   Target Milestone|--- |9.0
  Known to fail||9.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
That would be my recent commit. We will probably need to add if(size!=0) in
front of the call to memmove...

[Bug bootstrap/87788] New: [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[iains at gcc dot gnu.org]

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

Bug ID: 87788
   Summary: [9 Regression] Bootstrap fails for
x86_64-apple-darwin* with default languages selection
after D addition.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

bootstrap fails at stage #2 with:

../../src/gcc/d/dmd/constfold.c: In function 'UnionExp Cast(Loc, Type*, Type*,
Expression*)':
../../src/gcc/d/dmd/constfold.c:1162:50: error: conversion from 'real_t' {aka
'longdouble'} to 'sinteger_t' {aka 'long int'} is ambiguous
 1162 | result = (d_int8)(sinteger_t)r;
  |  ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: note: candidate: 'longdouble::operator
uint32_t()'
   60 |   operator uint32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:63:3: note: candidate: 'longdouble::operator
uint64_t()'
   63 |   operator uint64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:66:3: note: candidate: 'longdouble::operator
bool()'
   66 |   operator bool (void)
  |   ^~~~
../../src/gcc/d/dmd/constfold.c:1166:50: error: conversion from 'real_t' {aka
'longdouble'} to 'dinteger_t' {aka 'long unsigned int'} is ambiguous
 1166 | result = (d_uns8)(dinteger_t)r;
  |  ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: note: candidate: 'longdouble::operator
uint32_t()'
   60 |   operator uint32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:63:3: note: candidate: 'longdouble::operator
uint64_t()'
   63 |   operator uint64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:66:3: note: candidate: 'longdouble::operator
bool()'
   66 |   operator bool (void)
  |   ^~~~
../../src/gcc/d/dmd/constfold.c:1169:51: error: conversion from 'real_t' {aka
'longdouble'} to 'sinteger_t' {aka 'long int'} is ambiguous
 1169 | result = (d_int16)(sinteger_t)r;
  |   ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: note: candidate: 'longdouble::operator
uint32_t()'
   60 |   operator uint32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:63:3: note: candidate: 'longdouble::operator
uint64_t()'
   63 |   operator uint64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:66:3: note: candidate: 'longdouble::operator
bool()'
   66 |   operator bool (void)
  |   ^~~~
../../src/gcc/d/dmd/constfold.c:1173:51: error: conversion from 'real_t' {aka
'longdouble'} to 'dinteger_t' {aka 'long unsigned int'} is ambiguous
 1173 | result = (d_uns16)(dinteger_t)r;
  |   ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: 

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to David Grayson from comment #14)

> Does anyone have an idea of how to fix this bug for real?  What values
> should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> have  on Windows, and should they be controllable from the command-line? 
> Where do they get set?
> 
> --David

Reading symbols from /ssd/uros/gcc-build-xxx/gcc/cc1plus...done.
(gdb) watch x_rtl.preferred_stack_boundary 

Hardware watchpoint 1: x_rtl.preferred_stack_boundary

(gdb) r
Starting program: /ssd/uros/gcc-build-xxx/gcc/cc1plus pr58372.C
Hardware watchpoint 1: x_rtl.preferred_stack_boundary

Old value = 0
New value = 32
0x00b930dc in rtl_data::init_stack_alignment (this=0x23c8ac0 )
at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:6636
6636  preferred_stack_boundary = STACK_BOUNDARY;

Hardware watchpoint 1: x_rtl.preferred_stack_boundary

Old value = 32
New value = 128
emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode,
int, std::pair*) ()
at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
4744  if (outmode != VOIDmode)

(gdb) list
4739  if (crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
4740crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
4741
4742  /* If this kind of value comes back in memory,
4743 decide where in memory it should come back.  */
4744  if (outmode != VOIDmode)
4745{
4746  tfom = lang_hooks.types.type_for_mode (outmode, 0);
4747  if (aggregate_value_p (tfom, 0))
4748{

This happen when building SjLj landing pads:

#0  emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
() at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
#1  0x00b9b36c in emit_library_call (arg1_mode=,
arg1=, outmode=E_VOIDmode, 
fn_type=LCT_NORMAL, fun=) at
/home/uros/gcc-svn/trunk/gcc/rtl.h:4123
#2  sjlj_emit_function_enter(rtx_code_label*) () at
/home/uros/gcc-svn/trunk/gcc/except.c:1202
#3  0x00b9f20a in sjlj_build_landing_pads () at
/home/uros/gcc-svn/trunk/gcc/except.c:1481
#4  finish_eh_generation() () at /home/uros/gcc-svn/trunk/gcc/except.c:1510

Adding -mpreferred-stack-boundary=2 "fixes" compilation.

If you want to experiment, try the following patch:

Index: config/i386/mingw32.h
===
--- config/i386/mingw32.h   (revision 265582)
+++ config/i386/mingw32.h   (working copy)
@@ -251,6 +251,10 @@
 #undef  CHECK_EXECUTE_STACK_ENABLED
 #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable

+#undef PREFERRED_STACK_BOUNDARY_DEFAULT
+#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
+  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
+
 /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
 /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
 #if DWARF2_UNWIND_INFO

But I don't know the details of MS ABI, so I can't tell if the patch is
correct.

[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Marc Glisse from comment #1)
> That would be my recent commit. We will probably need to add if(size!=0) in
> front of the call to memmove...

That's what we already do in stl_algobase.h and fstream.tcc. I notice that we
do not do it in char_traits.h for the generic version (we do for each
specialization). I don't know if memcpy in locale_facets.h is safe either.

[Bug bootstrap/87789] New: D does not build on powerpc64-linux

[segher at gcc dot gnu.org]

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

Bug ID: 87789
   Summary: D does not build on powerpc64-linux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

$HOME/src/gcc/libphobos/src/std/internal/math/gammafunction.d:259:5: error:
static assert  "missing MAXGAMMA for other real types"

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ktietz at gcc dot gnu.org]

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

--- Comment #16 from Kai Tietz  ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to David Grayson from comment #14)
> 
> > Does anyone have an idea of how to fix this bug for real?  What values
> > should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> > have  on Windows, and should they be controllable from the command-line? 
> > Where do they get set?
> > 
> > --David
> 
> Reading symbols from /ssd/uros/gcc-build-xxx/gcc/cc1plus...done.
> (gdb) watch x_rtl.preferred_stack_boundary 
> 
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> (gdb) r
> Starting program: /ssd/uros/gcc-build-xxx/gcc/cc1plus pr58372.C
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> Old value = 0
> New value = 32
> 0x00b930dc in rtl_data::init_stack_alignment (this=0x23c8ac0
> ) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:6636
> 6636  preferred_stack_boundary = STACK_BOUNDARY;
> 
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> Old value = 32
> New value = 128
> emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair*) ()
> at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> 4744  if (outmode != VOIDmode)
> 
> (gdb) list
> 4739  if (crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
> 4740crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
> 4741
> 4742  /* If this kind of value comes back in memory,
> 4743 decide where in memory it should come back.  */
> 4744  if (outmode != VOIDmode)
> 4745{
> 4746  tfom = lang_hooks.types.type_for_mode (outmode, 0);
> 4747  if (aggregate_value_p (tfom, 0))
> 4748{
> 
> This happen when building SjLj landing pads:
> 
> #0  emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair*)
> () at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> #1  0x00b9b36c in emit_library_call (arg1_mode=,
> arg1=, outmode=E_VOIDmode, 
> fn_type=LCT_NORMAL, fun=) at
> /home/uros/gcc-svn/trunk/gcc/rtl.h:4123
> #2  sjlj_emit_function_enter(rtx_code_label*) () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1202
> #3  0x00b9f20a in sjlj_build_landing_pads () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1481
> #4  finish_eh_generation() () at /home/uros/gcc-svn/trunk/gcc/except.c:1510
> 
> Adding -mpreferred-stack-boundary=2 "fixes" compilation.
> 
> If you want to experiment, try the following patch:
> 
> Index: config/i386/mingw32.h
> ===
> --- config/i386/mingw32.h   (revision 265582)
> +++ config/i386/mingw32.h   (working copy)
> @@ -251,6 +251,10 @@
>  #undef  CHECK_EXECUTE_STACK_ENABLED
>  #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
>  
> +#undef PREFERRED_STACK_BOUNDARY_DEFAULT
> +#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
> +  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
> +
>  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
>  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
>  #if DWARF2_UNWIND_INFO> 
> But I don't know the details of MS ABI, so I can't tell if the patch is
> correct.

The x64 ABI part is correct, as for x64 abit there is just 16-byte stack
alignment. For x86 ms abi things aren't that strict AFAIK. The common stack
alignment on function entry is the natural one, but there is in general no
strict requirement for it. So the patch looks fine, but should be commented in
the release notes, as there might be fallout seen caused by it.

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin*
   Target Milestone|--- |9.0

[Bug c++/87663] using / typedef on recursive template leads to long compile time

[lumosimann at gmail dot com]

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

--- Comment #7 from Lukas Mosimann  ---
Thanks! I will do that.

First lets sum up state here such that it's not required to read through all
comments. I am playing around with integral constant and an "exponential
wrapper". First the "exponential wrapper":

```
template 
struct F : integral_constant::value -
  F::value> {};

template 
struct F : integral_constant {};

int main() {
F<0, 14>::value;
return 0;
}
```
I.e., we simply instantiate a huge set of integral constants. Now I play with
different integral_constants a measure compilation time.

=== V1 0.8s ===
template 
struct integral_constant {
static constexpr T value = v;
};


=== V2 4.4s === (used by type_traits)
template 
struct integral_constant {
static constexpr T value = v;
using value_type = T;
};

=== V3 4.2s ===
template 
struct integral_constant {
using value_type = T;
static constexpr T value = v;
};

=== V4 23 s === (!!)
template 
struct integral_constant {
using value_type = T;
static constexpr value_type value = v;
};

Currently I am working with a modified version of V2 (4.4s):

template 
struct integral_constant {
static constexpr T value = v;
using value_type = int;
};

In this case I see that we always create a new type variant of int (I guess one
per integral constant) through set_underlying type, and at another point we
iterate through large parts of the list to get the correct variant again (over
build_qualified_type). More precisely:
1) We first do build_qualified_type for value. This iterates through the whole
list and at some point finds "plain const int" (no typedef) - no new type
variant required.
2) We create a new type variant of int referring to the alias in this specific
integral_constant. This is prepended to the list of type variants, i.e., in the
next 1) we need to iterate over one additional entry than before to find "plain
const int".
Therefore, integral constant instantiation gets more expensive with each
instance.

I have seen the comment above set_underlying type, but my question is more
whether this is always needed (it is only talking about debugging and protoize
- so is it also required in a build without debugging information?).
And yes, it might also be possible to do it more efficient: Do all variants
need to be stored in this list? Is this the natural order for a list - and is a
list the right data structure for this?

I will post to the mailing list pointing to this comment.

[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 #40 from Tamar Christina  ---
> In most practical cases -B../../ is just redundant with $(CXX).  It's only 
> when you configure like Richard that you may run into issues, but then we can 
> assume that we're on Linux so the paths are OK I think.

Ah ok, I'll update to trunk and run a bootstrap today then and submit a patch
tomorrow. Thanks!

--- Comment #41 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct 29 09:45:50 2018
New Revision: 265583

URL: https://gcc.gnu.org/viewcvs?rev=265583&root=gcc&view=rev
Log:
Fix mingw-w64 Ada native bootstrap (PR81878).

Due to the changes in PR81878 builds of GCC8 and trunk are impossible
with Ada enabled[1][2].

The reason the patch breaks the bootstrap is due to how gnatlink receives it's
arguments.

gnatlink is usually invoked as

$(GNATLINK) -v gnatcmd -o ../../gnat$(exeext) \
  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)" $(TOOLS_LIBS)

so it passes $(CC) and $(GCC_LINK) as quoted arguments to the program.
Because of this quotation the msys2 shell does not translate any paths in
$(CC) and $(GCC_LINK) from their Unix version to their Windows version.

Furthermore because there are multiple paths in the values separated by space
and because the paths often contain a prefix like -L (e.g. -L/f/foo) we can't
use `fix_srcfile_path` to fix this.

An alternative solution would have been to create a stub program that echos the
commandline options it receives back, and calling this program with $(CC) and
$(GCC_LINK)
unquoted to get them translated.  However this was a bit more invasive.

So instead for native compilations we add -B../../ such that it picks up the
lto plugin
from the previous built compiler.  Since it's native there shouldn't be a
mismatch here.

[1] https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
[2] https://gcc.gnu.org/ml/gcc/2018-07/msg00410.html

gnattools/ChangeLog:

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


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

[Bug tree-optimization/87790] New: [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

Bug ID: 87790
   Summary: [9 Regression] ICE in vect_get_vec_def_for_operand_1,
at tree-vect-stmts.c:1475
   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
  Target Milestone: ---

Following cases an ICE:

$ cat dfa.i
int a, b;
void c(int d[][8]) {
  int e, f;
  for (; b; b++) {
e = d[b][0] % 4 * 21;
if (e >= 21)
  e--;
a = d[b][0] - e;
f = 1;
for (; f != 8; f++)
  d[b][f] = a;
  }
}

$ gcc dfa.i -Ofast -fprofile-generate -c -march=znver1
during GIMPLE pass: vect
dfa.i: In function ‘c’:
dfa.i:2:6: internal compiler error: in vect_get_vec_def_for_operand_1, at
tree-vect-stmts.c:1475
2 | void c(int d[][8]) {
  |  ^
0xf7cdce vect_get_vec_def_for_operand_1(_stmt_vec_info*, vect_def_type)
../../gcc/tree-vect-stmts.c:1475
0xf7f2ad vect_get_vec_def_for_operand(tree_node*, _stmt_vec_info*, tree_node*)
../../gcc/tree-vect-stmts.c:1554
0xf86bb5 vectorizable_condition(_stmt_vec_info*, gimple_stmt_iterator*,
_stmt_vec_info**, tree_node*, int, _slp_tree*, vec*)
../../gcc/tree-vect-stmts.c:8916
0xf9af25 vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:9676
0xf9cfd3 vect_transform_loop_stmt
../../gcc/tree-vect-loop.c:8146
0xfaf2f3 vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:8357
0xfceb85 try_vectorize_loop_1
../../gcc/tree-vectorizer.c:965
0xfcf636 vectorize_loops()
../../gcc/tree-vectorizer.c:1097
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-10-29
 CC||rguenth at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

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

[Bug c++/87791] New: Unnecessary zero-initialization of constexpr unions in arrays

[widlundtobias at gmail dot com]

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

Bug ID: 87791
   Summary: Unnecessary zero-initialization of constexpr unions in
arrays
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: widlundtobias at gmail dot com
  Target Milestone: ---

Created attachment 44918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44918&action=edit
Preprocessed code

Given a type that uses a constexpr-enabled union to store either a value, or an
empty dummy struct as followed.


>struct Container
>{
>struct Dummy{};
>union Storage
>{   
>constexpr Storage(): dummy(Dummy())
>{   
>
>}   
>Dummy dummy;
>int value;
>};  
>
>Storage storage;
>};

This code is a legal way to initialise the union with nothing, meaning that
it's legal for the compiler to leave the data uninitialised, even in constexpr
contexts.

However, if the above Container type is used like so:

>using Arr = std::array;
>
>Arr makeA()
>{
>Arr a;
>return a;
>}

Then the compiled code fills the array with zeroes, using memset.

Excerpt from compiled code:

>_Z5makeAv:
>.LFB1099:
>.cfi_startproc
>subq$8, %rsp
>.cfi_def_cfa_offset 16
>movl$16000, %edx
>xorl%esi, %esi
>callmemset@PLT   addq$8, %rsp
>.cfi_def_cfa_offset 8
>ret 
>.cfi_endproc
>.LFE1099:
>.size   _Z5makeAv, .-_Z5makeAv
>.section.text.startup,"ax",@progbits
>.p2align 4,,15
>.globl  main
>.type   main, @function

This is unnecessary and problematic as it incurs runtime overhead when using
the union-based storage as a way to store items that can possibly be
uninitialised, as a constexpr-friendly alternative to placement-new.

Happens even with -O3 and only happens if the `constexpr` keyword is present.

Preprocessed code attached.

Godbolt CE link for illustrative purpose: https://godbolt.org/z/FPnEy3




Output of gcc -v -save-temps -O3 main.cpp:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20180831 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -O3 -fpch-preprocess -o main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1

/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -O3 -version -o
main.s
GNU C++14 (GCC) version 8.2.1 20180831 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20180831, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.2.1 20180831 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20180831, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a03a3250bc7a24a525a6f08bf70a1ad6
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 as -v --64 -o main.o main.s
GNU assembler version 2.31.1 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.31.1
COMPILER_PATH=/usr/lib/gcc/x86_64-p

[Bug fortran/87782] [9 Regression] runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I see that at r265374.

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
The same can be seen on 526.blender_r with: -Ofast -g -flto=8 -march=znver1

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
With the right set of caching/failing events we miss loads for
slp_instance->loads.  I have a patch gathering loads after the fact which fixes
the issue but I don't have a nice testcase.

[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||nathan at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
We still insist on testcases being attached here regardless as stated at
https://gcc.gnu.org/bugs/ (which you were asked to read) so thanks for
attaching it.

This started to be rejected with r252005

Kill CLASSTYPE_SORTED_FIELDS.
* cp-tree.h (struct lang_type): Lose sorted_fields member.
(CLASSTYPE_SORTED_FIELDS): Delete.
* name-lookup.h (set_class_bindings): Add EXTRA arg.
* name-lookup.c (fields_linear_search): New, broken out of ...
(lookup_field_1): ... here.  Delete remainder of function.
(get_class_binding_direct): Reimplement without sorted_fields.
(get_class_binding): Rename TYPE arg to KLASS, for consistency.
(get_method_slot): Call set_class_binding when creating method_vec
on complete type.
(method_name_cmp): Order identically named slots.
(sorted_fields_type_new): Delete.
(field_vc_append_class_fields): Rename to ...
(method_vec_append_class_fields): ... here.  Adjust.
(field_vec_append_enum_values): Renme to ...
(method_vec_append_enum_values): ... here. Adjust.
(method_vec_dedup): New.
(set_class_bindings): Reimplement.
(insert_late_enum_def_bindings): Reimplement.

[Bug c++/87781] template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

[Bug c++/87783] `class A;` is incorrectly accepted at namespace or class scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

[Bug libstdc++/87784] A bug in tr2::dynamic_bitset::find_first

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug libstdc++/87784] A bug in tr2::dynamic_bitset::find_first

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Looks like this patch fixes it:

--- a/libstdc++-v3/include/tr2/dynamic_bitset
+++ b/libstdc++-v3/include/tr2/dynamic_bitset
@@ -729,8 +729,7 @@ namespace tr2
   {
if (size_t __offset = this->size() % bits_per_block == 0)
  this->_M_do_append_block(block_type(0), this->_M_Nb);
-   ++this->_M_Nb;
-   this->_M_unchecked_set(this->_M_Nb, __bit);
+   this->_M_unchecked_set(this->_M_Nb++, __bit);
   }

   /**

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

[iii at linux dot ibm.com]

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 CC||iii at linux dot ibm.com

--- Comment #2 from Ilya Leoshkevich  ---
This must have slipped through, because I tested the movdi patch on top of the
outdated trunk (r264877).

Candidate fix: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01793.html

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 13:31:28 2018
New Revision: 265588

URL: https://gcc.gnu.org/viewcvs?rev=265588&root=gcc&view=rev
Log:
2018-10-29  Richard Biener  

PR tree-optimization/87785
* tree-vect-slp.c (vect_build_slp_tree_2): Remove loads argument
and processing.
(vect_build_slp_tree): Likewise.
(vect_gather_slp_loads): New function.
(vect_analyze_slp_instance): Gather loads separately from the
SLP tree build.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-slp.c

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

[rguenth at gcc dot gnu.org]

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

Bug 87785 Summary: [9 Regression] ICE in dr_misalignment, at 
tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87785

   What|Removed |Added

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

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/87792] New: lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[fwmechanic at gmail dot com]

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

Bug ID: 87792
   Summary: lto1.exe: internal compiler error: in get_constructor,
at varpool.c:311
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fwmechanic at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44919&action=edit
contains minimized reproduction of error, all files

GCC "distro" I'm using is mingw-16.0-without-git.exe from
https://nuwen.net/mingw.html

Result: 

lto1.exe: internal compiler error: in get_constructor, at varpool.c:311
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error: g++ returned 1 exit status
compilation terminated.
[Leaving LTRANS bugexe.exe.ltrans0.o]
c:/users/kevin/appdata/local/programs/mingw/64/mingw/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

Because this is associated with -flto (apparently takes 2 g++ steps: compile,
link, to reproduce) I have included all further info in attached zip:

Archive:  lto1_internal_error_get_constructor_varpool.zip
  Length  DateTimeName
-  -- -   
26638  2018-10-29 06:28   err
  935  2018-10-29 06:28   out
38792  2018-10-29 06:28   bugexe_exe.map
 1608  2018-10-29 06:28   bugexe.exe.ltrans0.s
   22  2018-10-29 06:28   bugexe.exe.ltrans.out
17288  2018-10-29 06:28   bugexe.exe.ltrans0.o
  599  2018-10-29 06:28   -Bdynamic.res
14970  2018-10-29 06:28   bugsrc.o
34947  2018-10-29 06:28   bugsrc.s
   136444  2018-10-29 06:28   bugsrc.ii
- ---
   272243 10 files

File out is stdout, File err is stderr, respectively, from make.

[Bug lto/87792] lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[fwmechanic at gmail dot com]

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

--- Comment #1 from Kevin Goodwin  ---
Created attachment 44920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44920&action=edit
diff that fixes the problem: bugexe builds and runs successfully

[Bug c++/87663] using / typedef on recursive template leads to long compile time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
I think the "variant" type set_underlying_type builds doesn't have to be in the
variant type list.  The only thing that is probably needed is that it has
TYPE_CANONICAL (tt) = TYPE_CANONICAL (TREE_TYPE (x));

Other than that this whole dance of set_underlying_type & friends should
probably be revisited in the light of early debug info generation (add a debug
hook to emit DIEs in whatever way this is supposed to happen through this
mechanism?).

That is, if the FE knows an object is of a type with name X then say so rather
than requiring this type copy that is just used to refer to the typedef.  That
is, it looks like a quite awkward and expensive way to communicate this to
dwarf2out.

[Bug lto/87792] lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Looks the problematic line is:
  gcc_assert (DECL_INITIAL (decl) != error_mark_node);

so yes, it's somehow connected to __PRETTY_FUNCTION__ initialization.
Unfortunately I won't be able to help you as I can't reproduce that on Linux. I
don't have any access to mingw machine.

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[romain.geissler at amadeus dot com]

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

--- Comment #5 from Romain Geissler  ---
Hi,

Trying with today's trunk with this patch included, my clang PGO+LTO bootstrap
goes further, but then the generated clang fails to compile itself. Just
putting here the clang error for reference:

fatal error: error in backend: Cannot select: 0x20c13f8: ch = fp_to_fp16
0x201f1d8, 0x20bccd8, FrameIndex:i64<0>
  0x20bccd8: f80,ch = CopyFromReg 0x201f1d8, Register:f80 %0
0x20bcc08: f80 = Register %0
  0x20c1bb0: i64 = FrameIndex<0>
In function: __divtc3
clang-7: error: clang frontend command failed with exit code 70 (use -v to see
invocation)

The only thing that I changed recently is binutils/gcc/glibc, not the clang
sources. So there might still have some code gen issue left in gcc trunk (which
I don't know how to investigate).

Cheers,
Romain

[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
FWIW the following CSE enhancement cleans this up, but I'm unhappy with this
patch because it's too narrowly targeted; in particular, won't clean up

void g(int a, int *b, int c);
void f(int a, int *b, int c)
{
  if (a) *b = c;
  g(a, b, c);
}

Had to special-case for PARM_DECL because, in general, automatic variables that
are not address-taken on GIMPLE can become addressable on RTL when ABI requires
passing a large argument by reference.

--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -2232,6 +2232,15 @@ hash_rtx_string (const char *ps)
   return hash;
 }

+static bool
+mem_escapes_p (const_rtx x)
+{
+  tree decl = MEM_EXPR (x);
+  if (!decl || TREE_CODE (decl) != PARM_DECL)
+return true;
+  return may_be_aliased (decl);
+}
+
 /* Same as hash_rtx, but call CB on each rtx if it is not NULL.
When the callback returns true, we continue with the new rtx.  */

@@ -2421,7 +2430,8 @@ hash_rtx_cb (const_rtx x, machine_mode mode,
  return 0;
}
   if (hash_arg_in_memory_p && !MEM_READONLY_P (x))
-   *hash_arg_in_memory_p = 1;
+   if (*hash_arg_in_memory_p != 1)
+ *hash_arg_in_memory_p = mem_escapes_p (x) ? 1 : 2;

   /* Now that we have already found this special case,
 might as well speed it up as much as possible.  */
@@ -6127,7 +6137,7 @@ invalidate_memory (void)
 for (p = table[i]; p; p = next)
   {
next = p->next_same_hash;
-   if (p->in_memory)
+   if (p->in_memory == 1)
  remove_from_table (p, i);
   }
 }

[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 14:13:56 2018
New Revision: 265590

URL: https://gcc.gnu.org/viewcvs?rev=265590&root=gcc&view=rev
Log:
2018-10-29  Richard Biener  

Backport from mainline
2018-09-26  Richard Biener  

PR debug/87428
PR debug/87362
* tree-inline.c (expand_call_inline): When the location
of the call is UNKNOWN_LOCATION use DECL_SOURCE_LOCATION
or BUILTINS_LOCATION for the BLOCK_SOURCE_LOCATION of
the inserted BLOCK to make inlined_function_outer_scope_p
recognize it.
* dwarf2out.c (add_call_src_coords_attributes): Do not add
coords for reserved locations.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/tree-inline.c

[Bug debug/87428] "Missed" inline instances cause bogus DWARF to be emitted

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 14:13:56 2018
New Revision: 265590

URL: https://gcc.gnu.org/viewcvs?rev=265590&root=gcc&view=rev
Log:
2018-10-29  Richard Biener  

Backport from mainline
2018-09-26  Richard Biener  

PR debug/87428
PR debug/87362
* tree-inline.c (expand_call_inline): When the location
of the call is UNKNOWN_LOCATION use DECL_SOURCE_LOCATION
or BUILTINS_LOCATION for the BLOCK_SOURCE_LOCATION of
the inserted BLOCK to make inlined_function_outer_scope_p
recognize it.
* dwarf2out.c (add_call_src_coords_attributes): Do not add
coords for reserved locations.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/tree-inline.c

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #1 from Michael Matz  ---
One of usual fuzzer fake CVEs.

This is basically a similar "problem" like initially reported in
  https://sourceware.org/bugzilla/show_bug.cgi?id=23008
where I actually analyzed it.  The problem is that C++ mangled names
have a recursive structure.  For demonstration purposes let's assume that the
character 'F' in a mangled name means "here come nested template arguments,
described next", then you need to recurse down to decode those nested args,
and if the next character is 'F' as well, you just recurse down again.  So
a mangled "name" with a million 'F' characters in succession will need
a recursion depth of a million.

So, when you feed the demangler such a name a stack overflow is expected.
Exactly when the overflow occurs depends on how the demangler is compiled,
i.e. how much stack space is needed from one to the next recursion level
(sometimes the recursion is tail recursion, so in some compilation modes
can even be elided and so lead to non-exhaustion).

Many characters of the mangled names have this property, so there are multiple
variants of names that all lead to stack exhaustion, so the fuzzers were able
to create many different testcases:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 (aka bugzilla PR23008)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681

Unfortunately they now also started to submit fake CVEs for these, like this
one (CVE-2018-18701) or CVE-2018-18700 (aka bug 87681).

If libiberty ever implements a check for this (which essentially can only be an
arbitrary limit, which is frowned upon, especially as it must be very small, as
people might have their stack limit set very low) fine, if not, also fine.
Until then feeding such names to any demangling tool leads to stack exhaustion
and hence segfault.  Like any other memory exhaustion not a security bug.

[Bug lto/87792] lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[fwmechanic at gmail dot com]

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

--- Comment #3 from Kevin Goodwin  ---
aside: the exact same source code that triggers this internal error builds w/o
error using gcc version 4.8.1:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/users/kevin/appdata/local/programs/mingw/32/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.8.1/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/c/temp/gcc/dest
--with-gmp=/c/temp/gcc/gmp --with-mpfr=/c/temp/gcc/mpfr
--with-mpc=/c/temp/gcc/mpc --enable-languages=c,c++ --with-arch=i686
--with-tune=generic --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-sjlj-exceptions --disable-win32-registry --enable-checking=release
--enable-lto
Thread model: win32
gcc version 4.8.1 (GCC)

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[dory at satx dot rr.com]

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

Donna Ory  changed:

   What|Removed |Added

URL||https://www.youtube.com/wat
   ||ch?v=lAKyZd63_ns&t=559s

--- Comment #4 from Donna Ory  ---
I got the Master Tevo Flash files from here: 

https://www.facebook.com/groups/2058176381100233/files/

I have the "Standard" version, so that's the only one that I kept out of the
zip file.

Since it has all the Marlin files in it, I didn't need to download a new Marlin
set up.

I got the U8glib files off of github. I downloaded the zip file, to the folder
where I have my 3D printer stuff, and the followed the directions to add it to
the library. I did not unzip it.

Since this, I even tried using the newest version U8glib 1.18.1, but it still
has the same errors.

[Bug c/87793] New: GCC reports error when compiling with "-fpic -Os -g"

[bmeng.cn at gmail dot com]

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

Bug ID: 87793
   Summary: GCC reports error when compiling with "-fpic -Os -g"
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmeng.cn at gmail dot com
  Target Milestone: ---

Created attachment 44921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44921&action=edit
minimal test case (test.c) and the preprocessed file (test.i)

# Command line to call compiler 
$ /share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/i386-linux-gcc -march=i386
-m32 -c test.c -o test.o -fpic -Os -g --save-temps -v

# Output
Using built-in specs.
COLLECT_GCC=/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/i386-linux-gcc
Target: i386-linux
Configured with: /home/arnd/git/gcc/configure --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/i386-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
: (reconfigured) /home/arnd/git/gcc/configure --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/i386-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
Thread model: single
gcc version 8.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../libexec/gcc/i386-linux/8.1.0/cc1
-E -quiet -v -iprefix
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/
test.c -march=i386 -m32 -fpic -g -fworking-directory -Os -fpch-preprocess -o
test.i
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/sys-include"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/include"
ignoring duplicate directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/include"
ignoring duplicate directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/include-fixed"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/sys-include"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/include

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../libexec/gcc/i386-linux/8.1.0/cc1
-fpreprocessed test.i -quiet -dumpbase test.c -march=i386 -m32 -auxbase-strip
test.o -g -Os -version -fpic -o test.s
GNU C17 (GCC) version 8.1.0 (i386-linux)
compiled by GNU C version 5.4.1 20170519, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 8.1.0 (i386-linux)
compiled by GNU C version 5.4.1 20170519, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5b6be85f431a859ca20ca7e588057ee0
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/bin/as
-v --32 -o test.o test.s
GNU assembler version 2.30 (i386-linux) using BFD version (GNU Binutils) 2.30
test.s: Assembler messages:
test.s:715: Error: junk at end of line, first unrecognized character is `@'
test.s:760: Error: junk at end of line, first unrecognized character is `@'
test.s:715: Error: can't resolve `end.1561' {.u_boot_list_2_fit_loadable_3
section} - `start.1558' {.u_boot_list_2_fit_loadable_1 section}
test.s:760: Error: can't resolve `end.1561' {.u_boot_list_2_fit_loadable_3
section} - `start.1558' {.u_boot_list_2_fit_loadable_1 section}

# Workaround
Removing -fpic or -Os or -g will make t

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[dory at satx dot rr.com]

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

--- Comment #5 from Donna Ory  ---
Also, my "SanityCheck.h" is off the charts with all kinds of stuff that just
gives the the "Deer in the headlights" look!! lol!!

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 14:57:52 2018
New Revision: 265593

URL: https://gcc.gnu.org/viewcvs?rev=265593&root=gcc&view=rev
Log:
2018-10-29  Richard Biener  

PR tree-optimization/87790
* tree-vect-slp.c (vect_mark_slp_stmts): Simplify.
(vect_make_slp_decision): Adjust.
(vect_slp_analyze_bb_1): Likewise.
(vect_detect_hybrid_slp_stmts): Properly union SLP type over
edges.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr87790.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Donna Ory from comment #4)
> I got the Master Tevo Flash files from here: 
> 
> https://www.facebook.com/groups/2058176381100233/files/

That's a closed group.

> 
> I have the "Standard" version, so that's the only one that I kept out of the
> zip file.
> 
> Since it has all the Marlin files in it, I didn't need to download a new
> Marlin set up.
> 
> I got the U8glib files off of github. 

This one? https://github.com/olikraus/u8glib 

> I downloaded the zip file, to the folder where I have my 3D printer stuff,
> and the followed the directions to add it to the library. I did not unzip it.
> 
> Since this, I even tried using the newest version U8glib 1.18.1, but it
> still has the same errors.

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/87041] [8/9 Regression] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Testing a patch.

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 15:43:08 2018
New Revision: 265596

URL: https://gcc.gnu.org/viewcvs?rev=265596&root=gcc&view=rev
Log:
2018-10-29  Richard Biener  

PR tree-optimization/87785
* tree-vect-slp.c (vect_gather_slp_loads): Only gather
internal defs.

* gcc.dg/torture/20181029-1.c: New testcase.
* gcc.dg/torture/20181029-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/20181029-1.c
trunk/gcc/testsuite/gcc.dg/torture/20181029-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
On Mon, 29 Oct 2018, egallager at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
> 
> --- Comment #8 from Eric Gallager  ---
> (In reply to jos...@codesourcery.com from comment #6)
> > Rather than piecemeal fixes with no evidence of completeness, I think we 
> > should disable the smarts around system header macro locations determining 
> > whether diagnostics appear (i.e., the system-header tests for disabling 
> > diagnostics should all use the expansion location), until we have a proper 
> > design for avoiding such issues and have systematically reviewed all 
> > diagnostics for conforming to such a design (if the design needs each 
> > diagnostic function call to be reviewed).
> 
> Coming up with a proper design might never happen though. I'd rather just have
> the piecemeal fixes in the meantime.

Any such piecemeal fixes should I think be starting from a basis where the 
warnings appear even if sometimes the real issue is in the header, and 
then are selectively disabled, rather than from a basis of selectively 
trying to enable warnings that are wrongly disabled because a system 
header macro is involved.

[Bug c/87794] New: Excessive alignment permitted for functions and labels

[pkoning at gcc dot gnu.org]

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

Bug ID: 87794
   Summary: Excessive alignment permitted for functions and labels
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44922&action=edit
variable and function alignment test case

Variable alignment is checked against MAX_OFILE_ALIGNMENT but function and
label (-falign-label=n) alignment is not.  This causes requests to the target
code to generate alignment directives that the output format doesn't support,
causing ICE at least in some targets.
The attached testalign.c gets an error (on i386) for variable "ag", and on
pdp11 also for variable "a4" (since max alignment on pdp11 is 2 bytes).  But
the corresponding function alignments do not generate error messages.  
File testalign2.c with -falign-labels=n also passes the requested alignment to
the back end without checking it against MAX_OFILE_ALIGNMENT.

[Bug c/87795] New: Excessive alignment permitted for functions and labels

[pkoning at gcc dot gnu.org]

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

Bug ID: 87795
   Summary: Excessive alignment permitted for functions and labels
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

Variable alignment is checked against MAX_OFILE_ALIGNMENT but function and
label (-falign-label=n) alignment is not.  This causes requests to the target
code to generate alignment directives that the output format doesn't support,
causing ICE at least in some targets.
The attached testalign.c gets an error (on i386) for variable "ag", and on
pdp11 also for variable "a4" (since max alignment on pdp11 is 2 bytes).  But
the corresponding function alignments do not generate error messages.  
File testalign2.c with -falign-labels=n also passes the requested alignment to
the back end without checking it against MAX_OFILE_ALIGNMENT.

[Bug c/87795] Excessive alignment permitted for functions and labels

[pkoning at gcc dot gnu.org]

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

--- Comment #1 from pkoning at gcc dot gnu.org ---
Created attachment 44923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44923&action=edit
variable and function alignment test case

[Bug c/87795] Excessive alignment permitted for functions and labels

[pkoning at gcc dot gnu.org]

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

--- Comment #2 from pkoning at gcc dot gnu.org ---
Created attachment 44924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44924&action=edit
label alignment test case

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
That sounds like a clang problem; without more information, anyway.

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
maybe something like:
diff --git a/gcc/d/dmd/globals.h b/gcc/d/dmd/globals.h
index 63caeb7b6b..1279ac394e 100644
--- a/gcc/d/dmd/globals.h
+++ b/gcc/d/dmd/globals.h
@@ -237,19 +237,14 @@ extern Global global;
 // Because int64_t and friends may be any integral type of the
 // correct size, we have to explicitly ask for the correct
 // integer type to get the correct mangling with ddmd
-#if __LP64__
+
 // Be careful not to care about sign when using dinteger_t
 // use this instead of integer_t to
 // avoid conflicts with system #include's
-typedef unsigned long dinteger_t;
+typedef __UINT64_TYPE__ dinteger_t;
 // Signed and unsigned variants
-typedef long sinteger_t;
-typedef unsigned long uinteger_t;
-#else
-typedef unsigned long long dinteger_t;
-typedef long long sinteger_t;
-typedef unsigned long long uinteger_t;
-#endif
+typedef __INT64_TYPE__ sinteger_t;
+typedef __UINT64_TYPE__ uinteger_t;

 typedef int8_t  d_int8;
 typedef uint8_t d_uns8;

[Bug c/87795] Excessive alignment permitted for functions and labels

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

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

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

[Bug c/87794] Excessive alignment permitted for functions and labels

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

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

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 87795 ***

[Bug fortran/85896] ICE in gfc_convert_constant(): Unexpected type

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---
(In reply to Thomas Koenig from comment #3)
> What is the expected output?  Does this declare a new variable "min"
> or "max", or should the result simply be 'c' (or 'b')?

As it makes not much sense (IMO) to "specialise" a generic intrinsic via
user provided declaration, it looks more like a type conflict / error.


But following example is accepted, character is not matching intrinsic sin :

$ cat z4.f90
program p
   character :: sin
   print *, sin(1.0)
end

$ gfortran-9-20181028 -Wall -Wextra -fcheck=all z4.f90
$ a.out
  0.841470957


On the other hand :

$ cat z5.f90
program p
   character :: sin = 'c'
   print *, sin(1.0)
end

$ gfortran-9-20181028 z5.f90
z5.f90:2:19:

2 |character :: sin = 'c'
  |   1
Error: Function 'sin' at (1) cannot have an initializer
z5.f90:2:19:

2 |character :: sin = 'c'
  |   1
Error: 'sin' at (1) is not a VALUE


$ cat z5b.f90
program p
   character :: sin
   print *, sin(1.0)
   sin = 'c'
   print *, sin
end

$ gfortran-9-20181028 z5b.f90
z5b.f90:4:6:

4 |sin = 'c'
  |  1
Error: 'sin' at (1) is not a variable
z5b.f90:5:15:

5 |print *, sin
  |   1
Error: Function 'sin' requires an argument list at (1)

[Bug fortran/85896] ICE in gfc_convert_constant(): Unexpected type

[gs...@t-online.de]

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

--- Comment #5 from G. Steinmetz  ---

Looking again at intrinsic "max" and a variant of z1/z2 :

$ cat z6.f90
program p
   character :: max
   print *, max(1.0, 2.0)
end

$ gfortran-9-20181028 z6.f90
f951: internal compiler error: gfc_convert_constant(): Unexpected type


$ cat z7.f90
program p
   character :: max = 'c'
   print *, max(1.0, 2.0)
end

$ gfortran-9-20181028 z7.f90
z7.f90:2:19:

2 |character :: max = 'c'
  |   1
Error: Function 'max' at (1) cannot have an initializer
z7.f90:2:19:

2 |character :: max = 'c'
  |   1
Error: 'max' at (1) is not a VALUE


$ cat z7b.f90
program p
   character :: max
   print *, max(1.0, 2.0)
   max = 'c'
   print *, max
end

$ gfortran-9-20181028 z7b.f90
z7b.f90:4:6:

4 |max = 'c'
  |  1
Error: 'max' at (1) is not a variable
z7b.f90:5:15:

5 |print *, max
  |   1
Error: Function 'max' requires an argument list at (1)


---

With a user-defined type instead of an intrinsic type this happens :


$ cat zm1.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t) :: max
   print *, max(1, 2)
end

$ gfortran-9-20181028 zm1.f90
f951: internal compiler error: gfc_convert_constant(): Unexpected type


$ cat zm2.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t) :: max(3)
   print *, max(1, 2)
end

$ gfortran-9-20181028 zm2.f90
zm2.f90:6:15:

6 |print *, max(1, 2)
  |   1
Error: Rank mismatch in array reference at (1) (2/1)


$ cat zm3.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t) :: max(3, 3)
   print *, max(1, 2)
end

$ gfortran-9-20181028 -Wall -Wextra -fcheck=all zm3.f90
$ a.out
 c


BTW, thanks for working on this issue.

[Bug fortran/87796] New: ICE in gfc_conv_string_parameter, at fortran/trans-expr.c:8926

[gs...@t-online.de]

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

Bug ID: 87796
   Summary: ICE in gfc_conv_string_parameter, at
fortran/trans-expr.c:8926
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Might be related to pr85896.


$ cat z1.f90
program p
   character :: num_images
   print *, num_images()
end


$ cat z2.f90
program p
   character :: num_images
   print *, num_images(1)
end


$ gfortran-9-20181028 -c z2.f90 -fcoarray=single
$
$ gfortran-9-20181028 -c z2.f90 -fcoarray=lib
z2.f90:3:0:

3 |print *, num_images(1)
  |
internal compiler error: in gfc_conv_string_parameter, at
fortran/trans-expr.c:8926
0x6ebba0 gfc_conv_string_parameter(gfc_se*)
../../gcc/fortran/trans-expr.c:8926
0x7198e7 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2584
0x6bea57 trans_code
../../gcc/fortran/trans.c:2038
0x7173de build_dt
../../gcc/fortran/trans-io.c:2026
0x6bea37 trans_code
../../gcc/fortran/trans.c:2010
0x6e6054 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6505
0x673696 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673696 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bb28f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/87796] ICE in gfc_conv_string_parameter, at fortran/trans-expr.c:8926

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

$ cat z3.f90
program p
   character :: num_images = 'c'
   print *, num_images(1)
end

$ gfortran-9-20181028 -c z3.f90 -fcoarray=single
z3.f90:2:26:

2 |character :: num_images = 'c'
  |  1
Error: Function 'num_images' at (1) cannot have an initializer
z3.f90:2:26:

2 |character :: num_images = 'c'
  |  1
Error: 'num_images' at (1) is not a VALUE


$ cat z4.f90
program p
   character :: num_images
   print *, num_images()
   num_images = 'c'
   print *, num_images
end

$ gfortran-9-20181028 -c z4.f90 -fcoarray=single
z4.f90:4:13:

4 |num_images = 'c'
  | 1
Error: 'num_images' at (1) is not a variable
z4.f90:5:22:

5 |print *, num_images
  |  1
Error: Function 'num_images' requires an argument list at (1)

[Bug fortran/87797] New: Enhancement: Warning for potential name clash of variables/intrinsics...

[gs...@t-online.de]

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

Bug ID: 87797
   Summary: Enhancement: Warning for potential name clash of
variables/intrinsics...
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Regarding pr85896 and other issues, an additional Warning -Wxyz=key
(names "xyz" and "key" tbd) might be helpful :

Variant 1 (argument key1) :
  Warn if a _user_defined_ parameter/variable/array/type
  is named like an _intrinsic_ function/subroutine/type/module
  from a dedicated official standard (e.g. -std=f2008).
  See e.g. table of intrinsics in F2008 13.5, 13.6.

Variant 2 (argument key2) :
  Warn if a _user_defined_ function/subroutine/interface/module
  is named like an _intrinsic_ function/subroutine/type/module
  from a dedicated official standard (e.g. -std=f2008).

Knowing that gfortran can _not_ do the job of a static analyzer,
specifically for global analysis, it could mark "suspicious" code
this way. Just an idea.



Additionally :

Variant 3 (argument key3) :
  Warn if a _user_defined_ parameter/variable/array/type
  is named like an official statement name (like "stop").

Variant 4 (argument key4) :
  Warn if a _user_defined_ function/subroutine/interface/module
  is named like an official statement name.

Variant 5 (argument key5) :
  Warn if a _user_defined_ parameter/variable/array/type
  is named like an _user_defined_ function/subroutine/type/module,
  regarding sources in scope/progress.



Example :

$ cat z1.f90
module program
   integer :: function, sin, trim
   type public
  character :: max, else(1)
   end type
end
program end
   use program, len => trim
   real :: select, read(2)
contains
   function module (sin)
  character :: sin, stop
   end
end

[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
(In reply to Alexander Monakov from comment #4)
> It seems a bit strange to do full-blown constexpr evaluation for warnings,
> especially if normal compilation flow wouldn't perform the same evaluation.

If the warning might depend on a constant value, we try to come up with a
constant value for it.

[Bug c/87795] Excessive alignment permitted for functions and labels

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #4 from Joel Sherrill  ---
I added myself as a CC because I want to see if these become errors or
warnings. For core parts of RTEMS, I can see wanting these to be errors since
it indicates we did something in core OS code that did not achieve the desired
results. But in application code, it might not be as well considered or
necessary.

So ultimately, it's a hard decision on how to treat mistakes in alignment
requests

[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[paul at scruby dot com]

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

--- Comment #7 from Paul Scruby  ---
Feel free to close this ticket.

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59472
>
> --- Comment #6 from Eric Gallager  ---
> (In reply to Paul Scruby from comment #5)
>> Is there a patch to fix or suppress the warnings when link-time
>> optimizing
>> to libstdc++.a ?  I'm using gcc4.8.2, but I'm happy to upgrade to gcc4.9
>> if
>> this release is more likely to get fixed first?
>
> Well both those branches are closed now; could you upgrade to something
> more
> recent instead?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug middle-end/87798] New: EH lowering is creating a gimple_switch statement with type-incompatible index and case labels

[amacleod at redhat dot com]

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

Bug ID: 87798
   Summary: EH lowering is creating a gimple_switch statement with
type-incompatible index and case labels
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amacleod at redhat dot com
  Target Milestone: ---

Created attachment 44925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44925&action=edit
patch to check for the error condition and trigger a bootstrap failure

This shows up during bootstrap when building the ADA compiler

configuration is x86_64-pc-linux-gnu  with  
--enable-languages=all,ada,go,obj-c++,jit --enable-host-shared

from  https://gcc.gnu.org/ml/gcc/2018-10/msg00248.html :

I am doing some switch analysis and an triggering a failure in ADA when the
gimple_switch_index() is a signed 64 bit value and the case labels are only 32
bit integers.  I would have expected that these needed to be the same
precision?   I don't seem to get this failure anywhere else.

(gdb) p print_gimple_stmt (stderr, sw, 0, 0)

switch (_22)  [67.00%], case 1:  [33.00%]>


(gdb) p gimple_switch_index (sw)
$16 = (tree_node *) 0x7fffee3593f0
(gdb) p print_generic_expr (stderr, $16, 0)
_22
(gdb) p print_generic_expr (stderr, $16->typed.type, 0)
SIGNED_64   << signed 64 bit
index

low is the value of CASE_LOW()

(gdb) p print_generic_expr (stderr, low, 0)
1
(gdb) p low->typed.type
$19 = (tree) 0x7fffefacf5e8
(gdb) p print_generic_expr (stderr, $19, 0)
integer
(gdb) p low->typed.type->type_common.precision
$22 = 32 <<< 32 bit case label
(gdb) p type->type_common.precision
$23 = 64

(gdb) p useless_type_conversion_p ($16->typed.type, $19)
$24 = false
(gdb) p useless_type_conversion_p ($19, $16->typed.type)
$25 = false
(gdb) p types_compatible_p ($19, $16->typed.type)
$26 = false
(gdb) p types_compatible_p ($16->typed.type, $19)
$27 = false

These should at least be type_compatible_p should they not?


The attached patch adds a checking assert in gimple_build_switch() which
verifies that the type of the index and the case labels are compatible.

When added, bootstrap fails here:

/gcc/range2/build/./gcc/xgcc -B/gcc/range2/build/./gcc/
-B/gcc/range2/install/x86_64-pc-linux-gnu/bin/
-B/gcc/range2/install/x86_64-pc-linux-gnu/lib/ -isystem
/gcc/range2/install/x86_64-pc-linux-gnu/include -isystem
/gcc/range2/install/x86_64-pc-linux-gnu/sys-include -c -g -O2 -fpic -W -Wall
-gnatpg -nostdinc a-calcon.adb -o a-calcon.o -wrapper gdb,--args

Breakpoint 1, fancy_abort (file=0x26ba508 "/gcc/range2/gcc/gcc/gimple.c",
line=803, 
function=0x26bb550 )::__FUNCTION__> "gimple_build_switch") at
/gcc/range2/gcc/gcc/diagnostic.c:1560
1560  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
Missing separate debuginfos, use: dnf debuginfo-install gmp-6.1.1-1.fc25.x86_64
libgcc-6.4.1-1.fc25.x86_64 libmpc-1.0.2-5.fc24.x86_64
libstdc++-6.4.1-1.fc25.x86_64 mpfr-3.1.5-1.fc25.x86_64
(gdb) where
#0  fancy_abort (file=0x26ba508 "/gcc/range2/gcc/gcc/gimple.c", line=803, 
function=0x26bb550 )::__FUNCTION__> "gimple_build_switch") at
/gcc/range2/gcc/gcc/diagnostic.c:1560
#1  0x011273e4 in gimple_build_switch (index=0x7fffef75f4c8,
default_label=, args=...) at /gcc/range2/gcc/gcc/gimple.c:803
#2  0x0167f8ce in lower_eh_dispatch (src=0x7fffef74e478,
stmt=0x7fffef747870) at /gcc/range2/gcc/gcc/tree-eh.c:3775
#3  0x0167fcc4 in (anonymous
namespace)::pass_lower_eh_dispatch::execute (this=0x3971d30,
fun=0x7fffef72a580) at /gcc/range2/gcc/gcc/tree-eh.c:3859
#4  0x014464df in execute_one_pass (pass=0x3971d30) at
/gcc/range2/gcc/gcc/passes.c:2446
#5  0x01446884 in execute_pass_list_1 (pass=0x3971d30) at
/gcc/range2/gcc/gcc/passes.c:2535
#6  0x01446914 in execute_pass_list (fn=0x7fffef72a580, pass=0x3971cd0)
at /gcc/range2/gcc/gcc/passes.c:2546
#7  0x00f0e3ad in cgraph_node::expand (this=0x7fffefabcc60) at
/gcc/range2/gcc/gcc/cgraphunit.c:2121
#8  0x00f0ea4c in expand_all_functions () at
/gcc/range2/gcc/gcc/cgraphunit.c:2259
#9  0x00f0f73d in symbol_table::compile (this=0x7fffefabd100) at
/gcc/range2/gcc/gcc/cgraphunit.c:2610
#10 0x00f0fbd8 in symbol_table::finalize_compilation_unit
(this=0x7fffefabd100) at /gcc/range2/gcc/gcc/cgraphunit.c:2788
#11 0x015da4cc in compile_file () at /gcc/range2/gcc/gcc/toplev.c:480
#12 0x015dda0f in do_compile () at /gcc/range2/gcc/gcc/toplev.c:2170


It looks like there are labels for a switch which are subsumed for a try_catch
when lowering:  (from lower_eh_dispatch::tree-eh.c)

/* Don't generate a switch if there's only a default case.
   This is common in the form of try { A; } catch (...) { B; }.  */
if (!labels.exists ())
  {
  

[Bug d/87799] New: failure during bootstrap, fails to build d/filename.o

[rai...@emrich-ebersheim.de]

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

Bug ID: 87799
   Summary: failure during bootstrap, fails to build d/filename.o
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/./prev-gcc/xg++
-B/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/./prev-gcc/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0-test/x86_64-w64-mingw32/bin/
-nostdinc++
-B/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-B/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs

-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32

-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/include
 -I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/libstdc++-v3/libsupc++
-L/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -D__USE_MINGW_ACCESS
-Wno-pedantic-ms-format -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -I. -Id
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../include
-I./../intl
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libcpp/include
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include 
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libdecnumber/bid
-I../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libbacktrace
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include  -o d/filename.o -MT
d/filename.o -MMD -MP -MF d/.deps/filename.TPo
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd
-Id
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:
In static member function 'static int FileName::exists(const char*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:563:12:
warning: comparison of integer expressions of different signedness: 'DWORD'
{aka 'long unsigned int'} and 'long int' [-Wsign-compare]
  563 | if (dw == -1L)
  | ~~~^~
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:
In static member function 'static bool FileName::ensurePathExists(const
char*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:589:51:
error: invalid const_cast from type 'const char*' to type 'void*'
  589 | {   mem.xfree(const_cast(p));
  |   ^
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:
In static member function 'static const char* FileName::name(const char*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:280:34:
warning: this statement may fall through [-Wimplicit-fallthrough=]
  280 | if (e == str + 1 || e == str + len - 1)
  | ~^
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:283:13:
note: here
  283 | default:
  | ^~~
make[3]: ***
[../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/Make-lang.in:315:
d/filename.o] Error 1

[Bug c++/87594] constexpr rejects-valid code with range-based for-loop

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Oct 29 19:40:18 2018
New Revision: 265600

URL: https://gcc.gnu.org/viewcvs?rev=265600&root=gcc&view=rev
Log:
PR c++/87594 - constexpr rejects-valid with range-based for.
* constexpr.c (potential_constant_expression_1): If the condition
can't be evaluated, return true.

* g++.dg/cpp1y/constexpr-loop8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-loop8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87594] constexpr rejects-valid code with range-based for-loop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
that gets us to a fail because of an ELF-specific section directive in atomic.d

 .section minfo

It looks like there's an OS_X-specific sections file there - but ISTM that the
configuration expansion of :

DRUNTIME_OS_MINFO_BRACKETING

doesn't have a Darwin version .. maybe there's code you can borrow from
elsewhere - I've not gone looking yet.

[Bug tree-optimization/87800] New: [9 Regression] CPU2006 416.gamess failed to build with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 87800
   Summary: [9 Regression] CPU2006 416.gamess failed to build with
LTO
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64, r265457 caused:

gfortran  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64aldeci.fppized.o algnci.fppized.o
basecp.fppized.o basext.o bashuz.o bashz2.o basn21.fppized.o basn31.o
bassto.fppized.o blas.fppized.o ccaux.o ccsdt.fppized.o chgpen.fppized.o
cisgrd.fppized.o cosmo.fppized.o cphf.fppized.o cpmchf.o cprohf.fppized.o
ddi.fppized.o delocl.fppized.o dft.fppized.o dftaux.fppized.o dftexc.fppized.o
dftfun.o dftgrd.fppized.o dftint.fppized.o dgeev.o dmulti.fppized.o
drc.fppized.o dummygetenv.fppized.o ecp.fppized.o ecpder.fppized.o
ecplib.fppized.o ecppot.o efdrvr.fppized.o efelec.o efgrd2.fppized.o
efgrda.fppized.o efgrdb.fppized.o efgrdc.fppized.o efinp.fppized.o
efinta.fppized.o efintb.fppized.o efpaul.fppized.o efpcm.fppized.o
efpcov.fppized.o eigen.fppized.o eomcc.fppized.o ffield.fppized.o
frfmt.fppized.o fsodci.fppized.o gamess.fppized.o globop.fppized.o
gradex.fppized.o grd1.fppized.o grd2a.fppized.o grd2b.o grd2c.fppized.o
guess.fppized.o gugdga.fppized.o gugdgb.fppized.o gugdm.fppized.o
gugdm2.fppized.o gugdrt.fppized.o gugem.fppized.o gugsrt.fppized.o
gvb.fppized.o hess.fppized.o hss1a.fppized.o hss1b.fppized.o hss2a.fppized.o
hss2b.fppized.o inputa.fppized.o inputb.fppized.o inputc.fppized.o
int1.fppized.o int2a.fppized.o int2b.o iolib.fppized.o lagran.fppized.o
local.fppized.o loccd.fppized.o locpol.fppized.o mccas.fppized.o mcjac.o
mcpinp.fppized.o mcpint.fppized.o mcplib.o mcqdpt.fppized.o mcqdwt.o
mcqud.fppized.o mcscf.fppized.o mctwo.fppized.o morokm.fppized.o mp2.fppized.o
mp2ddi.fppized.o mp2grd.fppized.o mpcdat.o mpcgrd.fppized.o mpcint.fppized.o
mpcmol.fppized.o mpcmsc.fppized.o mthlib.fppized.o nameio.fppized.o
nmr.fppized.o olix.o ordint.fppized.o ormas1.fppized.o parley.fppized.o
pcm.fppized.o pcmcav.o pcmcv2.fppized.o pcmder.fppized.o pcmdis.fppized.o
pcmief.fppized.o pcmpol.fppized.o pcmvch.fppized.o prpel.fppized.o
prplib.fppized.o prppop.fppized.o qeigen.fppized.o qfmm.fppized.o
qmfm.fppized.o qmmm.fppized.o qrel.fppized.o raman.fppized.o rhfuhf.fppized.o
rxncrd.fppized.o ryspol.o scflib.fppized.o scfmi.fppized.o scrf.fppized.o
sobrt.fppized.o soffac.fppized.o solib.fppized.o sozeff.fppized.o
statpt.fppized.o surf.fppized.o symorb.fppized.o symslc.fppized.o
tdhf.fppized.o trans.fppized.o trfdm2.fppized.o trnstn.fppized.o
trudge.fppized.o umpddi.fppized.o unport.fppized.o vibanl.fppized.o
vscf.fppized.o zheev.fppized.o zmatrx.fppized.o -lm-o games
...
during GIMPLE pass: vect
grd2b.f: In function 'grdper.constprop':
grd2b.f:953: internal compiler error: in vect_build_slp_tree_2, at
tree-vect-slp.c:1128
0x6a9a06 vect_build_slp_tree_2
../../src-trunk/gcc/tree-vect-slp.c:1128
0xe3306c vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:1057
0xe33ffd vect_build_slp_tree_2
../../src-trunk/gcc/tree-vect-slp.c:1208
0xe3306c vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:1057
0xe39578 vect_analyze_slp_instance
../../src-trunk/gcc/tree-vect-slp.c:1940
0xe3aab0 vect_analyze_slp(vec_info*, unsigned int)
../../src-trunk/gcc/tree-vect-slp.c:2139
0xe23e76 vect_analyze_loop_2
../../src-trunk/gcc/tree-vect-loop.c:1881
0xe264e1 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
../../src-trunk/gcc/tree-vect-loop.c:2268
0xe3f98f try_vectorize_loop_1
../../src-trunk/gcc/tree-vectorizer.c:873
0xe40739 vectorize_loops()
../../src-trunk/gcc/tree-vectorizer.c:1097
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccA17T4q.mk:11: /tmp/gamess.EoWxwj.ltrans3.ltrans.o] Error 1

[Bug tree-optimization/87801] New: [9 Regression] CPU2006 454.calculix failed to build with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 87801
   Summary: [9 Regression] CPU2006 454.calculix failed to build
with LTO
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64, r265522 caused:

gfortran  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64CalculiX.o add_pr.o add_sm_ei.o
add_sm_st.o allocation.o amplitudes.o anisotropic.o beamsections.o bounadd.o
boundaries.o buckles.o calinput.o cfluxes.o changedepterm.o cloads.o
conductivities.o controlss.o couptempdisps.o creeps.o cychards.o cycsymmods.o
dasol.o datest.o datri.o defplasticities.o defplas.o densities.o depvars.o
deuldlag.o dfluxes.o dgesv.o diamtr.o dloads.o dot.o dredu.o dsort.o dynamics.o
dynsolv.o el.o elastics.o elements.o elprints.o envtemp.o equations.o
expansions.o extrapolate.o e_c3d.o e_c3d_th.o e_c3d_rhs.o fcrit.o films.o
finpro.o forcadd.o frd.fppized.o frdclose.o frequencies.o fsub.o fsuper.o
gen3delem.o genran.o getnewline.o graph.o headings.o heattransfers.o hyperel.o
hyperelastics.o hyperfoams.o ident.o ident2.o include.o incplas.o
initialconditions.o inputerror.o isorti.o isortid.o isortidc.o isortii.o
isortiid.o label.o linel.o lintemp.o lintemp_th.o loadadd.o loadaddt.o
mafillpr.o mafillsm.o mafillsmcs.o massflowrates.o matdata_co.o matdata_he.o
matdata_tg.o materialdata.o materials.o modaldampings.o modaldynamics.o mpcs.o
nident.o nident2.o near2d.o noanalysis.o nodalthicknesses.o nodeprints.o
nodes.o noelfiles.o noelsets.o nonlinmpc.o normals.o norshell.o number.o onf.o
op.o openfile.o orientations.o orthonl.o orthotropic.o out.o parser.o
physicalconstants.o planempc.o plastics.o plcopy.o plinterpol.o plmix.o
polynom.o profil.o radflowload.o radiates.o ranewr.o rearrange.o rectcyl.o
renumber.o restartread.o restarts.o restartshort.o restartwrite.o results.o
rhs.o rigidbodies.o rigidmpc.o rootls.o rubber.o saxpb.o selcycsymmods.o
shape3tri.o shape4q.o shape4tet.o shape6tri.o shape6w.o shape8h.o shape8q.o
shape10tet.o shape15w.o shape20h.o shellsections.o skip.o solidsections.o
spcmatch.o specificheats.o statics.o steps.o stiff2mat.o stop.o str2mat.o
straightmpc.o surfaces.o temperatures.o tempload.o ties.o transformatrix.o
transforms.o ucreep.o uhardening.o umat.o umat_aniso_creep.o umat_aniso_plas.o
umat_elastic_fiber.o umat_ideal_gas.o umat_lin_iso_el.o umat_single_crystal.o
umat_tension_only.o umat_user.o umpc_mean_rot.o umpc_user.o usermaterials.o
usermpc.o viscos.o wcoef.o writebv.o writeev.o writeevcs.o writempc.o
writesummary.o cascade.o frdcyc.o insert.o mastruct.o mastructcs.o nonlingeo.o
pcgsolver.o preiter.o prespooles.o profile.o remastruct.o spooles.o strcmp1.o
strcpy1.o u_calloc.o SPOOLES/A2/src/A2_IO.o SPOOLES/A2/src/A2_basics.o
SPOOLES/A2/src/A2_init.o SPOOLES/A2/src/A2_instance.o SPOOLES/A2/src/A2_norms.o
SPOOLES/A2/src/A2_sort.o SPOOLES/A2/src/A2_util.o SPOOLES/BKL/src/BKL_basics.o
SPOOLES/BKL/src/BKL_evalfcn.o SPOOLES/BKL/src/BKL_exhSearch.o
SPOOLES/BKL/src/BKL_fidmat.o SPOOLES/BKL/src/BKL_init.o
SPOOLES/BKL/src/BKL_util.o SPOOLES/BPG/src/BPG_IO.o
SPOOLES/BPG/src/BPG_basics.o SPOOLES/BPG/src/BPG_init.o
SPOOLES/BPG/src/BPG_makeGraphs.o SPOOLES/BPG/src/BPG_pseudo.o
SPOOLES/Chv/src/Chv_IO.o SPOOLES/Chv/src/Chv_assemble.o
SPOOLES/Chv/src/Chv_basics.o SPOOLES/Chv/src/Chv_copy.o
SPOOLES/Chv/src/Chv_factor.o SPOOLES/Chv/src/Chv_findPivot.o
SPOOLES/Chv/src/Chv_init.o SPOOLES/Chv/src/Chv_instance.o
SPOOLES/Chv/src/Chv_search.o SPOOLES/Chv/src/Chv_swap.o
SPOOLES/Chv/src/Chv_update.o SPOOLES/Chv/src/Chv_util.o
SPOOLES/ChvList/src/ChvList_basics.o SPOOLES/ChvList/src/ChvList_init.o
SPOOLES/ChvList/src/ChvList_util.o SPOOLES/ChvManager/src/ChvManager_basics.o
SPOOLES/ChvManager/src/ChvManager_init.o
SPOOLES/ChvManager/src/ChvManager_util.o SPOOLES/DSTree/src/DSTree_basics.o
SPOOLES/DSTree/src/DSTree_init.o SPOOLES/DSTree/src/DSTree_instance.o
SPOOLES/DSTree/src/DSTree_stages.o SPOOLES/DSTree/src/DSTree_util.o
SPOOLES/DV/src/DV_IO.o SPOOLES/DV/src/DV_basics.o SPOOLES/DV/src/DV_init.o
SPOOLES/DV/src/DV_instance.o SPOOLES/DV/src/DV_util.o
SPOOLES/DenseMtx/src/DenseMtx_IO.o SPOOLES/DenseMtx/src/DenseMtx_basics.o
SPOOLES/DenseMtx/src/DenseMtx_init.o SPOOLES/DenseMtx/src/DenseMtx_instance.o
SPOOLES/DenseMtx/src/DenseMtx_permute.o SPOOLES/DenseMtx/src/DenseMtx_util.o
SPOOLES/Drand/src/Drand_basics.o SPOOLES/Drand/src/Drand_init.o
SPOOLES/Drand/src/Drand_util.o SPOOLES/ETree/src/ETree_IO.o
SPOOLES/ETree/src/ETree_basics.o SPOOLES/ETree/src/ETree_compress.o
SPOOLES/ETree/src/ETree_init.o SPOOLES/ETree/src/ETree_instance.o
SPOOLES/ETree/src/ETree_permute.o SPOOLES/ETree/src/ETree_transform.o
SPOOLES/ETree/src/ETree_util.o SPOOLE

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to Kai Tietz from comment #16)
> > If you want to experiment, try the following patch:
> > 
> > Index: config/i386/mingw32.h
> > ===
> > --- config/i386/mingw32.h   (revision 265582)
> > +++ config/i386/mingw32.h   (working copy)
> > @@ -251,6 +251,10 @@
> >  #undef  CHECK_EXECUTE_STACK_ENABLED
> >  #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
> >  
> > +#undef PREFERRED_STACK_BOUNDARY_DEFAULT
> > +#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
> > +  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
> > +
> >  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
> >  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
> >  #if DWARF2_UNWIND_INFO> 
> > But I don't know the details of MS ABI, so I can't tell if the patch is
> > correct.
> 
> The x64 ABI part is correct, as for x64 abit there is just 16-byte stack
> alignment. For x86 ms abi things aren't that strict AFAIK. The common stack
> alignment on function entry is the natural one, but there is in general no
> strict requirement for it. So the patch looks fine, but should be commented
> in the release notes, as there might be fallout seen caused by it.

Unfortunately, I have no way of testing the patch on windows targets.

Please also note that the testcase still ICEs with patched compiler when
-mpreferred-stack-bonudary=4 option is used. Based on the comments in
emit-rtl.h:

  /* The largest alignment needed on the stack, including requirement
 for outgoing stack alignment.  */
  unsigned int stack_alignment_needed;

  /* Preferred alignment of the end of stack frame, which is preferred
 to call other functions.  */
  unsigned int preferred_stack_boundary;

it looks that somewhere stack_alignment_needed should be set to at least the
value of preferred_stack_boundary. Just above the assert in i386.c, there is:

  /* 64-bit MS ABI seem to require stack alignment to be always 16,
 except for function prologues, leaf functions and when the defult
 incoming stack boundary is overriden at command line or via
 force_align_arg_pointer attribute.  */
  if ((TARGET_64BIT_MS_ABI && crtl->preferred_stack_boundary < 128)
  && (!crtl->is_leaf || cfun->calls_alloca != 0
  || ix86_current_function_calls_tls_descriptor
  || ix86_incoming_stack_boundary < 128))
{
  crtl->preferred_stack_boundary = 128;
  crtl->stack_alignment_needed = 128;
}

so this maybe hints what to do in x86 case. Perhaps the patch in Comment #8 is
the way to go.

[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I think it's worth keeping open for my suggestion in comment 3 (which I'd
forgotten about).

[Bug other/87802] New: [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522

[seurer at gcc dot gnu.org]

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

Bug ID: 87802
   Summary: [9 regression] g++.dg/vect/slp-pr87105.cc fails
starting with r265522
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing this just on power 6 and 7 BE.


testgcc: Tried 265522
  testgcc: make -k check-gcc RUNTESTFLAGS=vect.exp=g++.dg/vect/slp-pr87105.cc


FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++14  scan-tree-dump-times slp2 "basic
block part vectorized" 1
FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++14  scan-tree-dump slp2
"vect_iftmp[^\rm]* = MIN"
FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++17  scan-tree-dump-times slp2 "basic
block part vectorized" 1
FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++17  scan-tree-dump slp2
"vect_iftmp[^\rm]* = MIN"

[Bug web/87803] New: GCC 6.5.0 release directory is misnamed

[ats-gccbugs at offog dot org]

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

Bug ID: 87803
   Summary: GCC 6.5.0 release directory is misnamed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ats-gccbugs at offog dot org
  Target Milestone: ---

I'm not sure this really counts as a bug in GCC as such, but...

Within ftp://ftp.gnu.org/gnu/gcc/, the subdirectory for each release is usually
named gcc-X.Y.Z - however, the subdirectory for GCC 6.5.0 is just called 6.5.0,
rather than gcc-6.5.0.

I spotted this because I have a packaging tool that scans for new releases, and
it wasn't picking up 6.5.0 because it didn't follow the usual pattern. I think
it'd be a good idea to rename the directory to match the others (but keep a
symlink called 6.5.0 in case anyone's already changed their packaging).

[Bug middle-end/87041] [8/9 Regression] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01860.html

[Bug c++/87469] [9 Regression] ice in record_estimate, at tree-ssa-loop-niter.c:3271

[kugan at gcc dot gnu.org]

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

--- Comment #5 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Oct 29 22:02:45 2018
New Revision: 265605

URL: https://gcc.gnu.org/viewcvs?rev=265605&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2018-10-29  Kugan Vivekanandarajah  

PR middle-end/87469
* g++.dg/pr87469.C: New test.

gcc/ChangeLog:

2018-10-29  Kugan Vivekanandarajah  

PR middle-end/87469
* tree-ssa-loop-niter.c (number_of_iterations_popcount): Fix niter
max value.



Added:
trunk/gcc/testsuite/g++.dg/pr87469.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c