[Bug target/85216] Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

--- Comment #4 from Timothy Pearson  ---
(In reply to Andrew Pinski from comment #3)
> This is 100% the equivalent code.
> 
> jmp *(%r15) # opline.199_67->handler
> Does two things:
> loads a pointer from %r15 and then jumps to that pointer.
> 
> In PowerPC, you can only jump indirectly via the CTR or LR registers.
> 
> ld 9,0(29)   # opline.200_67->handler, gotovar.1505_2678
> mtctr 9  # gotovar.1505_2678, gotovar.1505_2678
> bctr
> 
> 
> Most likely what is happening is the indirect branch predictor is not
> predicting the branch correctly on the powerpc side while it is on the x86
> side.  This is a micro-architecture difference between the two chips and is
> unrelated to the ISA differences.

I'm forwarding this for analysis to see if there's anything we can do in
firmware to "fix" the branch predictor.  If not, is there a way to prime the
predictor in this scenario, or is this too specific to be added compiler-side?

[Bug c++/85209] [8 Regression] ICE with lambda and structured binding

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-05
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
Broke with r251433.

[Bug gcov-profile/85217] [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[yangyibiao at nju dot edu.cn]

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

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

In addition, the result is also correct when Line #5 is removed.

[Bug gcov-profile/85199] [GCOV] A cond-expr with a iterative variable in a for loop is marked as "-" in gcov

[yangyibiao at nju dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
(In reply to Yibiao Yang from comment #0)
> $ gcc -v 
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
> --enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-8
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
> --with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
> 8-20170923-1ubuntu2)
> 
> $ cat small.c
> void main()
> {
> int b = 0;
> for(;
> b < 1;
> b++) {
> ;
> }
> }
> 
> $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
> File 'small.c'
> Lines executed:100.00% of 5
> Creating 'small.c.gcov'
> 
> -:0:Source:small.c
> -:0:Graph:small.gcno
> -:0:Data:small.gcda
> -:0:Runs:1
> -:0:Programs:1
> 1:1:void main()
> -:2:{
> 1:3:int b = 0;
> 2:4:for(;
> -:5:b < 1;
> 1:6:b++) {
> -:7:;
> -:8:}
> 1:9:}
> 
> Here, we can see that Line #4 is marked as executed twice and Line #5 "b <
> 1;" is marked as "-".
> 

I was wondering that this is the default behavior of gcov.

[Bug c++/71283] Inconsistent location for C++ warning options in the manual

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
Martin Sebor brought this up on the mailing lists here:
https://gcc.gnu.org/ml/gcc/2018-04/msg00021.html

[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-05
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed that g2() still contains the call to __builtin_abort()

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)
> Started somewhere between r258751 (unaffected) and r258755 (affected)

Probably started at r258755 (fix for PR c++/81311)

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
I don't think this is just an ICE on invalid: we can trivially fix the snippet
as:

template  struct remove_reference {};
template  struct remove_reference<_Tp &> {
  typedef _Tp type;
};
template 
constexpr typename remove_reference<_Tp>::type &(_Tp &&__t) noexcept {
return static_cast::type&&>(__t);
}
template  struct vector {
  vector(vector &&) noexcept {}
};
template  struct any_container {
  vector v;
  operator vector &&() && { return move(v); }
};
struct buffer_info {
  vector shape;
  buffer_info(any_container shape_in) : shape(move(shape_in)) {}
};

[Bug target/85216] New: Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

Bug ID: 85216
   Summary: Performance issue with PHP on ppc64 systems
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tpearson at raptorengineering dot com
  Target Milestone: ---

On ppc64[el] systems, GCC emits suboptimal code for the PHP VM (version 7.2.3)
that results in significant performance loss versus a standard x86 machine. 
This centers around the HYBRID_BREAK() function converting into two slow
instructions on ppc64el versus one fast instruction on x86.

x86 generated assembly example:

.L33600:
# php7.2-7.2.3/Zend/zend_vm_execute.h:59809: 
ZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);
.loc 2 59809 0
callZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER #
jmp *(%r15) # opline.199_67->handler

ppc64el generated assembly example:

.L35825:
 # php7.2-7.2.3/Zend/zend_vm_execute.h:59809: 
ZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);
.loc 2 59809 0
bl ZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER   #
 # php7.2-7.2.3/Zend/zend_vm_execute.h:59810: 
HYBRID_BREAK();
.loc 2 59810 0
ld 9,0(29)   # opline.200_67->handler, gotovar.1505_2678
mtctr 9  # gotovar.1505_2678, gotovar.1505_2678
bctr

Note the additional assembly instructions emitted for HYBRID_BREAK(); perf
indicates these are consuming considerable amounts of time on ppc64el while the
equivalent jmp on x86 consumes almost no time at all.

I'm not sure if this is a POWER9 quirk (cache problem) or what the correct
assembler should be, just that there is a serious performance loss with the
current emitted assembler versus the x86 equivalent.

Thanks!

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-05
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/85216] Performance issue with PHP on ppc64 systems

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Last reconfirmed|2018-04-05 00:00:00 |
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
This is 100% the equivalent code.

jmp *(%r15) # opline.199_67->handler
Does two things:
loads a pointer from %r15 and then jumps to that pointer.

In PowerPC, you can only jump indirectly via the CTR or LR registers.

ld 9,0(29)   # opline.200_67->handler, gotovar.1505_2678
mtctr 9  # gotovar.1505_2678, gotovar.1505_2678
bctr


Most likely what is happening is the indirect branch predictor is not
predicting the branch correctly on the powerpc side while it is on the x86
side.  This is a micro-architecture difference between the two chips and is
unrelated to the ISA differences.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from David Edelsohn  ---
The issue is *why* the branch predictor is not predicting it correctly. It may
be that the details of the branch predictor are causing the prediction to
conflict with another branch, for example, nullifying the correct prediction.
One should not leap to the conclusion that the predictor is not initialized.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

--- Comment #6 from Timothy Pearson  ---
Understood.  I'll update this report if we find a way to get the predictor
working optimally in this scenario.

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[munroesj at gcc dot gnu.org]

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

--- Comment #9 from Steven Munroe  ---
I suggested fixing the emmintrin.h source for both eventually ...

If you only fix AT11 then sometime later some will discover the difference and
try fix it. And likely break it again.

So fix AT immediately (with comments for why). Then when gcc trunk opens up.
fix it there as a code clean up and ask for a backport to gcc8 stable.

Because if you leave it alone in gcc 8. it might break again in gcc 9 :-/

[Bug target/85216] Performance issue with PHP on ppc64 systems

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
One possibility is bad luck and the branch happens to fall on an address that
conflicts with another branch.

[Bug tree-optimization/47316] devirtualize calls to virtual methods that are never further overriden

[egallager at gcc dot gnu.org]

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

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=46043

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Jambor from comment #3)
> Actually, thanks for filing the bug.  Devirtualization and other
> optimizations (such as struct-reorg) based on type escape analysis are
> a debated issue and it is nice to know users have interest in it.

Another example of interest in escape analysis:
https://twitter.com/gnutools/status/978633915450712064

[Bug gcov-profile/85219] New: [GCOV] A "if(1) continue;" statement in a the else block of "if(0)" statement is wrongly marked as executed when surrounded by array delaration statement and break/contin

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85219
   Summary: [GCOV] A "if(1) continue;" statement in a the else
block of "if(0)" statement is wrongly marked as
executed when surrounded by array delaration statement
and break/continue statement in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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


