[Bug c++/88181] New: ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[asolokha at gmx dot com]

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

Bug ID: 88181
   Summary: ICE: verify_type failed (error: type variant differs
by TYPE_PACKED)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20181118 snapshot (r266255) ICEs when compiling
gcc/testsuite/g++.dg/cpp0x/constexpr-tuple2.C w/ -fpack-struct -g:

% g++-9.0.0-alpha20181118 -fpack-struct -g -c
gcc/testsuite/g++.dg/cpp0x/constexpr-tuple2.C
In file included from
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/bits/move.h:55,
 from
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/bits/stl_pair.h:59,
 from
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/utility:70,
 from
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/tuple:38,
 from gcc/testsuite/g++.dg/cpp0x/constexpr-tuple2.C:4:
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/type_traits:
In instantiation of 'struct std::conditional&,
const std::__nonesuch_no_braces&>':
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/tuple:1205:7:
  required from 'class std::tuple'
gcc/testsuite/g++.dg/cpp0x/constexpr-tuple2.C:14:31:   required from here
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/type_traits:2070:12:
error: type variant differs by TYPE_PACKED
 2070 | struct conditional
  |^~~
 
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f4b617e8f18 method basetype 
arg-types 
chain 
chain 
chain  chain >
ignored decl_1 VOID
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/tuple:1199:18
align:1 warn_if_not_align:0 context 
parms 
value 
length:4
elt:0 >
elt:1 >
elt:2 >
elt:3  value
>>>
full-name "template() && (!
_ImplicitlyMoveConvertibleTuple<_U1, _U2>())), bool>::type  >
std::tuple<_T1, _T2>::tuple(std::allocator_arg_t, const _Alloc&, std::pair<_U1,
_U2>&&) [with _Alloc = _Alloc; _U1 = _U1; _U2 = _U2; typename
std::enable_if<(std::_TC::_MoveConstructibleTuple<_U1, _U2>()
&& (! std::_TC::_ImplicitlyMoveConvertibleTuple<_U1, _U2>())),
bool>::type  = ; _T1 = t1; _T2 = t2]"

chain 
ignored decl_1 VOID
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/tuple:1189:9
align:1 warn_if_not_align:0 context 
parms 
value 
length:4
elt:0 >
elt:1 >
elt:2 >
elt:3  value
>>>
full-name "template() &&
_ImplicitlyMoveConvertibleTuple<_U1, _U2>()), bool>::type  >
std::tuple<_T1, _T2>::tuple(std::allocator_arg_t, const _Alloc&, std::pair<_U1,
_U2>&&) [with _Alloc = _Alloc; _U1 = _U1; _U2 = _U2; typename
std::enable_if<(std::_TC::_MoveConstructibleTuple<_U1, _U2>()
&& std::_TC::_ImplicitlyMoveConvertibleTuple<_U1, _U2>()),
bool>::type  = ; _T1 = t1; _T2 = t2]"
chain >> context

full-name "class std::tuple"
X() X(constX&) n_parents=1 use_template=1 interface-unknown
pointer_to_this  reference_to_this
 chain >
 
