[Bug libstdc++/78565] undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Thanks for checking

[Bug other/46828] gengtype is not installed, but become a user [plugins with GTY-s] program

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Pretty sure gengtype is installed now in newer versions

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

  Attachment #43617|0   |1
is obsolete||

--- Comment #17 from Peter Bergner  ---
Created attachment 43621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43621=edit
Version 3 of the patch

Final version of the patch that bootstraps and regtests with no regressions on
both BE and LE.  The previous patch had some testsuite regressions on LE.

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[dlesnikov at hotmail dot com]

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

--- Comment #7 from Dmitry Lesnikov  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Dmitry Lesnikov from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > signed overflow is undefined behavior at runtime.
> > 
> > for(int i=0; i<10; i++)
> > 
> > this loop is correct.
> 
> But there is an overflow with the variable a when i is 6.

Why does the line
C1 c1;
affect the behavior of the loop?

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[dlesnikov at hotmail dot com]

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

--- Comment #6 from Dmitry Lesnikov  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Dmitry Lesnikov from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > signed overflow is undefined behavior at runtime.
> > 
> > for(int i=0; i<10; i++)
> > 
> > this loop is correct.
> 
> But there is an overflow with the variable a when i is 6.

Yes, but code generation incorrect. It's not runtime yet.

[Bug tree-optimization/43432] Missed vectorization: "complicated access pattern" for increasing and decreasing data indexing

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Michael Matz from comment #3)
> Subject: Bug 43432
> 
> Author: matz
> Date: Fri Sep 17 13:26:43 2010
> New Revision: 164367
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=164367
> Log:
>   PR tree-optimization/43432
>   * tree-vect-data-refs.c (vect_analyze_data_ref_access):
>   Accept backwards consecutive accesses.
>   (vect_create_data_ref_ptr): If step is negative generate
>   decreasing IVs.
>   * tree-vect-stmts.c (vectorizable_store): Reject negative steps.
>   (perm_mask_for_reverse, reverse_vec_elements): New functions.
>   (vectorizable_load): Handle loads with negative steps when easily
>   possible.
> 
> testsuite/
>   PR tree-optimization/43432
>   * lib/target-supports.exp (check_effective_target_vect_perm_byte,
>   check_effective_target_vect_perm_short): New predicates.
>   (check_effective_target_vect_perm): Include x86_64.
>   * gcc.dg/vect/pr43432.c: New test.
>   * gcc.dg/vect/vect-114.c: Adjust.
>   * gcc.dg/vect/vect-15.c: Ditto.
>   * gcc.dg/vect/slp-perm-8.c: Use new predicate.
>   * gcc.dg/vect/slp-perm-9.c: Ditto.
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/vect/pr43432.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.dg/vect/slp-perm-8.c
> trunk/gcc/testsuite/gcc.dg/vect/slp-perm-9.c
> trunk/gcc/testsuite/gcc.dg/vect/vect-114.c
> trunk/gcc/testsuite/gcc.dg/vect/vect-15.c
> trunk/gcc/testsuite/lib/target-supports.exp
> trunk/gcc/tree-vect-data-refs.c
> trunk/gcc/tree-vect-stmts.c

Did this fix it?

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Dmitry Lesnikov from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > signed overflow is undefined behavior at runtime.
> 
> for(int i=0; i<10; i++)
> 
> this loop is correct.

But there is an overflow with the variable a when i is 6.

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[dlesnikov at hotmail dot com]

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