$ cat small.c
void  main ()
{
int a = 0;
for (; a < 1; a++) {
int b[1];
if ( 1 )
;
else {
if (1)
continue;
break;
}
continue;
}
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:void  main ()
-:2:{
1:3:int a = 0;
2:4:for (; a < 1; a++) {
-:5:int b[1];
-:6:if ( 1 )
-:7:;
-:8:else {
-:9:if (1)
1:   10:continue;
-:   11:break;
-:   12:}
1:   13:continue;
-:   14:}
1:   15:}



**
Line #10 is wrongly marked as executed here. 
While remoing any of the statement in Line #11 or Line #13 or Line #5, the
result is correct. 
**

[Bug target/85216] Performance issue with PHP on ppc64 systems

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-05
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
What two additional instructions?  x86 is a CISC architecture and Power is a
RISC architecture.  x86 has an instruction that directly performs an indirect
call through a pointer. Power must explicitly load the pointer and move it to
the appropriate register to perform an indirect branch.

One can comment / questions that the *SEQUENCE* appears to require more time on
Power than the equivalent sequence on x86. But directly comparing instructions
and counting instructions in two different ISAs without context is not
meaningful.

[Bug gcov-profile/85218] New: [GCOV] A return statement in the if(0) block is wrongly marked as executed when there is an array index and an {array declare statement} around it in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85218
   Summary: [GCOV] A return statement in the if(0) block is
wrongly marked as executed when there is an array
index and an {array declare statement} around it in
gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat small.c
int main()
{
int b[1] = {0};
b[0];
if (0)
return 0;
return 1;

{
int c[1];
}
}


$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat sall.c.gcov
File 'small.c'
Lines executed:100.00% of 4
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main()
-:2:{
1:3:int b[1] = {0};
-:4:b[0];
-:5:if (0)
1:6:return 0;
1:7:return 1;
-:8:
-:9:{
-:   10:int c[1];
-:   11:}
-:   12:}


**
Line #6 is wrongly marked as executed. 

The result is correct while removing the following lines:
Line 9 and Line 11 (the braces) are removed
or
Line #4 is removed.

[Bug c++/85215] New: "gcc_assert (!force_elide);" failure

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 85215
   Summary: "gcc_assert (!force_elide);" failure
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43847=edit
Reproducer

The downstream bug report:
  https://bugzilla.redhat.com/show_bug.cgi?id=1562194
describes an ICE due to this assertion failing:

8243  gcc_assert (!force_elide);

I'm attaching a minimized reproducer, which ICEs on current trunk (r259106),
with -std=c++1z.

$ ./xg++ -B. -c /tmp/rhbz1562194.cc -std=c++1z 
/tmp/rhbz1562194.cc: In constructor
‘buffer_info::buffer_info(any_container)’:
/tmp/rhbz1562194.cc:17:66: internal compiler error: in build_over_call, at
cp/call.c:8243
   buffer_info(any_container shape_in) : shape(move(shape_in)) {}
  ^
0x823faa build_over_call
../../src/gcc/cp/call.c:8243
0x8298e3 build_new_method_call_1
../../src/gcc/cp/call.c:9366
0x829f29 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:9441
0x826f1b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:8969
0x954e20 expand_default_init
../../src/gcc/cp/init.c:1887
0x9554a3 expand_aggr_init_1
../../src/gcc/cp/init.c:2002
0x954053 build_aggr_init(tree_node*, tree_node*, int, int)
../../src/gcc/cp/init.c:1742
0x950227 perform_member_init
../../src/gcc/cp/init.c:847
0x9527d3 emit_mem_initializers(tree_node*)
../../src/gcc/cp/init.c:1293
0xad0a7c finish_mem_initializers(tree_node*)
../../src/gcc/cp/semantics.c:1704
0x9e03b5 cp_parser_mem_initializer_list
../../src/gcc/cp/parser.c:14440
0x9dfc74 cp_parser_ctor_initializer_opt
../../src/gcc/cp/parser.c:14353
0x9eeb48 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.c:21803
0x9f9053 cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.c:26839
0x9fb8dc cp_parser_late_parsing_for_member
../../src/gcc/cp/parser.c:27719
0x9f141a cp_parser_class_specifier_1
../../src/gcc/cp/parser.c:22757
0x9f14f7 cp_parser_class_specifier
../../src/gcc/cp/parser.c:22783
0x9e43a8 cp_parser_type_specifier
../../src/gcc/cp/parser.c:16766
0x9de948 cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.c:13617
0x9dd071 cp_parser_simple_declaration
../../src/gcc/cp/parser.c:12927
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug gcov-profile/85217] New: [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85217
   Summary: [GCOV] A no side effect statement between a break
statement and a continue statement will lead to
incorrect code coverage in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ cat small.c
int a=0;

void main() {
  for (;; a++) {
int c[1];
if (a) {
  break;
  a;
  continue;
}
continue;
  }
}


$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a=0;
-:2:
2:3:void main() {
1:4:  for (;; a++) {
-:5:int c[1];
2:6:if (a) {
1:7:  break;
-:8:  a;
1:9:  continue;
-:   10:}
1:   11:continue;
-:   12:  }
1:   13:}

Line #9 is wrongly marked as executed. While Line #8 or Line #11 is removed,
the result is correct.

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Started somewhere between r258751 (unaffected) and r258755 (affected)

[Bug tree-optimization/47815] Tail call regression with GCC snapshot

[adam at consulting dot net.nz]

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

Adam Warner  changed:

   What|Removed |Added

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

--- Comment #5 from Adam Warner  ---
(In reply to Eric Gallager from comment #4)
> Is this still an issue with newer versions of gcc?

I'm delighted to inform you the regression is resolved. Jumps instead of calls
are generated and optimisation for size is significantly improved (from 18
bytes down to 10 bytes due to the elimination of a duplicate xor instruction
and the use of smaller relative jump instructions):

$ gcc-snapshot.sh --version
gcc (Debian 20180322-1) 8.0.1 20180322 (experimental) [trunk revision 258755]
...

$ gcc-snapshot.sh -Os tail_call_regression.c && objdump -d -m i386:x86-64 a.out
|less

...
00400576 :
  400576:   31 c0   xor%eax,%eax
  400578:   85 ff   test   %edi,%edi
  40057a:   74 02   je 40057e 
  40057c:   eb a8   jmp400526 
  40057e:   eb ce   jmp40054e 
...

[Bug c++/71218] Add a warning about "new T[integer-literal]"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-05
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Marc Glisse from comment #1)
> > Can you be more specific? Do you mean people should have written:
> > T tab[8];
> 
> Yes, exactly. I was fixing some code earlier today that used a dynamically
> allocated buffer of 8 chars and deleted it at the end of the function (but
> failed to do so on two early return paths). There was no reason it was done
> that way instead of using an automatic array, probably just someone who
> learnt to programme in Java and didn't know better.
> 
> > instead? What if 8 or sizeof(T) is large?
> 
> The case I looked at was char, it would probably be OK to only warn for
> scalar types, and for small array lengths (for some value of small).
> 
> > If your "..." includes possible
> > writes to p, or if p escapes and "..." may throw, I guess that cancels the
> > warning? At some point the issue becomes similar to optimizing malloc to a
> > stack allocation.
> 
> Part of the problem in the code I was fixing was that the "..." certainly
> could throw, and the delete never happened.
> 
> But maybe the escape analysis is too tricky.

Worth trying anyways; confirmed that it could be worthwhile to add this
warning.

[Bug c++/84936] [8 Regression] ICE with unexpanded parameter pack

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 00:09:05 2018
New Revision: 259107

URL: https://gcc.gnu.org/viewcvs?rev=259107=gcc=rev
Log:
PR c++/84936 - ICE with unexpanded pack in mem-initializer.

* parser.c (cp_parser_mem_initializer_list): Call
check_for_bare_parameter_packs.

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

[Bug c++/84938] [7/8 Regression] internal compiler error: in gen_reg_rtx, at emit-rtl.c:1187 (gen_reg_rtx()/maybe_legitimize_operand())

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 00:09:10 2018
New Revision: 259108

URL: https://gcc.gnu.org/viewcvs?rev=259108=gcc=rev
Log:
PR c++/84938 - ICE with division by ~-1.

* call.c (set_up_extended_ref_temp): Call cp_fully_fold.

Added:
trunk/gcc/testsuite/g++.dg/expr/div-by-zero1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/84936] [8 Regression] ICE with unexpanded parameter pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug tree-optimization/52571] vectorizer changes alignment of common symbols

[egallager at gcc dot gnu.org]

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

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=48127,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=49379,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52614

--- Comment #15 from Eric Gallager  ---
(In reply to m...@gcc.gnu.org from comment #14)
> Uncommoning things I think might well be slightly harder than trivial.  A
> ctor is allowed to dynamically load a shared library, that defines a symbol,
> maybe, conditional on the environment.  But with proper escape analysis,
> seems like one can figure it all out, just be careful with the edge cases.

What changes need to be made to the escape analysis to make it "proper"?

[Bug c++/84792] [6/7/8 Regression] ICE with broken typedef of a struct

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

--- Comment #2 from Timothy Pearson  ---
(In reply to David Edelsohn from comment #1)
> What two additional instructions?  x86 is a CISC architecture and Power is a
> RISC architecture.  x86 has an instruction that directly performs an
> indirect call through a pointer. Power must explicitly load the pointer and
> move it to the appropriate register to perform an indirect branch.
> 
> One can comment / questions that the *SEQUENCE* appears to require more time
> on Power than the equivalent sequence on x86. But directly comparing
> instructions and counting instructions in two different ISAs without context
> is not meaningful.

That is in fact what I am concerned with, the fact that the sequence is taking
longer than the equivalent sequence on x86.  I am aware that the two
instruction sequences accomplish the same goal, but for some reason the x86 one
is fast enough that it doesn't even show up in the perf output as a hot
instruction, while the ppc64 sequence stalls twice (two hot instructions), once
on the load and once on the register move.

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #27 from Eric Gallager  ---
(In reply to Rainer Orth from comment #26)
> Author: ro
> Date: Thu Jun 30 10:02:45 2011
> New Revision: 175689
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=175689
> Log:
> 2011-06-28  Dominique d'Humieres  
>   Iain Sandoe  
> 
>   PR libobjc/36610
>   * objc.dg/torture/forward-1.m: Remove dg-xfail-run-if.
>   Only skip on 64-bit *-*-darwin8* && !objc2.
> 
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/objc.dg/torture/forward-1.m

Did this fix it?

[Bug target/82989] [6/7 regression] Inexplicable use of NEON for 64-bit math

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #26 from sudi at gcc dot gnu.org ---
Should be fixed on gcc-7 and gcc-6

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> As discussed on IRC, with current libasan __asan_register_globals, we have 2
> options:
> 1) add an object that we link early with -fsanitize=address that contains
> zero sized variables with following redzone registered with
> __asan_register_globals in .rodata, .data and .bss sections (similarly to
> how libasan_preinit.o is added to non- -shared links, this would be
> something added to every link)
> 2) in each TU emit such zero sized variable with following redzone and
> register it before the first variable in .data, .rodata and/or .bss if any
> vars are emitted there
> 
> 1) has the advantage that it wastes less memory in red zones (especially
> with many TUs), but will work well only if not mixing TUs with
> -fsanitize=address and without
> 2) wastes more memory and is more costly also because registering more
> globals, but will work better when mixing TUs with -fsanitize=address and
> without

