[Bug debug/84637] New: gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself

[marxin at gcc dot gnu.org]

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

Bug ID: 84637
   Summary: gcc/dbxout.c:684:14: runtime error: negation of
-9223372036854775808 cannot be represented in type
'long int'; cast to an unsigned type to negate this
value to itself
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

UBSAN boostrap compiler sees:

$  UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. 
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/debug/trivial.c -c -gstabs
-fno-diagnostics-show-caret -fdiagnostics-color=never -gstabs -S -o trivial.S
../../gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808
cannot be represented in type 'long int'; cast to an unsigned type to negate
this value to itself
#0 0xd673a5 in stabstr_D ../../gcc/dbxout.c:684
#1 0xd73400 in dbxout_range_type ../../gcc/dbxout.c:1745
#2 0xd6eba8 in dbxout_type ../../gcc/dbxout.c:2042
#3 0xd75c43 in dbxout_symbol(tree_node*, int) ../../gcc/dbxout.c:2865
#4 0xd783b2 in dbxout_init ../../gcc/dbxout.c:1079
#5 0x74faa0 in lang_dependent_init ../../gcc/toplev.c:1920
#6 0x74faa0 in do_compile ../../gcc/toplev.c:2118
#7 0x74faa0 in toplev::main(int, char**) ../../gcc/toplev.c:2267
#8 0x751cba in main ../../gcc/main.c:39
#9 0x7fb2075a06e4 in __libc_start_main (/lib64/libc.so.6+0x206e4)
#10 0x751de8 in _start
(/home/marxin/Programming/gcc/objdir/gcc/cc1+0x751de8)

[Bug c++/84636] New: internal compiler error: Segmentation fault (identifier_p()/grokdeclarator())

[vegard.nossum at gmail dot com]

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

Bug ID: 84636
   Summary: internal compiler error: Segmentation fault
(identifier_p()/grokdeclarator())
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

typedef void a();
struct {
  a: 1;
};

Output:

$ xgcc -x c++ -S -
:3:6: internal compiler error: Segmentation fault
0x3150de9 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0xc0c2f1 identifier_p(tree_node*)
/home/vegard/git/gcc/gcc/cp/cp-tree.h:573
0xc0c2f1 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/vegard/git/gcc/gcc/cp/decl.c:11934
0xc47de0 grokbitfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/decl2.c:1038
0xfe10e5 cp_parser_member_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:23730
0xf160fb cp_parser_member_specification_opt
/home/vegard/git/gcc/gcc/cp/parser.c:23363
0xf160fb cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22505
0xf2501b cp_parser_class_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:22757
0xf2501b cp_parser_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16763
0xf8aa5a cp_parser_decl_specifier_seq
/home/vegard/git/gcc/gcc/cp/parser.c:13625
0xfa6620 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12934
0xfae548 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12879
0x1001295 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12776
0xff826b cp_parser_declaration_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:12652
0xff9893 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4559
0xff9893 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38880
0x15a51f5 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132

$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)

Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).

Seems like versions all the way back to 4.4.7 (the oldest gcc on godbolt.org)
segfault. I haven't tested older compilers.

Test case was reduced by C-Reduce.

[Bug rtl-optimization/84635] New: gcc/regrename.c:1706:64: runtime error: index -1 out of bounds for type 'machine_mode [30]'

[marxin at gcc dot gnu.org]

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

Bug ID: 84635
   Summary: gcc/regrename.c:1706:64: runtime error: index -1 out
of bounds for type 'machine_mode [30]'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following test-case:

$ cat error.i
a () { a (); }

$ UBSAN_OPTIONS="print_stacktrace=1" /dev/shm/objdir/gcc/xgcc -B
/dev/shm/objdir/gcc/ -O1 -funroll-loops -c error.i -fmax-errors=1
error.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 a () { a (); }
 ^
/home/marxin/Programming/gcc2/gcc/regrename.c:1706:64: runtime error: index -1
out of bounds for type 'machine_mode [30]'
#0 0x169bea1 in build_def_use
/home/marxin/Programming/gcc2/gcc/regrename.c:1706
#1 0x1694d2f in regrename_analyze(bitmap_head*)
/home/marxin/Programming/gcc2/gcc/regrename.c:742
#2 0x169dace in regrename_optimize
/home/marxin/Programming/gcc2/gcc/regrename.c:1934
#3 0x169dbc6 in execute /home/marxin/Programming/gcc2/gcc/regrename.c:1971
#4 0x1598c61 in execute_one_pass(opt_pass*)
/home/marxin/Programming/gcc2/gcc/passes.c:2497
#5 0x159942b in execute_pass_list_1
/home/marxin/Programming/gcc2/gcc/passes.c:2586
#6 0x15994a2 in execute_pass_list_1
/home/marxin/Programming/gcc2/gcc/passes.c:2587
#7 0x15994a2 in execute_pass_list_1
/home/marxin/Programming/gcc2/gcc/passes.c:2587
#8 0x1599522 in execute_pass_list(function*, opt_pass*)
/home/marxin/Programming/gcc2/gcc/passes.c:2597
#9 0xc40833 in cgraph_node::expand()
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:2139
#10 0xc41740 in expand_all_functions
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:2275
#11 0xc430b8 in symbol_table::compile()
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:2624
#12 0xc43639 in symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:2717
#13 0x18a7f43 in compile_file
/home/marxin/Programming/gcc2/gcc/toplev.c:480
#14 0x18abd24 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2132
#15 0x18ac208 in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2267
#16 0x31e0f41 in main /home/marxin/Programming/gcc2/gcc/main.c:39
#17 0x75cfbf49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#18 0x81e9d9 in _start (/dev/shm/objdir/gcc/cc1+0x81e9d9)