full-name "const class std::tuple"
X() X(constX&) n_parents=1 use_template=1 interface-unknown
reference_to_this >
/usr/lib/gcc/x86_64-unknown-linux-gnu/9.0.0-alpha20181118/include/g++-v9/type_traits:2070:12:
internal compiler error: verify_type failed
0x11a9383 verify_type(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.c:14313
0xb8d204 gen_type_die_with_usage
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:25375
0xb8e466 gen_type_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:25605
0xb8ecfc modified_type_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:13368
0xb8ef34 modified_type_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:13238
0xb8f12d modified_type_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:13435
0xb940cd add_type_attribute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:21532
0xb9fa77 gen_typedef_die
   

[Bug c++/88180] New: ICE in vec::quick_push(tree_node* const&)

[asolokha at gmx dot com]

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

Bug ID: 88180
   Summary: ICE in vec::quick_push(tree_node* const&)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20181118 snapshot (r266255) ICEs when compiling
gcc/testsuite/g++.dg/pr85039-2.C w/ --param ggc-min-heapsize=1024:

% g++-9.0.0-alpha20181118 --param ggc-min-heapsize=1024 -c
gcc/testsuite/g++.dg/pr85039-2.C
gcc/testsuite/g++.dg/pr85039-2.C:5:36: error: types may not be defined within
__builtin_offsetof
5 | } * d::b(__builtin_offsetof(struct { // { dg-error "types may not be
defined" }
  |^
gcc/testsuite/g++.dg/pr85039-2.C:7:12: error: types may not be defined within
__builtin_offsetof
7 |   struct a { // { dg-error "types may not be defined" }
  |^
gcc/testsuite/g++.dg/pr85039-2.C:10:5: internal compiler error: Segmentation
fault
   10 | }, i));
  | ^
0xefd97f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/toplev.c:325
0x924bec vec::quick_push(tree_node* const&)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/vec.h:978
0x924bec tree_node** vec_safe_push(vec*&, tree_node* const&)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/vec.h:770
0x924bec cp_parser_parenthesized_expression_list
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:7840
0x925a0c cp_parser_initializer
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:22209
0x94b1e5 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:20028
0x92db0f cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:13269
0x952099 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:12966
0x952820 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:4672
0x952820 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/cp/parser.c:40540
0xa5c4ab c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c-family/c-opts.c:1151

==7759== Invalid write of size 8
==7759==at 0x924BEC: quick_push (vec.h:978)
==7759==by 0x924BEC: vec_safe_push (vec.h:770)
==7759==by 0x924BEC: cp_parser_parenthesized_expression_list(cp_parser*,
int, bool, bool, bool*, unsigned int*, bool) (parser.c:7840)
==7759==by 0x925A0C: cp_parser_initializer(cp_parser*, bool*, bool*, bool)
(parser.c:22209)
==7759==by 0x94B1E5: cp_parser_init_declarator(cp_parser*,
cp_decl_specifier_seq*, vec*, bool,
bool, int, bool*, tree_node**, unsigned int*, tree_node**) (parser.c:20028)
==7759==by 0x92DB0F: cp_parser_simple_declaration(cp_parser*, bool,
tree_node**) (parser.c:13269)
==7759==by 0x952099: cp_parser_declaration(cp_parser*) (parser.c:12966)
==7759==by 0x952820: cp_parser_translation_unit (parser.c:4672)
==7759==by 0x952820: c_parse_file() (parser.c:40540)
==7759==by 0xA5C4AB: c_common_parse_file() (c-opts.c:1151)
==7759==by 0xEFD9FD: compile_file() (toplev.c:455)
==7759==by 0x815608: do_compile (toplev.c:2172)
==7759==by 0x815608: toplev::main(int, char**) (toplev.c:2307)
==7759==by 0x818C5A: main (main.c:39)
==7759==  Address 0x532cd7fb0 is not stack'd, malloc'd or (recently) free'd

[Bug debug/39385] ICE in gen_type_die_with_usage

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
It seems to stop ICEing since gcc 4.9.

[Bug tree-optimization/87011] [9 Regression] partially dead memset before strcpy not eliminated

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Right.  If more than a word remains in a store, then try to keep the starting
point word aligned.

[Bug rtl-optimization/88179] New: [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[paul.hua.gm at gmail dot com]

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

Bug ID: 88179
   Summary: [9 regression][MIPS]  pr84941.c ICE in
lra_eliminate_reg_if_possible at
lra-eliminations.c:1393  start with r266385
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.hua.gm at gmail dot com
  Target Milestone: ---

./build/gcc/cc1 -fpreprocessed pr84941.i -mel -quiet -dumpbase pr84941.c
-march=mips64r2 -mabi=64 -mllsc -mips64r2 -mno-shared -auxbase-strip pr84941.s
-O2 -version -o pr84941.s
GNU C17 (GCC) version 9.0.0 20181122 (experimental) (mips64el-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 9.0.0 20181122 (experimental) (mips64el-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b095a3a071065c8cb9dc75b4f940fa0d
during RTL pass: reload
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/pr84941.c: In function
‘foo’:
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/pr84941.c:10:1:
internal compiler error: in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1393
0xa00930 lra_eliminate_reg_if_possible(rtx_def**)
/home/paulhua/gcc_git_trunk/gcc/lra-eliminations.c:1393
0x9ed66d address_eliminator
/home/paulhua/gcc_git_trunk/gcc/lra-constraints.c:362
0x9ed755 satisfies_address_constraint_p
/home/paulhua/gcc_git_trunk/gcc/lra-constraints.c:411
0x9f4396 satisfies_address_constraint_p
/home/paulhua/gcc_git_trunk/gcc/lra-constraints.c:423
0x9f4396 process_alt_operands
/home/paulhua/gcc_git_trunk/gcc/lra-constraints.c:2305
0x9fad7d curr_insn_transform
/home/paulhua/gcc_git_trunk/gcc/lra-constraints.c:3904
0x9fdd86 lra_constraints(bool)
/home/paulhua/gcc_git_trunk/gcc/lra-constraints.c:4921
0x9e5d94 lra(_IO_FILE*)
/home/paulhua/gcc_git_trunk/gcc/lra.c:2446
0x997589 do_reload
/home/paulhua/gcc_git_trunk/gcc/ira.c:5469
0x997589 execute
/home/paulhua/gcc_git_trunk/gcc/ira.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


paulhua@gcc122:~/build/gcc-bisect$ cat pr84941.i
# 1 "/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/pr84941.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/pr84941.c"




void
foo (void)
{
  short *b[1] = { 0 };
  asm volatile ("" : "=m,m" (b), "=r,r" (b) : "1,p" (b));
}


cross-compile configure with:
../configure MISSING=texinfo MAKEINFO=missing --target=mips64el-linux-gnu
--enable-languages=c,c++

[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Sat Nov 24 06:51:26 2018
New Revision: 266426

URL: https://gcc.gnu.org/viewcvs?rev=266426=gcc=rev
Log:
PR rtl-optimization/87468
* tree-ssa-threadupdate.c (create_block_for_threading): Clear
EDGE_IGNORE on all outgoing edges of the duplicate block.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr87468.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug target/88178] New: [9 Regression] ICE in dbx_reg_number, at dwarf2out.c:13659

[asolokha at gmx dot com]

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

Bug ID: 88178
   Summary: [9 Regression] ICE in dbx_reg_number, at
dwarf2out.c:13659
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-9.0.0-alpha20181118 snapshot (r266255) ICEs when compiling
gcc/testsuite/gcc.target/i386/pr79804.c w/ -g:

% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181118 -g -c
gcc/testsuite/gcc.target/i386/pr79804.c 
gcc/testsuite/gcc.target/i386/pr79804.c: In function 'foo':
gcc/testsuite/gcc.target/i386/pr79804.c:10:1: error: frame cannot be used in
asm here
   10 | }  /* { dg-error "cannot be used in asm here" } */
  | ^
gcc/testsuite/gcc.target/i386/pr79804.c:9:3: error: invalid 'asm': invalid use
of register 'frame'
9 |   asm volatile ("# %0" : "=r"(r19));  /* { dg-error "invalid use of
register" } */
  |   ^~~
during RTL pass: final
gcc/testsuite/gcc.target/i386/pr79804.c:10:1: internal compiler error: in
dbx_reg_number, at dwarf2out.c:13659
   10 | }  /* { dg-error "cannot be used in asm here" } */
  | ^
0x5ef0d1 dbx_reg_number
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:13659
0x980607 reg_loc_descriptor
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:13721
0x9633b5 loc_descriptor
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:16486
0x966503 loc_list_from_tree_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:18286
0x9668fa loc_list_from_tree
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:18836
0x967504 add_location_or_const_value_attribute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:20053
0x967504 add_location_or_const_value_attribute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:19991
0x97752a gen_variable_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:23811
0x96c2e6 gen_decl_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:26297
0x983e84 process_scope_var
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:25758
0x98423f decls_for_scope
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:25784
0x9699b1 gen_subprogram_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:23259
0x96bf49 gen_decl_die
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:26214
0x96cb8e dwarf2out_decl
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:26782
0x96d2fe dwarf2out_function_decl
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/dwarf2out.c:26797
0x9e226f rest_of_handle_final
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:4681
0x9e226f execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/final.c:4723

[Bug other/88141] Issues with texinfo when building GCC r266351 in MSYS2

[jmm4077 at rit dot edu]

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

--- Comment #4 from Joshua Morrison  ---
The issue's also occurring for me with the latest revision of the GCC 8 branch.
Is there a step that I'm missing during the build?

[Bug c++/85569] [8/9 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
I realized the preprocessed testcase was the work-around rather than the base
failure mode.  What confused me was that even the work-around was failing, and
that's what my patch is for.

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01969.html

I spent some time looking into the initial testcase, but to no avail so far.

[Bug c++/86397] [7/8/9 Regression] g++ ICE at on valid code in nothrow_spec_p, at cp/except.c:1158

[aoliva at gcc dot gnu.org]

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

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

[Bug c++/79996] spurious -Wreturn-type on a function that calls a noreturn function

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #6)
> Well, I guess it's probably too late to go back on it now, but I thought
> warnings enabled by default weren't supposed to have any false positives,
> and this is a false positive.

Arguably it's not. Arguably the bug is that the attribute should cause a
warning, so this is a false negative for -Wignored-attributes not a false
positive for -Wreturn-type. If the attribute doesn't affect the template
parameter then it isn't calling a noreturn function, and the warning is
correct.

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #3)
> > string dummy; // for some reason this is needed to force the error to be 
> > shown as  header.h:8:16:
> 
> causes the struct to be a non-POD and the copy constructor to be created
> differently.

Right, when it says "in this function" it's referring to the copy constructor,
because that's where the uninitialized value is used.

That implicitly-defined copy constructor doesn't have a location (because it's
not present in the source code) so it gets the location of the class
definition, which is in the header.

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
i.e. this would be wrong, because there is not 'copy' in test(info_t).

> So would be better if it was as follows:
> ===
> 
> $ g++ -O2 -Werror=uninitialized -o header header.cpp
> header.cpp: In function ‘void test(info_t)’:
> header.cpp:10:12: error: ‘copy.info::registered’ is used uninitialized in

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonny Grant from comment #4)
> Also, it is "copy" that is unused uninitialized? (not "temp")

Yes, in the test(info_t) function, which is what GCC says:

header.h: In function ‘void test(info_t)’:
header.h:8:16: error: ‘copy.info::registered’ is used uninitialized in this
function


But not in main(). There it's temp that's uninitialized, as GCC says:

header.h: In function ‘int main()’:
header.h:8:16: error: ‘temp.info::registered’ is used uninitialized in this
function

[Bug libstdc++/85930] [8/9 Regression] Misaligned reference created in shared_ptr_base.h with -fno-rtti

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||semi1 at posteo dot de

--- Comment #11 from Jonathan Wakely  ---
*** Bug 88177 has been marked as a duplicate of this bug. ***

[Bug libstdc++/88177] Clang detects undefined behavior in shared_ptr_base.h

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops I marked it as a dup of the wrong bug number.

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

[Bug libstdc++/87520] [8 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||semi1 at posteo dot de

--- Comment #9 from Jonathan Wakely  ---
*** Bug 88177 has been marked as a duplicate of this bug. ***

[Bug libstdc++/88177] Clang detects undefined behavior in shared_ptr_base.h

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
See Bug 85930 comment 6.

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

[Bug libstdc++/88177] New: Calng detectes undefined behavior in shared_ptr_base.h

[semi1 at posteo dot de]

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

Bug ID: 88177
   Summary: Calng detectes undefined behavior in shared_ptr_base.h
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: semi1 at posteo dot de
  Target Milestone: ---

Created attachment 45078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45078=edit
main.ii

The clang undefined behavior finds an reference binding to address with
insufficient space in shared_ptr_base.h

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.2.0-7ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-7ubuntu1) 

clang++-7 -v:
clang version 7.0.0-3 (tags/RELEASE_700/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Candidate multilib: .;@m64
Selected multilib: .;@m64

Program which cause the error:
main.cpp:
#include 
int main()
{
auto sp = std::make_shared(12);
}

Command line to compile:
clang++-7 -std=c++11 -Og -g -fsanitize=undefined -fno-omit-frame-pointer
-fno-rtti main.cpp

Error: 

UBSAN_OPTIONS=print_stacktrace=1 ./a.out 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/shared_ptr_base.h:514:14:
runtime error: reference binding to address 0x00434e38 with insufficient
space for an object of type 'const std::type_info'
0x00434e38: note: pointer points here
 00 00 00 00  00 46 4f 69 52 69 45 00  f8 ec 43 00 00 00 00 00  39 4e 43 00 00
00 00 00  01 1b 03 3b
  ^ 
#0 0x429c8a in std::_Sp_make_shared_tag::_S_ti()
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/shared_ptr_base.h:514:7
#1 0x4299e3 in std::__shared_ptr::__shared_ptr,
int>(std::_Sp_make_shared_tag, std::allocator const&, int&&)
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/shared_ptr_base.h:1329:43
#2 0x429822 in std::shared_ptr std::allocate_shared, int>(std::allocator const&, int&&)
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/shared_ptr.h:706:14
#3 0x429665 in std::shared_ptr std::make_shared(int&&)
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/shared_ptr.h:722:14
#4 0x429557 in main /home/jr/src/main.cpp:9:15
#5 0x7f89422fa09a in __libc_start_main
/build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16
#6 0x4033c9 in _start (/home/jr/src/a.out+0x4033c9)



Notes:
The error occures only when rtti is disabled. The gcc undefined behavior
sanitizer does not detect anything

[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear

[sandra at gcc dot gnu.org]

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

--- Comment #8 from sandra at gcc dot gnu.org ---
Right, I was expecting there would be a few of them that grep/sed would miss
because of line breaks.  I can hand-patch the ones I can find, but it's not the
end of the world if a few escape -- it's not like we don't have other typos in
comments etc as well.

Are there potential problems with the automated approach in relation to
touching generated files, etc that I need to beware of?

[Bug other/54265] Documentation of "preferred attribute syntax for Types" contradicts examples in info.

[sandra at gcc dot gnu.org]

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

--- Comment #3 from sandra at gcc dot gnu.org ---
OK, if there is an actual rationale for the preferred position and it wasn't
just an accidental extrapolation, I will change the examples to conform to that
instead.  Maybe also include the rationale in the documentation?

[Bug libstdc++/59075] python pretty printer does not work at OS X

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #12 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > Tom, do you know why the types might be shown differently on OS X and
> > GNU/Linux? (see comments 7 and 8).
> > 
> > Is that because of something different in the DWARF? Is that expected for OS
> > X, or is it a GCC bug?
> 
> Can we check that this is still current on trunk after the fix for 70694 was
> applied - since that alters visibility of some symbols (maybe a long shot).
> 
> It's not expected that Darwin will do anything differently modulo (1) it
> doesn't use .cfi_xxx at present, (2) it's generally limited to DWARF2 [a
> historical issue with older versions of dsymutil, see below], although I
> hope to lift that restriction soon, since we now have a DWARF4-capable
> dsymutil
> 
> However .. the status quo is:
> 
> Darwin has the following strategy for debug.
>  1. the static linker ignores DWARF but writes a table of object file
> locations into the executable.
>  2a.  the executable + the object files can be consumed by a debug client
> (e.g. GDB)
> - the table in the exe tells the client where to find the objects and it
> can read/link the DWARF from them directly.  This often makes sense for a
> developer who is doing a lot of compile/edit/debug loops.  GDB understands
> this approach (last i tried),
> 
>  2b.  if one doesn't want to keep the objects around; the executable + the
> objects can be consumed by "dsymutil" this is Darwin's debug linker, which
> produces a monolithic debug object (which can be consumed alongside the
> actual executable to provide the debug data).  For whatever reason, the
> design wraps this linked debug object in a macOS package structure thus:
>   .dSYM/
> Contents/
>   Resources/
>DWARF/
>  exename
> 
> This applies to any DSO, so shlibs are the same (for libstdc++ the 'exename'
> would be libstdc++.dlib).
> 
>   - I'm not 100% sure whether upstream GDB still (or ever did) understands
> the packaged version, Apple's GDB did - but that's long out of date.

I tried merging upstream GDB and Apple's GDB once, but got distracted by yak
shaving and eventually ended up breaking things worse than when I had
started... if you want to try picking up where I left off with merging them,
though, my repo is here: https://github.com/cooljeanius/apple-gdb-1824 
For this particular issue, of gdb understanding the packaged version of the
debug objects, check macosx-tdep.c:
https://github.com/cooljeanius/apple-gdb-1824/blob/master/src/gdb/macosx/macosx-tdep.c
And also macosx-bundle-utils.c:
https://github.com/cooljeanius/apple-gdb-1824/blob/master/src/gdb/macosx/macosx-bundle-utils.c

> 
> ==
> 
> As for reading Mach-O DWARF, binutils works for x86_64-apple-darwin last I
> tried (you have to point it at the actual linked DWARF tho, I don't think
> any of the tools understand the .dSYM package layout).
> 
> Alternately, the llvm binutils look-alikes are getting more compatible and
> consume Mach-O.
> 
> Caveat, I've, but not built/tested binutils / GDB for at least 6 months on
> Darwin, so my comments might be out of date.

[Bug c++/88176] New: Overload resolution chooses template non-member operator over non-template member operator

[Simon.Richter at hogyros dot de]

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

Bug ID: 88176
   Summary: Overload resolution chooses template non-member
operator over non-template member operator
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

Similar to #78291:

struct foo
{
foo operator+(foo const ) const { throw; }
};

template
auto operator+(T const , foo const ) -> decltype(rhs + lhs)
{
return rhs + lhs;
}

void test()
{
foo f1, f2;
f1 + f2;
}

This fails to compile because the template is evaluated recursively. I'd expect
the non-template overload to win.

MSVC compiles this correctly.

[Bug c++/79996] spurious -Wreturn-type on a function that calls a noreturn function

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Liška from comment #5)
> (In reply to Eric Gallager from comment #4)
> > (In reply to Eric Gallager from comment #3)
> > > Might want to revisit this now that -Wreturn-type is on by default
> > 
> > The other Martin did that; cc-ing him
> 
> Sorry, I'm not a C++ FE developer. Yes, I enabled the warning by default.
> What is the question related to my person here?

Well, I guess it's probably too late to go back on it now, but I thought
warnings enabled by default weren't supposed to have any false positives, and
this is a false positive. Which I realize still isn't question, but I already
pre-emptively answered the part that was going to be a question with the "I
guess it's probably too late to go back on it now" disclaimer myself, so... eh,
never mind, sorry.

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[jg at jguk dot org]

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

--- Comment #4 from Jonny Grant  ---
Also, it is "copy" that is unused uninitialized? (not "temp")

The line carat is also incorrect I believe, it should be header.cpp:10:12 ?


So would be better if it was as follows:
===

$ g++ -O2 -Werror=uninitialized -o header header.cpp
header.cpp: In function ‘void test(info_t)’:
header.cpp:10:12: error: ‘copy.info::registered’ is used uninitialized in this
function [-Werror=uninitialized]
 temp = copy;
   ~^~
cc1plus: some warnings being treated as errors

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
> string dummy; // for some reason this is needed to force the error to be 
> shown as  header.h:8:16:

causes the struct to be a non-POD and the copy constructor to be created
differently.

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

[iii at linux dot ibm.com]

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

--- Comment #7 from Ilya Leoshkevich  ---
Apparently, for this specific case doing more of hard register copy
propagation is enough.  I've just tried running pass_cprop_hardreg
before pass_thread_prologue_and_epilogue, and it helped.

So, would running a mini-cprop_hardreg instead of just
copyprop_hardreg_forward_bb_without_debug_insn (entry_block) be
reasonable here?  Something along the lines of:

- Do something like pre_and_rev_post_order_compute_fn (), but do not go
  further from bbs which contain insns satisfying
  requires_stack_frame_p (), since shrink-wrapping cannot happen past
  those anyway.

  Same for bbs which have more than 1 predecessor, since
  cprop_hardreg forgets everything it saw when it encounters those.  Not
  sure if a reasonable merge function can be defined for struct
  value_data to improve this?

  Maybe also stop completely when a certain number of bbs is found.

- Do something like pass_cprop_hardreg::execute (), but use only bbs
  computed during the previous step.  Btw, would reverse postorder be
  the "more intelligent queuing of blocks" mentioned in
  pass_cprop_hardreg::execute ()?



When you say that what IRA does is not effective, do you mean just the
need to track indirect hard register copies, or can it be improved even
further?

[Bug c++/88175] Showing header file instead of source code line in error

[jg at jguk dot org]

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

--- Comment #2 from Jonny Grant  ---
Created attachment 45077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45077=edit
testcase

[Bug c++/88175] Showing header file instead of source code line in error

[jg at jguk dot org]

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

--- Comment #1 from Jonny Grant  ---
Edit header.h to comment out this line, and the issue disapears.

string dummy; // for some reason this is needed to force the error to be
shown as  header.h:8:16:

[Bug c++/88175] New: Showing header file instead of source code line in error

[jg at jguk dot org]

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

Bug ID: 88175
   Summary: Showing header file instead of source code line in
error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Also reproduced in g++ 8

$ g++ -O2 -Werror=uninitialized -o header header.cpp
In file included from header.cpp:5:0:
header.h: In function ‘void test(info_t)’:
header.h:8:16: error: ‘copy.info::registered’ is used uninitialized in this
function [-Werror=uninitialized]
 typedef struct info
^~~~
header.h: In function ‘int main()’:
header.h:8:16: error: ‘temp.info::registered’ is used uninitialized in this
function [-Werror=uninitialized]
 typedef struct info
^~~~
cc1plus: some warnings being treated as errors


Expected it to show the following
==

$ g++ -O2 -Werror=uninitialized -o header header.cpp
header.cpp: In function ‘void test(info_t)’:
header.cpp:10:10: error: ‘copy’ is used uninitialized in this function
[-Werror=uninitialized]
 temp = copy;
 ~^~
cc1plus: some warnings being treated as errors

[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
(In reply to Arthur O'Dwyer from comment #13)
> Re https://gcc.gnu.org/viewcvs?rev=266386=gcc=rev — awesome, but
> I'm curious: Why `deque` before `vector`?
> I mean are you planning eventually to add the specializations of
> `__is_trivially_relocatable` for `vector`, `forward_list`,
> `reference_wrapper`, `optional`, `pair`, etc. etc., and you just decided to
> start with `deque`? or was there a specific motivating case?

Because deque is not noexcept-move-constructible. This means that by default it
cannot execute the destructors right after the move constructors, so it does
not have a chance to remove the unnecessary allocation. We really need to help
it at the library level, and the potential gain is significant.
For vector, the compiler sees a loop copying contiguous data from one place to
another, so it should be able to produce a call to memcpy without help: PR
86024. There may be complications related to aliasing, I haven't looked at it
yet. But I believe we should first explore making the compiler more clever,
which would apply to a lot of code, before optimizing a special case in one
library (which we could still do as a stopgap).
I expect we may add some specializations for wrapper types like
pair/tuple/optional/etc because we don't have compiler support to automatically
handle them (like your attribute), although I am not sure how far we should go
(without compiler support). Specializing for one type was a bit of a proof of
concept, checking that the code was ready for it, it isn't a promise to
specialize a lot more. I do still hope some version of destructive move will
eventually be standardized and resolve the issue.

This is all just my opinion, it may change, and others (in particular the
maintainers) may have a different opinion.

By the way, there won't be anything new for several months, this is gcc's
hibernation season where it tries to properly digest all it has eaten during
the summer.

[Bug bootstrap/88157] [9 Regression] ICE when building libgo encoding/gob.lo starting with r266385

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 23 22:00:43 2018
New Revision: 266422

URL: https://gcc.gnu.org/viewcvs?rev=266422=gcc=rev
Log:
2018-11-23  Vladimir Makarov  

PR bootstrap/88157
* ira-costs.c (record_operand_costs): Use bigger hard reg class if
its mode does not fit to the original class.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c

[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed

[arthur.j.odwyer at gmail dot com]

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

--- Comment #13 from Arthur O'Dwyer  ---
Re https://gcc.gnu.org/viewcvs?rev=266386=gcc=rev — awesome, but I'm
curious: Why `deque` before `vector`?
I mean are you planning eventually to add the specializations of
`__is_trivially_relocatable` for `vector`, `forward_list`, `reference_wrapper`,
`optional`, `pair`, etc. etc., and you just decided to start with `deque`? or
was there a specific motivating case?

[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 23 21:13:44 2018
New Revision: 266420

URL: https://gcc.gnu.org/viewcvs?rev=266420=gcc=rev
Log:
PR tree-optimization/87756
* gcc.dg/builtin-memchr-2.c: Scan the gimple dump instead of
optimized.
* gcc.dg/builtin-memchr-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-memchr-2.c
trunk/gcc/testsuite/gcc.dg/builtin-memchr-3.c

[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> The following patch restores the errors

It doesn't seem to cause any regressions in the testsuite either. Feel free to
commit this fix, Dominique.



Side note: In principle I would have preferred something like this:


diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index f22241da60b..e40c23f2a5d 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1374,7 +1374,8 @@ gfc_match_assignment (void)

   gfc_check_do_variable (lvalue->symtree);

-  if (lvalue->ts.type == BT_CLASS)
+  if (lvalue->ts.type == BT_CLASS && (rvalue->ts.type != BT_CLASS
+ || gfc_expr_attr (rvalue).class_ok))
 gfc_find_vtab (>ts);

   return MATCH_YES;


But that ICEs on class_array_3.f03.

[Bug other/54265] Documentation of "preferred attribute syntax for Types" contradicts examples in info.

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
The earlier position is preferred because logically at the closing brace 
the type should be fully defined and it should no longer be possible to 
change properties of it through attributes coming afterwards.

Note that for [[]]-style attributes (standard C++, also expected to be in 
C2X), an attribute after the struct/union/enum keyword appertains to the 
type being defined and becomes a property of that type whenever used, 
while one after the closing brace appertains to the type only for that 
declaration, not for any subsequent uses of that struct/union/enum.

[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
An ordered comparison (< <= > >=) with qNaN raises the "invalid" 
exception.  An equality comparison (== !=) does not, and nor do 
__builtin_isless etc.

I don't know how C++ constexpr rules relate to floating-point exceptions.

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[moritz at bunkus dot org]

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

Moritz Bunkus  changed:

   What|Removed |Added

 CC||moritz at bunkus dot org

--- Comment #13 from Moritz Bunkus  ---
I'm the author of MKVToolNix which has been mentioned as being affected by the
bug. I've just re-compiled my whole mingw cross compilation setup (using MXE)
using gcc 8.2.0 release + your proposed patch. The patch applies with offsets
but without rejects.

I'm happy to report that both all the components of MXE as well as MKVToolNix
itself compile fine, and more importantly MKVToolNix runs fine, too.

From my point of view the patch does what it's supposed to.

Note that I've only built 64-bit binaries, not 32-bit ones.

[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> (In reply to G. Steinmetz from comment #0)
> > With a typo, down to at least gcc-5 :
> > 
> > 
> > $ cat z1.f90
> > program p
> >type t
> >   integer :: a
> >end type
> >type(t) :: x
> >data x /t()1/
> >print *, x
> > end
> > 
> > 
> > $ gfortran-9-20181118 -c z1.f90
> > 0x618fae gfc_format_decoder
> > ../../gcc/fortran/error.c:947
> > 0x131577e pp_format(pretty_printer*, text_info*)
> > ../../gcc/pretty-print.c:1390
> > 0x130b125 diagnostic_report_diagnostic(diagnostic_context*, 
> > diagnostic_info*)
> > ../../gcc/diagnostic.c:1015
> > 0x618e4c gfc_error_opt
> > ../../gcc/fortran/error.c:1313
> > 0x61a3f0 gfc_error(char const*, ...)
> > ../../gcc/fortran/error.c:1342
> > 0x675e10 build_actual_constructor
> > ../../gcc/fortran/primary.c:2934
> 
> Interesting bug.  The pointer components of gfc_current_locus are NULL.
> Changing the use of %C to %L in gfc_error and using comp->loc yields
> 
> troutmask:sgk[203] gfcx -c a.f90
> a.f90:3:18:
> 
> 3 |   integer :: a
>   |  1
> Error: No initializer for component 'a' given in the structure constructor
> at (1)
> 
> which is of course the bogus locus.  Completely suppressing %C
> yields an error message but not a locus and source line output.

This sets the locus correctly.

Index: primary.c
===
--- primary.c   (revision 266386)
+++ primary.c   (working copy)
@@ -3212,6 +3212,7 @@ gfc_match_structure_constructor (gfc_symbol *sym, gfc_
   e = gfc_get_expr ();
   e->symtree = symtree;
   e->expr_type = EXPR_FUNCTION;
+  e->where = gfc_current_locus;

   gcc_assert (gfc_fl_struct (sym->attr.flavor)
  && symtree->n.sym->attr.flavor == FL_PROCEDURE);

[Bug c++/88174] Make __real__ += __val usable in constexpr context.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to emsr from comment #0)
> While updating libstdc++ for constexpr operators I came across this:
> __real__ _M_value += __z.real();
> is not constexpr even though
> __real__ _M_value = __z.real();
> is.

Is it? I get "error: modification of '__real__ x' is not a constant
expression".
cxx_eval_store_expression has special cases for ARRAY_REF, BIT_FIELD_REF,
COMPONENT_REF, maybe it needs more.

[Bug other/54265] Documentation of "preferred attribute syntax for Types" contradicts examples in info.

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from sandra at gcc dot gnu.org ---
The language has been changed a little bit since this PR was filed, but the
problem still exists on trunk.

The text that "the former syntax is preferred" originated in r115086, a patch
to overhaul the implementation of the "visibility" attribute in C++.  The
"visibility" attribute for C++ classes has the restriction that it has to
appear before the body of the class.  But I didn't see any discussion or
justification about why this should be a general preference for all attributes
in the mail thread for that patch, which starts here:

https://gcc.gnu.org/ml/gcc-patches/2006-06/msg01302.html

Prior to that the text just presented both possible locations for type
attributes without saying one was better than the other.  I think the best fix
for this is to remove the problematic recommendation again.  The docs for the
"visibility" type attribute do explicitly say that it has to go before the
class body, and I think that's adequate.

[Bug c++/86900] [8/9 Regression] -gdwarf-5 -O2 -ffunction-sections = assembler error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/86917] [7/8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
The last class' array can have even just a single element, like:
struct A
{
  constexpr A () : c (0) {}
  static const A z;
  unsigned c; 
};

struct B
{
  typedef A W[4];
  constexpr B () : w ({ A::z, A::z, A::z, A::z }) {}
  W w; 
};

struct C
{
  C ();
  B w[1];
};

C::C ()
{
} 

cxx_eval_array_reference is called with an ARRAY_REF {z, z, z, z}[0] and
ctx->ctor is properly a CONSTRUCTOR with A type.

The innermost ctx->ctor is created when calling cxx_eval_constant_expression
on TARGET_EXPR >;
So, should something have cleared ctx->ctor again, should
cxx_eval_array_reference (but cxx_eval_component_reference is similar) create
new context and build new new_ctx.ctor, or is ARRAY_REF of a CONSTRUCTOR not
expected to appear?

[Bug fortran/88169] Rejects USE rename of namelist group

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Neil Carlson from comment #5)
> Stated a bit more clearly, the question is, whether in
> 
>   The namelist-group-name shall not be a name accessed by use association.
> 
> the name (in the scope of the declaration) is accessed by use association,
> or the name is accessed in another scope by use association.

I've asked on the J3 mailing list for clairfication.  14.2.2
say ", identifiers, and namelist groups in a module."  Namelist 
groups is a bit vague, here.  Does this mean namelist group names 
or namelist group objects.  My current thinking is C8102 is to
prevent

  module foo

namelist /bar/ ...
  end module

  program bah
use foo
real x
namelist /bar/x
...
  end program bah

where program bar is trying to extend the namelist-group-object-list.

[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Patch committed in r266418.

[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Nov 23 18:45:45 2018
New Revision: 266418

URL: https://gcc.gnu.org/viewcvs?rev=266418=gcc=rev
Log:
PR tree-optimization/87756 - missing unterminated argument warning using
address of a constant character

gcc/ChangeLog:

PR tree-optimization/87756
* expr.c (string_constant): Synthesize a string literal from
the address of a constant character.
* tree.c (build_string_literal): Add an argument.
* tree.h (build_string_literal): Same.

gcc/testsuite/ChangeLog:

PR tree-optimization/87756
* gcc.dg/builtin-memchr-2.c: New test.
* gcc.dg/builtin-memchr-3.c: Same.
* gcc.dg/warn-sprintf-no-nul-2.c: Same.


Added:
trunk/gcc/testsuite/gcc.dg/builtin-memchr-2.c
trunk/gcc/testsuite/gcc.dg/builtin-memchr-3.c
trunk/gcc/testsuite/gcc.dg/warn-sprintf-no-nul-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/88174] New: Make __real__ += __val usable in constexpr context.

[emsr at gcc dot gnu.org]

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

Bug ID: 88174
   Summary: Make __real__ += __val usable in constexpr context.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emsr at gcc dot gnu.org
  Target Milestone: ---

While updating libstdc++ for constexpr operators I came across this:
__real__ _M_value += __z.real();
is not constexpr even though
__real__ _M_value = __z.real();
is.

I was able to use a workaraound with complex::__rep() but having the op= JUST
WORK would have made the patch less invasive.

I request that for the usual arithmetic operators @ = [+-*/]
__real__ _M_value @= __re;
__imag__ _M_value @= __im;
be available in contexpr contexts.

[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
-fno-trapping-math is relevant. Gcc believes that comparing QNaN to something
requires setting a flag in fenv, which can only be done at runtime. I expect
that's wrong, or almost any operation on double would not be constexpr because
of the inexact flag (that would have been a consistent choice, but most people
don't care about fenv...).

[Bug fortran/88169] Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from Neil Carlson  ---
Stated a bit more clearly, the question is, whether in

  The namelist-group-name shall not be a name accessed by use association.

the name (in the scope of the declaration) is accessed by use association,
or the name is accessed in another scope by use association.

[Bug c++/86905] [7/8/9 Regression] g++ ICE on valid code: verify_cgraph_node failed

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
extern "C" inline void foo () {}
static void bar () __attribute__((__weakref__("foo")));
void baz () { bar (); }

I've tried to:
--- cgraph.h.jj 2018-11-09 21:16:44.792168407 +0100
+++ cgraph.h2018-11-23 19:18:38.874777589 +0100
@@ -377,7 +377,11 @@ public:
  constructors.  */
   inline bool comdat_local_p (void)
   {
-return (same_comdat_group && !TREE_PUBLIC (decl));
+if (!same_comdat_group || TREE_PUBLIC (decl))
+  return false;
+if (weakref)
+  return get_alias_target ()->comdat_local_p ();
+return true;
   }

   /* Return true if ONE and TWO are part of the same COMDAT group.  */

but it ICEs later on.  Honza, can you please have a look?

[Bug testsuite/88098] [9 Regression] FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Nov 23 18:23:31 2018
New Revision: 266417

URL: https://gcc.gnu.org/viewcvs?rev=266417=gcc=rev
Log:
PR testsuite/88098 - FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c

gcc/c/ChangeLog:

PR testsuite/88098
* c-typeck.c (convert_arguments): Call builtin_decl_explicit instead.
(maybe_warn_builtin_no_proto_arg): Handle short enum to int promotion.

gcc/testsuite/ChangeLog:

PR testsuite/88098
* gcc.dg/Wbuiltin-declaration-mismatch-4.c: Adjust.
* gcc.dg/Wbuiltin-declaration-mismatch-5.c: New test.
* gcc.dg/torture/pr67222.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-5.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-4.c
trunk/gcc/testsuite/gcc.dg/torture/pr67222.c

[Bug testsuite/88098] [9 Regression] FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r266417.

[Bug testsuite/88098] [9 Regression] FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r266417.

[Bug fortran/88169] Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

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

--- Comment #4 from Neil Carlson  ---
I think the intent of

C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.

is to say you can't define a namelist with a name accessed by use association.
That seems to fit best with the Note that references it.

However, I suppose it could be taken to mean that a namelist-group cannot be
accessed via use association. But that flies in the face of 14.2.2

  The USE statement provides the means by which a scoping unit accesses named
  data objects, derived types, procedures, abstract interfaces, generic
  identifiers, and namelist groups in a module.

which clearly indicates namelist groups can be accessed by use association.

[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr

[g...@christoph-conrads.name]

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

--- Comment #2 from Christoph Conrads  ---
Created attachment 45076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45076=edit
Code pre-processed with GCC 6.3.0 on Raspbian 9.4

The file was created with
$ g++ -Wextra -Wall -std=c++11 -pedantic --save-temps nan.cpp
on Raspbian 9.4 (codename stretch).

[Bug c++/86905] [7/8/9 Regression] g++ ICE on valid code: verify_cgraph_node failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r211434.

[Bug c++/88173] `std::numeric_limits::quiet_NaN()` is not constexpr

[g...@christoph-conrads.name]

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

--- Comment #1 from Christoph Conrads  ---
Created attachment 45075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45075=edit
Code pre-processed with GCC 7.3.0 on Ubuntu 18.04 LTS

This file was created with
$ g++ -Wextra -Wall -std=c++11 -pedantic --save-temps nan.cpp
on Ubuntu 18.04 LTS.

[Bug go/88171] [9 Regression] libgo bootstrap failure on x86_64-linux-gnu (32bit multilib): ICE: Maximum number of LRA assignment passes is achieved (30)

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||bergner at vnet dot ibm.com,
   ||vmakarov at redhat dot com

--- Comment #1 from Ian Lance Taylor  ---
This seems unlikely to be related to the Go frontend.  CC'ing Vlad for LRA
thoughts and Peter Bergner because he seems to have made recent changes in this
area.

[Bug c++/88173] New: `std::numeric_limits::quiet_NaN()` is not constexpr

[g...@christoph-conrads.name]

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

Bug ID: 88173
   Summary: `std::numeric_limits::quiet_NaN()` is not
constexpr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@christoph-conrads.name
  Target Milestone: ---

Consider the following C++11 code:

$ cat nan.cpp 
#include 

constexpr bool foo(double x)
{
return !(x <= 0);
}

int main()
{
static_assert(std::numeric_limits::has_quiet_NaN, "");
static_assert(!(0 <= std::numeric_limits::quiet_NaN()), "");
static_assert(foo(std::numeric_limits::quiet_NaN()), "");
}

I expect this code to compile because `foo()` is a constexpr function and
because `std::numeric_limits::quiet_NaN()` must be a constexpr function
according to §18.3.2.4 of the C++ standard draft N3337 (and because there are
quiet NaNs on my computer). Nevertheless, the code fails to compile with GCC:

$ g++ -Wextra -Wall -std=c++11 -pedantic nan.cpp
nan.cpp: In function ‘int main()’:
nan.cpp:12:2: error: non-constant condition for static assertion
  static_assert(foo(std::numeric_limits::quiet_NaN()), "");
  ^
nan.cpp:12:19:   in constexpr expansion of
‘foo(std::numeric_limits::quiet_NaN())’
nan.cpp:5:13: error: ‘(+QNaN <= 0.0)’ is not a constant expression
  return !(x <= 0);
  ~~~^

The errors is the same with GCC 7.3.0 on Ubuntu 18.04 LTS (Bionic Beaver), GCC
7.3.0 on Gentoo (no output posted), and GCC 6.3.0 on Raspbian (output below).

$ lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic
$ g++ -Wextra -Wall -std=c++11 -pedantic -v nan.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-Wpedantic' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE nan.cpp -quiet -dumpbase nan.cpp -mtune=generic -march=x86-64
-auxbase nan -Wextra -Wall -Wpedantic -std=c++11 -version
-fstack-protector-strong -Wformat-security -o /tmp/ccSEEcsH.s
GNU C++11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, 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
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, 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: 1bfae38ae5df64de6196cbd8c3b07d86
nan.cpp: In function ‘int main()’:
nan.cpp:12:2: error: non-constant condition for static assertion
  static_assert(foo(std::numeric_limits::quiet_NaN()), "");
  ^
nan.cpp:12:19:   in constexpr expansion of
‘foo(std::numeric_limits::quiet_NaN())’

[Bug c/88172] attribute aligned of zero silently accepted but ignored

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Martin Sebor  ---
Clang rejects the test case with the following errors:

t.c:1:17: error: requested alignment is not a power of 2
__attribute__ ((aligned (0))) void f (void);
^~
t.c:4:17: error: requested alignment is not a power of 2
__attribute__ ((aligned (0))) int i;
^~
t.c:7:17: error: requested alignment is not a power of 2
__attribute__ ((aligned (0))) typedef int Int0;
^~
t.c:11:17: warning: '_Alignof' applied to an expression is a GNU extension
[-Wgnu-alignof-expression]
_Static_assert (_Alignof (i) == _Alignof (int), "#4");

[Bug middle-end/87296] [8/9 Regression] -Wstringop-overflow false positive due to bogus MEM_REF type

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The MEM_REF type is significant only when actually accessing that memory, for
_REF[...]; it is insignificant and you really shouldn't assume anything
from it except for the address computation (like if it was _7 + 4).
Not really sure why we don't just fold _REF[x, y] to x p+ y though if x is
SSA_NAME.

Another example:

struct S { char a[4]; char b[6]; char c[2]; };
struct T { char a[10]; char b[4]; char c[2]; };
union U { struct S s; struct T t; };

void bar (union U *);
void baz (char *, char *, char *);

void
foo (union U *u)
{
  char (*q)[4] = >s.a;
  q++;
  baz ((char *) q, >s.b[2], >s.b[6]);
  bar (u);
  __builtin_strncpy (>t.a[4], "abcdef", 6);
}

Because pointer conversions are useless, one pointer can be replaced for
another one which has provenly the same value, but might point to different
fields etc.

[Bug c/88172] New: attribute aligned of zero silently accepted but ignored

[msebor at gcc dot gnu.org]

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

Bug ID: 88172
   Summary: attribute aligned of zero silently accepted but
ignored
   Product: gcc
   Version: 9.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: ---

According to the the latest GCC 9 manual the argument to the aligned variable
attribute is required to be a power of 2:

The aligned attribute specifies a minimum alignment for the variable or
structure field, measured in bytes. When specified, alignment must be an
integer constant power of 2.

However, GCC silently also accepts and ignores an alignment of zero.  Either
the manual should be updated or GCC should issue a warning noting that that
attribute is ignored.  I lean toward the latter for the GNU attribute, even
though C11 explicitly specifies that in _Alignof, a zero argument is ignored
(not sure why this is so).

$ cat t.c && gcc -S -Wall -Wextra t.c
__attribute__ ((aligned (0))) void f (void);
_Static_assert (__alignof__ (f) == __alignof__ (void ()));

__attribute__ ((aligned (0))) int i;
_Static_assert (__alignof__ (i) == __alignof__ (int));

__attribute__ ((aligned (0))) typedef int Int0;
_Static_assert (__alignof__ (Int0) == __alignof__ (int));

_Alignas (0) int j;
_Static_assert (_Alignof (i) == _Alignof (int));
$

[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any

[jeff at jgarrett dot org]

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

--- Comment #3 from Jeff Garrett  ---
That's such a good point about the local types in general.

Considering that the gdb python API seems to prefer readable names, e.g. for
lookup, and those are not standard nor unique, might it be perhaps preferable
to avoid going through the regex to get the manager type, and from that the
contained type? Something like this?

mgr = self.val['_M_manager']
if mgr != 0:
# cast to uintptr_t doesn't seem to be necessary
func = gdb.block_for_pc(long(mgr))
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
self.contained_type = gdb.lookup_symbol('_Tp', func)[0].type
valptr = None
mgrfuncname = func.function.name
if
mgrfuncname.startswith('{0}::_Manager_internal'.format(self.typename)):
valptr = self.val['_M_storage']['_M_buffer'].address
elif
mgrfuncname.startswith('{0}::_Manager_external'.format(self.typename)):
valptr = self.val['_M_storage']['_M_ptr']
else:
raise ValueError("Unknown manager function in %s" %
self.typename)
contained_value =
valptr.cast(self.contained_type.pointer()).dereference()

We can lookup the symbol for the formal template parameter of the manager by
its name ('_Tp') in the context of the block for the _S_manage function. I'm
not an expert in any of this, so there may be a reason this is not preferable.
It does seem to work with some fundamental types and std::string as well (with
no magic to handle the typedef).

It still fails in the multiple local lambdas case... But that seems like an
easier to solve problem, because I believe the DWARF debugging has enough
information to know which lambda is _Tp in each of the instantiations, and gdb
is just getting confused. I think it should work in principle.

[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
See the glambda example in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html

Core 1937 seems relevant here.

[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
The non-normative note in [expr.prim.lambda.closure] p8 does seem to support
GCC's semantics. It suggests the returned function pointer is to an invoker
function not the operator() itself. The {} initializes the argument of the
invoker, which then forwards it to the operator() resulting in a move
construction.

[Bug fortran/88169] Rejects USE rename of namelist group

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Fortran 95 contains
> 
> NOTE 11.8
> 
> The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name
> from appearing as a common-block-object in a COMMON statement, an
> equivalence-
> object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST
> statement, respectively. There is no prohibition against the local-name
> appearing as a common-block-name or a namelist-object.
> 
> This appears to prohibit 
> 
>   program main
> use foo_nml, only: bar => foo
> namelist /bah/ bar   ! <-- Invalid

Upon further reflection, the Note seems to prohibit

 namelist /bar/x  ! Local name is namelist-group-name, adding x to group.

> x = 42
> write(*,nml=bar)

But, the constraints make foo inaccess from the get-go.

[Bug c++/85861] g++ -Wconversion misses int to size_t

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
My guess is that we don't want to warn about conversions that are well-defined
and the original value can be obtained by a round-trip. Converting a size_t to
an int is lossy, i.e. converting back to size_t may not give the original
value. But converting an int to size_t and back to an int is value preserving.

So I can see why it makes sense to have different warnings for lossy and
non-lossy conversions.

[Bug middle-end/87296] [8/9 Regression] -Wstringop-overflow false positive due to bogus MEM_REF type

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The MEM_REF type must mean something, otherwise why have it at all? (If it's
completely meaningless it could/should just be null or void or error_mark_node
instead to prevent using it.)  Is it just that array bounds in the type are
unreliable?  Unless it really is completely useless (in which case we should
make it so) it would be helpful to summarize the conditions when it can safely
be relied on.

[Bug go/88171] New: [9 Regression] libgo bootstrap failure on x86_64-linux-gnu (32bit multilib): ICE: Maximum number of LRA assignment passes is achieved (30)

[doko at debian dot org]

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

Bug ID: 88171
   Summary: [9 Regression] libgo bootstrap failure on
x86_64-linux-gnu (32bit multilib): ICE: Maximum number
of LRA assignment passes is achieved (30)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

seen with 20181123, r266404:

during RTL pass: reload
../../../../src/libgo/go/encoding/gob/decode.go: In function
'gob.decodeSlice..1encoding/gob.Decoder':
../../../../src/libgo/go/encoding/gob/decode.go:613:1: internal compiler error:
Maximum number of LRA assignment passes is achieved (30)

  613 | func (dec *Decoder) decodeSlice(state *decoderState, value
reflect.Value, elemOp decOp, ovfl error, helper decHelper) {
  | ^
0xbc84ae lra_assign(bool&)
../../src/gcc/lra-assigns.c:1669
0xbc323d lra(_IO_FILE*)
../../src/gcc/lra.c:2508
0xb7af79 do_reload
../../src/gcc/ira.c:5469
0xb7af79 execute
../../src/gcc/ira.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
make[10]: *** [Makefile:2835: encoding/gob.lo] Error 1
make[10]: Leaving directory '/<>/build/x86_64-linux-gnu/32/libgo'
make[9]: *** [Makefile:2233: all-recursive] Error 1
make[9]: Leaving directory '/<>/build/x86_64-linux-gnu/32/libgo'
make[8]: *** [Makefile:1158: all] Error 2
make[8]: Leaving directory '/<>/build/x86_64-linux-gnu/32/libgo'
make[7]: *** [Makefile:3059: multi-do] Error 1
make[7]: Leaving directory '/<>/build/x86_64-linux-gnu/libgo'
make[6]: *** [Makefile:3027: all-multi] Error 2

[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
--- gcc/cp/cp-gimplify.c.jj 2018-11-17 00:16:41.924381941 +0100
+++ gcc/cp/cp-gimplify.c2018-11-23 17:29:24.764459373 +0100
@@ -1108,6 +1108,18 @@ cp_genericize_r (tree *stmt_p, int *walk
   || (TREE_CODE (stmt) == AGGR_INIT_EXPR && AGGR_INIT_FROM_THUNK_P
(stmt)))
 {
   *walk_subtrees = 0;
+  /* For CALL_EXPRs, if the arguments aren't decls, recurse into them
+though.  See PR86943.  */
+  if (TREE_CODE (stmt) == CALL_EXPR)
+   {
+ unsigned int n = call_expr_nargs (stmt);
+ for (unsigned int i = 0; i < n; i++)
+   {
+ tree  = CALL_EXPR_ARG (stmt, i);
+ if (!DECL_P (arg))
+   cp_walk_tree (, cp_genericize_r, data, NULL);
+   }
+   }
   return NULL;
 }

seems to fix the double indirection bug (and in make check-c++-all doesn't seem
to regress anything else).  That said, the move constructor is still called
even with -std=c++17 or -std=c++2a.

[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
I might be wrong about the C++14 rules ... maybe the {} initializer should
directly initialize the parameter, without any move.

I don't know if we need to fix the incorrect argument to the move constructor
as well as prevent that move, so the incorrect move doesn't remain latent.

[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9 Regression] Wrong code |[7/8/9 Regression] Wrong
   |when converting stateless   |code when converting
   |generic lambda to function  |stateless generic lambda to
   |pointer |function pointer
  Known to fail||7.3.1

--- Comment #5 from Jonathan Wakely  ---
I see the wrong behaviour for GCC 7.3.1 so it seems to have regressed since
7.3.0

I think GCC is allowed to use a default constructor then move constructor in
C++14 mode, although ideally it would elide the move. In C++17 mode I think
it's required to elide it.

So Clang and EDG's behaviour is preferable for C++14, and required for C++17.

[Bug c++/86943] [8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I haven't analyzed the code to say what it should do, but EDG agrees with
Clang.

[Bug c++/86943] [8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
And, note that clang 5/6 don't call the move ctor at all and only one dtor. 
What is correct?

[Bug c++/86943] [8/9 Regression] Wrong code when converting stateless generic lambda to function pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
extern "C" int printf (const char *fmt, ...);

struct S
{
  S () { printf ("default-construct %p\n", this); }
  S (const S ) { printf ("copy-construct %p from %p\n", this, ); }
  S (S &) noexcept { printf ("move-construct %p from %p\n", this, ); }
  ~S () { printf ("destroy %p\n", this); }
};

using F = void (*) (S);

F
foo ()
{
  return [] (auto val) { printf ("called %p\n", ); };
}

int
main ()
{
  volatile F cb = foo ();
  cb ({});
  return 0;
}

The extra indirection is because in _FUN we have:
<::operator() (0B, _EXPR >>
  (struct S &)  ) >;
return;
and CALL_FROM_THUNK_P is set on the operator() call.
cp_genericize on _FUN changes the D.2160 argument, originally with type S, is
changed to S & and the PARM_DECL turned into DECL_BY_REFERENCE one, but because
the call is CALL_FROM_THUNK_P, no adjustment of the arguments is done:
  /* Don't dereference parms in a thunk, pass the references through. */
  if ((TREE_CODE (stmt) == CALL_EXPR && CALL_FROM_THUNK_P (stmt))
  || (TREE_CODE (stmt) == AGGR_INIT_EXPR && AGGR_INIT_FROM_THUNK_P (stmt)))
{
  *walk_subtrees = 0;
  return NULL;
}
Do we want to just prevent changing the direct PARM_DECL arguments of such
calls, but still recurse into more complex arguments?  Or is it incorrect that
CALL_FROM_THUNK_P is set here?

[Bug libstdc++/65229] pretty-printer exception on std::bitset<0>

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #1 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/65229] pretty-printer exception on std::bitset<0>

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Nov 23 16:12:03 2018
New Revision: 266409

URL: https://gcc.gnu.org/viewcvs?rev=266409=gcc=rev
Log:
PR libstdc++/65229 fix pretty printer for std::bitset<0>

2018-11-23  Martin Sebor  
Jonathan Wakely  

PR libstdc++/65229
* python/libstdcxx/v6/printers.py (StdBitsetPrinter): Handle
exception thrown for std::bitset<0>.
* testsuite/libstdc++-prettyprinters/simple.cc: Test std::bitset<0>.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc

[Bug c++/85861] g++ -Wconversion misses int to size_t

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #10 from Martin Sebor  ---
He's at Microsoft and no longer involved in GCC development.

[Bug fortran/88169] Rejects USE rename of namelist group

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Fortran 95 contains
> 
> NOTE 11.8
> 
> The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name
> from appearing as a common-block-object in a COMMON statement, an
> equivalence-
> object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST
> statement, respectively. There is no prohibition against the local-name
> appearing as a common-block-name or a namelist-object.
> 
> This appears to prohibit 
> 
>   program main
> use foo_nml, only: bar => foo
> namelist /bah/ bar   ! <-- Invalid
> x = 42
> write(*,nml=bar)
>   end program
> 
> So, I do believe you are correct.  Your code is conforming.

Hmmm, upon further reading of F95 and checking the code, one finds

  /* This departure from the standard is flagged as an error.
 It does, in fact, work correctly. TODO: Allow it
 conditionally?  */
  if (sym->attr.flavor == FL_NAMELIST)
{
  check_name = find_use_name (sym->name, false);
  if (check_name && strcmp (check_name, sym->name) != 0)
gfc_error ("Namelist %s cannot be renamed by USE "
   "association to %s", sym->name, check_name);
}

F95 contains

Constraint: The namelist-group-name shall not be a name made
   accessible by use association.

The code is definitely non-conforming by this constraint.  Note 11.8
is a red herring.  It deals with a namelist-group-objects not a
namelist-group-name.

Now, looking at F2018, one has

C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.

Your code is invalid.  What does ifort and NAG report if you request
strict adherence to the Fortran standard.

I suppose that one could argue that the renaming of the namelist
group name 'foo' to 'bar' prevents 'foo' from being accessible,
but 'foo' had to be accessible to permit the renaming to occur.

[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri Nov 23 15:48:56 2018
New Revision: 266408

URL: https://gcc.gnu.org/viewcvs?rev=266408=gcc=rev
Log:
PR libstdc++/87308 adjust regex used in std::any pretty printer

The pretty printer for std::any fails when the contained value is a
locally-defined type, because the name in the debuginfo has
cv-qualifiers and ptr-declarators in different positions. The unexpected
format confuses the printer. This makes the printer's regex handle
either format.

This isn't a complete fix because looking up the contained type fails
when there are two types with the same name (defined in different local
scopes). This applies to all closure types defined in a given function,
as they all appear as "func()::lambda" in the debuginfo names.

PR libstdc++/87308 (partial)
* python/libstdcxx/v6/printers.py (StdExpAnyPrinter): Adjust regex to
work around PR 88166.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Test std::any
containing a local type.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc

[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Nov 23 15:48:56 2018
New Revision: 266408

URL: https://gcc.gnu.org/viewcvs?rev=266408=gcc=rev
Log:
PR libstdc++/87308 adjust regex used in std::any pretty printer

The pretty printer for std::any fails when the contained value is a
locally-defined type, because the name in the debuginfo has
cv-qualifiers and ptr-declarators in different positions. The unexpected
format confuses the printer. This makes the printer's regex handle
either format.

This isn't a complete fix because looking up the contained type fails
when there are two types with the same name (defined in different local
scopes). This applies to all closure types defined in a given function,
as they all appear as "func()::lambda" in the debuginfo names.

PR libstdc++/87308 (partial)
* python/libstdcxx/v6/printers.py (StdExpAnyPrinter): Adjust regex to
work around PR 88166.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Test std::any
containing a local type.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc

[Bug fortran/88169] Rejects USE rename of namelist group

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-23
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Fortran 95 contains

NOTE 11.8

The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name
from appearing as a common-block-object in a COMMON statement, an equivalence-
object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST
statement, respectively. There is no prohibition against the local-name
appearing as a common-block-name or a namelist-object.

This appears to prohibit 

  program main
use foo_nml, only: bar => foo
namelist /bah/ bar   ! <-- Invalid
x = 42
write(*,nml=bar)
  end program

So, I do believe you are correct.  Your code is conforming.

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[john at johnwarburton dot net]

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

--- Comment #12 from John Warburton  ---
On Fri, Nov 23, 2018 at 11:26 AM John Warburton  wrote:
>
> On Thu, Nov 22, 2018 at 10:09 AM jakub at gcc dot gnu.org
>  wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
> >
> > --- Comment #10 from Jakub Jelinek  ---
> > Can somebody please test this on mingw (on the trunk)? Thanks.
>
> I've started a compilation of the trunk on GNU/Linux outputting
> x86_64-w64-mingw32-gcc etc.

This happens during the compilation of the trunk, I'm afraid:

 ../../../../src/gcc-trunk/libgfortran/generated/matmul_i4.c: In
function 'matmul_i4_avx2':
 ../../../../src/gcc-trunk/libgfortran/generated/matmul_i4.c:1210:1:
error: insn outside basic block
  1210 | }
   | ^
 (insn 10250 8120 10251 (parallel [
 (set (reg:DI 5752)
 (plus:DI (reg/f:DI 19 frame)
 (const_int -1200 [0xfb50])))
 (clobber (reg:CC 17 flags))
 ]) 191 {*adddi_1}
  (nil))
 during RTL pass: reload
 ../../../../src/gcc-trunk/libgfortran/generated/matmul_i4.c:1210:1:
internal compiler error: in rtl_verify_bb_layout, at cfgrtl.c:2987
 0x6a259f _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
 ../../../src/gcc-trunk/gcc/rtl-error.c:108
 0x92b8f1 rtl_verify_bb_layout
 ../../../src/gcc-trunk/gcc/cfgrtl.c:2987
 0x92b8f1 rtl_verify_flow_info
 ../../../src/gcc-trunk/gcc/cfgrtl.c:3033
 0x90fb1d verify_flow_info()
 ../../../src/gcc-trunk/gcc/cfghooks.c:263
 0x14c3569 checking_verify_flow_info
 ../../../src/gcc-trunk/gcc/cfghooks.h:198
 0x14c3569 try_optimize_cfg
 ../../../src/gcc-trunk/gcc/cfgcleanup.c:2991
 0x14c3569 cleanup_cfg(int)
 ../../../src/gcc-trunk/gcc/cfgcleanup.c:3156
 0xb6c969 do_reload
 ../../../src/gcc-trunk/gcc/ira.c:5518
 0xb6c969 execute
 ../../../src/gcc-trunk/gcc/ira.c:5653
 Please submit a full bug report,
 with preprocessed source if appropriate.
 Please include the complete backtrace with any bug report.
 See  for instructions.
 make[3]: *** [Makefile:4194: matmul_i4.lo] Error 1

[Bug tree-optimization/87645] [7 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
On trunk I see it fixed in r259672:

Author: rguenth
2018-04-26  Richard Biener  

PR tree-optimization/85116
* tree-ssa-loop-ch.c (do_while_loop_p): A do-while loop should
have a loop exit from the single latch predecessor.  Remove
case of header with just condition.
(ch_base::copy_headers): Exclude infinite loops from any
processing.
(pass_ch::execute): Record exits.

* gcc.dg/tree-ssa/copy-headers-2.c: New testcase.
* gcc.dg/tree-ssa/copy-headers-3.c: Likewise.
* gcc.dg/tree-ssa/copy-headers-4.c: Likewise.
* gcc.dg/tree-ssa/loadpre6.c: Adjust.

GCC 6 branch is OK, so it appeared in trunk in r250212
Author: wschmidt
[gcc]

2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Don't
replace a negate with an add.

[gcc/testsuite]

2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gcc.dg/pr81162.c: New file.

[Bug libstdc++/88170] New: pretty printer FAILs

[redi at gcc dot gnu.org]

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

Bug ID: 88170
   Summary: pretty printer FAILs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

type =
std::unique_ptr, std::allocator >>[]>>[99]>^M
got: type =
std::unique_ptr, std::allocator >>[]>>[99]>^M
FAIL: libstdc++-prettyprinters/80276.cc whatis p4

This fails because std::__cxx11::basic_string is not
substituted  with std::string as expected.

There are also several fails related to shared_ptr:

$21 = warning: RTTI symbol not found for class 'std::_Sp_counted_deleter, (__gnu_cxx::_Lock_policy)2>'^M
got: $21 = warning: RTTI symbol not found for class
'std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>'^M

I don't know why the RTTI is missing here. The same problem causes:

FAIL: libstdc++-prettyprinters/cxx17.cc print p
FAIL: libstdc++-prettyprinters/cxx17.cc print wp
FAIL: libstdc++-prettyprinters/cxx17.cc print q
FAIL: libstdc++-prettyprinters/cxx17.cc print wq
FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2

[Bug target/88167] [ARM] Function __builtin_return_address returns invalid address

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-23
 CC||thopre01 at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mihail.ionescu at arm 
dot com
 Ever confirmed|0   |1

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Martin Liška  ---
Thanks for it, will work on that next week.

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #7 from H.J. Lu  ---
Please try retpoline-table branch at

https://github.com/hjl-tools/microbenchmark

I got

[hjl@gnu-cfl-1 microbenchmark]$ make
gcc -g -I. -O2 -mindirect-branch=thunk   -c -o test.o test.c
gcc -g -I. -O2 -mindirect-branch=thunk -fno-jump-tables   -c -o
switch-no-table.o switch-no-table.c
gcc -g -I. -O2 -mindirect-branch=thunk   -c -o switch.o switch.c
gcc -o test test.o switch-no-table.o switch.o
./test
no jump table: 189484
jump table   : 333016
[hjl@gnu-cfl-1 microbenchmark]$

[Bug fortran/88169] New: Rejects USE rename of namelist group

[neil.n.carlson at gmail dot com]

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

Bug ID: 88169
   Summary: Rejects USE rename of namelist group
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

The current 8.2.1 compiler rejects this example,

  module foo_nml
real :: x
namelist /foo/ x
  end module

  program main
use foo_nml, only: bar => foo
x = 42
write(*,nml=bar)
  end program

with this error,

f951: Error: Namelist foo cannot be renamed by USE association to bar

I believe this is valid code. Section 11.2.2 par 2 (F2008) explicitly includes
namelist groups in the list of entities that may be accessed via use
association, and there is no subsequent restriction on a namelist group
appearing in a rename that I could find. FWIW, both the Intel and NAG compilers
accept this code as valid.

[Bug middle-end/87296] [8/9 Regression] -Wstringop-overflow false positive due to bogus MEM_REF type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Regressed with r254630.  If you are relying on what pointer types in GIMPLE IL
point to, don't, as pointer conversions in GIMPLE are useless.  Exception can
be perhaps if it is a type on a PARM_DECL and the default def SSA_NAME of that
PARM_DECL is passed to a string function, in that case you can trust that.

[Bug c++/83372] ICE in GC within gt_ggc_mx building Mir

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Martin Liška  ---
I think so.

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to H.J. Lu from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to H.J. Lu from comment #3)
> > > (In reply to Martin Liška from comment #2)
> > > > H.J. I can write a patch for it. Do you expect more expensive costs when
> > > > retpolines are enabled?
> > > 
> > > retpoline is more expensive than 4 branches.
> > 
> > Can you please make a microbenchmark that will expose how exactly is that
> > expensive? Based on that I can tune current costs.
> 
> Is there a testcase where GCC generates a jump table for a five-entry
> switch statement?

$ cat jt.c
int global;

int foo3 (int x)
{
  switch (x) {
case 0:
  return 11;
case 1:
  return 123;
case 2:
  global += 1;
  return 3;
case 3:
  return 44;
case 4:
  return 444;
default:
  return 0;
  }
}

$ gcc jt.c -O2  -S -o/dev/stdout
.file   "jt.c"
.text
.p2align 4,,15
.globl  foo3
.type   foo3, @function
foo3:
.LFB0:
.cfi_startproc
cmpl$4, %edi
ja  .L2
movl%edi, %edi
jmp *.L4(,%rdi,8)
.section.rodata
.align 8
.align 4
.L4:
.quad   .L9
.quad   .L7
.quad   .L6
.quad   .L5
.quad   .L3
.text
.p2align 4,,10
.p2align 3
...

[Bug rtl-optimization/87305] [9 Regression] Segfault in end_hard_regno in setup_live_pseudos_and_spill_after_risky_transforms on aarch64 big-endian

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-23
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I can confirm it still ICEs with current trunk.

[Bug testsuite/87304] [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
The difference is:
bb-slp-over-widen-1.c:33:1: note:   Vectorizing an unaligned access.
in -mcpu=power8 or on e.g. x86_64 vs.
bb-slp-over-widen-1.c:33:1: missed:   not vectorized: unsupported unaligned
store: *a_116(D)
bb-slp-over-widen-1.c:33:1: missed:   not vectorized: bad data alignment in
basic block.
bb-slp-over-widen-1.c:33:1: note:  removing SLP instance operations starting
from: *a_116(D) = _7;
with -mcpu=power7 or earlier.  So, shall we:
--- gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c.jj  2018-11-23
15:42:50.345052674 +0100
+++ gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c 2018-11-23
15:53:41.438334280 +0100
@@ -64,4 +64,4 @@ main (void)
 /* { dg-final { scan-tree-dump "demoting int to signed short" "slp2" { target
{ ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump "demoting int to unsigned short" "slp2" {
target { ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump {\.AVG_FLOOR} "slp2" { target vect_avg_qi } } }
*/
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" } } */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" {
target vect_hw_misalign } } } */

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Martin Liška from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > H.J. I can write a patch for it. Do you expect more expensive costs when
> > > retpolines are enabled?
> > 
> > retpoline is more expensive than 4 branches.
> 
> Can you please make a microbenchmark that will expose how exactly is that
> expensive? Based on that I can tune current costs.

Is there a testcase where GCC generates a jump table for a five-entry
switch statement?

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #19 from Gary Mills  ---
The reason that OI-SPARC uses the native assembler is the same as in Fiddler
on the Roof: tradition.  Actually, there are some kernel files written in SPARC
assembly language.  These only compile with the native assembler.  Hence, gcc
is
built to use the native assembler.

On OI-x86, the native assembler is not necessary and therefore not used.

It's entirely possible that the assembler is an old version.  OI does not have
source for the assembler, only the binary that came from Opensolaris.  The one
I use on my T2000 has this version string:

as: Sun Compiler Common 12 SunOS_sparc snv_121 08/03/2009

I'm in the midst of tracking down the origin of that null pointer that causes
the ICE.  With gdb, breakpoints seem not to work, but I can use it to analyze
core files.

[Bug rtl-optimization/87727] [9 regression] gcc.target/sparc/overflow-2.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Note, the PR87718 changes don't help here.

[Bug d/87788] Support D on x86_64-apple-darwin*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|9.0 |---
Summary|[9 Regression] Bootstrap|Support D on
   |fails for   |x86_64-apple-darwin*
   |x86_64-apple-darwin* with   |
   |default languages selection |
   |after D addition.   |

--- Comment #17 from Jakub Jelinek  ---
Dropping the regression flag as from what I understand based on above comments
the bootstrap issue is resolved already.

[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Jonathan Wakely  ---
Ah ok, thanks.

There seems to be yet another format, which includes the enum-key and class-key
for the types:

$15 = {_M_manager = 0x10006cd0
::_S_manage(enum std::any::_Op,
const std::any *, union std::any::_Arg *)>, _M_storage = {_M_ptr = 0x63,
_M_buffer = {__data = "c\000\000\000\000\000\000", __align = {