Jakub on IRC:
if we go with the single *.o file with registered dummies at start of each
section, it would need to include .sdata and .sbss vars too on powerpc

[Bug tree-optimization/85191] [8 regression] gcc.dg/vect/slp-perm-9.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
possibly the vect_perm_short case?  how do you configure targets?  Shouldn't
have affected ia64 though...  maybe my TCL fu was too weak and I botched sth?

Doesn't fail on x86_64-linux for me.

[Bug sanitizer/85174] c-c++-common/asan/pointer-compare-1.c does not work for powerpc with sdata

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Wed Apr  4 10:40:57 2018
New Revision: 259074

URL: https://gcc.gnu.org/viewcvs?rev=259074=gcc=rev
Log:
Disable anchors and msdata for ASAN test-case (PR sanirizer/85174).

2018-04-04  Martin Liska  

PR sanitizer/85174
* c-c++-common/asan/pointer-compare-1.c: Disable section anchors
and msdata as a workaround for powerpc.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.4

[Bug fortran/85192] Memory leak on every read() from string

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Thomas Koenig  ---
Hmm... still strange.

There is no 7.2.1 in the official gcc releases, possibly the Fedora
people backported some patch which fixes this issue (but I don't
see an obvious candidate at the moment).

That's as may be, I am closing this as WORKSFORME for now.

If the problem persists with newer versions, or if there are other
problems, please reopen or submit a new bug report.

[Bug target/85181] Loading wrong source/dest registers for xviexpdp instruction with -O2 optimization

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
When you change the asm to

__asm__ __volatile__ ("xviexpdp   %x0, %x1, %x2 " : "+wa" (vec_xt): "wa"
(vec_xa), "wa" (vec_xb));

it works as expected (%xN also is needed here with "v" constraints; that also
works).

Closing as invalid.

[Bug debug/85176] ICE in force_decl_die, at dwarf2out.c:25910

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
A valid test-case started to find in r251220:

$ cat ice.ii
namespace a {
template  class c;
template  void e(c &);
void operator<<(c , const char *) { e(f); }
extern c cout;
} // namespace a
int main() { a::cout << ""; }

[Bug target/85193] New: [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[zsojka at seznam dot cz]

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

Bug ID: 85193
   Summary: [7/8 Regression] ICE: SIGSEGV in memory_operand at
recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre
-mno-sse
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 43838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43838=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-ccp -fno-tree-fre -mno-sse testcase.c
-wrapper valgrind,-q
testcase.c: In function 'foo':
testcase.c:10:1: warning: SSE vector argument without SSE enabled changes the
ABI [-Wpsabi]
 foo(U f) {
 ^~~
==18107== Invalid read of size 2
==18107==at 0xC8C6B4: memory_operand(rtx_def*, machine_mode) (recog.c:1358)
==18107==by 0x12D9756: get_attr_memory(rtx_insn*) (i386.md:2472)
==18107==by 0x1155FAD: ix86_adjust_cost(rtx_insn*, int, rtx_insn*, int,
unsigned int) (x86-tune-sched.c:434)
==18107==by 0x16FFB75: dep_cost_1(_dep*, unsigned int) (haifa-sched.c:1493)
==18107==by 0x1701AF9: dep_cost (haifa-sched.c:1509)
==18107==by 0x1701AF9: priority(rtx_insn*) (haifa-sched.c:1660)
==18107==by 0x1701BEE: set_priorities(rtx_insn*, rtx_insn*)
(haifa-sched.c:7122)
==18107==by 0xCF7C6D: compute_priorities() (sched-rgn.c:3020)
==18107==by 0xCFB025: schedule_region (sched-rgn.c:3113)
==18107==by 0xCFB025: schedule_insns() [clone .part.41] (sched-rgn.c:3513)
==18107==by 0xCFB87D: schedule_insns (sched-rgn.c:3498)
==18107==by 0xCFB87D: rest_of_handle_sched2 (sched-rgn.c:3737)
==18107==by 0xCFB87D: (anonymous
namespace)::pass_sched2::execute(function*) (sched-rgn.c:3873)
==18107==by 0xC39F83: execute_one_pass(opt_pass*) (passes.c:2497)
==18107==by 0xC3A8B7: execute_pass_list_1(opt_pass*) (passes.c:2586)
==18107==by 0xC3A8C9: execute_pass_list_1(opt_pass*) (passes.c:2587)
==18107==  Address 0xabababababababab is not stack'd, malloc'd or (recently)
free'd
==18107== 
during RTL pass: sched2
testcase.c:13:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259070-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259070-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64
Thread model: posix
gcc version 8.0.1 20180404 (experimental) (GCC)

[Bug c++/85194] New: ICE with structured binding in broken for-loop

[reichelt at gcc dot gnu.org]

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

Bug ID: 85194
   Summary: ICE with structured binding in broken for-loop
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, 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 invalid code snippet (compiled with "-std=c++17") triggers
an ICE since GCC 7.1.0 (when structured bindings were introduced):


struct A { int i; };

A x[2];

void foo()
{
  for (auto [i] = A() : x)
;
}


bug.cc: In function 'void foo()':
bug.cc:7:17: error: initializer in range-based 'for' loop
   for (auto [i] = A() : x)
 ^
bug.cc:7:23: internal compiler error: Segmentation fault
   for (auto [i] = A() : x)
   ^
0xebccdf crash_signal
../../gcc/gcc/toplev.c:325
0x91bd07 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/gcc/tree.h:3172
0x91bd07 cp_parser_range_for
../../gcc/gcc/cp/parser.c:11755
0x946866 cp_parser_for
../../gcc/gcc/cp/parser.c:11685
0x946866 cp_parser_iteration_statement
../../gcc/gcc/cp/parser.c:12242
0x923d06 cp_parser_statement
../../gcc/gcc/cp/parser.c:10824
0x924d10 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11276
0x924de7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11230
0x93ba20 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21791
0x93ba20 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21828
0x93c2d0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26849
0x93d056 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26765
0x93d056 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19511
0x944148 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13059
0x944f58 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12884
0x948ee2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12782
0x9492f1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12658
0x9495e4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x9495e4 c_parse_file()
../../gcc/gcc/cp/parser.c:39026
0xa491c6 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug c++/71174] [concepts] Segmentation fault while processing concepts error

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-04
 CC||reichelt at gcc dot gnu.org
 Blocks||67491
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #5 from Volker Reichelt  ---
Confirmed.
To me it looks as if the self-referencing concept causes a stack-overflow.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug fortran/85192] Memory leak on every read() from string

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-04
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Works for me with current trunk and with gcc 7:

ig25@flaemmli:~/Krempel/Leak> gfortran b.f90 meminfo.c && ./a.out
3312
3408
3504
3600
3696
3792
3888
3888
3888
3888
ig25@flaemmli:~/Krempel/Leak> /usr/bin/gfortran-7 b.f90 meminfo.c && ./a.out
3296
3392
3488
3584
3680
3776
3872
3872
3872
3872

Also, valgrind disagrees (on a slightly reduced test case):

ig25@flaemmli:~/Krempel/Leak> cat a.f90 
! PR 85192
 real*8  x, y, z, u, v, w, erg, tme, wgt
 character*250 line
 line='1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10'
!nstart = meminfo()
 do i=1,10
read(line,*) x,y,z,u,v,w,erg,tme,wgt,ij
!print *, x,y,z,u,v,w,erg,tme,wgt,ij
!   print *,meminfo()-nstart
 enddo
 end
