[Bug inline-asm/71572] ICE on valid code on x86_64-linux-gnu: in force_constant_size, at gimplify.c:671

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |inline-asm

--- Comment #1 from Andrew Pinski  ---
This might be invalid code ...

[Bug c++/71577] New: ICE on invalid C++11 code (with extra struct initializer) on x86_64-linux-gnu: in digest_init_r, at cp/typeck2.c:1117

[su at cs dot ucdavis.edu]

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

Bug ID: 71577
   Summary: ICE on invalid C++11 code (with extra struct
initializer) on x86_64-linux-gnu: in digest_init_r, at
cp/typeck2.c:1117
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It is a regression from 6.1.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160617 (experimental) [trunk revision 237557] (GCC) 
$ 
$ g++-6.1 -c small.cpp
small.cpp:1:36: error: too many initializers for ‘’
 struct { int a; } s1, s2 = { s1, 0 };
^
small.cpp:1:36: error: cannot convert ‘’ to ‘int’ in
initialization
$ 
$ g++-trunk -c small.cpp
small.cpp:1:36: error: too many initializers for ‘’
 struct { int a; } s1, s2 = { s1, 0 };
^
small.cpp:1:36: internal compiler error: in digest_init_r, at cp/typeck2.c:1117
0x726db8 digest_init_r
../../gcc-source-trunk/gcc/cp/typeck2.c:1117
0x72839a digest_init_flags
../../gcc-source-trunk/gcc/cp/typeck2.c:1167
0x72839a store_init_value(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
../../gcc-source-trunk/gcc/cp/typeck2.c:796
0x687abc check_initializer
../../gcc-source-trunk/gcc/cp/decl.c:6193
0x6b1c0d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-source-trunk/gcc/cp/decl.c:6851
0x7ac1a7 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18697
0x7ac9d9 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12378
0x7acce1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
0x7b60c0 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12143
0x7b4b94 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12022
0x7b4ec8 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4324
0x7b4ec8 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37486
0x918e02 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 




// valid in C++11 & okay: struct { int a; } s1, s2 = { s1 }; 
struct { int a; } s1, s2 = { s1, 0 };

[Bug c++/71576] New: ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385

[su at cs dot ucdavis.edu]

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

Bug ID: 71576
   Summary: ICE on valid C++11 code (with xvalue and bitfield) on
x86_64-linux-gnu: in build_target_expr, at
cp/tree.c:385
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 6.1.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160617 (experimental) [trunk revision 237557] (GCC) 
$ 
$ g++-6.1 -c small.cpp
$ 
$ g++-trunk -c small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:10:26: internal compiler error: in build_target_expr, at
cp/tree.c:385
   int & = foo < A > ().i;
  ^
0x83597f build_target_expr
../../gcc-source-trunk/gcc/cp/tree.c:379
0x66d066 convert_like_real
../../gcc-source-trunk/gcc/cp/call.c:6769
0x67934b initialize_reference(tree_node*, tree_node*, int, int)
../../gcc-source-trunk/gcc/cp/call.c:10054
0x688224 grok_reference_init
../../gcc-source-trunk/gcc/cp/decl.c:5186
0x688224 check_initializer
../../gcc-source-trunk/gcc/cp/decl.c:6085
0x6b1c0d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-source-trunk/gcc/cp/decl.c:6851
0x7ac1a7 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18697
0x7ac9d9 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12378
0x7acce1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
0x7ad738 cp_parser_declaration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11858
0x7aa30b cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10526
0x7aac2c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10804
0x7aad1f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10758
0x7aaecf cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20696
0x7aaecf cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20732
0x7ab971 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25415
0x7ac685 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25327
0x7ac685 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18468
0x7ac9d9 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12378
0x7acce1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


--


template < typename T > T && foo ();

struct A 
{
  int i:5;
};

void foo ()
{
  int & = foo < A > ().i;
}

[Bug regression/71575] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[lluixhi at gmail dot com]

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

--- Comment #1 from Aric Belsito  ---
Forgot this in OP:

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-gentoo-linux-musl/gcc-bin/6.1.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-gentoo-linux-musl/6.1.0/lto-wrapper
Target: x86_64-gentoo-linux-musl
Configured with: /var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/configure
--host=x86_64-gentoo-linux-musl --build=x86_64-gentoo-linux-musl --prefix=/usr
--bindir=/usr/x86_64-gentoo-linux-musl/gcc-bin/6.1.0
--includedir=/usr/lib/gcc/x86_64-gentoo-linux-musl/6.1.0/include
--datadir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/6.1.0
--mandir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/6.1.0/man
--infodir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/6.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-gentoo-linux-musl/6.1.0/include/g++-v6
--with-python-dir=/share/gcc-data/x86_64-gentoo-linux-musl/6.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror
--with-system-zlib --enable-nls --without-included-gettext --disable-symvers
libat_cv_have_ifunc=no --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 6.1.0
p1.1' --enable-esp --enable-libstdcxx-time --disable-libstdcxx-pch
--enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-multilib
--with-multilib-list=m64 --disable-altivec --disable-fixed-point
--enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap
--disable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify
--disable-libvtv --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1)

[Bug regression/71575] New: internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[lluixhi at gmail dot com]

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

Bug ID: 71575
   Summary: internal compiler error: in copy_cond_phi_nodes, at
graphite-isl-ast-to-gimple.c:2500
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lluixhi at gmail dot com
  Target Milestone: ---

Reduced Testcase:
void w(int x, double *y)
{
int i, j;
double a;
double c[32];

for (i = 0; i < x; i++) {
for (j = 0; j < x - i; j++) {
c[j] = y[i];
}
y[i] = a;
a += c[0] + y[i];
}
}

void v(int x, double *y)
{
w(x, y);
}

on amd64 with -O2 -floop-nest-optimize

test.c: In function 'w':
test.c:1:6: internal compiler error: in copy_cond_phi_nodes, at
graphite-isl-ast-to-gimple.c:2500
 void w(int x, double *y)
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I have the pull request from pr69068 applied.

[Bug c/71574] New: ICE on code with alloc_align attribute on x86_64-linux-gnu: in default_conversion, at c/c-typeck.c:2126

[su at cs dot ucdavis.edu]

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

Bug ID: 71574
   Summary: ICE on code with alloc_align attribute on
x86_64-linux-gnu: in default_conversion, at
c/c-typeck.c:2126
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

It ICEs all GCC versions 5.x and later. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160617 (experimental) [trunk revision 237557] (GCC) 
$ 
$ gcc-trunk -c small.c
small.c:2:1: internal compiler error: in default_conversion, at
c/c-typeck.c:2118
 int fn2 () __attribute__ ((alloc_align (fn1)));
 ^~~