--- Comment #4 from Dmitry Lesnikov  ---
(In reply to Andrew Pinski from comment #1)
> signed overflow is undefined behavior at runtime.

for(int i=0; i<10; i++)

this loop is correct.

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Does not matter, the behavior is undefined.

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[dlesnikov at hotmail dot com]

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

Dmitry Lesnikov  changed:

   What|Removed |Added

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

--- Comment #2 from Dmitry Lesnikov  ---
gcc 5.4.1 make correct code.

[Bug c++/84816] [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_84  |
 Status|UNCONFIRMED |RESOLVED
  Known to work|5.4.1   |
   Host|Ubuntu 16.04 x86_84 |
 Resolution|--- |INVALID
  Known to fail|7.2.0, 8.0.1|

--- Comment #1 from Andrew Pinski  ---
signed overflow is undefined behavior at runtime.

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker  ---
Reading the relevant part of the standard in more detail, it seems like it's a
GCC bug that GCC is applying the exception for plain int to typedefs. ¶5:

"Each of the comma-separated multisets designates the same type, except that
for bit-fields, it is implementation-defined whether the specifier int
designates the same type as signed int or the same type as unsigned int."

This text is referring to an above (¶3) list of types, containing "int, signed,
or signed int" as one line item and "typedef name" as another. The exception is
written explicitly in terms of the former, and makes no mention of the latter.

[Bug c++/84816] New: [7.2.0/8.0.1 x86_64] Incorrect code generation if signed overflow

[dlesnikov at hotmail dot com]

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

Bug ID: 84816
   Summary: [7.2.0/8.0.1 x86_64] Incorrect code generation if
signed overflow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dlesnikov at hotmail dot com
  Target Milestone: ---

Hello!

# g++-7 --version
g++-7 (Ubuntu 7.2.0-8ubuntu3.1~16.04.york0) 7.2.0

# g++-8 --version
g++-8 (Ubuntu 8-20180218-1ubuntu1~16.04.york0) 8.0.1 20180218 (experimental)
[trunk revision 257787]

c++ code :

#include 

class C1 {};

int main(void)
{
   C1 c1;
   int a = 0x7FFA;
   for(int i=0; i<10; i++)
  printf("%d\n", ++a);
   return 0;
}


g++-7[8] -O2 -S sigover.cpp

the loop assembler code with error:
.L2:
addl$1, %ebx
movl$.LC0, %esi
movl$1, %edi
movl%ebx, %edx
xorl%eax, %eax
call__printf_chk
jmp .L2<-- infinite loop
.cfi_endproc
.LFE30:

g++-7[8] -O1 -S sigover.cpp

the loop assembler code without error:
.L2:
addl$1, %ebx
movl%ebx, %edx
movl$.LC0, %esi
movl$1, %edi
movl$0, %eax
call__printf_chk
cmpl$-2147483644, %ebx<-- check the end of loop
jne .L2
movl$0, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE30:

if comment 1st line in main:
// C1 c1;
then g++-7 -O2 correctly generates the code
but g++-8 -O2 still makes an infinite loop

[Bug c/84815] gcc fwrite failed write to stdout in binary mode (Win7)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is a library issue and not a GCC issue.  Please report it to who you got
your libc from; in this case most likely mingw folks.

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[bugdal at aerifal dot cx]

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

--- Comment #4 from Rich Felker  ---
Further examination shows that this GCC feature (-funsigned-bitfields) is
actually buggy/non-conforming. It changes the default signedness of all integer
types in bitfields, not just plain int. This behavior seems consistent with the
documentation, but not with the C standard, which only permits it for plain
int; see C11 6.7.2 ¶5:

"Each of the comma-separated multisets designates the same type, except that
for bit-fields, it is implementation-defined whether the specifier int
designates the same type as signed int or the same type as unsigned int."

Should this be opened as a separate bug?

[Bug c/84815] New: gcc fwrite failed write to stdout in binary mode (Win7)

[albertmcchan at yahoo dot com]

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

Bug ID: 84815
   Summary: gcc fwrite failed write to stdout in binary mode
(Win7)
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albertmcchan at yahoo dot com
  Target Milestone: ---

#include 
#include 
#include 
#include 

int main()
{
size_t n = 64*1024; // code ok if below 64k
char* buf = malloc(n);
if (buf == NULL) return 1;
memset(buf, 'O', n);
buf[n-1] = 'X'; // signal for last byte

setmode(STDOUT_FILENO, _O_BINARY);  // <-- this caused the bug

n = fwrite(buf, 1, n, stdout);  // fwrite failed, but why ?
printf("\nfwrite %d bytes\n", n);   // output: fwrite 0 bytes
free(buf);
return 0;
}

[Bug c++/84814] Type of arithmetic expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
the integral promotions (4.5) shall be performed on both operands

This means uint16_t is promoted to int first.

So:
if((curtime - LastTime) >= Request)

Is really:
if(((int)curtime - (int)LastTime) >= (int)Request)


In the second case the code is equivalent to:
if((int)(uint16_t)((int)curtime - (int)LastTime) >= (int)Request)

[Bug c++/84814] New: Type of arithmetic expression

[smal.root at gmail dot com]

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

Bug ID: 84814
   Summary: Type of arithmetic expression
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smal.root at gmail dot com
  Target Milestone: ---

Created attachment 43620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43620=edit
Project archive

File: main.cpp, line: 20.

When used variant
> if((curtime - LastTime) >= Request)

then we get following assembly code (file: type_test_wo_conv.lss):

> 8000260:  8806ldrhr6, [r0, #0]
> 8000262:  7825ldrbr5, [r4, #0]
> 8000264:  b292uxthr2, r2
> 8000266:  1b92subsr2, r2, r6
> 8000268:  42aacmp r2, r5

as you can see "subs" result is not converted to uint16_t, but must. Because
both arguments of subtraction has same type:

"— Otherwise, the integral promotions (4.5) shall be performed on both
operands. Then the following rules shall be applied to the promoted operands:

— If both operands have the same type, no further conversion is needed."

As result - arguments of "cmp" is invalid uint32_t values.

If we use additional "manual" type conversion for expression

> if((uint16_t)(curtime - LastTime) >= Request)

then we get right result:

> 8000260:  8806ldrhr6, [r0, #0]
> 8000262:  7825ldrbr5, [r4, #0]
> 8000264:  1b92subsr2, r2, r6
> 8000266:  b292uxthr2, r2
> 8000268:  42aacmp r2, r5

after "subs" result is converted to uint16_t.

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[noloader at gmail dot com]

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

--- Comment #7 from Jeffrey Walton  ---
(In reply to Bill Schmidt from comment #4)
> ...
> 
> The best performance will be achieved by writing this loop entirely using
> inline asm code, with all data loaded/stored using lxvd2x and stxvd2x (no
> swaps), thus in "big-endian element order" (element 0 in the high-order
> position of the register).  Because of the big-endian nature of vshasigmaw,
> this is always going to be the best approach.

Thanks Bill.

We are working on your lxvd2x suggestion using inline assembly.

Related, see "GCC vec_xl_be replacement using inline assembly",
https://stackoverflow.com/q/49215090/608639.

-

I'm not sure if I am doing something wrong, or this is a new issue:

$ cat test.cxx
...

typedef __vector unsigned int  uint32x4_p8;

uint32x4_p8 VEC_XL_BE(const uint8_t* data, int offset)
{
#if defined(__xlc__) || defined(__xlC__)
  return (uint32x4_p8)vec_xl_be(offset, (uint8_t*)data);
#else
  uint32x4_p8 res;
  __asm(" lxvd2x  %x0, %1, %2\n\t"
: "=wa" (res)
: "g" (data), "g" (offset));
  return res;

#endif
}

When I use VEC_XL_BE in real life it results in:

$ g++ -DTEST_MAIN -g3 -O3 -mcpu=power8 sha256-p8.cxx -o sha256-p8.exe
/home/noloader/tmp/ccbDnfFr.s: Assembler messages:
/home/noloader/tmp/ccbDnfFr.s:758: Error: operand out of range (32 is not
between 0 and 31)
/home/noloader/tmp/ccbDnfFr.s:983: Error: operand out of range (48 is not
between 0 and 31)

[Bug c++/84813] New: internal compiler error: Segmentation fault with lambdas and constexpr variables

[wtt6 at cornell dot edu]

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

Bug ID: 84813
   Summary: internal compiler error: Segmentation fault with
lambdas and constexpr variables
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wtt6 at cornell dot edu
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 43619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43619=edit
test.cpp

The attached source file causes segfaults in gcc 7.3.0 and 6.4.0 when compiling
with debug symbols.  (The below output is from a Gentoo system but I have
verified that this occurs elsewhere as well.)

$ g++-7.3.0 -v -std=c++14 -g test.cpp 
Using built-in specs.
COLLECT_GCC=g++-7.3.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-7.3.0/work/gcc-7.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 7.3.0 p1.0' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto
--without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.0 (Gentoo 7.3.0 p1.0) 
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-g' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test
-g -std=c++14 -version -o /tmp/ccwMTi4n.s
GNU C++14 (Gentoo 7.3.0 p1.0) version 7.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version noneGGC heuristics: --param ggc-min-expand=100
--param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (Gentoo 7.3.0 p1.0) version 7.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 97a14d92d195bbf5fa3050d06d00adda
g++-7.3.0: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL

[kretz at kde dot org]

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

--- Comment #2 from Matthias Kretz  ---
Created attachment 43618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43618=edit
unreduced testcase

Compile with `g++ -std=c++17 -O2 -march=knl -o knl-fail knl-fail.cpp`.
The function `Tests::operators_ > >::run()` countains the invalid instructions.

% g++-7 --version
g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0

[Bug c++/84812] New: [8 Regression] ICE with local function

[reichelt at gcc dot gnu.org]

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

Bug ID: 84812
   Summary: [8 Regression] ICE with local function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE on trunk:

==
struct A { void foo(); };
struct B { void foo(); };

struct C : A, B
{
  C()
  {
void foo();
  }
};
==

bug.cc: In constructor 'C::C()':
bug.cc:8:14: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'tree_list' in set_local_extern_decl_linkage, at
cp/name-lookup.c:2886
 void foo();
  ^
0x78c545 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9507
0x623f07 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3246
0x623f07 set_local_extern_decl_linkage
../../gcc/gcc/cp/name-lookup.c:2886
0x623f07 do_pushdecl
../../gcc/gcc/cp/name-lookup.c:3011
0x623f07 pushdecl(tree_node*, bool)
../../gcc/gcc/cp/name-lookup.c:3154
0x8aa093 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:5197
0x93ae39 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19598
0x942578 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13057
0x943388 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12882
0x943db9 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12476
0x922433 cp_parser_statement
../../gcc/gcc/cp/parser.c:10925
0x9233a0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11274
0x923477 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11228
0x939f00 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21776
0x939f00 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21813
0x93a7b0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26828
0x93c49c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:27708
0x92e6c3 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22752
0x92fad9 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22778
0x92fad9 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16774
Please submit a full bug report, [etc.]

The regression was introduced between 2017-05-19 and 2017-05-25.

Nathan, this might be caused by your name-lookup changes.
Would you mind having a look?

[Bug ipa/84811] New: ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

Bug ID: 84811
   Summary: ICE on valid code at -O3 in 64-bit mode on
x86_64-linux-gnu: in smallest_mode_for_size, at
stor-layout.c:355
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180310 (experimental) [trunk revision 258413] (GCC)
$
$ gcctk -O2 -c small.c
$ gcc-7.2.0 -O3 -c small.c
$
$ gcctk -O3 -c small.c
during RTL pass: dse1
small.c: In function ‘fn1’:
small.c:12:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc95e8b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x146b92b smallest_int_mode_for_size
../../gcc-source-trunk/gcc/machmode.h:842
0x146b92b find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1701
0x146b92b get_stored_val
../../gcc-source-trunk/gcc/dse.c:1847
0x146e4b3 record_store
../../gcc-source-trunk/gcc/dse.c:1557
0x146f3be scan_insn
../../gcc-source-trunk/gcc/dse.c:2545
0x146f3be dse_step1
../../gcc-source-trunk/gcc/dse.c:2657
0x146f3be rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3574
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


-


int a;
long b[1][9];

void fn1 ()
{ 
  while (a)
{ 
  for (a = 0; a < 9; a++)
b[218][a] = 1;
  break;
}
}

[Bug c++/84810] New: [concepts][c++20] constraints of lambdas with explicit template parameters are not checked

[eric.niebler at gmail dot com]

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

Bug ID: 84810
   Summary: [concepts][c++20] constraints of lambdas with explicit
template parameters are not checked
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

The following code declares a C++20 lambda with a constraint. The invocation of
the lambda should be ill-formed unless the constraint is satisfied; however,
gcc is accepting invalid code.


template  constexpr bool is_int = false;
template <> constexpr bool is_int = true;

template 
concept bool Int = is_int;

int main() {
auto x = [](T t) { return 42; };
auto y = x(42);
auto z = x(""); // should be ill-formed.
return z;
}

Compile with gcc trunk and `-fconcepts -std=gnu++2a`.

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[kaushikp at gcc dot gnu.org]

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

kaushikp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kaushikp at gcc dot gnu.org

--- Comment #16 from kaushikp at gcc dot gnu.org ---
Thanks for the patch Peter.
gcc builds without errors on trunk with this patch.

I will let you know how my tests go.

[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues

[kargl at gcc dot gnu.org]

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

Bug 84734 Summary: [8 Regression] Compiling codes with insane array dimensions 
gives an ICE after r257971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734

   What|Removed |Added

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

[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|8.0 |6.5

--- Comment #11 from kargl at gcc dot gnu.org ---
fixed.

[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Mar 10 19:00:49 2018
New Revision: 258419

URL: https://gcc.gnu.org/viewcvs?rev=258419=gcc=rev
Log:
2018-03-10  Steven G. Kargl  

PR fortran/84734
* arith.c (check_result, eval_intrinsic):  If result overflows, pass
the expression up the chain instead of a NULL pointer.

2018-03-10  Steven G. Kargl  

PR fortran/84734
* gfortran.dg/pr84734.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr84734.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/arith.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug other/82352] [7 Regression] comdat-local function called by void h::i() outside its comdat

[hjl at gcc dot gnu.org]

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

--- Comment #13 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sat Mar 10 18:45:55 2018
New Revision: 258418

URL: https://gcc.gnu.org/viewcvs?rev=258418=gcc=rev
Log:
Backport r256266 from mainline

Backport from mainline
2018-01-04  Jakub Jelinek  

PR ipa/82352
* g++.dg/ipa/pr82352.C (size_t): Define to __SIZE_TYPE__ instead of
long unsigned int.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr82352.C

[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Mar 10 18:44:25 2018
New Revision: 258417

URL: https://gcc.gnu.org/viewcvs?rev=258417=gcc=rev
Log:
2018-03-10  Steven G. Kargl  

PR fortran/84734
* arith.c (check_result, eval_intrinsic):  If result overflows, pass
the expression up the chain instead of a NULL pointer.

2018-03-10  Steven G. Kargl  

PR fortran/84734
* gfortran.dg/pr84734.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr84734.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/arith.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Mar 10 18:34:12 2018
New Revision: 258416

URL: https://gcc.gnu.org/viewcvs?rev=258416=gcc=rev
Log:
2018-03-09  Steven G. Kargl  

PR fortran/84734
* arith.c (check_result, eval_intrinsic):  If result overflows, pass
the expression up the chain instead of a NULL pointer.

2018-03-09  Steven G. Kargl  

PR fortran/84734
* gfortran.dg/pr84734.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr84734.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84809] RFE: saveall attribute

[a...@cloudius-systems.com]

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

--- Comment #1 from Avi Kivity  ---
I think no_caller_saved_registers is very close to what I want, except for
"Since GCC doesn't preserve MPX, SSE, MMX nor x87 states, the GCC option
'-mgeneral-regs-only' should be used to compile functions with
'no_caller_saved_registers' attribute."

[Bug target/84809] New: RFE: saveall attribute

[a...@cloudius-systems.com]

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

Bug ID: 84809
   Summary: RFE: saveall attribute
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

A saveall function attribute, with the meaning that the function saves all
registers and therefore its caller does not need to save them, can be useful.

Two use cases:
 - currently, debugging code dumps generated from assertion failures is
needlessly hard, because gcc clobbers most of the registers during
__assert_fail's execution. If __assert_fail were marked saveall, then the
frames that called __assert_fail would be able to recover their register values
 - reducing the overhead of a cold function called from a hot inline

 inline void hot_function(...) {
   if (some_rare_condition) {
   cold_function(...);
   }
   some more code
 }

if cold_function() is marked saveall, then any registers used by hot_function()
(for example, its arguments) and its caller would be preserved and would not
need to be assumed clobbered.

The implementation would be similar to the interrupt attribute, except for the
return instruction. On x86 special care would be needed for the fpu registers
(would need alloca() since the size of the register stack is only known at
runtime, or perhaps saveall would still clobber fpu registers).

[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
And the actual problem happens earlier: the earlier 63, 70 -> 71 combination
links
the much later insn 100 to 70, for cc, but there are plenty other setters and
users of cc earlier.

[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Insn 55 is a parallel, and that is split into two insns i1 and i2, both
numbered as 55.  The i1 will never become part of the insn stream.  It is
this insn that is deleted.

Later on insn 55 is combined into insn 100:

   55:
cc:CC_C=zero_extend(r165:DI)+zero_extend(x2:DI)!=zero_extend(r165:DI+x2:DI)
  100:
{cc:CC_C=zero_extend(r178:DI)+zero_extend(r198:DI)!=zero_extend(r178:DI+r198:DI);r200:DI=r178:DI+r198:DI;}
  REG_DEAD r198:DI
  REG_DEAD r178:DI

becomes

100:
{cc:CC_C=zero_extend(r178:DI)+zero_extend(r198:DI)!=zero_extend(r178:DI+r198:DI);r200:DI=r178:DI+r198:DI;}
  REG_DEAD r178:DI
  REG_DEAD r198:DI

and that seems fine, too?  Or does something in between use cc?  Ah yes, insn
71
does.  Somehow insn 100 has a LOG_LINK to 55 though (for cc).  This happens at
the 55 -> 70 combination.

[Bug c++/84808] New: [8 Regression] ICE with constexpr and array

[reichelt at gcc dot gnu.org]

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

Bug ID: 84808
   Summary: [8 Regression] ICE with constexpr and array
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE on trunk:

=
struct A
{
  int i;
  constexpr A() : i() {}
};

struct B
{
  A a[8];
};

constexpr int foo(int n)
{
  B b;
  ++b.a[n+2].i;
  ++b.a[n].i;
  return 0;
}

constexpr int i = foo(2);
=

bug.cc:20:22:   in 'constexpr' expansion of 'foo(2)'
bug.cc:20:24: internal compiler error: Segmentation fault
 constexpr int i = foo(2);
^
0xeb9a7f crash_signal
../../gcc/gcc/toplev.c:325
0x84e8e3 find_constructor
../../gcc/gcc/cp/constexpr.c:1255
0x116183b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/gcc/tree.c:11400
0x84ee9e unshare_constructor
../../gcc/gcc/cp/constexpr.c:1268
0x853c1d find_array_ctor_elt
../../gcc/gcc/cp/constexpr.c:2257
0x859cef cxx_eval_store_expression
../../gcc/gcc/cp/constexpr.c:3633
0x8571df cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4262
0x856986 cxx_eval_increment_expression
../../gcc/gcc/cp/constexpr.c:3789
0x856986 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4670
0x85777f cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4566
0x8562a7 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4310
0x8562a7 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4310
0x856ed1 cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.c:3912
0x856ed1 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4657
0x85623d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4661
0x855472 cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1700
0x85625b cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4184
0x85b8e7 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4833
0x85e596 maybe_constant_value(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:5051
0x9f2729 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:825
Please submit a full bug report, [etc.]

The regression was introduced between 2018-02-07 and 2018-02-15.
The bug depends on the size of the array B::a and the value passed into foo.
Due to this fragile behavior, it might be that the bug was latent before.

[Bug target/83712] [6/7 Regression] "Unable to find a register to spill" when compiling for thumb1

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Sat Mar 10 16:32:21 2018
New Revision: 258415

URL: https://gcc.gnu.org/viewcvs?rev=258415=gcc=rev
Log:
2018-03-10  Vladimir Makarov  

Reverting patch:
2018-03-09  Vladimir Makarov  

PR target/83712
* lra-assigns.c (assign_by_spills): Return a flag of reload
assignment failure.  Do not process the reload assignment
failures.  Do not spill other reload pseudos if they has the same
reg class.
(lra_assign): Add a return arg.  Set up from the result of
assign_by_spills call.
(find_reload_regno_insns, lra_split_hard_reg_for): New functions.
* lra-constraints.c (split_reg): Add a new arg.  Use it instead of
usage_insns if it is not NULL.
(spill_hard_reg_in_range): New function.
(split_if_necessary, inherit_in_ebb): Pass a new arg to split_reg.
* lra-int.h (spill_hard_reg_in_range, lra_split_hard_reg_for): New
function prototypes.
(lra_assign): Change prototype.
* lra.c (lra): Add code to deal with fails by splitting hard reg
live ranges.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/lra-int.h
trunk/gcc/lra.c

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

  Attachment #43611|0   |1
is obsolete||

--- Comment #15 from Peter Bergner  ---
Created attachment 43617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43617=edit
Yet another updated patch

Sorry, the previous patch had a typo that only seemed to show up on my LE
testing.  Please test this patch to see if it fixes your ICE.

[Bug target/84807] i386: typo "Support Control-flow Enforcment Technology"

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unknown |8.0.1
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 8.

[Bug target/84807] i386: typo "Support Control-flow Enforcment Technology"

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sat Mar 10 15:57:10 2018
New Revision: 258414

URL: https://gcc.gnu.org/viewcvs?rev=258414=gcc=rev
Log:
i386: Fix a typo: Enforcment -> Enforcement

PR target/84807
* config/i386/i386.opt: Replace Enforcment with Enforcement.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.opt

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

 CC||gk at torproject dot org

--- Comment #13 from Georg Koppen  ---
*** Bug 78565 has been marked as a duplicate of this bug. ***

[Bug libstdc++/78565] undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Georg Koppen  ---
Yes, I just tested it, the fix for 79190 fixes this bug as well, thanks.

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

[Bug target/84807] New: i386: typo "Support Control-flow Enforcment Technology"

[roland.illig at gmx dot de]

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

Bug ID: 84807
   Summary: i386: typo "Support Control-flow  Enforcment
Technology"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

* There are two spaces in a row
* Enforcement has 3 e's.

[Bug c/84717] suffix for double constant is a GCC extension is not documented

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=63886

--- Comment #3 from Eric Gallager  ---
This also came up in bug 63886 comment 11

[Bug fortran/54687] Use gcc option machinery for gfortran

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64334
 Depends on|64334   |

--- Comment #15 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #12)
> (In reply to Dominique d'Humieres from comment #11)
> > What is left in this PR before closing it as FIXED?
> 
> 
> There are some things that both the common machinery and Fortran do manually
> (PR64334). Factoring out that code (possibly generating it automatically
> from the .opt files) would be nice, but not essential (so PR64334 does not
> actually block this).

Moving that from "Depends on" to "See Also" then


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64334
[Bug 64334] Common .opt handling: Support flags which take a list of values
(-fopt=a,b,c ...)

[Bug target/83712] [6/7 Regression] "Unable to find a register to spill" when compiling for thumb1

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Alexandre Oliva from comment #8)
> Hey, Vlad, I'm afraid bisection tells me r258390 caused a regression I'm
> seeing on i686-linux-gnu.  hsa-regalloc now fails to compile in stage2:

See

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

for simple testcases.

[Bug target/83712] [6/7 Regression] "Unable to find a register to spill" when compiling for thumb1

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
Hey, Vlad, I'm afraid bisection tells me r258390 caused a regression I'm seeing
on i686-linux-gnu.  hsa-regalloc now fails to compile in stage2:

../../gcc/hsa-regalloc.c: In function ‘void hsa_regalloc()’:
../../gcc/hsa-regalloc.c:728:1: error: unable to find a register to spill
 }
 ^
../../gcc/hsa-regalloc.c:728:1: error: this is the insn:
(insn 1513 3740 3741 249 (parallel [
(set (reg/v:SI 1258 [orig:435 ret ] [435])
(div:SI (reg/v:SI 1258 [orig:435 ret ] [435])
(reg:SI 1162)))
(set (reg:SI 1280 [709])
(mod:SI (reg/v:SI 1258 [orig:435 ret ] [435])
(reg:SI 1162)))
(clobber (reg:CC 17 flags))
]) "../../gcc/hsa-regalloc.c":305 312 {*divmodsi4}
 (expr_list:REG_UNUSED (reg:SI 1280 [709])
(expr_list:REG_DEAD (reg:SI 1162)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
during RTL pass: reload
../../gcc/hsa-regalloc.c:728:1: internal compiler error: in
lra_split_hard_reg_for, at lra-assigns.c:1802
0x8c4e069 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x8aef4e2 lra_split_hard_reg_for()
../../gcc/lra-assigns.c:1802
0x8ae909a lra(_IO_FILE*)
../../gcc/lra.c:2506
0x8a9cce7 do_reload
../../gcc/ira.c:5465
0x8a9d17a execute
../../gcc/ira.c:5649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:1110: recipe for target 'hsa-regalloc.o' failed

[Bug rtl-optimization/84806] New: [8 Regression] r258390 caused in internal compiler error

[hjl.tools at gmail dot com]

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

Bug ID: 84806
   Summary: [8 Regression] r258390 caused in internal compiler
error
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: vmakarov at redhat dot com
  Target Milestone: ---
Target: x86

On x86, r258390 caused:

FAIL: gcc.target/i386/pr55512-1.c (internal compiler error)
FAIL: gcc.target/i386/pr55512-1.c (test for excess errors)
FAIL: gcc.target/i386/pr55512-2.c (internal compiler error)
FAIL: gcc.target/i386/pr55512-2.c (test for excess errors)
FAIL: gcc.target/i386/pr55512-3.c (internal compiler error)
FAIL: gcc.target/i386/pr55512-3.c (test for excess errors)
FAIL: gcc.target/i386/pr55512-4.c (internal compiler error)
FAIL: gcc.target/i386/pr55512-4.c (test for excess errors)
FAIL: gcc.target/i386/pr78911-2.c (test for excess errors)
FAIL: g++.dg/ubsan/vptr-11.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: g++.dg/ubsan/vptr-11.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/ubsan/vptr-11.C   -O2  (internal compiler error)
FAIL: g++.dg/ubsan/vptr-11.C   -O2  (test for excess errors)

/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr55512-1.c
-m32 -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt/.libs
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o pr55512-1.s

/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr55512-1.c:
In function \u2018foo\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr55512-1.c:7:3:
error: \u2018asm\u2019 operand has impossible constraints
during RTL pass: reload
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr55512-1.c:14:1:
internal compiler error: Segmentation fault
0xcac92f crash_signal
/export/gnu/import/git/sources/gcc/gcc/toplev.c:325
0x15b4df7 xmalloc
/export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:147
0xb422d9 lra_assign(bool&)
/export/gnu/import/git/sources/gcc/gcc/lra-assigns.c:1598
0xb3e133 lra(_IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/lra.c:2482
0xaf5bc1 do_reload
/export/gnu/import/git/sources/gcc/gcc/ira.c:5465
0xaf5bc1 execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++6/../../xg++
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++6/../../
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ubsan/vptr-11.C  -m32  
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/include/backward
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/testsuite/util
-fmessage-length=0   -O2  -fsanitize=vptr -fno-sanitize-recover=vptr -S
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ubsan/vptr-11.C: In
function \u2018int main()\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ubsan/vptr-11.C:84:1:
error: unable to find a register to spill
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ubsan/vptr-11.C:84:1:
error: this is the insn:
(insn 175 339 340 11 (parallel [
(set (reg:DI 322 [orig:155 _93 ] [155])
(mult:DI (zero_extend:DI (subreg/j:SI (reg:DI 322 [orig:155 _93
] [155]) 0))
(zero_extend:DI (reg:SI 301
(clobber (reg:CC 17 flags))
])
"/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ubsan/vptr-11.C":44
355 {*umulsidi3_1}
 (expr_list:REG_DEAD (reg:SI 301)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:DI (zero_extend:DI (subreg:SI (reg:DI
247) 0))
(const_int 3946327401 [0xeb382d69]))
(nil)
during RTL pass: reload

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

[mschif...@universe-factory.net]

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

--- Comment #2 from Matthias Schiffer  ---
The problem seems to be that the gp init sequence

li  $2,%hi(_gp_disp)
addiu   $3,$pc,%lo(_gp_disp)
sll $2,16
addu$2,$3

is generated very late and does not appear in the RTL in any way, so optimizing
passes are not aware of the $3 (and possibly $2?) clobber. I don't know enough
about GCC internals for further analysis.

[Bug c++/84729] [6/7/8 Regression] internal compiler error: verify_gimple failed

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Alexandre Oliva  ---
Proposed patch at https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00475.html

[Bug c++/84647] [6/7/8 Regression] ICE: segfault with NULL "from" in standard_conversion()

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Alexandre Oliva  ---
Proposed patch at https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00474.html

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-10
 CC||ebotcazou at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org
  Known to work||7.3.0
 Ever confirmed|0   |1
  Known to fail||8.0

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

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Alexandre Oliva  ---
Proposed patch at https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00473.html

[Bug c++/84642] [6/7/8 Regression] ICE: segfault reading through NULL current_template_parms in synthesize_implicit_template_parm

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Alexandre Oliva  ---
Proposed patch at https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00473.html

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 43614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43614=edit
test-case

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 43616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43616=edit
test-case

[Bug lto/84805] New: [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

[marxin at gcc dot gnu.org]

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

Bug ID: 84805
   Summary: [8 Regression] ICE in get_odr_type, at
ipa-devirt.c:2096 since r258133
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following ICEs:

$ g++ -shared -fPIC -flto=8 -O2 -std=gnu++17 libre-1.ii libre-2.ii libre-3.ii
libre-1.ii:139:7: warning: type ‘struct XclRoot’ violates the C++ One
Definition Rule [-Wodr]
 class XclRoot {
   ^
libre-2.ii:1:7: note: a different type is defined in another translation unit
 class XclRoot {
   ^
libre-1.ii:142:16: note: the first difference of corresponding definitions is
field ‘mrData’
   XclRootData 
^
libre-2.ii:1:7: note: a type with different number of fields is defined in
another translation unit
 class XclRoot {
   ^
libre-1.ii:144:7: warning: type ‘struct XclImpRoot’ violates the C++ One
Definition Rule [-Wodr]
 class XclImpRoot : XclRoot {};
   ^
libre-2.ii:5:7: note: a type with different bases is defined in another
translation unit
 class XclImpRoot : XclRoot {};
   ^
libre-2.ii:6:8: warning: type ‘struct RootData’ violates the C++ One Definition
Rule [-Wodr]
 struct RootData {
^
libre-3.ii:121:8: note: a different type is defined in another translation unit
 struct RootData {
^
libre-2.ii:7:14: note: the first difference of corresponding definitions is
field ‘pIR’
   XclImpRoot pIR;
  ^
libre-3.ii:122:11: note: a field with different name is defined in another
translation unit
   BiffTyp eDateiTyp;
   ^
libre-3.ii:18:7: warning: type ‘struct __shared_ptr’ violates the C++ One
Definition Rule [-Wodr]
 class __shared_ptr : __shared_ptr_access< a, l > {
   ^
libre-1.ii:21:7: note: a different type is defined in another translation unit
 class __shared_ptr : __shared_ptr_access< _Tp, _Lp > {
   ^
libre-3.ii:20:6: note: the first difference of corresponding definitions is
field ‘_M_ptr’
   m *_M_ptr;
  ^
libre-1.ii:23:17: note: a field of same name but different type is defined in
another translation unit
   element_type *_M_ptr;
 ^
libre-3.ii:19:14: note: type ‘struct m’ should match type ‘struct element_type’
   using m = a;
  ^
libre-1.ii:22:27: note: the incompatible type is defined here
   using element_type = _Tp;
   ^
libre-1.ii:103:8: warning: type ‘struct XclRootData’ violates the C++ One
Definition Rule [-Wodr]
 struct XclRootData {
^
libre-3.ii:82:8: note: a different type is defined in another translation unit
 struct XclRootData {
^
libre-1.ii:136:15: note: the first difference of corresponding definitions is
field ‘mxRD’
   RootDataRef mxRD;
   ^
libre-3.ii:107:22: note: a field of same name but different type is defined in
another translation unit
   std::n< RootData > mxRD;
  ^
libre-1.ii:111:39: note: type ‘struct RootDataRef’ should match type ‘struct n’
   typedef std::shared_ptr< RootData > RootDataRef;
   ^
libre-3.ii:23:31: note: the incompatible type is defined here
 template < typename a > class n : __shared_ptr< a > {};
   ^
lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:2096
0x8d7ca7 get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2096
0x8d7e0c register_odr_type(tree_node*)
../../gcc/ipa-devirt.c:2121
0x6156a0 lto_read_decls
../../gcc/lto/lto.c:1782
0x6178c4 lto_file_finalize
../../gcc/lto/lto.c:2076
0x6178c4 lto_create_files_from_ids
../../gcc/lto/lto.c:2086
0x6178c4 lto_file_read
../../gcc/lto/lto.c:2127
0x6178c4 read_cgraph_and_symbols
../../gcc/lto/lto.c:2839
0x6178c4 lto_main()
../../gcc/lto/lto.c:3356
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/cc6NqUBv.mk:2: /tmp/ccU4uBCo.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 43615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43615=edit
test-case

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[8 Regression] Executable   |[8 Regression] Executable
   |Segfault for tests compiled |Segfault for some tests
   |with -fdefault-integer-8|compiled with -m32 after
   |and -m32|r256284

--- Comment #7 from Dominique d'Humieres  ---
This caused by revision r256284 (r256265 is OK) and -fdefault-integer-8 is not
needed: summary updated.

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

[mschif...@universe-factory.net]

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

--- Comment #1 from Matthias Schiffer <mschif...@universe-factory.net> ---
Issue still present in gcc version 8.0.1 20180310 (experimental) (GCC). Again,
output it identical to that of GCC 5 and 7.

[Bug target/84799] ICE on valid code at -O1: in lra_split_hard_reg_for, at lra-assigns.c:1802

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-10
 CC||tschwinge at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
I'm seeing something like this also during libgomp build of the -m32 multilib
of x86_64-pc-linux-gnu:

/bin/sh ./libtool --tag=CC   --mode=compile [...]/build-gcc/./gcc/xgcc
-B[...]/build-gcc/./gcc/ -B/x86_64-pc-linux-gnu/bin/
-B/x86_64-pc-linux-gnu/lib/ -isystem /x86_64-pc-linux-gnu/include -isystem
/x86_64-pc-linux-gnu/sys-include-DHAVE_CONFIG_H -I.
-I[...]/source-gcc/libgomp  -I[...]/source-gcc/libgomp/config/linux/x86
-I[...]/source-gcc/libgomp/config/linux -I[...]/source-gcc/libgomp/config/posix
-I[...]/source-gcc/libgomp -I[...]/source-gcc/libgomp/../include  -Wall -Werror
-ftls-model=initial-exec -march=i486 -mtune=generic -Wc,-pthread  -g -O2  -m32
-MT affinity.lo -MD -MP -MF .deps/affinity.Tpo -c -o affinity.lo
[...]/source-gcc/libgomp/config/linux/affinity.c
libtool: compile:  [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/
-B/x86_64-pc-linux-gnu/bin/ -B/x86_64-pc-linux-gnu/lib/ -isystem
/x86_64-pc-linux-gnu/include -isystem /x86_64-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I[...]/source-gcc/libgomp
-I[...]/source-gcc/libgomp/config/linux/x86
-I[...]/source-gcc/libgomp/config/linux -I[...]/source-gcc/libgomp/config/posix
-I[...]/source-gcc/libgomp -I[...]/source-gcc/libgomp/../include -Wall -Werror
-ftls-model=initial-exec -march=i486 -pthread -mtune=generic -g -O2 -m32 -MT
affinity.lo -MD -MP -MF .deps/affinity.Tpo -c
[...]/source-gcc/libgomp/config/linux/affinity.c  -fPIC -DPIC -o
.libs/affinity.o
[...]/source-gcc/libgomp/config/linux/affinity.c: In function
'gomp_affinity_copy_place':
[...]/source-gcc/libgomp/config/linux/affinity.c:174:1: error: unable to
find a register to spill
 }
 ^
[...]/source-gcc/libgomp/config/linux/affinity.c:174:1: error: this is the
insn:
(insn 189 222 220 14 (parallel [
(set (reg:SI 154 [140])
(ashift:SI (reg:SI 154 [140])
(reg:QI 156)))
(clobber (reg:CC 17 flags))
]) "[...]/source-gcc/libgomp/config/linux/affinity.c":171 540
{*ashlsi3_1}
 (expr_list:REG_DEAD (reg:QI 156)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
during RTL pass: reload
[...]/source-gcc/libgomp/config/linux/affinity.c:174:1: internal compiler
error: in lra_split_hard_reg_for, at lra-assigns.c:1802
0x103d65f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
[...]/source-gcc/gcc/rtl-error.c:108
0xe1e911 lra_split_hard_reg_for()
[...]/source-gcc/gcc/lra-assigns.c:1802
0xe170b1 lra(_IO_FILE*)
[...]/source-gcc/gcc/lra.c:2506
0xda636b do_reload
[...]/source-gcc/gcc/ira.c:5465
0xda6860 execute
[...]/source-gcc/gcc/ira.c:5649

Bisected to r258390 (PR83712).

[Bug c++/84804] New: [8 Regression] ICE with lambda in default argument

[reichelt at gcc dot gnu.org]

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

Bug ID: 84804
   Summary: [8 Regression] ICE with lambda in default argument
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following inavlid code snippet triggers an ICE on trunk:

=
template struct A
{
  friend void foo(int i = []{ return 0;}()) {}
};

void bar()
{
  A<0>::foo();
}
=

bug.cc: In instantiation of 'struct A<0>':
bug.cc:8:7:   required from here
bug.cc:3:41: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17155
   friend void foo(int i = []{ return 0;}()) {}
   ~~^~
0x78b66e tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9385
0x639e0e tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3255
0x639e0e tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17155
0x95f422 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18495
0x96036f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17820
0x96dd9f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17255
0x96dd9f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16987
0x95c936 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16175
0x95c936 tsubst_default_argument(tree_node*, int, tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:12346
0x95e2e6 tsubst_default_arguments
../../gcc/gcc/cp/pt.c:12404
0x95e2e6 tsubst_function_decl
../../gcc/gcc/cp/pt.c:12651
0x979c56 tsubst_decl
../../gcc/gcc/cp/pt.c:12924
0x9740ef tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13812
0x98c962 tsubst_friend_function
../../gcc/gcc/cp/pt.c:9948
0x98c962 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10989
0x98c962 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:11055
0x9d38fd complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:136
0x9321aa cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6445
0x933cb5 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:17177
0x92de15 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16850
Please submit a full bug report, [etc.]

The regression was introduced between 2017-11-09 and 2017-11-17.

[Bug target/83822] trunk/gcc/config/rs6000/rs6000-string.c:970]: (style) Redundant condition

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Similar thing in a different file:

trunk/gcc/config/rs6000/rs6000-c.c:646]: (style) Redundant condition:
TARGET_HARD_FLOAT. '!A || (A && B)' is equivalent to '!A || B'

Source code is

  if (!TARGET_HARD_FLOAT
  || (TARGET_HARD_FLOAT && !TARGET_DOUBLE_FLOAT))
builtin_define ("_SOFT_DOUBLE");

[Bug c/84803] ice from ifcvt_memrefs_wont_trap with -O3

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
svn blame suggests vekumar might be able to help.

230454vekumar   data_reference_p *master_dr, *base_master_dr;
230454vekumar   data_reference_p a = drs[gimple_uid (stmt) - 1];
230454vekumar

[Bug c++/84729] [6/7/8 Regression] internal compiler error: verify_gimple failed

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
Mine

[Bug c/84803] ice from ifcvt_memrefs_wont_trap with -O3

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced C code:

a;
*b;
c(d) {
  if (a)
*b = d;
}
e() { f(e, c); }
f(int d, int *g) { h(d, g, ""); }
h(int d, int g(), char *j, char *k) {
  int i;
  h(0, g, j + 1, 1);
  while (--i)
g(*j);
}

[Bug c/84803] New: ice from ifcvt_memrefs_wont_trap with -O3

[dcb314 at hotmail dot com]

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

Bug ID: 84803
   Summary: ice from ifcvt_memrefs_wont_trap with -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 43613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43613=edit
C source code

The attached code, when compiled by recent gcc trunk and 
compiler flag -O3, does this:

$ ../results/bin/gcc -c -O3 bug420.c
during GIMPLE pass: ifcvt
n4.c: In function ‘setn1’:
n4.c:185:6: internal compiler error: in operator[], at vec.h:841
0x65f564 vec::operator[](unsigned int)
../../trunk/gcc/vec.h:841
0x65f564 vec::operator[](unsigned int)
../../trunk/gcc/vec.h:1326
0x65f564 ifcvt_memrefs_wont_trap
../../trunk/gcc/tree-if-conv.c:868
0x65f564 if_convertible_gimple_assign_stmt_p
../../trunk/gcc/tree-if-conv.c:1001

$ ../results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=../results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.258387/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.258387
--disable-multilib --disable-werror --enable-checking=df,extra,fold,rtl,yes
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.0.1 20180309 (experimental) (GCC) 
$

Further checking suggests that the bug exists sometime before revision 257000

 $ for i in ../results.257*/bin/gcc; do echo $i; $i -c -O3 bug420.c ; done 
../results.257009/bin/gcc
==12304== Invalid read of size 8
==12304==at 0xA869AD: ifcvt_memrefs_wont_trap (tree-if-conv.c:853)
==12304==by 0xA869AD: if_convertible_gimple_assign_stmt_p
(tree-if-conv.c:98
6)
==12304==by 0xA869AD: if_convertible_stmt_p (tree-if-conv.c:1026)
==12304==by 0xA869AD: if_convertible_loop_p_1(loop*, vec*) (tree-if-conv.c:1457)

Also, here is a recent valgrind to show more detail:

$ ../results.258387.valgrind/bin/gcc -c -O3 bug420.c 2>&1 | more
==1913== Invalid read of size 8
==1913==at 0xA8ECDC: ifcvt_memrefs_wont_trap (tree-if-conv.c:868)
==1913==by 0xA8ECDC: if_convertible_gimple_assign_stmt_p
(tree-if-conv.c:100
1)
==1913==by 0xA8ECDC: if_convertible_stmt_p (tree-if-conv.c:1041)
==1913==by 0xA8ECDC: if_convertible_loop_p_1(loop*, vec*) (tree-if-conv.c:1472)

I'll have my usual go at reducing the code.

[Bug c++/84802] [8 Regression] ICE in gimplify_decl_expr since r251433

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43612=edit
pr84802.C

Updated testcase so that clang++ accepts it (just changed sizeof(int) to 1).

[Bug c++/84802] [8 Regression] ICE in gimplify_decl_expr since r251433

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-10
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug c++/84802] New: [8 Regression] ICE in gimplify_decl_expr since r251433

[jakub at gcc dot gnu.org]

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

Bug ID: 84802
   Summary: [8 Regression] ICE in gimplify_decl_expr since r251433
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase ICEs with -std=c++17 starting with r251433:
rh1553747.ii: In lambda function:
rh1553747.ii:176:55: internal compiler error: Segmentation fault
   auto en() { return ek([](const auto ) { auto eo = [eh] {}; return eo;
}); }
   ^~
0x117d273 crash_signal
../../gcc/toplev.c:341
0xe0a924 gimplify_decl_expr
../../gcc/gimplify.c:1644
0xe34287 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11526
0xe1c327 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6546
0xe0adb2 gimplify_statement_list
../../gcc/gimplify.c:1734
Apparently it ICEs on a DEC_EXPR for VOIDmode variable that has not been laid
out and has DECL_VALUE_EXPR.

namespace a {
typedef decltype(nullptr) b;
template  struct n { static constexpr c e = d; };
typedef n f;
typedef n g;
template  using h = n;
template  using i = n;
template  struct aa;
template  struct j;
template  struct j : aa::m {};
struct o : h {};
template  p ab(int);
template  auto ac() -> decltype(ab(0));
template 
struct ae : h<__is_constructible(c, ad...)> {};
template  struct q : h<__is_assignable(c, p)> {};
template  struct r : g {};
template  struct t {
  template  static f z(int);
  typedef decltype(z(0)) m;
};
template  struct af : t::m {};
template  struct ag;
template  struct ag { typedef c m; };
template  struct aa { typedef ah m; };
template  using aj = c;
template  using ak = typename ag::m;
template  using am = al;
template  constexpr bool an = ae::e;
template  constexpr bool ao = r::e;
template  constexpr bool ap = af::e;
template  void aq();
template  c ar(c);
struct as { template  using at = p *; };
int au;
template  struct aw {
  template  static o ax(c *, ad... ay) { c(ay...);
return o(); }
  template  static auto az(av, c ba, ad... ay) {
ax(ba, ay...); }
};
}
template  struct u : a::aw { typedef av bb; };
class bc;
class bd {};
namespace a {
template  class be;
template  struct bg {
  static bf *bh(int) { return nullptr; }
};
template  class bi;
template 
struct bi : bg {
  static bj bl(const int , bk...) { (*bg::bh(bm))(aq...); return bj
(); }
};
template  using bn = j, af>;
template  struct be {
  struct bo : bn {};
  template  using bq = typename ag::m;
  template , typename = bq>
  be(bf);
  using bp = bj (*)(const int &, bk...);
  bp bs;
};
template 
template 
be::be(bf) {
  bs = bi::bl;
}
}
struct br { br(bd *); };
class bu : public bd {};
namespace a {
template  struct bt {
  template  using bw = as::at;
  bw v;
};
template  class bv {
protected:
  typedef u by;
  typedef u bx;
  struct : by {
bt ca;
  } bz;
};
template  struct cc : bv {
  typedef typename bv::bx bx;
  typedef typename bx::bb bb;
  template  bb cb(ad &&...);
};
template 
template 
typename cc::bb cc::cb(ad &&... ay) {
  bx::az(this->bz, this->bz.ca.v, ay...); return cc::bb ();
}
}
template  struct ce {
  static_assert(a::q::e);
  operator cd();
};
namespace base {
template  class cf;
template  struct cf {
  template ()), cg>>>
  cf(ci cj) : cf(cj, {}) {}
  template  cf(ci cj, a::f) : ck(cj) {}
  a::be ck;
};
template  using cm = a::be;
template  using cn = cf;
}
namespace co {
struct de {
  de();
  template ())> de(cp &&);
  a::cc> cq;
};
template  de::de(cp &) { cq.cb(cr); }
template  struct ct : a::i {};
template  constexpr bool cs = ct<>::e;
template  struct x;
template  struct x : a::i {};
template  constexpr bool cu = x::e;
template  class cv;
struct cw;
namespace cx {
struct cy { void cz(de) const; };
}
template  class consumer : public cx::cy {};
template 
consumer dg(db, y, dd);
namespace cx {
template  consumer ();
template  struct df {
  template  using dh = consumer;
  template ()), de> &&
!a::ao>>
  df(di cj) : dm(cj) {}
  base::cm>)> dm;
};
}
template > class dk;
namespace cx {
template  struct dl {
  template >>
  dl(ec &&);
  template >>
  de dn(db &&, y &&, dd &&) &&;
  template  void ed(const dj &, de &) &&;
  di ef;
};
template 
template 
dl::dl(ec &) : ef(generator) {}

[Bug c++/84801] New: ICE: Segmentation fault instead of "error: parameter packs not expanded with '...'"

[gjl at gcc dot gnu.org]

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

Bug ID: 84801
   Summary: ICE: Segmentation fault instead of "error: parameter
packs not expanded with '...'"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

int v;
int main() { [](auto... c) { v = c; }(1); }

triggers ICE with v8:

$ avr-g++ foo.cpp -std=gnu++14 -v
foo.cpp: In instantiation of 'main():: [with auto:1 =
{int}]':
foo.cpp:2:40:   required from here
foo.cpp:2:32: internal compiler error: Segmentation fault
 int main() { [](auto... c) { v = c; }(1); }
  ~~^~~

Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --disable-nls
--prefix=/gnu/gcc-avr --host=i686-w64-mingw32 --build=x86_64-linux-gnu
--enable-languages=c,c++,lto --with-gnu-as --with-gnu-ld --disable-shared
--with-dwarf2 --enable-checking=release
Thread model: single
gcc version 8.0.1 20180119 (experimental) [trunk revision 256890] (GCC) 

GNU C++14 (GCC) version 8.0.1 20180119 (experimental) [trunk revision 256890]
(avr)
compiled by GNU C version 4.9.3, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

v7 issues an error instead:

foo.cpp: In lambda function:
foo.cpp:2:32: error: parameter packs not expanded with '...':
 int main() { [](auto... c) { v = c; }(1); }
  ~~^~~
foo.cpp:2:32: note: 'c'