ig25@flaemmli:~/Krempel/Leak> gfortran a.f90 
ig25@flaemmli:~/Krempel/Leak> valgrind ./a.out
==4343== Memcheck, a memory error detector
==4343== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4343== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4343== Command: ./a.out
==4343== 
==4343== 
==4343== HEAP SUMMARY:
==4343== in use at exit: 0 bytes in 0 blocks
==4343==   total heap usage: 153 allocs, 153 frees, 46,760 bytes allocated
==4343== 
==4343== All heap blocks were freed -- no leaks are possible
==4343== 
==4343== For counts of detected and suppressed errors, rerun with: -v
==4343== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

What version are you using?

[Bug fortran/85192] Memory leak on every read() from string

[Vasilis.Vlachoudis at cern dot ch]

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

--- Comment #2 from Vasilis.Vlachoudis at cern dot ch  ---
I am using 7.2.0 from ubuntu. I've just checked on the latest Fedora with 7.2.1
and it gives the same result as in your case, so probably it is fixed.

[Bug middle-end/85195] New: [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O -fno-tree-ccp --param=sccvn-max-scc-size=10

[zsojka at seznam dot cz]

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

Bug ID: 85195
   Summary: [8 Regression] ICE: verify_gimple failed: non-trivial
conversion at assignment with -O -fno-tree-ccp
--param=sccvn-max-scc-size=10
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 43840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43840=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-ccp --param=sccvn-max-scc-size=10
testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: error: non-trivial conversion at assignment
 foo (void)
 ^~~
vector(1) __int128
__int128
_14 = _28;
during GIMPLE pass: forwprop
testcase.c:9:1: internal compiler error: verify_gimple failed
0xdb9ff9 verify_gimple_in_cfg(function*, bool)
/repo/gcc-trunk/gcc/tree-cfg.c:5585
0xc36c93 execute_function_todo
/repo/gcc-trunk/gcc/passes.c:1994
0xc375d9 execute_todo
/repo/gcc-trunk/gcc/passes.c:2048
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259070-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259070-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64
Thread model: posix
gcc version 8.0.1 20180404 (experimental) (GCC)

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

[zev+gccbug at bewilderbeest dot net]

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

--- Comment #5 from Zev Weiss  ---
Created attachment 43837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43837=edit
codegen & RTL dump for aarch64 & avr

(Attached generated code & -fdump-rtl-expand output for aarch64 and avr, both
7.3.0.)

[Bug debug/85176] [8 Regression] ICE in force_decl_die, at dwarf2out.c:25910

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0
Summary|ICE in force_decl_die, at   |[8 Regression] ICE in
   |dwarf2out.c:25910   |force_decl_die, at
   ||dwarf2out.c:25910

--- Comment #6 from Richard Biener  ---
In the end caused by -g1 not generating DIEs for NAMESPACE_DECLs.  At
compile-time
the DIEs are rooted at comp_unit_die () but LTO expects to re-generate the
DIE child->parent relationship via DECL/TYPE_CONTEXT, we do not stream that
(because DIEs lack a back-mapping to the tree it was generated off, rightfully
so).

So we have to mimick that in dwarf2out_register_external_die.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 259069)
+++ gcc/dwarf2out.c (working copy)
@@ -5903,8 +5903,13 @@ dwarf2out_register_external_die (tree de
 }
   else
 ctx = DECL_CONTEXT (decl);
+  /* Peel types in the context stack.  */
   while (ctx && TYPE_P (ctx))
 ctx = TYPE_CONTEXT (ctx);
+  /* Likewise namespaces in case we do not want to emit DIEs for them.  */
+  if (debug_info_level <= DINFO_LEVEL_TERSE)
+while (ctx && TREE_CODE (ctx) == NAMESPACE_DECL)
+  ctx = DECL_CONTEXT (ctx);
   if (ctx)
 {
   if (TREE_CODE (ctx) == BLOCK)

[Bug inline-asm/85172] internal compiler error: unexpected expression '' of kind asm_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43839=edit
gcc8-pr85172.patch

Untested fix.  The issue is that for certain builtins we say calls to them are
potential constant expressions no matter what arguments they have.  But we try
to evaluate those arguments as constant expressions anyway, which creates a
loophole, anything that is normally rejected as potential constant expression
can through this appear in the constexpr.c evaluation.

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

[zev+gccbug at bewilderbeest dot net]

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

--- Comment #4 from Zev Weiss  ---
I'm afraid I'm not quite GCC-savvy enough to know exactly what PROMOTE_SUBREG
refers to or which targets it covers (a quick grep of the source tree didn't
appear turn up any clues).

As for the RTL (hopefully I've used the right dump flag here)...

riscv64, 7.2.0:
--
$ riscv64-unknown-elf-gcc -fdump-rtl-expand -S -o /dev/null -Og min.c
$ cat min.c.229r.expand 

;; Function outer (outer, funcdef_no=1, decl_uid=1419, cgraph_uid=1,
symbol_order=2)

Partition 0: size 4 align 8
sub

;; Generating RTL for gimple basic block 2


try_optimize_cfg iteration 1

Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without moving.
Merging block 4 into block 2...
Merged blocks 2 and 4.
Merged 2 and 4 without moving.


try_optimize_cfg iteration 2



;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg:DI 73)
(high:DI (symbol_ref:DI ("S") [flags 0x84]  ))) -1
 (nil))
(insn 6 5 7 2 (set (reg/f:DI 74)
(lo_sum:DI (reg:DI 73)
(symbol_ref:DI ("S") [flags 0x84]  )))
-1
 (nil))
(insn 7 6 8 2 (set (reg:SI 75)
(mem/c:SI (plus:DI (reg/f:DI 74)
(const_int 4 [0x4])) [1 S.P+0 S4 A32])) -1
 (nil))
(insn 8 7 9 2 (set (mem/c:SI (plus:DI (reg/f:DI 67 virtual-stack-vars)
(const_int -8 [0xfff8])) [1 sub+0 S4 A64])
(reg:SI 75)) -1
 (nil))
(insn 9 8 10 2 (set (reg:DI 72 [ _2 ])
(sign_extend:DI (mem/c:HI (plus:DI (reg/f:DI 67 virtual-stack-vars)
(const_int -8 [0xfff8])) [2 sub.a+0 S2 A64])))
"min.c":12 -1
 (nil))
(insn 10 9 0 2 (parallel [
(asm_operands/v ("magic %0") ("") 0 [
(subreg/s/u:HI (reg:DI 72 [ _2 ]) 0)
]
 [
(asm_input:HI ("r") min.c:12)
]
 [] min.c:12)
(clobber (mem:BLK (scratch) [0  A8]))
]) "min.c":12 -1
 (nil))
--

x86-64, 7.3.0 (for what it's worth):
--
$ gcc -fdump-rtl-expand -S -o /dev/null -Og min.c 
$ cat min.c.229r.expand 

;; Function outer (outer, funcdef_no=1, decl_uid=1803, cgraph_uid=1,
symbol_order=2)


;; Generating RTL for gimple basic block 2


try_optimize_cfg iteration 1

Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without moving.
Merging block 4 into block 2...
Merged blocks 2 and 4.
Merged 2 and 4 without moving.


try_optimize_cfg iteration 2



;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg/f:DI 89)
(symbol_ref:DI ("S") [flags 0x2]  )) -1
 (nil))
(insn 6 5 7 2 (set (reg/v:SI 88 [ sub ])
(mem/c:SI (plus:DI (reg/f:DI 89)
(const_int 4 [0x4])) [1 S.P+0 S4 A32])) -1
 (nil))
(insn 7 6 8 2 (set (reg:HI 87 [ _2 ])
(subreg:HI (reg/v:SI 88 [ sub ]) 0)) "min.c":12 -1
 (nil))