0x66b0dd default_conversion(tree_node*)
../../gcc-source-trunk/gcc/c/c-typeck.c:2118
0x6d4cf0 handle_alloc_align_attribute
../../gcc-source-trunk/gcc/c-family/c-common.c:8365
0x641441 decl_attributes(tree_node**, tree_node*, int)
../../gcc-source-trunk/gcc/attribs.c:551
0x65991a start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc-source-trunk/gcc/c/c-decl.c:4545
0x6bdff5 c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:1963
0x6c7f95 c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1549
0x6c8829 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1430
0x6c8829 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:17930
0x72b1b2 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


int fn1 ();
int fn2 () __attribute__ ((alloc_align (fn1)));

[Bug c/71573] New: ICE on invalid C code on x86_64-linux-gnu (tree check: expected function_decl, have var_decl in implicitly_declare)

[chengniansun at gmail dot com]

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

Bug ID: 71573
   Summary: ICE on invalid C code on x86_64-linux-gnu (tree check:
expected function_decl, have var_decl in
implicitly_declare)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk on on x86_64-linux-gnu in both 32-bit and
64-bit modes. 

gcc-6.1 and all older versions do not crash. This should be a recent
regression.


$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160617 (experimental) [trunk revision 237557] (GCC) 
$: 
$: gcc-trunk small.c
small.c: In function ‘f2’:
small.c:4:3: internal compiler error: tree check: expected function_decl, have
var_decl in implicitly_declare, at c/c-decl.c:3313
   t(g);
   ^
0xe6b3bc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9752
0x64dc01 tree_check
../../gcc-source-trunk/gcc/tree.h:3030
0x64dc01 implicitly_declare(unsigned int, tree_node*)
../../gcc-source-trunk/gcc/c/c-decl.c:3313
0x66ba52 build_external_ref(unsigned int, tree_node*, int, tree_node**)
../../gcc-source-trunk/gcc/c/c-typeck.c:2728
0x6a1457 c_parser_postfix_expression
../../gcc-source-trunk/gcc/c/c-parser.c:7497
0x6a1c2a c_parser_unary_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6942
0x6a2a3a c_parser_cast_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6771
0x6a2c44 c_parser_binary_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6580
0x6a38f5 c_parser_conditional_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6351
0x6a3f70 c_parser_expr_no_commas
../../gcc-source-trunk/gcc/c/c-parser.c:6268
0x6a4672 c_parser_expression
../../gcc-source-trunk/gcc/c/c-parser.c:8463
0x6a50d9 c_parser_expression_conv
../../gcc-source-trunk/gcc/c/c-parser.c:8496
0x6bb408 c_parser_statement_after_labels
../../gcc-source-trunk/gcc/c/c-parser.c:5287
0x6bd2ab c_parser_compound_statement_nostart
../../gcc-source-trunk/gcc/c/c-parser.c:4861
0x6bdb3e c_parser_compound_statement
../../gcc-source-trunk/gcc/c/c-parser.c:4696
0x6bed67 c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:2105
0x6c7f95 c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1549
0x6c8829 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1430
0x6c8829 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:17930
0x72b1b2 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: cat small.c
void f1() { extern int t; }
void f2() {
  int g;
  t(g);
}
$:

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-17
 Ever confirmed|0   |1

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hp at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson  ---
Confirmed by inspection of cris.c:cris_asm_output_mi_thunk; -fpic or -fPIC is
required and also crisv32-axis-linux-gnu "only".

[Bug c/71572] New: ICE on valid code on x86_64-linux-gnu: in force_constant_size, at gimplify.c:671

[su at cs dot ucdavis.edu]

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

Bug ID: 71572
   Summary: ICE on valid code on x86_64-linux-gnu: in
force_constant_size, at gimplify.c:671
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

It seems to affect all versions 4.7.x and later. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160617 (experimental) [trunk revision 237557] (GCC)
$
$ clang-3.8 -c small.c
$
$ gcc-trunk -c small.c
small.c: In function ‘fn1’:
small.c:7:3: internal compiler error: in force_constant_size, at gimplify.c:671
   __asm ("":"+g" (b));
   ^
0x946f46 force_constant_size
../../gcc-source-trunk/gcc/gimplify.c:671
0x94d897 gimple_add_tmp_var(tree_node*)
../../gcc-source-trunk/gcc/gimplify.c:709
0x92765a create_tmp_var(tree_node*, char const*)
../../gcc-source-trunk/gcc/gimple-expr.c:476
0x959194 create_tmp_from_val
../../gcc-source-trunk/gcc/gimplify.c:500
0x959194 lookup_tmp_var
../../gcc-source-trunk/gcc/gimplify.c:521
0x959194 internal_get_tmp_var
../../gcc-source-trunk/gcc/gimplify.c:574
0x9519c8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11374
0x95fcfe gimplify_asm_expr
../../gcc-source-trunk/gcc/gimplify.c:5471
0x952ff5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10754
0x9565a6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:5767
0x95329b gimplify_statement_list
../../gcc-source-trunk/gcc/gimplify.c:1549
0x95329b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10851
0x9565a6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:5767
0x9577c7 gimplify_bind_expr
../../gcc-source-trunk/gcc/gimplify.c:1154
0x9527f4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10633
0x9565a6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:5767
0x9582cb gimplify_body(tree_node*, bool)
../../gcc-source-trunk/gcc/gimplify.c:11617
0x958926 gimplify_function_tree(tree_node*)
../../gcc-source-trunk/gcc/gimplify.c:11773
0x7d5667 cgraph_node::analyze()
../../gcc-source-trunk/gcc/cgraphunit.c:625
0x7d81f0 analyze_functions
../../gcc-source-trunk/gcc/cgraphunit.c:1086
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


--


int a;

void
fn1 ()
{ 
  int b[a];
  __asm ("":"+g" (b));
}

[Bug target/71338] [RL78] mulu instruction not used on G10

[dj at gcc dot gnu.org]

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

--- Comment #2 from dj at gcc dot gnu.org  ---
Author: dj
Date: Fri Jun 17 22:24:17 2016
New Revision: 237566

URL: https://gcc.gnu.org/viewcvs?rev=237566=gcc=rev
Log:
PR target/71338
* config/rl78/rl78-expand.c (umulqihi3): Enable for G10.
* config/rl78/rl78-virtual.c (umulhi3_shift_virt): Likewise.
(umulqihi3_virt): Likewise.
* config/rl78/rl78-real.c (umulhi3_shift_real): Likewise.
(umulqihi3_real): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rl78/rl78-expand.md
trunk/gcc/config/rl78/rl78-real.md
trunk/gcc/config/rl78/rl78-virt.md

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> The tentative fix restored bootstrap on sparc-linux.  Test results look
> OK-ish.

Thanks, I'll post it tomorrow morning.

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[mikpelinux at gmail dot com]

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