[Bug tree-optimization/84634] [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/84634] New: [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info

[marxin at gcc dot gnu.org]

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

Bug ID: 84634
   Summary: [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime
error: member access within null pointer of type
'struct _loop_vec_info
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: richard.sandiford at linaro dot org
  Target Milestone: ---

Started probable since Richard's r256625:

$ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20020129-1.c
-O3
../../gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null
pointer of type 'struct _loop_vec_info'
#0 0x2b6462b in vectorizable_store ../../gcc/tree-vect-stmts.c:6786
#1 0x2ba7d19 in vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*) ../../gcc/tree-vect-stmts.c:9482
#2 0x2c91d42 in vect_schedule_slp_instance ../../gcc/tree-vect-slp.c:4187
#3 0x2c98669 in vect_schedule_slp(vec_info*) ../../gcc/tree-vect-slp.c:4256
#4 0x2cabcad in vect_slp_bb(basic_block_def*)
../../gcc/tree-vect-slp.c:3250
#5 0x2cba557 in execute ../../gcc/tree-vectorizer.c:978
#6 0x1b8f0ac in execute_one_pass(opt_pass*) ../../gcc/passes.c:2497
#7 0x1b92bc7 in execute_pass_list_1 ../../gcc/passes.c:2586
#8 0x1b92c0e in execute_pass_list_1 ../../gcc/passes.c:2587
#9 0x1b92c0e in execute_pass_list_1 ../../gcc/passes.c:2587
#10 0x1b92ce8 in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2597
#11 0xce8eba in cgraph_node::expand() ../../gcc/cgraphunit.c:2139
#12 0xcee454 in expand_all_functions ../../gcc/cgraphunit.c:2275
#13 0xcee454 in symbol_table::compile() ../../gcc/cgraphunit.c:2624
#14 0xcf89c6 in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2717
#15 0x208763c in compile_file ../../gcc/toplev.c:480
#16 0x74ee29 in do_compile ../../gcc/toplev.c:2132
#17 0x74ee29 in toplev::main(int, char**) ../../gcc/toplev.c:2267
#18 0x751cba in main ../../gcc/main.c:39
#19 0x7fa721d2b6e4 in __libc_start_main (/lib64/libc.so.6+0x206e4)
#20 0x751de8 in _start
(/home/marxin/Programming/gcc/objdir/gcc/cc1+0x751de8)

Can be easily triggered with:

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index a98e0e5e259..db14c8063c4 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -6783,6 +6783,7 @@ vectorizable_store (gimple *stmt, gimple_stmt_iterator
*gsi, gimple **vec_stmt,

   prev_stmt_info = NULL;
   tree vec_mask = NULL_TREE;
+  gcc_assert (loop_vinfo);
   vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
   for (j = 0; j < ncopies; j++)
 {

[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

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

--- Comment #2 from Jay  ---
Err oops let me look again. Failure must be something else then.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
deprecated
deprecated (msg)
The deprecated attribute results in a warning if the function is used anywhere
in the source file. This is useful when identifying functions that are expected
to be removed in a future version of a program. The warning also includes the
location of the declaration of the deprecated function, to enable users to
easily find further information about why the function is deprecated, or what
they should do instead. Note that the warnings only occurs for uses:

int old_fn () __attribute__ ((deprecated));
int old_fn ();
int (*fn_ptr)() = old_fn;
results in a warning on line 3 but not line 2. The optional msg argument, which
must be a string, is printed in the warning if present.

The deprecated attribute can also be used for variables and types (see Variable
Attributes, see Type Attributes.)

[Bug c++/84633] New: internal compiler error: in lvalue_kind, at cp/tree.c:206

[vegard.nossum at gmail dot com]

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

Bug ID: 84633
   Summary: internal compiler error: in lvalue_kind, at
cp/tree.c:206
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

a (void[sizeof(0 = auto)]);

Output:

$ xgcc -x c++ -S -fpermissive -
:1:20: error: expected primary-expression before 'auto'
:1:19: error: expected ')' before 'auto'
:1:26: internal compiler error: in lvalue_kind, at cp/tree.c:206
0x132aa6f lvalue_kind(tree_node const*)
/home/vegard/git/gcc/gcc/cp/tree.c:206
0x132b560 bitfield_p(tree_node const*)
/home/vegard/git/gcc/gcc/cp/tree.c:331
0x138f97a cxx_sizeof_expr
/home/vegard/git/gcc/gcc/cp/typeck.c:1700
0x138f97a cxx_sizeof_or_alignof_expr(tree_node*, tree_code, bool)
/home/vegard/git/gcc/gcc/cp/typeck.c:1802
0xf2c443 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8017
0xec1cba cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9086
0xec42e6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9187
0xec80ba cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9482
0xecde93 cp_parser_constant_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9766
0xf5da83 cp_parser_direct_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:20114
0xf621c0 cp_parser_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19855
0xfb99c3 cp_parser_parameter_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:21555
0xfbc09a cp_parser_parameter_declaration_list
/home/vegard/git/gcc/gcc/cp/parser.c:21307
0xfbed30 cp_parser_parameter_declaration_clause
/home/vegard/git/gcc/gcc/cp/parser.c:21228
0xf5ad8f cp_parser_direct_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19981
0xfa10a8 cp_parser_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19855
0xfa137e cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19381
0xfa8357 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13061
0xfae548 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12879
0x1001295 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12776

$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)

Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).

Similar message to #52596 but that is an old bug.

7.3.0 seems fine.

Test case was reduced by C-Reduce.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

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

--- Comment #8 from Jay  ---
Aha, kinda the same thing, but before or after analysis.
And this “deprecated” somewhat matches msvc - I was wondering about that but
didn’t see it.

It’d be nice to be able to customize the deprecated message but hopefully we’ll
keep the baby despite the bathwater. (Msvc added that option later.)

Thank you.

[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
* is special as it is regex character and this won't be fixed as a good idea
never to have files with * as the shells will always treat * as a wild card. 
Note a similar issue is with @ too.

[Bug c++/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion

[michael at moekadu dot de]

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

--- Comment #2 from michael at moekadu dot de ---
Created attachment 43532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43532=edit
Preprocessed test-program

Here the preprocessed test-programmed 
(g++ -Ieigen test.cpp -O3 -funsafe-math-optimizations -E > test_prep.cpp)

Sorry, that I had to pack it to satisfy the file size limit.

[Bug c++/84632] New: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778

[vegard.nossum at gmail dot com]

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

Bug ID: 84632
   Summary: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have
array_type in reduced_constant_expression_p, at
cp/constexpr.c:1778
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

class {
  &
} b[] = b

Output:

$ xgcc -x c++ -S -fpermissive -
:2:5: warning: ISO C++ forbids declaration of 'a' with no type
[-fpermissive]
:3:3: error: initializer fails to determine size of 'b'
:3:9: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in
reduced_constant_expression_p, at cp/constexpr.c:1778
0x65f8d0 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/vegard/git/gcc/gcc/tree.c:9337
0xa157d9 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
/home/vegard/git/gcc/gcc/tree.h:3172
0xa157d9 reduced_constant_expression_p(tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:1778
0xa159cc verify_constant
/home/vegard/git/gcc/gcc/cp/constexpr.c:1822
0xa4e0c3 cxx_eval_outermost_constant_expr
/home/vegard/git/gcc/gcc/cp/constexpr.c:4829
0xa5cf6c maybe_constant_init_1
/home/vegard/git/gcc/gcc/cp/constexpr.c:5152
0x142bf0e store_init_value(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
/home/vegard/git/gcc/gcc/cp/typeck2.c:836
0xb48848 check_initializer
/home/vegard/git/gcc/gcc/cp/decl.c:6427
0xbdccae cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/vegard/git/gcc/gcc/cp/decl.c:7081
0xfa35d9 cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19720
0xfa8357 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13061
0xfae548 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12879
0x1001295 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12776
0xff826b cp_parser_declaration_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:12652
0xff9893 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4559
0xff9893 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38880
0x15a51f5 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132

$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)

Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).

Looks like bug #84424 but that has been fixed in r257924 and I'm using r258063.

7.3.0 seems fine.

Test case was reduced by C-Reduce.

[Bug c++/84630] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
Does not look like a regression from 7.x

This:
:1: confused by earlier errors, 

Just means there was an internal error after an normal error has been emitted
(with checking disabled or release checking).  The trunk has checking enabled
by default.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The warning/error attributes have been added for purposes like glibc memset
inline, which does:
  if (__builtin_constant_p (__len) && __len == 0
  && (!__builtin_constant_p (__ch) || __ch != 0))
{
  __warn_memset_zero_len ();
  return __dest;
}
where __warn_memset_zero_len has the warning attribute.  This only works if it
is after optimization.  If you want a diagnostics whenever you reference some
function, you are looking for the deprecated attribute instead.

[Bug c/84631] New: make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

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

Bug ID: 84631
   Summary: make check in fixincludes fails seemingly due to star
in directory names, on WSL
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

make check in fixincludes fails, seemingly due to "*" in directory names.
This is on WSL (Windows Subsystem for Linux).

I think Posix says stuff, like, / and \0 are the only special characters, but
for portability use a reduced set.

[Bug c++/84630] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141

[vegard.nossum at gmail dot com]

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

Bug ID: 84630
   Summary: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in
tsubst_lambda_expr, at cp/pt.c:17141
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

I was quite sure I had submitted this one but I have searched and cannot see it
anywhere, my apologies if it turns out to be a duplicate.

Input:

template  struct c {
  template  __attribute__((noinline([] {}))) b() {}
};
c<> a;

Output:

$ xgcc -x c++ -S -
:2:13: error: ISO C++ forbids declaration of 'parameter' with no type
[-fpermissive]
:2:55: error: ISO C++ forbids declaration of 'b' with no type
[-fpermissive]
: In member function 'int c<  >::b()':
:2:58: warning: no return statement in function returning non-void
[-Wreturn-type]
: In instantiation of 'struct c<>':
:4:5:   required from here
:2:53: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141
0x6602e9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/vegard/git/gcc/gcc/tree.c:9388
0x11dd0a0 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/vegard/git/gcc/gcc/tree.h:3255
0x11dd0a0 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:17141
0x10f640b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:18479
0x10f408a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:18168
0x10bfe06 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/pt.c:16973
0x1164bbf tsubst_attribute
/home/vegard/git/gcc/gcc/cp/pt.c:10327
0x1174e7c apply_late_template_attributes
/home/vegard/git/gcc/gcc/cp/pt.c:10428
0x117ef90 tsubst_function_decl
/home/vegard/git/gcc/gcc/cp/pt.c:12687
0x1184e90 tsubst_template_decl
/home/vegard/git/gcc/gcc/cp/pt.c:12804
0x1155421 tsubst_decl
/home/vegard/git/gcc/gcc/cp/pt.c:12906
0x1105c06 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:13798
0x11e2760 instantiate_class_template_1
/home/vegard/git/gcc/gcc/cp/pt.c:10743
0x11ef20b instantiate_class_template(tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:11041
0x138b930 complete_type(tree_node*)
/home/vegard/git/gcc/gcc/cp/typeck.c:136
0xb38193 start_decl_1(tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/decl.c:5244
0xc1a64f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/home/vegard/git/gcc/gcc/cp/decl.c:5207
0xfa251c cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19589
0xfa8357 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13061
0xfae548 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12879

$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)

Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).

7.3.0 says:

:2:13: error: ISO C++ forbids declaration of 'parameter' with no type
[-fpermissive]
   template  __attribute__((noinline([] {}))) b() {}
 ^
:2:55: error: ISO C++ forbids declaration of 'b' with no type
[-fpermissive]
   template  __attribute__((noinline([] {}))) b() {}
   ^
:1: confused by earlier errors, bailing out
Compiler returned: 1

Test case was reduced by C-Reduce.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

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

--- Comment #6 from Jay  ---
Misplaced comment:
But, the thing is, because optimization can remove the use of such functions,
people are now advocating that we noinline along with the attribute, which
hypothetically is unwarranted damage. Noinline being a partial disabling of
optimization, not complete.

See here:
https://github.com/mono/mono/pull/7353

But it isn't clear as I said, if it is worth warning/error for what the source
states, vs. what the optimizer divines from the code.

[Bug sanitizer/84629] sanitizer warnings and errors on Linux

[jay.krell at cornell dot edu]

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

--- Comment #4 from Jay  ---
-disable-multilib fixed the errors. 
I didn't watch for the warnings.

[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms

[jay.krell at cornell dot edu]

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

--- Comment #4 from Jay  ---
Incorrect bug.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

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

--- Comment #5 from Jay  ---
I know. We just noticed and were surprised. It isn't clear if this is what
users would expect or not. Warn because they wrote code that "merely looks
bad", or only if the compiler decides after analysis that it really is bad?
Anyway, there are two points here I think. One is far more arguable than the
other. I don't think the small case shown should error.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jay from comment #3)
> The original case said something about "localalias" in the error, so aliases
> don't seem to address it. I can dig that up probably.
> 
> Shouldn't it warn for:
>  if (0)
>banned_function()
> ?
> 
> I believe we want it to.
> You know, strive for equal warnings/errors w/ or w/o optimization, but I
> know that is impossible in general, because optimization==analysis.

The documentation is explicit here though:
" call to such a function is not eliminated through dead code elimination or
other optimizations"

[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms

[jay.krell at cornell dot edu]

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

--- Comment #3 from Jay  ---
But, the thing is, because optimization can remove the use of such functions,
people are now advocating that we noinline along with the attribute, which
hypothetically is unwarranted damage. Noinline being a partial disabling of
optimization, not complete.

See here:
https://github.com/mono/mono/pull/7353

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

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

--- Comment #3 from Jay  ---
The original case said something about "localalias" in the error, so aliases
don't seem to address it. I can dig that up probably.

Shouldn't it warn for:
 if (0)
   banned_function()
?

I believe we want it to.
You know, strive for equal warnings/errors w/ or w/o optimization, but I know
that is impossible in general, because optimization==analysis.


I believe attribute(error) should be like pragma poison except:
 - easier to implement the deprecated function
 - can provide custom error
 - works with C++ overloads -- attach attribute to full declaration, not just
identifier


But yeah, another option is to optimize a little less, on a case by case basis.
Or actually remove the attribute, or don't warn, if the compiler essentially
introduced the use.

[Bug inline-asm/84625] [6/7/8 Regression] ICE with empty constraint and vector constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-01
Version|unknown |7.0
   Target Milestone|--- |6.5
Summary|ICE with empty constraint   |[6/7/8 Regression] ICE with
   |and vector constant |empty constraint and vector
   ||constant
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This used to be rejected before r151701:
pr84625.c: In function ‘foo’:
pr84625.c:5:3: warning: asm operand 0 probably doesn’t match constraints
pr84625.c:5:3: error: impossible constraint in ‘asm’
and started to ICE with r188665.

[Bug inline-asm/84625] ICE with empty constraint and vector constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|ICE with constexpr and  |ICE with empty constraint
   |inline asm  |and vector constant

--- Comment #1 from Jakub Jelinek  ---
That has nothing to do with constexpr and everything to do with the invalid
(empty) constraint.

void
foo ()
{
  typedef int V __attribute__((vector_size (16)));
  asm ("%0" : : "" ((V) { 1, 2, 3, 4 }));
}

ICEs the same.

[Bug sanitizer/84629] sanitizer warnings and errors on Linux

[jay.krell at cornell dot edu]

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

--- Comment #3 from Jay  ---
This is ubuntu xenial I think, on WSL.
Which doesn't have multi-arch.
So I'll try configure -disable-multilib.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-01
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Of course it has to be evaluated after optimization, that is the whole point of
these attributes.  In this case just IPA ICF should not try to fold error1 with
error2 if it can't use aliases and the functions involved have warning or error
attributes.

[Bug sanitizer/84629] sanitizer warnings and errors on Linux

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The __NR_* macros are actually provided by kernel headers rather than glibc,
/usr/include/asm*/unistd*.h
So this looks like a distro bug to me.

[Bug sanitizer/84629] sanitizer warnings and errors on Linux

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-01
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What target is this?  Also what version of glibc are you using?

[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #13 from Tom de Vries  ---
> Suspended until the infrastructure is ready.

With PR83327 fixed, it may make sense to reenable ix86_spill_class and see if
the problems are gone.

Tentatively setting status to NEW.

[Bug regression/84623] [8 Regression] "-fcompare-debug failure (length)" testing pr46066.c start with r257826 on mips

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Hasn't r257993 fixed this already?

[Bug sanitizer/84629] New: sanitizer warnings and errors on Linux

[jay.krell at cornell dot edu]

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

Bug ID: 84629
   Summary: sanitizer warnings and errors on Linux
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:230:44: note: in
expansion of macro 'SYSCALL'
   HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd,
^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: 'SYS_ftruncat
'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:377:14: note:
in definition of macro 'HANDLE_EINTR'
   res = (f);   \
  ^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:230:44: note: in
expansion of macro 'SYSCALL'
   HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd,
^~~
In file included from
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:152:
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_stat(const char*, void*)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_stat64' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:322:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(stat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: '__lxstat64'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:322:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(stat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_lstat(const char*, void*)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_lstat64' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:349:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(lstat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: '__lxstat64'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:349:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(lstat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_dup2(int, int)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_dup2' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:385:27: note: in
expansion of macro 'SYSCALL'
   return internal_syscall(SYSCALL(dup2), oldfd, newfd);
   ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: 'SYS_dup2'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:385:27: note: in
expansion of macro 'SYSCALL'
   return internal_syscall(SYSCALL(dup2), oldfd, newfd);
   ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_readlink(const char*, char*,
__sanitizer::uptr)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_readlink' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:396:27: note: in
expansion of macro 'SYSCALL'
   return internal_syscall(SYSCALL(readlink), (uptr)path, (uptr)buf, bufsize);
   ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: 'SYS_readlink'
 # define 

[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #14 from Tom de Vries  ---
Patch tested on MIPS16 and committed.

Marking resolved-fixed.

[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries  ---
Author: vries
Date: Thu Mar  1 05:51:08 2018
New Revision: 258093

URL: https://gcc.gnu.org/viewcvs?rev=258093=gcc=rev
Log:
Fix liveness analysis in lra for spilled-into hard regs

2018-03-01  Tom de Vries  

PR rtl-optimization/83327
* lra-int.h (hard_regs_spilled_into): Declare.
* lra.c (hard_regs_spilled_into): Define.
(init_reg_info): Init hard_regs_spilled_into.
* lra-spills.c (assign_spill_hard_regs): Update hard_regs_spilled_into.
* lra-lives.c (make_hard_regno_born, make_hard_regno_dead)
(process_bb_lives): Handle hard_regs_spilled_into.
(lra_create_live_ranges_1): Before doing liveness propagation, clear
regs in all_hard_regs_bitmap if set in hard_regs_spilled_into.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-int.h
trunk/gcc/lra-lives.c
trunk/gcc/lra-spills.c
trunk/gcc/lra.c

[Bug c/84628] attribute(warning/error) should be evaluated before optimization

[jay.krell at cornell dot edu]

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

--- Comment #1 from Jay  ---
Also occurs with git trunk ef8d0c5bff3c11a5d67617df2f43775f7a26fad2 8.0.1
20180228.

[Bug c/84628] New: attribute(warning/error) should be evaluated before optimization

[jay.krell at cornell dot edu]

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

Bug ID: 84628
   Summary: attribute(warning/error) should be evaluated before
optimization
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

This code should not error.
It is derived from real world code.

$ cat object.c
#define ERROR __attribute__ ((__error__ ("do not call this")))

int (*f1)();
int f2 () { return f1 (); }
ERROR int error1 () { return f2(); }
ERROR int error2 () { return f2(); }

$ $HOME/gcc720/bin/gcc -v

Using built-in specs.
COLLECT_GCC=/home/jay/gcc720/bin/gcc
COLLECT_LTO_WRAPPER=/home/jay/gcc720/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /src/gcc-7.2.0/configure -prefix=/home/jay/gcc720
-enable-languages=objc,obj-c++,go,fortran -disable-multilib
Thread model: posix

gcc version 7.2.0 (GCC)

$ $HOME/gcc720/bin/gcc -c -O2 object.c
object.c: In function ‘error2’:
cc1: error: call to ‘error1’ declared with attribute error: do not call this


I will try trunk.

[Bug target/84627] powerpc excess padding generated for POWER9 target

[npiggin at gmail dot com]

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

--- Comment #2 from Nicholas Piggin  ---
Ah sorry, target is powerpc64le

[Bug target/84627] powerpc excess padding generated for POWER9 target

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc

--- Comment #1 from Andrew Pinski  ---
Is this little endian or big-endian?  32bit or 64bit?

[Bug target/84627] New: powerpc excess padding generated for POWER9 target

[npiggin at gmail dot com]

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

Bug ID: 84627
   Summary: powerpc excess padding generated for POWER9 target
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---

gcc version 8.0.1 20180207 (experimental) [trunk revision 257435] (Debian
8-20180207-2):

Test case:

void test(void (*fn)(void), unsigned long i)
{ 
while (i--)
fn();
}

Generates code with -O2 -mcpu=power9:

  2c:   18 00 41 f8 std r2,24(r1)
  30:   00 00 00 60 nop
  34:   00 00 00 60 nop
  38:   00 00 00 60 nop
  3c:   00 00 42 60 ori r2,r2,0
  40:   78 f3 cc 7f mr  r12,r30
  44:   a6 03 c9 7f mtctr   r30
  48:   ff ff ff 3b addir31,r31,-1
  4c:   21 04 80 4e bctrl
  50:   18 00 41 e8 ld  r2,24(r1)
  54:   ff ff bf 2f cmpdi   cr7,r31,-1
  58:   e8 ff 9e 40 bne cr7,40 

On power9, I wonder if nops and ori should be avoided? Aligning to quad word
boundary is reasonable for fetch, but is there any advantage for dispatch to
add the extra padding?

[Bug target/84626] powerpc toc register is reloaded unnecessarily

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc
   Severity|normal  |enhancement

[Bug target/84626] New: powerpc toc register is reloaded unnecessarily

[npiggin at gmail dot com]

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

Bug ID: 84626
   Summary: powerpc toc register is reloaded unnecessarily
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---

gcc version 8.0.1 20180207 (experimental) [trunk revision 257435] (Debian
8-20180207-2):

Test case:

void test(void (*fn)(void), unsigned long i)
{ 
while (i--)
fn();
}

Generates code:

  2c:   18 00 41 f8 std r2,24(r1)
  30:   00 00 00 60 nop
  34:   00 00 00 60 nop
  38:   00 00 00 60 nop
  3c:   00 00 42 60 ori r2,r2,0
  40:   78 f3 cc 7f mr  r12,r30
  44:   a6 03 c9 7f mtctr   r30
  48:   ff ff ff 3b addir31,r31,-1
  4c:   21 04 80 4e bctrl
  50:   18 00 41 e8 ld  r2,24(r1)
  54:   ff ff bf 2f cmpdi   cr7,r31,-1
  58:   e8 ff 9e 40 bne cr7,40 

The r2 load could be moved out of the loop.

[Bug inline-asm/84625] New: ICE with constexpr and inline asm

[SztfG at yandex dot ru]

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

Bug ID: 84625
   Summary: ICE with constexpr and inline asm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

testcase:

#include 

void crasher()
{
  constexpr __m128 w = {1,2,3,4};
  asm ("addps %[w], %[w]" : : [w] ""(w));
}

[Bug tree-optimization/84624] New: bogus -Wstringop-truncation in a catch statement and nul assignment outside it

[msebor at gcc dot gnu.org]

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

Bug ID: 84624
   Summary: bogus -Wstringop-truncation in a catch statement and
nul assignment outside it
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-truncation warning for the strncpy call below should have been
suppressed by the subsequent assignment to d but the suppression logic is
thwarted by the __cxa_end_catch () call.

$ cat b.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.C
char d[3];

void f ();

void g (const char *s)
{
  try
{
  f ();
}
  catch (...)
{
  __builtin_strncpy (d, s, sizeof d);   // bogus warning
}

  d[sizeof d - 1] = 0;   // because of this
}

b.C: In function ‘void g(const char*)’:
b.C:13:25: warning: ‘char* __builtin_strncpy(char*, const char*, long unsigned
int)’ specified bound 3 equals destination size [-Wstringop-truncation]
   __builtin_strncpy (d, s, sizeof d);   // bogus warning
   ~~^~~~

;; Function g (_Z1gPKc, funcdef_no=0, decl_uid=2362, cgraph_uid=0,
symbol_order=1)

g (const char * s)
{
  void * _1;

   [local count: 1073741825]:
  f ();

   [local count: 1073741825]:
  d[2] = 0;
  return;

   [count: 0]:
:
  _1 = __builtin_eh_pointer (1);
  __cxa_begin_catch (_1);
  __builtin_strncpy (, s_7(D), 3);
  __cxa_end_catch ();
  goto ; [100.00%]

}

[Bug regression/84623] New: [8 Regression] "-fcompare-debug failure (length)" testing pr46066.c start with r257826 on mips

[paul.hua.gm at gmail dot com]

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

Bug ID: 84623
   Summary: [8 Regression]  "-fcompare-debug failure (length)"
testing pr46066.c start with r257826 on mips
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.hua.gm at gmail dot com
  Target Milestone: ---

paulhua@erpro8-fsf2:~/GCC/build/gcc-r257826_obj$ ./gcc/xgcc -B./gcc
/home/paulhua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcompare-debug -O
-ftree-parallelize-loops=4 -S -o pr46066.s 
xgcc: error:
/home/paulhua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c:
-fcompare-debug failure (length)

Start with r257826.

Can not reproduce with cross compiler.

On gcc23 gcc config with:

../configure --prefix=/opt/gcc-8 MISSING=texinfo MAKEINFO=missing
--target=mips64el-linux-gnu --enable-languages=c,c++

[Bug fortran/84622] [F08] gfortran accepts invalid intent(out) polymorphic dummy argument with coarray component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-01
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (8.0). I get an ICE with 4.8.

[Bug fortran/84622] New: [F08] gfortran accepts invalid intent(out) polymorphic dummy argument with coarray component

[damian at sourceryinstitute dot org]

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

Bug ID: 84622
   Summary: [F08] gfortran accepts invalid intent(out) polymorphic
dummy argument with coarray component
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

gfortran 7 and 8 accept the following invalid code when the dummy argument is
declared with "class" but give the correct error message when "type" replaces
"class":

  type foo
logical, allocatable :: bar[:]
  end type
contains
  subroutine foobar(this)
class(foo), intent(out) :: this
  end subroutine
end

[Bug c++/84294] attributes on a function template redeclaration silently discarded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01625.html

[Bug c++/84621] bogus -Wreturn-type on a template instantiated on a function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|bogus -Wresturn-type on a   |bogus -Wreturn-type on a
   |template instantiated on a  |template instantiated on a
   |function|function
  Known to fail||4.1.0, 4.5.4, 4.8.3, 4.9.4,
   ||5.4.0, 6.3.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
This never worked as expected so it's not a regresion.

[Bug c++/84621] New: bogus -Wresturn-type on a template instantiated on a function

[msebor at gcc dot gnu.org]

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

Bug ID: 84621
   Summary: bogus -Wresturn-type on a template instantiated on a
function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a non-void function template that doesn't return value and that is
parameterized on a function pointer is instantiated on the address of a
noreturn function calls the function, G++ issues a bogus -Wreturn-type warning
even though it successfully eliminates statements after the call to the
noreturn function (as it should).

Interestingly, other compilers suffer the same or similar problem.  Clang and
ICC issue the same bogus warning while also eliminating the second call, and
MSVC doesn't warn or eliminate the call.

$ cat b.C && gcc -O -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.C

template 
int ff ()
{
  f ();
  f ();   // eliminated
} // bogus -Wreturn-type

void __attribute__ ((noreturn)) f ();

template int ff();

b.C: In function ‘int ff()’:
b.C:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 } // bogus -Wreturn-type
 ^

;; Function ff (_Z2ffIXadL_Z1fvEEEiv, funcdef_no=1, decl_uid=2366,
cgraph_uid=0, symbol_order=0)

ff ()
{
   [local count: 1073741825]:
  f ();

}

[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #18 from Jason Merrill  ---
Fixed.

[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
Author: jason
Date: Wed Feb 28 21:34:56 2018
New Revision: 258087

URL: https://gcc.gnu.org/viewcvs?rev=258087=gcc=rev
Log:
PR c++/71784 - ICE with ref-qualifier and explicit specialization.

* pt.c (determine_specialization): Check ref-qualifier.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Wed Feb 28 21:34:07 2018
New Revision: 258085

URL: https://gcc.gnu.org/viewcvs?rev=258085=gcc=rev
Log:
PR c++/71784 - ICE with ref-qualifier and explicit specialization.

* pt.c (determine_specialization): Check ref-qualifier.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
Author: jason
Date: Wed Feb 28 21:34:31 2018
New Revision: 258086

URL: https://gcc.gnu.org/viewcvs?rev=258086=gcc=rev
Log:
PR c++/71784 - ICE with ref-qualifier and explicit specialization.

* pt.c (determine_specialization): Check ref-qualifier.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug middle-end/52285] [6/7/8 Regression] libgcrypt _gcry_burn_stack slowdown

[vmakarov at gcc dot gnu.org]

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

--- Comment #21 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #20)
> Vlad, your thoughts on this?  Can it be done in LRA or postreload-gcse or
> some other post-LRA pass (if they do have loops)?

I don't think it can be done easily after RA.  There are no optimizations
working with loops after IRA.  postreload-gcse is very simple pass working with
loads/stores.  It is hard to modify it (e.g. into PRE) to do invariant motion.
Probably we could repeat loop invariant motion pass again after LRA but it
needs investigation and running such heavy pass for rare cases may be doubtful.

I don't think that this PR will be fixed for GCC-8 or even later.  It will be
hard to justify compilation slowdown without visible performance improvements
for example on SPEC.

[Bug c++/84610] [6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|[5/6/7/8 Regression] ICE in |[6/7/8 Regression] ICE in
   |synthesize_implicit_templat |synthesize_implicit_templat
   |e_parm, at  |e_parm, at
   |cp/parser.c:38843   |cp/parser.c:38843

[Bug rtl-optimization/84614] [8 Regression] wrong code with u16->u128 extension at aarch64 -fno-split-wide-types -g3 --param=max-combine-insns=3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/84618] [8 Regression] ICE in build_capture_proxy, at cp/lambda.c:460

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[dev at benjarobin dot fr]

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

--- Comment #34 from Benjamin Robin  ---
Thank you a lot for the fix.
I have no idea what I did yesterday when I did test bf-ms-layout-2.c (Yes the
test was wrong, and by default cannot compile under Visual Studio VC)

The test can be slightly improved by replacing:

#ifdef __GNUC__
#define ATTR __attribute__ ((ms_struct))
#endif

By:

#ifdef __GNUC__
# ifdef _TEST_MS_LAYOUT
#  define ATTR __attribute__ ((ms_struct))
# else
#  define ATTR __attribute__ ((gcc_struct))
# endif
#else
# define ATTR
#endif

Otherwise the else branch of "#if defined (_TEST_MS_LAYOUT) || defined
(_MSC_VER)" cannot be tested easily.
And even more important, it can be directly compiled with Visual Studio VC (VC
does not known what is ATTR)

[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P4  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug target/70321] [6/7/8 Regression] STV generates less optimized code

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #16)
> We didn't do that in stage1, stage4 is too risky for that.  Can somebody
> from Intel try that for GCC9 stage1?
> I'm willing to help, but will have lots of work on OpenMP 5.0, so can't
> drive that.

We will look into it.  Thanks.

[Bug target/84014] [6/7 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
Author: dje
Date: Wed Feb 28 19:53:24 2018
New Revision: 258081

URL: https://gcc.gnu.org/viewcvs?rev=258081=gcc=rev
Log:
PR target/84014
* gcc.target/powerpc/pr84014.c: Use ilp32, not -m32 option.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr84014.c

[Bug target/82258] [8 regression] allocate_zerosize_3.f fails since r251949

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
armeb-*-* is neither primary nor secondary target.

[Bug c++/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-28
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Please can you attach the preprocessed source (via -E), so that we're all
looking at the same thing.  Thanks.

[Bug target/70321] [6/7/8 Regression] STV generates less optimized code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||itsimbal at gcc dot gnu.org
   Target Milestone|8.0 |9.0

--- Comment #16 from Jakub Jelinek  ---
We didn't do that in stage1, stage4 is too risky for that.  Can somebody from
Intel try that for GCC9 stage1?
I'm willing to help, but will have lots of work on OpenMP 5.0, so can't drive
that.

[Bug c++/84610] [5/6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-28
 CC||dmalcolm at gcc dot gnu.org
Summary|internal compiler error: in |[5/6/7/8 Regression] ICE in
   |synthesize_implicit_templat |synthesize_implicit_templat
   |e_parm, at  |e_parm, at
   |cp/parser.c:38843   |cp/parser.c:38843
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed on trunk, 5, 6 and 7 (with an explicit -std=c++14 needed for gcc 5).

Failing in synthesize_implicit_template_parm (parser=0x77ffbbd0,
constr=) at ../../src/gcc/cp/parser.c:3

3 gcc_assert (current_binding_level->kind == sk_function_parms);

(gdb) p cfun
$2 = (function *) 0x0
(gdb) p scope_chain->bindings->kind
$5 = sk_template_parms

Started with r208426 (with -std=c++14).

[Bug c++/84609] [8 Regression] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:28960 (cp_parser_member_declaration())

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/84618] [8 Regression] ICE in build_capture_proxy, at cp/lambda.c:460

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Failing here in build_capture_proxy (member=,
init=) at ../../src/gcc/cp/lambda.c:458:

458   gcc_assert (VAR_P (init) || TREE_CODE (init) == PARM_DECL);

where init is a component_ref.

[Bug c++/84611] [5/67/8 Regression] ICE in operator[], at vec.h:826 (local_class_index())

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-28
 CC||dmalcolm at gcc dot gnu.org
Summary|internal compiler error: in |[5/67/8 Regression] ICE in
   |operator[], at vec.h:826|operator[], at vec.h:826
   |(local_class_index())   |(local_class_index())
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.  

826   gcc_checking_assert (ix < m_vecpfx.m_num);

(gdb) p ix
$1 = 1
(gdb) p m_vecpfx.m_num
$2 = 1

at:

1921  tree type = (*local_classes)[ix];

Bisecting with pre-built cc1plus binaries shows the ICE starts somewhere
between r19 and r190022.

Doesn't ICE on my builds of 7, 6, or 5 (presumably due to checking being
disabled), but running each of these under valgrind shows the bogus read:

==19292== Invalid read of size 8
==19292==at 0x783FF4: local_class_index(tree_node*) (mangle.c:1958)
==19292==by 0x78726A: write_name(tree_node*, int) (mangle.c:1990)
==19292==by 0x787B16: write_type(tree_node*) (mangle.c:2841)
==19292==by 0x78EBDA: mangle_special_for_type(tree_node*, char const*)
(mangle.c:4032)
==19292==by 0x7302AF: get_tinfo_decl(tree_node*) (rtti.c:417)
==19292==by 0x747A77: expand_start_catch_block(tree_node*) (except.c:380)
==19292==by 0x75ED8C: finish_handler_parms(tree_node*, tree_node*)
(semantics.c:1327)

[Bug c++/84609] [8 Regression] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:28960 (cp_parser_member_declaration())

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 28 18:57:38 2018
New Revision: 258080

URL: https://gcc.gnu.org/viewcvs?rev=258080=gcc=rev
Log:
PR c++/84609
* parser.c (cp_parser_attributes_opt): Formatting fix.
(cp_parser_skip_balanced_tokens, cp_parser_skip_gnu_attributes_opt,
cp_parser_skip_std_attribute_spec_seq, cp_parser_skip_attributes_opt):
New functions.
(cp_parser_member_declaration): Use cp_parser_skip_attributes_opt
instead of tentative parse to peek over optional attribute tokens
to check for CPP_COLON after them.

* g++.dg/cpp0x/pr84609.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr84609.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 28 18:56:36 2018
New Revision: 258079

URL: https://gcc.gnu.org/viewcvs?rev=258079=gcc=rev
Log:
PR c++/83871
PR c++/83503
* pt.c (INCLUDE_STRING): Remove define.
(warn_spec_missing_attributes): Use pretty_printer instead of
std::string.  Fix up inform call so that the list of attributes
is in %s argument.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 28 18:56:36 2018
New Revision: 258079

URL: https://gcc.gnu.org/viewcvs?rev=258079=gcc=rev
Log:
PR c++/83871
PR c++/83503
* pt.c (INCLUDE_STRING): Remove define.
(warn_spec_missing_attributes): Use pretty_printer instead of
std::string.  Fix up inform call so that the list of attributes
is in %s argument.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug tree-optimization/80293] [6/7 Regression] unnecessary code at -O2 (-O1 is fine)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #11 from Jakub Jelinek  ---
*** Bug 80837 has been marked as a duplicate of this bug. ***

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Jakub Jelinek  ---
Actually managed to reproduce today using godbolt's -E output.
This is something that got fixed with r247104 on the trunk and backported
to 7.2 as r248724.  So I believe this is fixed.  The choice to emit
__atomic_load_16 calls is intentional, see the overlong thread about it from
the last week or so on gcc at gcc.gnu.org mailing list.

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

[Bug c++/84618] [8 Regression] ICE in build_capture_proxy, at cp/lambda.c:460

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-28
 CC||dmalcolm at gcc dot gnu.org
Summary|internal compiler error: in |[8 Regression] ICE in
   |build_capture_proxy, at |build_capture_proxy, at
   |cp/lambda.c:460 |cp/lambda.c:460
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.  Started with r253265.

[Bug testsuite/84617] [8 Regression] new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r258077.

[Bug testsuite/84617] [8 Regression] new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Feb 28 18:28:53 2018
New Revision: 258077

URL: https://gcc.gnu.org/viewcvs?rev=258077=gcc=rev
Log:
PR testsuite/84617 - new test cases g++.dg/ext/attr-const.C and
g++.dg/ext/attr-pure.C fail

gcc/cp/ChangeLog:

* decl.c (duplicate_decls): Fully merge attributes const, pure,
and malloc.

gcc/testsuite/ChangeLog:

* g++.dg/ext/attr-malloc-3.C: New test.
* g++.dg/ext/attr-const.C: Adjust.  Xfail assertions failing due
to pre-existing problems.
* g++.dg/ext/attr-pure.C: Same.


Added:
trunk/gcc/testsuite/g++.dg/ext/attr-malloc-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attr-const.C
trunk/gcc/testsuite/g++.dg/ext/attr-pure.C

[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On February 28, 2018 6:44:43 PM GMT+01:00, "jnordholz at sect dot tu-berlin.de"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562
>
>--- Comment #7 from Jan Nordholz 
>---
>(In reply to Richard Biener from comment #5)
>> Btw, the behavior is the way you describe since forever.  That GCC
>looks at
>> the constant initializer for the array is just a direct consequence
>of it
>> looking at the constant initializer of the scalar.
>
>And my point is that the compiler shouldn't look at the initializer of
>weak
>objects in the first place. :) How long this behaviour already exists
>or what
>the competition is doing doesn't really change my feeling that this is
>the
>Wrong Thing To Do. But it's your bugtracker, I won't argue if you
>insist that
>this should be flagged as invalid.
>
>If I (or somebody else who happens to find this bug report) would come
>up with
>a patch to fix this inconsistency (as Alexander has showcased even more
>concisely in comment #3), would this be considered by the project?

I guess yes.

[Bug fortran/84594] Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Wed, Feb 28, 2018 at 04:41:00PM +, dominiq at lps dot ens.fr wrote:
> 
> Do you at least agree that
> 
> (a) || flag_default_real_10 || flag_default_real_16 should be added
> to flag_default_integer || flag_default_real_8 in module.c,

Yes, those should probably be added.

> 
> (b) the warning should be documented?
> 

I thought that there was a warning in the -fdefault-*
documentation about these options changing the ABI,
which could cause problems.  So, yes, there should
be something like

Warning: This option conflicts with NUMERIC_STORAGE_SIZE
from ISO_FORTRAN_ENV module because it effects the underlying
storage association between numeric types.  It may also
cause problems with changes in a library's ABI and 
interoperability with the C language.

[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures

[jnordholz at sect dot tu-berlin.de]

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

--- Comment #7 from Jan Nordholz  ---
(In reply to Richard Biener from comment #5)
> Btw, the behavior is the way you describe since forever.  That GCC looks at
> the constant initializer for the array is just a direct consequence of it
> looking at the constant initializer of the scalar.

And my point is that the compiler shouldn't look at the initializer of weak
objects in the first place. :) How long this behaviour already exists or what
the competition is doing doesn't really change my feeling that this is the
Wrong Thing To Do. But it's your bugtracker, I won't argue if you insist that
this should be flagged as invalid.

If I (or somebody else who happens to find this bug report) would come up with
a patch to fix this inconsistency (as Alexander has showcased even more
concisely in comment #3), would this be considered by the project?

[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Having placement new represented in the IL is something I've suggested several
times (e.g. to be able to be more aggressive on TBAA in loops which don't
contain any placement new), but Richard didn't like that.

[Bug c++/84612] Overload resolution of operator* fails for valarray

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
For completeness, the standard says that the operator is defined like this:

template valarray operator*(const valarray&, const T&);

That's what libstdc++ provides, and it fails to deduce T in your example.

The libc++ version looks like:

template valarray operator*(const valarray&, const typename
valarray::value_type&);

This only deduces T from the valarray argument, so the test case works. But
that is a non-standard behaviour, it's not a bug that GCC doesn't compile this
test case, because we are following the standard.

I've filed a new issue with the standard committee proposing to change the
standard to do what libc++ does, and if that happens we will change GCC's
implementation.

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|6.5 |9.0

--- Comment #30 from Jeffrey A. Law  ---
OK.  Moving to gcc-9.  Note I think there's multiple instances of this issue
that would likely be helped if we can get IVOPTS to DTRT here.  I'll try to
link them via "See Also" the next time I come across them.

[Bug fortran/83901] [8 Regression] ICE in fold_convert_loc, at fold-const.c:2402

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Wed Feb 28 17:36:20 2018
New Revision: 258076

URL: https://gcc.gnu.org/viewcvs?rev=258076=gcc=rev
Log:
2018-02-28  Paul Thomas  

PR fortran/83901
* trans-stmt.c (trans_associate_var): Make sure that the se
expression is a pointer type before converting it to the symbol
backend_decl type.

2018-02-28  Paul Thomas  

PR fortran/83901
* gfortran.dg/associate_37.f90: New test.

PR fortran/83344
* gfortran.dg/associate_36.f90: Add Steve Kargl as contributer.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_37.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_36.f90

[Bug fortran/83344] Use of uninitialized memory with ASSOCIATE and strings

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  ---
Author: pault
Date: Wed Feb 28 17:36:20 2018
New Revision: 258076

URL: https://gcc.gnu.org/viewcvs?rev=258076=gcc=rev
Log:
2018-02-28  Paul Thomas  

PR fortran/83901
* trans-stmt.c (trans_associate_var): Make sure that the se
expression is a pointer type before converting it to the symbol
backend_decl type.

2018-02-28  Paul Thomas  

PR fortran/83901
* gfortran.dg/associate_37.f90: New test.

PR fortran/83344
* gfortran.dg/associate_36.f90: Add Steve Kargl as contributer.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_37.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_36.f90

[Bug middle-end/52285] [6/7/8 Regression] libgcrypt _gcry_burn_stack slowdown

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Vlad, your thoughts on this?  Can it be done in LRA or postreload-gcse or some
other post-LRA pass (if they do have loops)?

[Bug c++/84294] attributes on a function template redeclaration silently discarded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-28
Summary|missing warning for ignored |attributes on a function
   |attribute on a function |template redeclaration
   |template declaration|silently discarded
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
I'll confirm this bug because it was the indirect cause of a number of test
suite regressions recently (bug 84617).  The problem is also not just one of a
missing diagnostic but rather one of G++ failing to apply attributes specified
on a function template re-declaration that were not specified on the first
declaration of the template.  I.e., it's a missed optimization opportunity.

An enhanced test case:

$cat b.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.C
int f ();

int __attribute__ ((const)) f ();

void ff ()
{
  int i0 = f ();
  int i1 = f ();

  if (i0 != i1)   // folded to false
__builtin_abort ();
}

template 
int g ();

template 
int __attribute__ ((const)) g ();

void gg ()
{
  int i0 = g();
  int i1 = g();

  if (i0 != i1)   // not folded
__builtin_abort ();
}

template 
int __attribute__ ((const)) h ();

template 
int h ();

void hh ()
{
  int i0 = h();
  int i1 = h();

  if (i0 != i1)   // folded to false
__builtin_abort ();
}


;; Function ff (_Z2ffv, funcdef_no=0, decl_uid=2361, cgraph_uid=0,
symbol_order=0)

ff ()
{
   [local count: 1073741825]:
  return;

}



;; Function gg (_Z2ggv, funcdef_no=1, decl_uid=2371, cgraph_uid=1,
symbol_order=1)

gg ()
{
  int _3;
  int _5;

   [local count: 1073741825]:
  _3 = g ();
  _5 = g ();
  if (_3 != _5)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  return;

}



;; Function hh (_Z2hhv, funcdef_no=4, decl_uid=2382, cgraph_uid=2,
symbol_order=2)

hh ()
{
   [local count: 1073741825]:
  return;

}

[Bug debug/84620] New: DW_AT_GNU_entry_view should not use address class forms, but constant forms

[mark at gcc dot gnu.org]

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

Bug ID: 84620
   Summary: DW_AT_GNU_entry_view should not use address class
forms, but constant forms
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

In some situations gcc will emit the view index in DWARF as a DW_FORM_addr (or
DW_FORM_GNU_addr_index). This is confusing to DWARF consumers which might
process address class attributes specially. A view number really is a constant
class attribute. Ideally it should use DW_FORM_udata. But if a constant sized
form is needed, it could also use DW_FORM_data1, DW_FORM_data2, DW_FORM_data4
or
DW_FORM_data8.

The issue seems to come from gcc dwarf2out.c internally using
dw_val_class_lbl_id, which seems to be used for the special DW_AT_high_pc case
where it could be either an address or an (constant) offset from low_pc (so it
can be represented either as address class or constant class).

It seems view numbers are always constant class and so should use a different
(or new) dw_val_class in dwarf2out.

[Bug c/84619] Segmentation fault when running a c-program which is calling a fortran subroutine

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  ---
size_t is the documented type, but for various reasons due to idiosyncrasies in
the gfortran frontend, for the moment it emits a signed type the same size as
size_t. 

Just use size_t, that should work fine.

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #33 from Jakub Jelinek  ---
Hopefully fixed in GCC 8.  It is an ABI change, so not going to backport it.

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 28 17:17:29 2018
New Revision: 258075

URL: https://gcc.gnu.org/viewcvs?rev=258075=gcc=rev
Log:
PR target/52991
* stor-layout.c (update_alignment_for_field): For
targetm.ms_bitfield_layout_p (rli->t), if !is_bitfield
&& !DECL_PACKED (field), do the alignment update, just use
only desired_align instead of MAX (type_align, desired_align)
as the alignment.
(place_field): Don't do known_align < desired_align handling
early if targetm.ms_bitfield_layout_p (rli->t) and rli->prev_field
is non-NULL, instead do it after rli->prev_field handling and
only if not within a bitfield word.  For DECL_PACKED (field)
use type_align of BITS_PER_UNIT.

* gcc.dg/bf-ms-layout.c: Revert 2012-04-26 changes.
* gcc.dg/bf-ms-layout-2.c: Revert 2012-02-23 changes.
* gcc.dg/bf-ms-layout-4.c: New test.
* gcc.dg/bf-ms-layout-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/bf-ms-layout-4.c
trunk/gcc/testsuite/gcc.dg/bf-ms-layout-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/bf-ms-layout-2.c
trunk/gcc/testsuite/gcc.dg/bf-ms-layout.c

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[amker at gcc dot gnu.org]

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

--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #28)
> BTW, ISTM that we need Bin to chime in on the complexity of improving this
> in IVOPTS -- ie, is it gcc-8 or gcc-9 material.  If the latter, then we
> should adjust the target milestone.

Yes, it's more like a GCC9 stuff.
For the record, I think this could be generalized to cover addressing mode
issue revealed by PR84037.  That is, not only non-iv addresses, but also
addresses after iv_rewrite could be refined for best selection of addressing
mode.

[Bug testsuite/84617] [8 Regression] new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01603.html

[Bug c++/84609] [8 Regression] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:28960 (cp_parser_member_declaration())

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 43529 [details]
> gcc8-pr84609.patch
> 
> Untested fix.

Looks good.

[Bug c/84619] Segmentation fault when running a c-program which is calling a fortran subroutine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
There is nothing strange on it, gfortran changed ABI in GCC 8, so on 64-bit
architectures your C prototype for the function defined in Fortran is no longer
valid.

void get3_ (int* ih, char* cp, char* cx, double* res, int* ier, int cp_len, int
cx_len);
doesn't match what we actually emit, which is:
void get3_ (int* ih, char* cp, char* cx, double* res, int* ier, long cp_len,
long cx_len);

long should work on Linux, but might not work e.g. on 64-bit Windows, not
really sure if the lengths there are 64-bit or 32-bit.  If 64-bit, probably
intptr_t is better (if you include stdint.h), though PR78534 claims it is
size_t.

[Bug c++/84590] [7/8 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #3)
> assumes that at least for non-vector cp_fully_fold of a CONSTRUCTOR will
> yield again a CONSTRUCTOR as well, but that is generally not the case.
> It could (at least in theory) result in error_mark_node, or VIEW_CONVERT_EXPR
> around the CONSTRUCTOR:
> or a TARGET_EXPR around the CONSTRUCTOR:

Hmm, I think cp_fully_fold should probably strip those.

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[law at redhat dot com]

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

--- Comment #28 from Jeffrey A. Law  ---
BTW, ISTM that we need Bin to chime in on the complexity of improving this in
IVOPTS -- ie, is it gcc-8 or gcc-9 material.  If the latter, then we should
adjust the target milestone.

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[law at redhat dot com]

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

--- Comment #27 from Jeffrey A. Law  ---
WRT c#21.  There is a good paper from Click on an integrated GVN/GCM/reassoc.

"Combining Analyses, Combining Optimizations"  It was published in PLDI. I've
probably got a copy here if you want it.

[Bug fortran/84594] Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> > (1) AFAICT this not documented. Is NUMERIC_STORAGE_SIZE the only parameter 
> > in
> > ISO_FORTRAN_ENV triggering a warning?
> 
> Don't know.  But, it is obviously a correct warning
> as -fdefault-integer-8 applies to only the default
> integer kind while NUMERIC_STORAGE_SIZE applies to
> all numeric types.
>
> > (2) The warning is not emitted with -fdefault-real-10 nor with
> > -fdefault-real-16. I guess this was overlooked when these options were 
> > added.
> > 
> > (3) The options -finteger-4-integer-8 and -freal-*-real-* don't trigger the
> > warning. Is it because they change all the occurrences of INT or REAL, while
> > -fdefault-* only change the implicit ones?
> AFAIK, Yes.  INTEGER(4) is known to the compiler with -finteger-4-integer-8,
> the user simply cannot use it as internally gfortran map everything
> to INTEGER(8) as-if the user actually ported the code.   In other words,
> storage association isn't broken by these options.

Do you at least agree that

(a) || flag_default_real_10 || flag_default_real_16 should be added
to flag_default_integer || flag_default_real_8 in module.c,

(b) the warning should be documented?

[Bug c/84619] New: Segmentation fault when running a c-program which is calling a fortran subroutine

[mario-baumann at web dot de]

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

Bug ID: 84619
   Summary: Segmentation fault when running a c-program which is
calling a fortran subroutine
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario-baumann at web dot de
  Target Milestone: ---

Created attachment 43531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43531=edit
contains the 4 sources: lnx_c.c, lnx_f.f, mac_c.c and mac_f.f

I have a strange segmentation fault when running the c-programm which is
calling a fortran subroutine.

The strip down created slightly different codes on linux and macOS.

GCC revision: 258059

Tested on:
(1) linux
> /Gcc/8.0.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Gcc/8.0.1/bin/gcc
COLLECT_LTO_WRAPPER=/opt/Gcc/8.0.1/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /Gcc/8.0.1/.src/configure --prefix=/Gcc/8.0.1
--enable-languages=c,c++,fortran --enable-lto --disable-nls
--disable-libquadmath --disable-libquadmath-support
Thread model: posix
gcc version 8.0.1 20180228 (experimental) (GCC) 

> /Gcc/8.0.1/bin/gcc -c -m64 -march=nocona -O1 lnx_c.c
> /Gcc/8.0.1/bin/gfortran -o z_lnx -m64 -march=nocona lnx_c.o lnx_f.f
> ./z_lnx 
Segmentation fault (core dumped)


(2) macOS
> /Gcc/8.0.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Gcc/8.0.1/bin/gcc
COLLECT_LTO_WRAPPER=/Gcc/8.0.1/libexec/gcc/x86_64-apple-darwin17/8.0.1/lto-wrapper
Target: x86_64-apple-darwin17
Configured with: /Gcc/8.0.1/.src/configure --prefix=/Gcc/8.0.1
--build=x86_64-apple-darwin17 --enable-languages=c,c++,fortran --enable-lto
--enable-stage1-checking --enable-libstdcxx-time --disable-nls
--disable-libquadmath --disable-libquadmath-support --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-as=/opt/local/bin/as --with-system-zlib
--with-pkgversion=svn-revision-258059
Thread model: posix
gcc version 8.0.1 20180228 (experimental) (svn-revision-258059)

> /Gcc/8.0.1/bin/gcc -c -m64 -march=nocona -O1 mac_c.c
> /Gcc/8.0.1/bin/gfortran -o z_mac -m64 -march=nocona mac_c.o mac_f.f
> ./z_mac
Segmentation fault: 11



Findings:
(1) -O2 instead of -O1 crashes too
(2) -O0 works fiine
(3) gcc-7.3 works fine with -O0, -O1 and -O2
(4) valgrind complains about:
==11458==at 0x501846A: _gfortran_string_index (string_intrinsics_inc.c:254)
==11458==at 0x5018483: _gfortran_string_index (string_intrinsics_inc.c:270)

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[palves at redhat dot com]

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

--- Comment #6 from Pedro Alves  ---
I see the same thing with your reduced testcase:

~~~
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400580
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x400410
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 13966] at 0x400580
~~~

0x400410 is never hit.

With:

(gdb) disassemble /s qux
Dump of assembler code for function qux(C*):
t.c:
33if (!p->c) __builtin_abort ();
   0x00400410 <+0>: callq  0x400400 
   0x00400415:  nopw   %cs:0x0(%rax,%rax,1)
   0x0040041f:  nop
...
   0x00400578 <+16>:nopl   0x0(%rax,%rax,1)

9 return false;
   0x00400580 <+0>: xor%eax,%eax
   0x00400582 <+2>: retq   
   0x00400583:  nopl   (%rax)
   0x00400586:  nopw   %cs:0x0(%rax,%rax,1)
---Type  to continue, or q  to quit---

... we see that "foo" is sharing the tail end of qux?

And we see that "0x400410", where GDB things foo's prologue ends,
is actually the end of qux's prologue:

(gdb) disassemble /s foo
Dump of assembler code for function qux(C*):
t.c:
33if (!p->c) __builtin_abort ();
   0x00400410 <+0>: callq  0x400400 
   0x00400415:  nopw   %cs:0x0(%rax,%rax,1)
   0x0040041f:  nop

When we do "b foo", gdb sets a breakpoint at 0x400580 instead (passed foo's
prologue).  I don't know why it gets it wrong when stepping into the function.