(insn 8 7 0 2 (parallel [
(asm_operands/v ("magic %0") ("") 0 [
(reg:HI 87 [ _2 ])
]
 [
(asm_input:HI ("r") min.c:12)
]
 [] min.c:12)
(clobber (mem:BLK (scratch) [0  A8]))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "min.c":12 -1
 (nil))
--

I also realized my distro happens to package cross compilers for avr & aarch64,
though I'm not familiar enough with those ISAs offhand to interpret the
generated code (will attach separately in case they're of interest).

[Bug c++/83481] ICE in const-ref structured bindings.

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||reichelt at gcc dot gnu.org
  Known to work||7.3.0
 Resolution|--- |DUPLICATE
   Target Milestone|--- |7.3
  Known to fail||7.1.0

--- Comment #3 from Volker Reichelt  ---
Let's mark it as duplicate of PR83217, because it's fixed by the corresponding
patch.

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

[Bug c++/83217] Compiler segfault: structured binding by reference to a templated type via a pointer

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||antanubis at gmail dot com

--- Comment #6 from Volker Reichelt  ---
*** Bug 83481 has been marked as a duplicate of this bug. ***

[Bug c++/79627] Ice with type of VLA in lambda

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-04
 CC||reichelt at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.5.0, 4.6.0, 4.7.0, 4.8.0,
   ||5.1.0, 6.1.0, 7.1.0, 8.0

[Bug target/85220] New: [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[vries at gcc dot gnu.org]

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

Bug ID: 85220
   Summary: [meta-bug, nvptx] Run trunk with og7 openacc testcases
and analyze execution failures
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

OpenACC for nvptx development has been going on in the development branch
openacc-gcc-7-branch (og7 for short). [ And before that, in gomp-4_0-branch. ]

The test-cases in the og7 branch may uncover problems in trunk, for which no
upstream PR exists (f.i., in the case of broadcast-1.c, a patch attempting to
fix a problem was submitted for trunk, and then committed to og7, without
opening a PR, leaving the problem existing and untracked on trunk. I've just
filed PR85204 - "[nvptx] infinite loop generated" for that one).

We need to run the test-cases from og7 using trunk, and analyze the execution
failures.

[Bug c++/84979] [6/7/8 Regression] ICE with auto as template parameter and -fconcepts

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Apr  5 04:26:36 2018
New Revision: 259124

URL: https://gcc.gnu.org/viewcvs?rev=259124=gcc=rev
Log:
[PR c++/84979] reject auto in explicit tmpl args for tmpl-fn

With concepts, we accept auto in explicit template arguments, but we
should only accept them for template classes.  Passing them to
template functions or variables is not allowed.  So, reject it, at
parse time if possible, at specialization time otherwise.


for  gcc/cp/ChangeLog

PR c++/84979
* pt.c (check_auto_in_tmpl_args): New.
(tsubst_qualified_id): Use it to reject template args
referencing auto for non-type templates.
* parser.c (cp_parser_template_id): Likewise.
* cp-tree.h (check_auto_in_tmpl_args): Declare.
* typeck2.c (build_functional_cast): Report correct location
for invalid use of auto.

for  gcc/testsuite/ChangeLog

PR c++/84979
* g++.dg/concepts/pr84979.C: New.
* g++.dg/concepts/pr84979-2.C: New.
* g++.dg/concepts/pr84979-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr84979-2.C
trunk/gcc/testsuite/g++.dg/concepts/pr84979-3.C
trunk/gcc/testsuite/g++.dg/concepts/pr84979.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80290] [6/7/8 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #19 from Alexandre Oliva  ---
Mine

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 04:01:15 2018
New Revision: 259123

URL: https://gcc.gnu.org/viewcvs?rev=259123=gcc=rev
Log:
PR c++/85215 - ICE with copy-init from conversion.

* call.c (merge_conversion_sequences): Fix type of direct binding
sequence.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/elide3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug target/85220] [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
I've copied the test-cases, and build r259123.

For libgomp.oacc-c/c.exp, we get:
...
$ cat libgomp.testsuite/libgomp.sum | grep ^FAIL:.*execution | grep -v /lib- |
sed 's/libgomp.oacc-c\/..\/libgomp.oacc-c-c++-common\///'
FAIL: avoid-offloading-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: broadcast-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: data-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: data-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: data-4.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: data-4.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: declare-3.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: declare-3.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: enter-data.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: enter-data.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: fp-dyn-arrays.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: fp-dyn-arrays.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: gang-private-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: gang-private-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: inner-reduction.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: pr70828.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: pr70828.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: reduction-9.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: reduction-9.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
...

[Bug middle-end/85196] New: [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

[ro at gcc dot gnu.org]

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

Bug ID: 85196
   Summary: [6/7 regression] ICE in extract_insn, at recog.c:2311:
unrecognizable insn
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.*

Created attachment 43841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43841=edit
reduced testcase: Unified_cpp_js_src10.ii

The attached testcase, reduced from mozjs-38.0.0
js/src/Unified_cpp_js_src10.cpp, ICEs on 64-bit Solaris/SPARC:

$ 
cc1plus -fpreprocessed Unified_cpp_js_src10.ii -mptr64 -mstack-bias -mno-v8plus
-mcpu=v9 -quiet -m64 -O -w -fPIC -fpermissive
Unified_cpp_js_src10.ii: In function 'int ba()':
Unified_cpp_js_src10.ii:82:36: error: unrecognizable insn:
 ba() { an::au(ax, ay, ); }
^
(insn 28 56 29 6 (set (reg/f:DI 122)
(const:DI (plus:DI (label_ref:DI 34)
(const_int 32 [0x20] "Unified_cpp_js_src10.ii":19 -1
 (insn_list:REG_LABEL_OPERAND 34 (nil)))
Unified_cpp_js_src10.ii:82:36: internal compiler error: in extract_insn, at
recog.c:2311
0x908e33 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/rtl-error.c:108
0x908e6f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/rtl-error.c:116
0x8ceef7 extract_insn(rtx_insn*)
/vol/gcc/src/hg/gcc-7-branch/local/gcc/recog.c:2311
0x6f2fef instantiate_virtual_regs_in_insn
/vol/gcc/src/hg/gcc-7-branch/local/gcc/function.c:1589
0x6f2fef instantiate_virtual_regs
/vol/gcc/src/hg/gcc-7-branch/local/gcc/function.c:1957
0x6f2fef execute
/vol/gcc/src/hg/gcc-7-branch/local/gcc/function.c:2006

This only happens on the gcc-6 and 7 branches, while gcc-5 and trunk are fine.

  Rainer

[Bug gcov-profile/85199] New: [GCOV] A cond-expr with a iterative variable in a for loop is marked as "-" in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85199
   Summary: [GCOV] A cond-expr with a iterative variable in a for
loop is marked as "-" in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat small.c
void main()
{
int b = 0;
for(;
b < 1;
b++) {
;
}
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 5
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:void main()
-:2:{
1:3:int b = 0;
2:4:for(;
-:5:b < 1;
1:6:b++) {
-:7:;
-:8:}
1:9:}

Here, we can see that Line #4 is marked as executed twice and Line #5 "b < 1;"
is marked as "-".

I was wondering whether this is a bug. 

Since b is changed in each loop, such that "b < 1" should not be optimized out.
Therefore, I think the correct mark should be as follows: 
Line #4 is marked as executed once and Line #5 is marked as executed twice.

[Bug debug/85176] [8 Regression] ICE in force_decl_die, at dwarf2out.c:25910

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/85176] [8 Regression] ICE in force_decl_die, at dwarf2out.c:25910

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Apr  4 14:11:39 2018
New Revision: 259080

URL: https://gcc.gnu.org/viewcvs?rev=259080=gcc=rev
Log:
2018-04-04  Richard Biener  

PR lto/85176
* dwarf2out.c (dwarf2out_register_external_die): Peel namespaces
from contexts for DINFO_LEVEL_TERSE and below.

* g++.dg/lto/pr85176_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr85176_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85191] [8 regression] gcc.dg/vect/slp-perm-9.c FAILs

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 4 Apr 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85191
> 
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #1 from Richard Biener  ---
> > possibly the vect_perm_short case?  how do you configure targets?  Shouldn't
> > have affected ia64 though...  maybe my TCL fu was too weak and I botched 
> > sth?
> 
> Looking at
> 
> +|| (([istarget i?86-*-*] || [istarget x86_64-*-*]
> +&& [check_ssse3_available]))
> 
> shouldn't this be
> 
> +|| (([istarget i?86-*-*] || [istarget x86_64-*-*])
> +&& [check_ssse3_available])
> 
> ?

Doh!  Indeed...

> > Doesn't fail on x86_64-linux for me.
> 
> For me neither (also not on amd64-pc-solaris2.* or x86_64-apple-darwin11).
> 
> Seems to be a 32-bit host only thing: I'm seeing it on all of
> i386-pc-solaris2.*, i386-apple-darwin11, and i686-pc-linux-gnu.

The above explains the i?86-*-* FAILs.  I'll commit the fix as obvious.

[Bug gcov-profile/85197] [GCOV] The main function is wrongly marked as executed twice in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-04
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/85200] New: [8 Regression] ICE in constexpr-if in lambda in template

[benni.buch at gmail dot com]

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

Bug ID: 85200
   Summary: [8 Regression] ICE in constexpr-if in lambda in
template
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

struct A{
constexpr operator int(){ return 0; }
};

template < typename >
void f(){
[](auto known){
if constexpr(constexpr int k = known);
}(A{});
}

int main(){
f();
}


$ g++ -std=c++17 main.cpp 
main.cpp: In instantiation of 'f() [with  =
int]::<lambda(auto:1)> [with auto:1 = A]':
main.cpp:9:6:   required from 'void f() [with  = int]'
main.cpp:13:12:   required from here
main.cpp:8:36: internal compiler error: in tsubst_copy, at cp/pt.c:15001
 if constexpr(constexpr int k = known);
^
0x611c81 tsubst_copy
../../gcc/gcc/cp/pt.c:15001
0x930440 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18504
0x93f6bf tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17345
0x93f6bf tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17077
0x9423c2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:14946
0x9423c2 tsubst_init
../../gcc/gcc/cp/pt.c:14950
0x940ec8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16391
0x93ed68 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17059
0x93e5a7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16508
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x93b9b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16249
0x93b9b8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23659
0x882f9b maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5190
0x884fd7 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5291
0x7eee9a build_over_call
../../gcc/gcc/cp/call.c:8246
0x7fd2ca build_op_call_1
../../gcc/gcc/cp/call.c:4563
0x7fd2ca build_op_call(tree_node*, vec<tree_node*, va_gc, vl_embed>**, int)
../../gcc/gcc/cp/call.c:4592
0x97b13b finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2551
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.

$ g++ --version
g++ (GCC) 8.0.1 20180404 (experimental)
Copyright (C) 2018 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.


Known to work in GCC 7:
$ g++-7 --version
g++-7 (GCC) 7.3.1 20180226
Copyright (C) 2017 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.

[Bug testsuite/85189] [8 regression] g++.dg/inherit/override-attribs.C FAILs on 32-bit x86

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  4 14:14:08 2018
New Revision: 259082

URL: https://gcc.gnu.org/viewcvs?rev=259082=gcc=rev
Log:
PR testsuite/85189
* g++.dg/inherit/override-attribs.C: Use dg-message instead of dg-error
for the diagnostics of overridden functions.  Adjust for new wording.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/inherit/override-attribs.C

[Bug middle-end/85195] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O -fno-tree-ccp --param=sccvn-max-scc-size=10

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r247092.

[Bug middle-end/85195] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O -fno-tree-ccp --param=sccvn-max-scc-size=10

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On Wed, 4 Apr 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
> 
> --- Comment #20 from Martin Liška  ---
> For the libsanitizer/*/*_interceptors I make a quick patch:
> https://github.com/marxin/gcc/commit/5ce658230db567474997fa411f23ac78366487ce
> which basically splits asan_interceptors.cc and
> sanitizer_common_interceptors.inc and moves implementation of string functions
> to a separate compile unit.
> This shrinks time from 38->34s for asan_interceptors.cc being built with
> enabled checking stage1 compiler.
> 
> I believe splitting the interceptors to couple of logical sub-files will make
> it very fast. List of interceptors grepped from
> sanitizer_common_interceptors.inc:
> I can imagine splitting that to components like string, stdio, time, process,
> thread, math,..

The question is of course _why_ it is this slow.  It's not that this
is 1s of functions or very large ones...

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
(In reply to Richard Biener from comment #32)
> Now the reverse fails - a program compiled with a GCC defaulting to the old
> ABI
> (like GCC 4.8) now fails to run with a dual-ABI libstdc++:
> 
> #include 
> #include 
> using namespace std;
> int main ()
> {
>   std::ifstream pstats;
>   pstats.exceptions(ifstream::failbit | ifstream::badbit | ifstream::eofbit);
>   try {
>   printf("\n Opening file : /proc/0/stat ");
>   pstats.open("/proc/0/stat");
>   }
>   catch(ifstream::failure e)
> {
>   printf("\n!!Caught ifstream exception!!\n");
>   if(pstats.is_open()) {
>   pstats.close();
>   }
> }
>   return 0;
> }
> tmp> g++-4.8 t.C
> tmp> ./a.out 
> 
> terminate called after throwing an instance of
> 'std::ios_base::failure[abi:cxx11]'
>   what():  basic_ios::clear: iostream error
> Aborted (core dumped)
> tmp> LD_LIBRARY_PATH=/space/rguenther/install/gcc-6.4/lib64 ./a.out 
> 
>  Opening file : /proc/0/stat 
> !!Caught ifstream exception!!

--disable-libstdcxx-dual-abi makes the symbol (__throw_ios_failure) throw
c++98 classes again.  --with-default-libstdcxx-abi=gcc4-compatible does not.

Probably impossible to fix without breaking the ABI again, but there should
have been two __throw_ios_failure entries (and callers be "versioned" as well).
At least the old symbol should have been preserved as backward compatible
and a new with a new version be added ... should have been ...

[Bug tree-optimization/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The regression on x86 should eventually be fixed now, not sure if powerpc/spu
are regressions?

[Bug tree-optimization/85191] [8 regression] gcc.dg/vect/slp-perm-9.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Apr  4 12:16:21 2018
New Revision: 259075

URL: https://gcc.gnu.org/viewcvs?rev=259075=gcc=rev
Log:
2018-04-04  Richard Biener  

PR testsuite/85191
* lib/target-supports.exp (check_effective_target_vect_perm_short):
Fix typo.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug tree-optimization/85191] [8 regression] gcc.dg/vect/slp-perm-9.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Should be fixed.

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug middle-end/85195] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O -fno-tree-ccp --param=sccvn-max-scc-size=10

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 43842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43842=edit
gcc8-pr85195.patch

Untested fix.

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-04
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Created attachment 43843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43843=edit
Prototype patch

I have a patch.

[Bug gcov-profile/85197] New: [GCOV] The main function is wrongly marked as executed twice in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85197
   Summary: [GCOV] The main function is wrongly marked as executed
twice in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat small.c
int a = 0;
int *b = 
void main() {
  while(1) {
if (a)
  break;
a++;
  }
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 5
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a = 0;
-:2:int *b = 
2:3:void main() {
-:4:  while(1) {
2:5:if (a)
1:6:  break;
1:7:a++;
-:8:  }
1:9:}


Line #3 (the main function) is wrongly marked as executed twice. It should be
executed once.

[Bug tree-optimization/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #0)
> The gcc.dg/vect/pr81196.c testcase started to FAIL between 20180326
> (r258856) and 20180327 (r258886)
> on a couple of targets:
> 
> +FAIL: gcc.dg/vect/pr81196.c -flto -ffat-lto-objects  scan-tree-dump-times
> vect "vectorized 1 loops" 2
> 
> gcc.dg/vect/pr81196.c: pattern found 0 times
> 
> +FAIL: gcc.dg/vect/pr81196.c scan-tree-dump-times vect "vectorized 1 loops" 2
> 
> I'm seeing it on Solaris/x86 (32 and 64-bit), and there are similar
> testresults
> for FreeBSD, Linux/x86, Linux/PowerPC64, and SPU.

Hmm, what options did you use?
For example,
@r258886 I configured powerpc64 like:
$ ../gcc/configure --enable-languages=c,fortran,c++ --with-cpu=power8
--disable-bootstrap 

Then compile the test case with below options:
./powerpc64le-unknown-linux-gnu-gcc -S -O2 -ftree-vectorize pr81196.c -o
pr81196.S -fdump-tree-ifcvt -fdump-tree-vect-details -flto -ffat-lto-objects
-mcpu=power6/7/8

power6/power7 would fail, but on power8 loops are vectorized.

Problem is, on power6/power7, the case would fail even for r258856 as you
bisected.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Biener  ---
Now the reverse fails - a program compiled with a GCC defaulting to the old ABI
(like GCC 4.8) now fails to run with a dual-ABI libstdc++:

#include 
#include 
using namespace std;
int main ()
{
  std::ifstream pstats;
  pstats.exceptions(ifstream::failbit | ifstream::badbit | ifstream::eofbit);
  try {
  printf("\n Opening file : /proc/0/stat ");
  pstats.open("/proc/0/stat");
  }
  catch(ifstream::failure e)
{
  printf("\n!!Caught ifstream exception!!\n");
  if(pstats.is_open()) {
  pstats.close();
  }
}
  return 0;
}
tmp> g++-4.8 t.C
tmp> ./a.out 

terminate called after throwing an instance of
'std::ios_base::failure[abi:cxx11]'
  what():  basic_ios::clear: iostream error
Aborted (core dumped)
tmp> LD_LIBRARY_PATH=/space/rguenther/install/gcc-6.4/lib64 ./a.out 

 Opening file : /proc/0/stat 
!!Caught ifstream exception!!

[Bug testsuite/85189] [8 regression] g++.dg/inherit/override-attribs.C FAILs on 32-bit x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Introduced with r258898, should be fixed now by the above commit.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
For the libsanitizer/*/*_interceptors I make a quick patch:
https://github.com/marxin/gcc/commit/5ce658230db567474997fa411f23ac78366487ce
which basically splits asan_interceptors.cc and
sanitizer_common_interceptors.inc and moves implementation of string functions
to a separate compile unit.
This shrinks time from 38->34s for asan_interceptors.cc being built with
enabled checking stage1 compiler.

I believe splitting the interceptors to couple of logical sub-files will make
it very fast. List of interceptors grepped from
sanitizer_common_interceptors.inc:
I can imagine splitting that to components like string, stdio, time, process,
thread, math,..

INTERCEPTOR(SIZE_T, strlen, const char *s) {
INTERCEPTOR(SIZE_T, strnlen, const char *s, SIZE_T maxlen) {
INTERCEPTOR(char*, strndup, const char *s, uptr size) {
INTERCEPTOR(char*, __strndup, const char *s, uptr size) {
INTERCEPTOR(char*, textdomain, const char *domainname) {
INTERCEPTOR(int, strcmp, const char *s1, const char *s2) {
INTERCEPTOR(int, strncmp, const char *s1, const char *s2, uptr size) {
INTERCEPTOR(int, strcasecmp, const char *s1, const char *s2) {
INTERCEPTOR(int, strncasecmp, const char *s1, const char *s2, SIZE_T size) {
INTERCEPTOR(char*, strstr, const char *s1, const char *s2) {
INTERCEPTOR(char*, strcasestr, const char *s1, const char *s2) {
INTERCEPTOR(char*, strtok, char *str, const char *delimiters) {
INTERCEPTOR(void*, memmem, const void *s1, SIZE_T len1, const void *s2,
INTERCEPTOR(char*, strchr, const char *s, int c) {
INTERCEPTOR(char*, strchrnul, const char *s, int c) {
INTERCEPTOR(char*, strrchr, const char *s, int c) {
INTERCEPTOR(SIZE_T, strspn, const char *s1, const char *s2) {
INTERCEPTOR(SIZE_T, strcspn, const char *s1, const char *s2) {
INTERCEPTOR(char *, strpbrk, const char *s1, const char *s2) {
INTERCEPTOR(void *, memset, void *dst, int v, uptr size) {
INTERCEPTOR(void *, memmove, void *dst, const void *src, uptr size) {
INTERCEPTOR(void *, memcpy, void *dst, const void *src, uptr size) {
INTERCEPTOR(int, memcmp, const void *a1, const void *a2, uptr size) {
INTERCEPTOR(void*, memchr, const void *s, int c, SIZE_T n) {
INTERCEPTOR(void*, memrchr, const void *s, int c, SIZE_T n) {
INTERCEPTOR(double, frexp, double x, int *exp) {
INTERCEPTOR(float, frexpf, float x, int *exp) {
INTERCEPTOR(long double, frexpl, long double x, int *exp) {
INTERCEPTOR(SSIZE_T, read, int fd, void *ptr, SIZE_T count) {
INTERCEPTOR(SIZE_T, fread, void *ptr, SIZE_T size, SIZE_T nmemb, void *file) {
INTERCEPTOR(SSIZE_T, pread, int fd, void *ptr, SIZE_T count, OFF_T offset) {
INTERCEPTOR(SSIZE_T, pread64, int fd, void *ptr, SIZE_T count, OFF64_T offset)
{
INTERCEPTOR_WITH_SUFFIX(SSIZE_T, readv, int fd, __sanitizer_iovec *iov,
INTERCEPTOR(SSIZE_T, preadv, int fd, __sanitizer_iovec *iov, int iovcnt,
INTERCEPTOR(SSIZE_T, preadv64, int fd, __sanitizer_iovec *iov, int iovcnt,
INTERCEPTOR(SSIZE_T, write, int fd, void *ptr, SIZE_T count) {
INTERCEPTOR(SIZE_T, fwrite, const void *p, uptr size, uptr nmemb, void *file) {
INTERCEPTOR(SSIZE_T, pwrite, int fd, void *ptr, SIZE_T count, OFF_T offset) {
INTERCEPTOR(SSIZE_T, pwrite64, int fd, void *ptr, OFF64_T count,
INTERCEPTOR_WITH_SUFFIX(SSIZE_T, writev, int fd, __sanitizer_iovec *iov,
INTERCEPTOR(SSIZE_T, pwritev, int fd, __sanitizer_iovec *iov, int iovcnt,
INTERCEPTOR(SSIZE_T, pwritev64, int fd, __sanitizer_iovec *iov, int iovcnt,
INTERCEPTOR(int, prctl, int option, unsigned long arg2,
INTERCEPTOR(unsigned long, time, unsigned long *t) {
INTERCEPTOR(__sanitizer_tm *, localtime, unsigned long *timep) {
INTERCEPTOR(__sanitizer_tm *, localtime_r, unsigned long *timep, void *result)
{
INTERCEPTOR(__sanitizer_tm *, gmtime, unsigned long *timep) {
INTERCEPTOR(__sanitizer_tm *, gmtime_r, unsigned long *timep, void *result) {
INTERCEPTOR(char *, ctime, unsigned long *timep) {
INTERCEPTOR(char *, ctime_r, unsigned long *timep, char *result) {
INTERCEPTOR(char *, asctime, __sanitizer_tm *tm) {
INTERCEPTOR(char *, asctime_r, __sanitizer_tm *tm, char *result) {
INTERCEPTOR(long, mktime, __sanitizer_tm *tm) {
INTERCEPTOR(char *, strptime, char *s, char *format, __sanitizer_tm *tm) {
INTERCEPTOR(int, vscanf, const char *format, va_list ap)
INTERCEPTOR(int, vsscanf, const char *str, const char *format, va_list ap)
INTERCEPTOR(int, vfscanf, void *stream, const char *format, va_list ap)
INTERCEPTOR(int, __isoc99_vscanf, const char *format, va_list ap)
INTERCEPTOR(int, __isoc99_vsscanf, const char *str, const char *format,
INTERCEPTOR(int, __isoc99_vfscanf, void *stream, const char *format, va_list
ap)
INTERCEPTOR(int, scanf, const char *format, ...)
INTERCEPTOR(int, fscanf, void *stream, const char *format, ...)
INTERCEPTOR(int, sscanf, const char *str, const char *format, ...)
INTERCEPTOR(int, __isoc99_scanf, const char *format, ...)
INTERCEPTOR(int, __isoc99_fscanf, void *stream, const char *format, ...)
INTERCEPTOR(int, 

[Bug c++/85194] ICE with structured binding in broken for-loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43844=edit
gcc8-pr85194.patch

Untested fix.

[Bug c++/85200] [8 Regression] ICE in constexpr-if in lambda in template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |8.0

[Bug c++/85200] [8 Regression] ICE in constexpr-if in lambda in template

[benni.buch at gmail dot com]

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

--- Comment #1 from Benjamin Buch  ---
Another version of the ICE is:

struct B{
constexpr operator bool(){ return 1; }
};

template < typename >
void f(){
[](auto v, auto b){
if constexpr(b){
auto x = [](auto){ return 0; }(v);
}
}(0, B{});
}

int main(){
f();
}


$ g++ -std=c++17 main.cpp
main.cpp: In instantiation of 'f() [with  =
int]::<lambda(auto:1, auto:2)> [with auto:1 = int; auto:2 = B]':
main.cpp:11:6:   required from 'void f() [with  = int]'
main.cpp:15:12:   required from here
main.cpp:9:44: internal compiler error: in tsubst_copy, at cp/pt.c:15001
 auto x = [](auto){ return 0; }(v);
^
0x611c81 tsubst_copy
../../gcc/gcc/cp/pt.c:15001
0x930440 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18504
0x9328ae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18623
0x930d9d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17925
0x93f6bf tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17345
0x93f6bf tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17077
0x9423c2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:14946
0x9423c2 tsubst_init
../../gcc/gcc/cp/pt.c:14950
0x940ec8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16391
0x93ee24 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16264
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x94097e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16531
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x93c81f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x93b9b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16249
0x93b9b8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23659
0x882f9b maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5190
0x884fd7 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5291
0x7eee9a build_over_call
../../gcc/gcc/cp/call.c:8246
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.

$ g++ --version
g++ (GCC) 8.0.1 20180404 (experimental)
Copyright (C) 2018 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.

Again known to work with GCC 7:
$ g++-7 --version
g++-7 (GCC) 7.3.1 20180226
Copyright (C) 2017 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.

[Bug tree-optimization/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from amker at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #0)
[...]
> Hmm, what options did you use?

Nothing special in the Solaris/x86 (i386-pc-solaris2.11) case:

$ configure --with-as=/usr/ccs/bin/as --without-gnu-as
--enable-languages=all,ada,obj-c++,go

> Then compile the test case with below options:
> ./powerpc64le-unknown-linux-gnu-gcc -S -O2 -ftree-vectorize pr81196.c -o
> pr81196.S -fdump-tree-ifcvt -fdump-tree-vect-details -flto -ffat-lto-objects
> -mcpu=power6/7/8
>
> power6/power7 would fail, but on power8 loops are vectorized.
>
> Problem is, on power6/power7, the case would fail even for r258856 as you
> bisected.

I don't have access to power systems, but for i386 it's

$ gcc pr81196.c -mclear-hwcap -msse2 -ftree-vectorize -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details

or

$ gcc pr81196.c -m64 -mclear-hwcap -msse2 -ftree-vectorize -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details

for amd64.

[Bug tree-optimization/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Created attachment 43845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43845=edit
i386-pc-solaris2.11 pr81196.c.161t.vect

32-bit Solaris/x86 dump for reference

[Bug tree-optimization/85191] [8 regression] gcc.dg/vect/slp-perm-9.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Richard Biener  ---
> possibly the vect_perm_short case?  how do you configure targets?  Shouldn't
> have affected ia64 though...  maybe my TCL fu was too weak and I botched sth?

Looking at

+|| (([istarget i?86-*-*] || [istarget x86_64-*-*]
+&& [check_ssse3_available]))

shouldn't this be

+|| (([istarget i?86-*-*] || [istarget x86_64-*-*])
+&& [check_ssse3_available])

?

> Doesn't fail on x86_64-linux for me.

For me neither (also not on amd64-pc-solaris2.* or x86_64-apple-darwin11).

Seems to be a 32-bit host only thing: I'm seeing it on all of
i386-pc-solaris2.*, i386-apple-darwin11, and i686-pc-linux-gnu.

[Bug target/85198] New: long long int vector mistaken as long int vector

[kelvin at gcc dot gnu.org]

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

Bug ID: 85198
   Summary: long long int vector mistaken as long int vector
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

With the current trunk, the following program:

#include 

vector long long int vulli;

int main (int argc, char *argv[]) {

  printf ("vector element is %lld\n", vulli[0]);

}

produces a warning to stderr:

$GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc/ -maltivec -Wall -O2
-fstack-protector-strong -o problem problem.c
problem.c: In function ‘main’:
problem.c:8:33: warning: format ‘%lld’ expects argument of type ‘long long
int’, but argument 2 has type ‘long int’ [-Wformat=]
   printf ("vector element is %lld\n", vulli[0]);
  ~~~^ 
  %ld

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
(In reply to rguent...@suse.de from comment #21)
> On Wed, 4 Apr 2018, marxin at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
> > 
> > --- Comment #20 from Martin Liška  ---
> > For the libsanitizer/*/*_interceptors I make a quick patch:
> > https://github.com/marxin/gcc/commit/5ce658230db567474997fa411f23ac78366487ce
> > which basically splits asan_interceptors.cc and
> > sanitizer_common_interceptors.inc and moves implementation of string 
> > functions
> > to a separate compile unit.
> > This shrinks time from 38->34s for asan_interceptors.cc being built with
> > enabled checking stage1 compiler.
> > 
> > I believe splitting the interceptors to couple of logical sub-files will 
> > make
> > it very fast. List of interceptors grepped from
> > sanitizer_common_interceptors.inc:
> > I can imagine splitting that to components like string, stdio, time, 
> > process,
> > thread, math,..
> 
> The question is of course _why_ it is this slow.  It's not that this
> is 1s of functions or very large ones...

It's analyzed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288

[Bug tree-optimization/85168] [7 Regression] ICE in tree-ssa-coalesce.c: SSA corruption: Unable to coalesce ssa_names which are marked as MUST COALESCE when -O2 is used

[ivo.raisr at oracle dot com]

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

--- Comment #7 from Ivo Raisr  ---
Fix backported to 7.3.0 correctly compiles the original (huge) source module.
Thank you, Richard.

[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[sirl at gcc dot gnu.org]

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

Franz Sirl  changed:

   What|Removed |Added

  Known to fail||3.1.1

--- Comment #11 from Franz Sirl  ---
It is wrong since the introduction of -msvr4-struct-return during the gcc-3.1
development. Before that GCC followed a draft ABI spec and returned all
aggregates in memory for ABI_V4.
A quick check reveals that a fix is probably easy to implement with a new
option (non-default for backwards compatibility), a small change in
rs6000_return_in_msb() and an additional value in rs6000_elf_file_end() for
".gnu_attribute 12".

[Bug gcov-profile/85201] New: [GCOV] A statement with two && operators and a comma operator in the for loop body is wrongly marked in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85201
   Summary: [GCOV] A statement with two && operators and a comma
operator in the for loop body is wrongly marked in
gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat small.c
void main() {
  int a = 0;
  int b = 0;
  int c = 0;
  for (; a >= 0; a--) {
(c && b, 1) && b;
  }
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:void main() {
1:2:  int a = 0;
1:3:  int b = 0;
1:4:  int c = 0;
2:5:  for (; a >= 0; a--) {
2:6:(c && b, 1) && b;
-:7:  }
1:8:}


Line #6 is wrongly marked as executed twice.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
I think I have finally found the culprit.  Took me a couple of hours...

The type in question is introduced in gimple-match-head.c, in

763 return (gimple_resimplify2 (seq, rcode,
764 boolean_type_node, ops, valueize)
765 || valueized);

This is probably where the wrong type is being generated.

[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Simplified testcase:
struct words
{
#define V(n) short word_##n;
#define W(n) V(n)
#define X(n) W(n##0) W(n##1) W(n##2) W(n##3) W(n##4) W(n##5) W(n##6) W(n##7)
W(n##8) W(n##9)
#define Y X(0) X(1) X(2) X(3) X(4) X(5)
  Y
};

static char *pbuf, **pbuf_ptrs;

void
foo (struct words *w)
{
  char *aa = pbuf, **cptr = pbuf_ptrs;

  *cptr = aa;
#undef V
#define V(n) \
  __builtin_sprintf (*(cptr++), "word_" #n " %d ", w->word_##n); \
  *cptr = (aa += __builtin_strlen (aa) + 1);
  Y

  __builtin_sprintf (*(cptr++), " ");
  *cptr = (aa += __builtin_strlen (aa) + 1);
}

void
bar (char *x, char **y)
{
  pbuf = x;
  pbuf_ptrs = y;
}

Infinite recursion is not possible and is not what's going on here, that is
prevented through:
  f = val->locs;
  /* Temporarily reset val->locs to avoid infinite recursion.  */
  val->locs = NULL;
...
  val->locs = f;
in find_base_term.

I think the problem is rather that for PLUS and MINUS we recurse up to twice
(once for each argument) and for VALUEs we can recurse even more times if it
has long locs list, so if we are unlucky it can be exponential, one single
toplevel find_base_term call recursing transitively on a particular VALUE many
times.

Now, I guess caching find_base_term return value for each VALUE (or perhaps
delayed, look up say 20 VALUEs without caching and only then build the cache
and start caching) could be a way out of this, but the val->locs = NULL; hack
above will not be very good for that, because then we might cache a negative
answer even for VALUEs that would yield non-NULL answer if we called
find_base_term for it from the toplevel.  Dunno if that is acceptable or not.

I also wonder if we couldn't (either in new struct cselib_val field or on the
side table) just record find_base_term value (and find_base_value?) of each
VALUE we create when we process the instruction that created the VALUE.  Or is
the find_base_term not meant to be sticky for each VALUE forever and is
supposed to change as further insns are processed (invalidate locs from VALUEs
etc.)?

[Bug target/85204] New: [nvptx] infinite loop generated

[vries at gcc dot gnu.org]

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

Bug ID: 85204
   Summary: [nvptx] infinite loop generated
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the following testcase (broadcast-1.c in the og7 branch):
...
#include 
#include 

#define N 1024

int A[N][N] ;

void test(int x)
{
#pragma acc parallel num_gangs(16) num_workers(4) vector_length(32) copyout(A)
  {
#pragma acc loop gang
for(int j=0;j

[Bug gcov-profile/85206] New: [GCOV] a return statement in the body of for(;0;) loop is wrongly marked as executed in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85206
   Summary: [GCOV] a return statement in the body of for(;0;) loop
is wrongly marked as executed in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

$ cat small.c
int a = 1;
int main() {
  if (1) {
int e[1];
for (; a>0;) {
  for (; 0;)
return 2;
  return 1;
}
  }
  return 0;
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:83.33% of 6
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a = 1;
1:2:int main() {
-:3:  if (1) {
-:4:int e[1];
1:5:for (; a>0;) {
1:6:  for (; 0;)
1:7:return 2;
1:8:  return 1;
-:9:}
-:   10:  }
#:   11:  return 0;
-:   12:}


Line #7 is wrongly marked as executed. However, it should be not executed since
it is in the for(;0;) body.

[Bug target/85198] long long int vector mistaken as long int vector

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
And the bug is obvious, rs6000_handle_altivec_attribute only cares about mode
of the type and returns precomputed vector types like unsigned_V2DI_type_node
etc. based on the mode, rather than different types based on what the element
type main variant is.

[Bug c++/65923] False positive for warning about literal operator suffix and using

[ville at gcc dot gnu.org]

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

--- Comment #7 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Apr  4 16:05:11 2018
New Revision: 259087

URL: https://gcc.gnu.org/viewcvs?rev=259087=gcc=rev
Log:
PR c++/65923

gcc/cp

PR c++/65923
* decl.c (grokfndecl): Handle standard UDL diagnostics here..
* parser.c (cp_parser_unqualified_id): ..not here.

testsuite/

PR c++/65923
* g++.dg/diagnostic/pr65923.C: New.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr65923.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c