--- Comment #11 from Mikael Pettersson  ---
(In reply to Mikael Pettersson from comment #10)
> (In reply to Eric Botcazou from comment #9)
> > > Created attachment 38699 [details]
> > > Tentative fix.
> > 
> > It successfully passed a full bootstrap/test cycle on SPARC/Solaris.
> 
> I can test it on SPARC/Linux on Friday.

The tentative fix restored bootstrap on sparc-linux.  Test results look OK-ish.

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Fri, 17 Jun 2016, jakub at gcc dot gnu.org wrote:

> The patch is completely untested though (and wonder if we have testcases for
> not raising exceptions when isgreater etc. arguments are qNaNs.

We probably don't have such tests - tests for exception raising or its 
absence are fairly limited.  Those functions are covered in the glibc 
testsuite, but of course that only covers whichever insn patterns get used 
for __builtin_is* for that particular build of the glibc tests.

There are definitely bugs on some architectures involving ordinary ordered 
comparisons such as < and >= wrongly using quiet instructions.  See bug 
52451 for i386 (x87 floating point) and bug 58684 for powerpc, for 
example.  A consequence of this is that if you add tests of comparisons 
doing the right thing, some of those tests would immediately fail on some 
architectures.

(These sorts of local bugs with particular operations or optimizations 
being incorrect regarding exceptions are certainly easier to fix than the 
issues with optimizations not being aware of exceptions and rounding modes 
as extra inputs / outputs to floating-point operations.  The ones with 
individual operations could I expect largely be found through thorough 
test coverage; those with optimizations might be harder to find.)

Note that there is some ambiguity about whether LTGT RTL (and 
corresponding GENERIC / GIMPLE) should be a quiet operation corresponding 
to islessgreater, or ((x < y) || (x > y)) raising exceptions for quiet 
NaNs.  See the discussion at 
.  Fixing 
the ambiguity in either direction would probably involve changes to the 
part of the compiler expecting the other semantics.

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

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

David B. Robins  changed:

   What|Removed |Added

 Target||crisv32-axis-linux-gnu
   Host||x86_64-unknown-linux-gnu
  Known to fail||4.3.1, 7.0
  Build||x86_64-unknown-linux-gnu
   Severity|normal  |major

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

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

--- Comment #2 from David B. Robins  ---
Created attachment 38721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38721=edit
Larger repro - crashes reliably - requires additional -O2 -fno-inline

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

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

--- Comment #1 from David B. Robins  ---
Created attachment 38720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38720=edit
Small repro - emits branch (ba) without delay-slot instruction

[Bug target/71571] New: [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

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

Bug ID: 71571
   Summary: [CRIS] Multiple inheritance non-virtual PIC thunk
causes crash
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at davidrobins dot net
  Target Milestone: ---

Created attachment 38719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38719=edit
Add nop for ba (branch) delay slot in PIC multiple inheritance thunk

The jump to the primary function in the generated non-virtual thunk for the
CRIS platform is missing the delay slot instruction (an instruction following
the jump that is executed before it) in PIC mode, so it runs the following
instruction in the text segment instead. (This following instruction is
frequently the next function's preamble, usually a sub from $sp, which causes a
crash in a subsequent return or other stack lookup.)

We initially saw this problem on a vendor-provided (Axis) GCC 4.3.1, but it
repros on current SVN (r237536 when I checked it out). Details of GCC build:
gcc version 7.0.0 20160616 (experimental) (GCC)
Host: x86_64-unknown-linux-gnu
Target: crisv32-axis-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/opt/cross
--target=crisv32-axis-linux-gnu --enable-languages=c,c++ --disable-multilib

The build command-line is: /opt/cross/bin/crisv32-axis-linux-gnu-g++ -fPIC
-save-temps -o test main.cpp (substitute main.ii)

I am attaching:
 * a repro program, main.ii; after reduction it (probably) doesn't crash but
the thunk with branch ("ba") without a delay-slot instruction can be seen in
the assembly,
 * a slightly larger repro, crash.ii, that reliably crashes (due to an
$sp-modifying instruction following the branch); this requires additional g++
options -O2 -fno-inline (the -O2 to eliminate a dword stored in memory after
the ba instruction, and -fno-inline to prevent the thunk from being an inline
copy of the function it would jump to)
 * a patch to fix the problem.

Runs of "make check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim" with/without
the fix do not differ in passes/failures. I would like to add a test for this
issue but am unsure as to the correct way of doing so; crash.ii could be used
in an execute test, or is checking the output assembly better, or something
else?

[Bug libstdc++/71545] [6/7 Regression] Incorrect irreflexive comparison debug check in std::lower_bound

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/71545] [6/7 Regression] Incorrect irreflexive comparison debug check in std::lower_bound

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 17 18:53:46 2016
New Revision: 237561

URL: https://gcc.gnu.org/viewcvs?rev=237561=gcc=rev
Log:
libstdc++/71545 fix debug checks in binary search algorithms

PR libstdc++/71545
* include/bits/stl_algobase.h (lower_bound, lexicographical_compare):
Remove irreflexive checks.
* include/bits/stl_algo.h (lower_bound, upper_bound, equal_range,
binary_search): Likewise.
* testsuite/25_algorithms/equal_range/partitioned.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/71545.cc: New test.
* testsuite/25_algorithms/lower_bound/partitioned.cc: New test.
* testsuite/25_algorithms/upper_bound/partitioned.cc: New test.
* testsuite/util/testsuite_iterators.h (__gnu_test::test_container):
Add constructor from array.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/binary_search/partitioned.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/equal_range/partitioned.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/71545.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/lower_bound/partitioned.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/upper_bound/partitioned.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_algo.h
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_algobase.h
branches/gcc-6-branch/libstdc++-v3/testsuite/util/testsuite_iterators.h

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
This is related to PR 37158?

[Bug libstdc++/71545] [6/7 Regression] Incorrect irreflexive comparison debug check in std::lower_bound

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 17 18:28:34 2016
New Revision: 237560

URL: https://gcc.gnu.org/viewcvs?rev=237560=gcc=rev
Log:
libstdc++/71545 fix debug checks in binary search algorithms

PR libstdc++/71545
* include/bits/stl_algobase.h (lower_bound, lexicographical_compare):
Remove irreflexive checks.
* include/bits/stl_algo.h (lower_bound, upper_bound, equal_range,
binary_search): Likewise.
* testsuite/25_algorithms/equal_range/partitioned.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/71545.cc: New test.
* testsuite/25_algorithms/lower_bound/partitioned.cc: New test.
* testsuite/25_algorithms/upper_bound/partitioned.cc: New test.
* testsuite/util/testsuite_iterators.h (__gnu_test::test_container):
Add constructor from array.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/binary_search/partitioned.cc
trunk/libstdc++-v3/testsuite/25_algorithms/equal_range/partitioned.cc
trunk/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/71545.cc
trunk/libstdc++-v3/testsuite/25_algorithms/lower_bound/partitioned.cc
trunk/libstdc++-v3/testsuite/25_algorithms/upper_bound/partitioned.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h
trunk/libstdc++-v3/testsuite/util/testsuite_iterators.h

[Bug c++/71548] Invalid declaration involving template template param causes crash

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-17
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.7.0, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed as ice-on-invalid-code.  My bisection points to r179441 as the first
commit that triggered an ICE but since the commit isn't relevant to the C++
front end it must have been one before it and after r179435 which fails with:
sorry, unimplemented: cannot expand ‘T ...’ into a fixed-length argument list
Looking at the commits in between r179436 is the only possible root cause.

Recent trunk fails with the following output:

$ cat t.C && gcc -Wall t.C
template class fl {};
template class = fl>
struct S {};
template
void f(S ) {}
void lol() {
S<> s;
f(s);
}
t.C: In substitution of ‘template void f(S) [with T =
]’:
t.C:8:8:   required from here
t.C:8:8: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (template_decl) in cp_type_quals, at cp/typeck.c:9154
 f(s);
^
0x13ad713 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9803
0x72a08d tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
../../gcc/tree.h:3409
0x911f1e cp_type_quals(tree_node const*)
../../gcc/cp/typeck.c:9154
0x803b7c check_cv_quals_for_unify
../../gcc/cp/pt.c:19053
0x807fab unify
../../gcc/cp/pt.c:19707
0x8010f4 unify_one_argument
../../gcc/cp/pt.c:18292
0x8045b2 unify_pack_expansion
../../gcc/cp/pt.c:19203
0x808fac unify
../../gcc/cp/pt.c:19969
0x80382f try_class_unification
../../gcc/cp/pt.c:18965
0x8093af unify
../../gcc/cp/pt.c:1
0x8010f4 unify_one_argument
../../gcc/cp/pt.c:18292
0x80139d type_unification_real
../../gcc/cp/pt.c:18366
0x7ff912 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/cp/pt.c:17811
0x73495c add_template_candidate_real
../../gcc/cp/call.c:3110
0x734db1 add_template_candidate
../../gcc/cp/call.c:3188
0x73c9ed add_candidates
../../gcc/cp/call.c:5361
0x737b34 perform_overload_resolution
../../gcc/cp/call.c:4045
0x737d9b build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/cp/call.c:4122
0x954894 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2433
0x898a02 cp_parser_postfix_expression
../../gcc/cp/parser.c:6904
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
If I compile the above testcase with -O2 -mavx -ftrapping-math, then it
generates vucomiss in each case, which seems wrong to me (because for
gt/ge/lt/le it should raise exceptions, so IMHO should use vcomiss in that
case).

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jsm28 at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
#define N 1024
float a[N], b[N];
int c[N];

void eq () { int i; for (i = 0; i < N; i++) c[i] = a[i] == b[i]; }
void ne () { int i; for (i = 0; i < N; i++) c[i] = a[i] != b[i]; }
void gt () { int i; for (i = 0; i < N; i++) c[i] = a[i] > b[i]; }
void ge () { int i; for (i = 0; i < N; i++) c[i] = a[i] >= b[i]; }
void lt () { int i; for (i = 0; i < N; i++) c[i] = a[i] < b[i]; }
void le () { int i; for (i = 0; i < N; i++) c[i] = a[i] <= b[i]; }
void unle () { int i; for (i = 0; i < N; i++) c[i] = !__builtin_isgreater
(a[i], b[i]); }
void unlt () { int i; for (i = 0; i < N; i++) c[i] = !__builtin_isgreaterequal
(a[i], b[i]); }
void unge () { int i; for (i = 0; i < N; i++) c[i] = !__builtin_isless (a[i],
b[i]); }
void ungt () { int i; for (i = 0; i < N; i++) c[i] = !__builtin_islessequal
(a[i], b[i]); }
void uneq () { int i; for (i = 0; i < N; i++) c[i] = !__builtin_islessgreater
(a[i], b[i]); }
void ordered () { int i; for (i = 0; i < N; i++) c[i] = !__builtin_isunordered
(a[i], b[i]); }
void unordered () { int i; for (i = 0; i < N; i++) c[i] = __builtin_isunordered
(a[i], b[i]); }

shows the various codes in vcond.
From C99 and other sources, all of the
isgreater/isequal/isless/isequal/islessgreater return false if any argument is
NaN and don't raise exceptions (except for sNaN). isunordered returns true only
if any argument is NaN and doesn't raise exceptions either.
The matching of the above to RTX codes has been confirmed by compiling the
above testcase.
Thus, IMNSHO the right values are:
 A > BA < BA = BUNORDSIGNALIMM
EQ FFTF N   0
NE TTFT N   4
GT TFFF Y   0xe
GE TFTF Y   0xd
LT FTFF Y   1
LE FTTF Y   2
UNLE   FTTT N   0x1a
UNLT   FTFT N   0x19
UNGE   TFTT N   0x15
UNGT   TFFT N   0x16
UNEQ   FFTT N   8
LTGT   TTFF N   0xc
ORDEREDTTTF N   7
UNORDERED  FFFT N   3

This is in sync with the 'D' stuff except for UN{LE,LT,GE,GT,EQ} where the AVX
implementation uses the signalling instructions instead of non-signalling. 
Unless there is some bug in the generic code, I'd say if one gets UNLE for
inverted isgreater, then in the above table
one needs to replace all Ts for Fs and vice versa, but keep Y and N as is
(because the fact whether the insn raises exception or not just depends on the
arguments (and not even on their order), not on whether the result is inverted
(nor arguments swapped).

So I'd expect something like:
--- gcc/config/i386/i386.c.jj   2016-06-16 21:00:08.0 +0200
+++ gcc/config/i386/i386.c  2016-06-17 19:35:52.237836780 +0200
@@ -17628,7 +17628,7 @@ ix86_print_operand (FILE *file, rtx x, i
case UNEQ:
  if (TARGET_AVX)
{
- fputs ("eq_us", file);
+ fputs ("eq_uq", file);
  break;
}
case EQ:
@@ -17637,7 +17637,7 @@ ix86_print_operand (FILE *file, rtx x, i
case UNLT:
  if (TARGET_AVX)
{
- fputs ("nge", file);
+ fputs ("nge_uq", file);
  break;
}
case LT:
@@ -17646,7 +17646,7 @@ ix86_print_operand (FILE *file, rtx x, i
case UNLE:
  if (TARGET_AVX)
{
- fputs ("ngt", file);
+ fputs ("ngt_uq", file);
  break;
}
case LE:
@@ -17671,7 +17671,10 @@ ix86_print_operand (FILE *file, rtx x, i
  break;
}
case UNGE:
- fputs ("nlt", file);
+ if (TARGET_AVX)
+   fputs ("nlt_uq", file);
+ else
+   fputs ("nlt", file);
  break;
case GT:
  if (TARGET_AVX)
@@ -17680,7 +17683,10 @@ ix86_print_operand (FILE *file, rtx x, i
  break;
}
case UNGT:
- fputs ("nle", file);
+ if (TARGET_AVX)
+   fputs ("nle_uq", 

[Bug c++/71570] New: ICE on invalid C++11 code (with invalid variable capture) on x86_64-linux-gnu: in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551

[su at cs dot ucdavis.edu]

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

Bug ID: 71570
   Summary: ICE on invalid C++11 code (with invalid variable
capture) on x86_64-linux-gnu: in
cxx_incomplete_type_diagnostic, at cp/typeck2.c:551
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It also affects 6.1.x and is a regression from 5.4.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160617 (experimental) [trunk revision 237557] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:5:5: error: cannot capture ‘foo’ by reference
   []
 ^~~
small.cpp: In lambda function:
small.cpp:7:11: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:551
 foo (0);
   ^
0x727e2d cxx_incomplete_type_diagnostic(unsigned int, tree_node const*,
tree_node const*, diagnostic_t)
../../gcc-source-trunk/gcc/cp/typeck2.c:551
0x7bffd5 cxx_incomplete_type_diagnostic
../../gcc-source-trunk/gcc/cp/cp-tree.h:6757
0x7bffd5 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/typeck.c:152
0x7cde76 decay_conversion(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/typeck.c:2044
0x661e52 build_addr_func(tree_node*, int)
../../gcc-source-trunk/gcc/cp/call.c:282
0x7d0f6e cp_build_function_call_vec(tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
../../gcc-source-trunk/gcc/cp/typeck.c:3583
0x817680 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2454
0x78ee50 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6904
0x78d4ac cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:7986
0x797327 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8663
0x797925 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8765
0x798210 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9053
0x79ab09 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9220
0x79b12f cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10681
0x7a9f6b cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10532
0x7aac2c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10804
0x7b03be cp_parser_lambda_body
../../gcc-source-trunk/gcc/cp/parser.c:10270
0x7b03be cp_parser_lambda_expression
../../gcc-source-trunk/gcc/cp/parser.c:9754
0x7848dc cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4934
0x78f076 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6691
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


void foo (int);

void foo (void)
{
  []
  {
foo (0); 
  };
}

[Bug c++/71569] [5/6] Crash: External definition of template member from template struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-17
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was introduced in 5.0 via the following commit:

r218104 | jason | 2014-11-26 16:58:38 -0500 (Wed, 26 Nov 2014) | 14 lines

Allow partial specialization of variable templates.
* cp-tree.h (TINFO_USED_TEMPLATE_ID): New.
* decl.c (duplicate_decls): Copy it.
* error.c (dump_decl) [TEMPLATE_ID_EXPR]: Handle variables.
* parser.c (cp_parser_decltype_expr): Do call finish_id_expression
on template-ids.
* pt.c (register_specialization): Remember variable template insts.
(instantiate_template_1): Find the matching partial specialization.
(check_explicit_specialization): Allow variable partial specialization.
(process_partial_specialization): Likewise.
(push_template_decl_real): Likewise.
(more_specialized_partial_spec): Rename from more_specialized_class.
(most_specialized_partial_spec): Rename from most_specialized_class.
(get_partial_spec_bindings): Rename from get_class_bindings.

[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[vp at gcc dot gnu.org]

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

--- Comment #7 from Vidya Praveen  ---
Author: jason
Date: Fri Jun 17 16:35:33 2016
New Revision: 237558

URL: https://gcc.gnu.org/viewcvs?rev=237558=gcc=rev
Log:
PR c++/71209 - wrong error with dependent base

* typeck.c (finish_class_member_access_expr): Avoid "not a base"
warning when there are dependent bases.

Added:
trunk/gcc/testsuite/g++.dg/template/dependent-base1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug tree-optimization/71550] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
I suspect this is a check that exists for the old style threader, but which is
not in the backwards threader.  Namely that when threading through a loop
header, we have to verify that the final block in the path dominates the latch.

[Bug c/71560] union compound literal initializes wrong union field

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-17
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed as a documentation bug.  The quoted sentence:

  Compound literals for scalar types and union types are also allowed, but then
the compound literal is equivalent to a cast.

is incorrect because a compound literal is an lvalue while a cast yields an
rvalue.  So for example:

  int i;
  i = ++(int){ 123.4 };

is valid and initializes i to 124, while

  i = ++(int)123;

is not valid.  This reflected in footnote 99 in C11 which clarifies the
semantics of compound literals by saying:

99) Note that this differs from a cast expression.  For example, a cast
specifies a conversion to scalar types or void only, and the result of a cast
expression is not an lvalue.

[Bug c++/71569] New: [5/6] Crash: External definition of template member from template struct

[oliver.tale at web dot de]

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

Bug ID: 71569
   Summary: [5/6] Crash: External definition of template member
from template struct
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oliver.tale at web dot de
  Target Milestone: ---

Created attachment 38718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38718=edit
gcc -v -save-temps crash.cpp

Check out this:


template 
class Foo
{
template 
static bool Bar;
};

template
template
bool Foo::Bar;

int main()
{ }


I know that its not valid code, because <= 4.9.3 report the following:

"5 : error: template declaration of 'bool Bar'
static bool Bar;
^
10 : error: expected initializer before '<' token
bool Foo::Bar;
^"

But since 5.1 and up to 6.1.1 - it just crashes:

"crash.cpp:10:14: internal compiler error: in determine_specialization, at
cp/pt.c:2075
bool Foo::Bar;"
See the attachment for stack trace.

I couldnt get my hand on a 4.9.4 or 5.0 or something newer than 6.1.1, maybe
someone can track the exact version jump.
Must be between 4.9.3 and 5.1.

[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
fixed

[Bug c++/71209] [c++] erroneous 'is not a base class of' error

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jun 17 16:35:33 2016
New Revision: 237558

URL: https://gcc.gnu.org/viewcvs?rev=237558=gcc=rev
Log:
PR c++/71209 - wrong error with dependent base

* typeck.c (finish_class_member_access_expr): Avoid "not a base"
warning when there are dependent bases.

Added:
trunk/gcc/testsuite/g++.dg/template/dependent-base1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
This testcase is ill-formed, no diagnostic required, but the 71209 testcase is
well-formed, so let's use that one instead:

class A {
  int table_clear;
};

template 
class B : T {
  B() { this->A::table_clear; }
};

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I've created the table just by walking through the 'D' handling.
That said, looking e.g. at
https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
for the C comparisons (EQ, NE, LT, LE, GT, GE) EQ and NE should not raise
FE_INVALID, while LT, LE, GT, GE should.
And, if one or both operands are NaNs, then NE must be true, while EQ, LT, LE,
GT, GE false.
So, at least for these, the 'D' numbers in the table are right, i.e.
EQ 0, NE 4, GT 0xe, GE 0xd, LT 1, LE 2.  Let me investigate the other
comparison codes.

[Bug libstdc++/71545] [6/7 Regression] Incorrect irreflexive comparison debug check in std::lower_bound

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The irreflexive assertion is incorrect for lexicographical compare too:

#include 

struct X { };

bool operator<(X, int) { return true; }
bool operator<(int, X) { return false; }

// Not a strict weak order
bool operator<(X, X) { return true; }

int main()
{
  X x[1];
  int i[1];
  std::lexicographical_compare(x, x+1, i, i+1);
}

This fails in Debug Mode because operator<(X, X) doesn't define a strict weak
order, but that operator is not used by the algorithm.

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[tripiana at gmail dot com]

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

--- Comment #6 from Carlos Tripiana Montes  ---
Hope you guys can do that and fix this problem soon. It would much appreciated
as we are (at Barcelona Supercomputing Center, Spain) doing research on KNL and
we need the fastest/most robust code we can obtain.

Thanks in advance.

(In reply to Ilya Enkovich from comment #5)
> (In reply to Jakub Jelinek from comment #3)
> > I'd say it is a bug in ix86_fp_cmp_code_to_pcmp_immediate that it handles
> > only a small portion of the FP comparison codes, while VCMPP[SD]
> > instructions should be able to handle everything needed.
> > But, I'm also surprised where the values in that function come from.
> > Looking at the D modifier expansion in i386.c that is used for AVX vcmp, I
> > see that:
> > code  %D3 emits corresponding imm   
> > ix86_fp_cmp_code_to_pcmp_immediate
> > UNEQ  eq_us 0x18 ICE
> > EQeq08
> > UNLT  nge   9ICE
> > LTlt10x19
> > UNLE  ngt   0xa  ICE
> > LEle20x1a
> > UNORDERED unord 3ICE
> > LTGT  neq_oq0xc  ICE
> > NEneq   44
> > GEge0xd  0x15
> > UNGE  nlt   5ICE
> > GTgt0xe  0x16
> > UNGT  nle   6ICE
> > ORDERED   ord   7ICE
> > So, there is agreement only on NE and nothing else.
> 
> I took values for ix86_fp_cmp_code_to_pcmp_immediate from some table Kirill
> gave me and seems all values I used were unordered non-signaling variants. 
> I don't fully understand the logic of imms in this table.  Some of them are
> signalling and some of them are not.  Also why is NE unordered?  But I
> suspect there is good reason for such choice and suppose AVX512 compares
> should be put in a consistent state with AVX ones by fixing
> ix86_fp_cmp_code_to_pcmp_immediate appropriately.

[Bug c++/71568] New: Inexplicable error: "X is inaccessible within this context" for a public member

[richardg.work at gmail dot com]

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

Bug ID: 71568
   Summary: Inexplicable error: "X is inaccessible within this
context" for a public member
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardg.work at gmail dot com
  Target Milestone: ---

Created attachment 38717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38717=edit
Demonstration of the error & a possible workaround

The attached 90 line test.cpp fails to compile with an inexplicable error
message :  "X is inaccessible within this context".  The X is clearly a public
member, so this is not a C++ private memeber issue.  Critically, the same code
compiles without issue on the clang compiler (clang 3.7.1)

Note : Compile test.cpp with -std=c++14.

I've seen this error in unrelated template code before, but this time I've been
able to simplify it to a 90 line repro.  

Godbolt demonstrating the error : https://godbolt.org/g/Z4hDez

/tmp/gcc-explorer-compiler116517-85-12v5300/example.cpp: In instantiation of
'struct has_nlog_custom':
35 : required by substitution of 'template typename
std::enable_if::type write(NLogger&, const
Head&) [with Head = std::tuple]'
70 : required from 'typename std::enable_if<(!
has_nlog_custom::value)>::type log(NLogger&, const Head&) [with Head =
LogStructN; typename std::enable_if<(! has_nlog_custom::value)>::type =
void]'
88 : required from here
21 : error: 'void Foo0::nlog_custom(NLogger&) const' is inaccessible within
this context
struct has_nlog_custom> : std::true_type
{};
^~
78 : note: declared here
void nlog_custom(NLogger & nl) const {}
^~~
21 : error: 'void Foo0::nlog_custom(NLogger&) const' is inaccessible within
this context
struct has_nlog_custom> : std::true_type
{};
^~
78 : note: declared here
void nlog_custom(NLogger & nl) const {}
^~~
Compilation failed


I have a workaround, changing the #if between 0 & 1 toggles the error.  But I
don't believe that I've found the root cause of the issue.  It would be very
helpful to either diagnose this as a gcc bug, or have gcc provide more
diagnostic information on the root cause.

Thanks

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #5 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #3)
> I'd say it is a bug in ix86_fp_cmp_code_to_pcmp_immediate that it handles
> only a small portion of the FP comparison codes, while VCMPP[SD]
> instructions should be able to handle everything needed.
> But, I'm also surprised where the values in that function come from.
> Looking at the D modifier expansion in i386.c that is used for AVX vcmp, I
> see that:
> code  %D3 emits corresponding imm   
> ix86_fp_cmp_code_to_pcmp_immediate
> UNEQ  eq_us 0x18 ICE
> EQeq08
> UNLT  nge   9ICE
> LTlt10x19
> UNLE  ngt   0xa  ICE
> LEle20x1a
> UNORDERED unord 3ICE
> LTGT  neq_oq0xc  ICE
> NEneq   44
> GEge0xd  0x15
> UNGE  nlt   5ICE
> GTgt0xe  0x16
> UNGT  nle   6ICE
> ORDERED   ord   7ICE
> So, there is agreement only on NE and nothing else.

I took values for ix86_fp_cmp_code_to_pcmp_immediate from some table Kirill
gave me and seems all values I used were unordered non-signaling variants.  I
don't fully understand the logic of imms in this table.  Some of them are
signalling and some of them are not.  Also why is NE unordered?  But I suspect
there is good reason for such choice and suppose AVX512 compares should be put
in a consistent state with AVX ones by fixing
ix86_fp_cmp_code_to_pcmp_immediate appropriately.

[Bug c/71567] Incorrect loop optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This:
*(gr->ggint[i]) != '\0' && i < NIN 

is reading one past the array bounds.  Swapping the operands of && fixes the
problem.

The reason dummy influences GCC optimization is that if it is not there, GCC
assumes struct1 has a flexible array at the end of it.

[Bug c++/71508] Huge memory usage on compiling with many types

[olarupaulstelian97+bugzilla at gmail dot com]

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

--- Comment #2 from Paul Olaru  
---
Created attachment 38716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38716=edit
Preprocessed source (gzipped)

The uncompressed file is barely above 1MB. Is it normal for it to be this
large?

[Bug tree-optimization/71354] [7 Regression] gcc.dg/vect/vect-23.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jun 17 13:55:06 2016
New Revision: 237555

URL: https://gcc.gnu.org/viewcvs?rev=237555=gcc=rev
Log:

PR tree-optimization/71354
* gcc.dg/vect/vect-23.c: Use vect_condition instead of vect_cond.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-23.c

[Bug c/71567] New: Incorrect loop optimization

[tyoma.ariv at gmail dot com]

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

Bug ID: 71567
   Summary: Incorrect loop optimization
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tyoma.ariv at gmail dot com
  Target Milestone: ---

#define NIN 2


struct struct1 {
char ggint[NIN][6];
char dummy;
};
/*--*/
int get_struct1cnt(struct struct1 *gr)
{
int i=0 ;
for ( i=0 ; *(gr->ggint[i]) != '\0' && i < NIN ; ++i )
;
return i ;
}
/*--*/
int main (int argc, char **argv)
{
struct struct1 grp = {0};

for ( int i=0 ; i < NIN ; i++ )
grp.ggint[i][0] = 'A'+i;
printf("%d\n", get_struct1cnt ());

return 0;
}

When compiled with gcc -O -std=c99 one.c: the program display 1.
When compiled with gcc -std=c99 one.c: the programm display 2 as expcted

If optimization level is -Og or not, the program displays 2, if optimization
level is -O or higher, the program displays 1.

Note: removing dummy field from struct struct1 make this bug not reproducable

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[fortranbug at gmail dot com]

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

--- Comment #6 from fortranbug at gmail dot com ---
Thank you for the suggested workaround. This can certainly be helpful in the
short term.  However, we would not want to rely on tuning compiler optimization
switches in the future to ensure correct code operation.  (Our system is used
by a community of users and it is not possible for us to ensure that they all
use specific optimizations switches.)

Can someone clarify the status of this bug report?  Is this a recognized issue
that will be addressed at some point?

[Bug c++/59861] Inconsistent error output format

[milasudril at gmail dot com]

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

milasudril at gmail dot com changed:

   What|Removed |Added

   Severity|minor   |enhancement

[Bug c++/71541] destructor of condition_variable_any crashes with static linkage

[gcc_bugzilla at haphi dot de]

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

--- Comment #6 from Hans Philipp Annen  ---
>  -Wl,--whole-archive -lpthread -Wl,--no-whole-archive
This did help.
Without it, the destructor of condition_variable just jumps to nowhere:

> Dump of assembler code for function _ZNSt18condition_variableD2Ev:
> => 0x00402ef0 <+0>: jmpq   0x0
> End of assembler dump.

With -Wl,--whole-archive -lpthread: 
> Dump of assembler code for function _ZNSt18condition_variableD2Ev:
> => 0x0040f240 <+0>: jmpq   0x407df0 
> End of assembler dump.

[Bug libstdc++/71562] Changing the hard coded size of _S_local_capacity in sso_string_base.h

[developm...@faf-ltd.com]

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

--- Comment #2 from Peter VARGA  ---
I disagree 100% with your comment!

I am definitely NOT a genius and I needed 5 minutes to find out where the hard
coded size is set.
Look at the GNU Glibc - you can crash an existing system when running
./configure with the wrong paths/settings. In the documentation is a warning.

You NEVER can be responsible if a programmer does NOT know what he is doing.
You can only warn them and then let it go.

I do NOT need this define - I set it already to my own value but because
vstring.h has the special status I thought it may be also for other programner
useful.

Why 15 and not 30? Do you understand what I mean?

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[tripiana at gmail dot com]

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

--- Comment #4 from Carlos Tripiana Montes  ---
I wasn't sure but that was my intuition. But I'm afraid I don't have enough
knowledge to propose a fix.

(In reply to Jakub Jelinek from comment #3)
> I'd say it is a bug in ix86_fp_cmp_code_to_pcmp_immediate that it handles
> only a small portion of the FP comparison codes, while VCMPP[SD]
> instructions should be able to handle everything needed.
> But, I'm also surprised where the values in that function come from.
> Looking at the D modifier expansion in i386.c that is used for AVX vcmp, I
> see that:
> code  %D3 emits corresponding imm   
> ix86_fp_cmp_code_to_pcmp_immediate
> UNEQ  eq_us 0x18 ICE
> EQeq08
> UNLT  nge   9ICE
> LTlt10x19
> UNLE  ngt   0xa  ICE
> LEle20x1a
> UNORDERED unord 3ICE
> LTGT  neq_oq0xc  ICE
> NEneq   44
> GEge0xd  0x15
> UNGE  nlt   5ICE
> GTgt0xe  0x16
> UNGT  nle   6ICE
> ORDERED   ord   7ICE
> So, there is agreement only on NE and nothing else.

[Bug c++/71566] Attribute [[aligned(16)]] on function is ignored

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to denis.campredon from comment #1)
> You have to change `[[aligned(16)]]' to `[[gnu::aligned(16)]]' as attribute
> aligned is a gnu extension to the standard.

Indeed. The warning is telling you that [[aligned(16)]] is not a recognised
attribute.

[Bug libstdc++/71545] [6/7 Regression] Incorrect irreflexive comparison debug check in std::lower_bound

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.2

[Bug c++/71541] destructor of condition_variable_any crashes with static linkage

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
It does for Fedora and Red Hat-derived systems. Try:

 -Wl,--whole-archive -lpthread -Wl,--no-whole-archive

[Bug libstdc++/71562] Changing the hard coded size of _S_local_capacity in sso_string_base.h

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Peter VARGA from comment #0)
> This would increase the flexibility for the programmer without a hack in the
> c++ include file...

Allowing programmers to change the ABI per-translation unit ... chaos ensues.

[Bug c++/71566] Attribute [[aligned(16)]] on function is ignored

[denis.campredon at gmail dot com]

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

denis.campredon at gmail dot com changed:

   What|Removed |Added

 CC||denis.campredon at gmail dot 
com

--- Comment #1 from denis.campredon at gmail dot com ---
You have to change `[[aligned(16)]]' to `[[gnu::aligned(16)]]' as attribute
aligned is a gnu extension to the standard.

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jun 17 09:26:05 2016
New Revision: 237552

URL: https://gcc.gnu.org/viewcvs?rev=237552=gcc=rev
Log:
PR tree-optimization/71347
* tree-ssa-loop-ivopts.c (determine_group_iv_cost_address): Compute
cost for all uses in group.

PR tree-optimization/71347
* gcc.dg/tree-ssa/pr71347.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug tree-optimization/71354] [7 Regression] gcc.dg/vect/vect-23.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jun 17 09:21:12 2016
New Revision: 237551

URL: https://gcc.gnu.org/viewcvs?rev=237551=gcc=rev
Log:
PR tree-optimization/71354
* gcc.dg/vect/vect-23.c: Add VECT_COND requirement.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-23.c

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-17
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
I'd say it is a bug in ix86_fp_cmp_code_to_pcmp_immediate that it handles only
a small portion of the FP comparison codes, while VCMPP[SD] instructions should
be able to handle everything needed.
But, I'm also surprised where the values in that function come from.
Looking at the D modifier expansion in i386.c that is used for AVX vcmp, I see
that:
code  %D3 emits corresponding immix86_fp_cmp_code_to_pcmp_immediate
UNEQ  eq_us 0x18 ICE
EQeq08
UNLT  nge   9ICE
LTlt10x19
UNLE  ngt   0xa  ICE
LEle20x1a
UNORDERED unord 3ICE
LTGT  neq_oq0xc  ICE
NEneq   44
GEge0xd  0x15
UNGE  nlt   5ICE
GTgt0xe  0x16
UNGT  nle   6ICE
ORDERED   ord   7ICE
So, there is agreement only on NE and nothing else.

[Bug c++/71566] New: Attribute [[aligned(16)]] on function is ignored

[milasudril at gmail dot com]

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

Bug ID: 71566
   Summary: Attribute [[aligned(16)]] on function is ignored
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: milasudril at gmail dot com
  Target Milestone: ---

g++ does not accept [[aligned(16)]] as attribute on a function. However, the
non-standard notation works.

Example:

#include 

__attribute__((aligned(16))) int test(int x)
{
printf("Address of test: %p\n",test);
return 0;
}

[[aligned(16)]] int test2(int x)
{
printf("Address of test2: %p\n",test2);
return 0;
}

int main()
{
test(0);
test2(0);
return 0;
}

g++ --version && g++ -std=c++14 -Wall main.cpp && ./a.out

g++ (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

main.cpp:9:32: warning: 'aligned' attribute directive ignored [-Wattributes]
 [[aligned(16)]] int test2(int x)
^
Address of test: 0x4005a0
Address of test2: 0x4005c6

[Bug c++/64385] odd behaviour of std::is_move_constructible< std::ostringstream >

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This works correctly in GCC 5, but isn't going to be fixed in the 4.9 branch.

[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #2)
> That said, about the zero/non-zero bits, it is
> even more complicated in this case, because e.g. 1 / -1 has all bits set,
> the thing is just that it is then undefined behavior for the shift.
> Wonder what optimization performed this at the RTL level and if it gets all
> the cases right.

(I didn't check)
A << B is the same as A << (B & 31). If B is C << 8, it isn't hard to determine
that (C << 8) & 31 is 0.

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #2 from Igor Zamyatin  ---
Created attachment 38715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38715=edit
Raw fortran source file

Fail can be seen on trunk with
gfortran -march=knl -Ofast -fno-finite-math-only prja.f.

Adding Ilya to look at it

[Bug fortran/71565] New: INTENT(IN) polymorphic argument with pointer components - reject valid code

[mrestelli at gmail dot com]

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

Bug ID: 71565
   Summary: INTENT(IN) polymorphic argument with pointer
components - reject valid code
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

(This was also discussed on comp.lang.fortran:
https://groups.google.com/forum/#!topic/comp.lang.fortran/dPaOv53SGeA )

gfortran refuses to compile s1 in the attached code (while accepting
s2 and s3 which do essentially the same thing):


$ gfortran -c test.f90 -o test.o
test.f90:17:3:

select type(var); class is(t_b)
   2
var%i = 3
   1
Error: Associate-name »var« can not appear in a variable definition context at
(1) because its target at (2) can not, either

$ gfortran --version
GNU Fortran (GCC) 7.0.0 20160615 (experimental)


This seems a bug in gfortran, since the assignment defines the target
of the pointer, not the pointer itself.

Here is the code


module m

 implicit none

 type, abstract :: t_a
 end type t_a

 type, extends(t_a), abstract :: t_b
  integer, pointer :: i => null()
 end type t_b

contains

 subroutine s1(var)
  class(t_a), intent(in) :: var
   select type(var); class is(t_b)
   var%i = 3
   end select
 end subroutine s1

 subroutine s2(var)
  class(t_b), intent(in) :: var
   var%i = 3
 end subroutine s2

 subroutine s3(var)
  class(t_a), intent(in) :: var
  integer, pointer :: tmp
   select type(var); class is(t_b)
   tmp => var%i
   tmp = 3
   end select
 end subroutine s3

end module m

[Bug c++/71561] [5/6/7 Regression] ICE with -Wall on valid C++ code on x86_64-linux-gnu: in potential_constant_expression_1, at cp/constexpr.c:5249

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE with -Wall on valid C++ |[5/6/7 Regression] ICE with
   |code on x86_64-linux-gnu:   |-Wall on valid C++ code on
   |in  |x86_64-linux-gnu: in
   |potential_constant_expressi |potential_constant_expressi
   |on_1, at|on_1, at
   |cp/constexpr.c:5249 |cp/constexpr.c:5249

--- Comment #2 from Jakub Jelinek  ---
Indeed, started with r217663.

[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed with r224283.
Note, I wouldn't use volatile in any testcase like this, but
int
foo (int k)
{
  int t = 1 << ((1 / k) << 8);
  if (t != 1)
__builtin_abort ();
  return 0;
}
can serve the same purpose.  That said, about the zero/non-zero bits, it is
even more complicated in this case, because e.g. 1 / -1 has all bits set, the
thing is just that it is then undefined behavior for the shift.
Wonder what optimization performed this at the RTL level and if it gets all the
cases right.

[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-17
Summary|Regression in GCC-7.0.0's   |[6/7 Regression] Regression
   |optimizer.  |in GCC-7.0.0's optimizer.
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
Surprisingly, in gcc-5, this all gets simplified in RTL. In gcc-6, we do the
first step of the optimization in gimple, and that prevents RTL from doing the
rest, probably because we lose the fact that (1/k)<<8 is used in a (truncated)
shift.

In gimple, we have now:

  k.0_1 ={v} k;
  _2 = 1 / k.0_1;
  _3 = _2 << 8;
  if (_3 != 0)

We could turn (a << 8) != 0 into a != 0 because of the range of a. More
generally, we could produce (a & CST) != 0, but I am not sure it is always a
win, and then we still need to drop the & CST.

And then we would be left with (1 / k) != 0 (the range is [-1,1]), which could
possibly become (unsigned)k+1<=2, but not a constant.

So the first optimization from (1 << X) != 1 to X != 0 lost the information. To
preserve it, we would need, before that transformation, to notice that (1/k)<<8
has enough low-order zero bits that 0 is the only valid value it can have in a
shift. CCP seems like the only time this could happen (though the
transformation itself could be in match.pd or elsewhere).

Note that in any case the optimization will be fragile. That could be because
the testcase seems a bit artificial.

[Bug target/56164] [avr] ICE: spill fail with __flash keyword

[pitchumani.s at hotmail dot com]

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

Pitchumani  changed:

   What|Removed |Added

 CC||pitchumani.s at hotmail dot com

--- Comment #7 from Pitchumani  ---
Not re-producible in trunk (gcc-7).

[Bug target/53935] [avr][c++] missing warning for non-const data in progmem

[pitchumani.s at hotmail dot com]

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

Pitchumani  changed:

   What|Removed |Added

 CC||pitchumani.s at hotmail dot com

--- Comment #1 from Pitchumani  ---
Works in trunk (gcc-7)

[Bug target/52305] [avr] ICE in avr_print_operand: unknown mode (const_double)

[pitchumani.s at hotmail dot com]

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

Pitchumani  changed:

   What|Removed |Added

 CC||pitchumani.s at hotmail dot com

--- Comment #3 from Pitchumani  ---
Not re-producible in gcc-7 trunk. Is it valid anymore?