[Bug tree-optimization/84452] New: [8 Regression] ICE in expand_simd_clones at gcc/omp-simd-clone.c:1612

[marxin at gcc dot gnu.org]

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

Bug ID: 84452
   Summary: [8 Regression] ICE in expand_simd_clones at
gcc/omp-simd-clone.c:1612
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: ppc64le-linux-gnu

Probably GCC 8 regression:

$ ppc64le-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr84309.c  -Ofast
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr84309.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr84309.c:10:1:
internal compiler error: Segmentation fault
 foo (void)
 ^~~
0xb84bff crash_signal
.././../gcc/toplev.c:325

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x012d0bc3 in expand_simd_clones (node=node@entry=0x769cd2e0)
at .././../gcc/omp-simd-clone.c:1612
#2  0x013085d7 in vect_recog_pow_pattern (stmts=,
type_in=0x7fffd0b0, type_out=0x7fffd0b8) at
.././../gcc/tree-vect-patterns.c:1118
#3  0x01303fe9 in vect_pattern_recog_1
(recog_func=recog_func@entry=0x1ca16a0 ,
stmts_to_replace=stmts_to_replace@entry=0x7fffd100, si=...) at
.././../gcc/tree-vect-patterns.c:4489
#4  0x013089f7 in vect_pattern_recog (vinfo=vinfo@entry=0x1e8bc00) at
.././../gcc/tree-vect-patterns.c:4681
#5  0x00e15a6f in vect_analyze_loop_2 (fatal=:
, loop_vinfo=) at
.././../gcc/tree-vect-loop.c:2161
#6  vect_analyze_loop (loop=loop@entry=0x767fc770,
orig_loop_vinfo=orig_loop_vinfo@entry=0x0) at .././../gcc/tree-vect-loop.c:2612
#7  0x00e33557 in vectorize_loops () at
.././../gcc/tree-vectorizer.c:664
#8  0x00aa4281 in execute_one_pass (pass=pass@entry=0x1dc3200) at
.././../gcc/passes.c:2497
#9  0x00aa4b41 in execute_pass_list_1 (pass=0x1dc3200) at
.././../gcc/passes.c:2586
#10 0x00aa4b53 in execute_pass_list_1 (pass=0x1dc2a70) at
.././../gcc/passes.c:2587
#11 0x00aa4b53 in execute_pass_list_1 (pass=0x1dc16e0) at
.././../gcc/passes.c:2587
#12 0x00aa4b95 in execute_pass_list (fn=,
pass=) at .././../gcc/passes.c:2597
#13 0x0074bcf0 in cgraph_node::expand (this=0x769cd000) at
.././../gcc/cgraphunit.c:2139
#14 0x0074d291 in expand_all_functions () at
.././../gcc/cgraphunit.c:2275
#15 symbol_table::compile (this=this@entry=0x767fe000) at
.././../gcc/cgraphunit.c:2624
#16 0x0074fb67 in symbol_table::compile (this=0x767fe000) at
.././../gcc/cgraphunit.c:2720
#17 symbol_table::finalize_compilation_unit (this=0x767fe000) at
.././../gcc/cgraphunit.c:2717
#18 0x00b84ede in compile_file () at .././../gcc/toplev.c:480
#19 0x0059fd75 in do_compile () at .././../gcc/toplev.c:2132
#20 toplev::main (this=this@entry=0x7fffd58e, argc=,
argc@entry=23, argv=, argv@entry=0x7fffd688) at
.././../gcc/toplev.c:2267
#21 0x005a22ab in main (argc=23, argv=0x7fffd688) at
.././../gcc/main.c:39
(gdb) p *current_pass
$1 = { = {type = GIMPLE_PASS, name = 0x14d5527 "vect", optinfo_flags
= 36, tv_id = TV_TREE_VECTORIZATION, properties_required = 40,
properties_provided = 0, properties_destroyed = 0, todo_flags_start = 524288,
todo_flags_finish = 0}, 
  _vptr.opt_pass = 0x14dace8 , sub = 0x1dc3260, next = 0x1dc32c0,
static_pass_number = 166, m_ctxt = 0x1d9a860}

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://llvm.org/bugs/show_
   ||bug.cgi?id=25757

--- Comment #16 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #14)
> (In reply to Nenad Vukicevic from comment #13)
> > For what is worth I filed two bug reports:
> 
> Thanks!
> 
> > LLVM:
> > https://llvm.org/bugs/show_bug.cgi?id=25757
> > 
> > APPLE:
> > Bug 23778972 (not sure how to get URL for this bug)
> 
> AFAIK there isn't any way (radr:// URLs are not visible externally)
> Some folks have an "unofficial" external radar site, but not sure how
> successful that is in progressing bug reports.
>

Link to the "unofficial" external site: https://openradar.appspot.com/page/1
(not seeing that bug there though)

[Bug c++/22238] Awful error messages with virtual functions

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #24 from AK  ---
The recent error messages look much better. Maybe we can close this.

prog.cpp: In member function ‘void A::bar()’:
prog.cpp:6:23: error: could not convert ‘A::foo()’ from ‘void’ to ‘bool’
   void bar() { if (foo()) ; }

[Bug c++/17913] ICE jumping into statement expression

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #25 from AK  ---
I think this bug is fixed:


void f(void) { 1 ? 1 : ({ a : 1; 1; }); goto a; }


g++-7.3 -O3 -std=c++11 test.c -S -o -



f():
.L2:
jmp .L2

[Bug c++/84451] New: Multiple invocation of virtual base class constructor in diamond inheritance

[tolez_xuninada at hotmail dot com]

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

Bug ID: 84451
   Summary: Multiple invocation of virtual base class constructor
in diamond inheritance
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tolez_xuninada at hotmail dot com
  Target Milestone: ---

I have a virtual and multiple inheritance situation: classes E and 
F inherits virtually from Root and G 
inherits from a wrapper class MultipleInherit,E,F>, 
which in turns inherit from E and F. Here's a minimal working 
example: 

In testbases1.cpp: 
#include 
#include 
#include 

using namespace std; 

namespace details { 
template 
< 
  template  class BinaryPred, 
  class FirstOp, 
  class SecondOp, 
  class ... RestOp 
> struct OneToAll { 
  static constexpr bool value = 
BinaryPred::value && 
OneToAll::value; 
}; 

template 
< 
  template  class BinaryPred, 
  class FirstOp, 
  class SecondOp, 
  class ... RestOp 
> 
constexpr bool OneToAll_v = 
OneToAll::value; 

template 
< 
  template  class BinaryPred, 
  class FirstOp, 
  class SecondOp 
> 
struct OneToAll { 
  static constexpr bool value = BinaryPred::value; 
}; 

struct EmptyBase {}; 

template < class VirtualBase, class ... Bases > 
struct MultipleInherit : 
  public 
std::conditional_t, 
 EmptyBase, 
 VirtualBase>, 
  public Bases... 
{ 

  static constexpr std::size_t NBases = sizeof...(Bases)+1; 

  template < class ... Args > 
  MultipleInherit(Args&&... args) 
:VirtualBase(std::forward(args)...) 
,Bases{std::forward(args)...}... 
  { 
cout << "MI()\n"; 
  } 

}; 

} 

using namespace details; 

template  
struct Root { 
  Root(T& i, const double& d) : ri_(i), d_(d) { cout << "Root()\n"; }; 
protected: 
  T& ri_; 
  double d_; 
}; 

template < class T > 
struct E : public virtual Root { 
  E(T& i, const double& d) : Root(i,d) { 
cout << "E()\n"; 
  } 
}; 

template < class T > 
struct F : public virtual Root { 
  F(T& i, const double& d) : Root(i,d) { 
cout << "F()\n"; 
  } 
}; 

template < class T > 
struct G : public MultipleInherit,E,F> { 
  using BaseType = MultipleInherit,E,F>; 
  G(T& i, const double& d) : Root(i,d),BaseType(i,d) { 
cout << "G()\n"; 
  } 
}; 

int main(int argc, char* argv[]) { 
  int i = 3; 
  double d = 4; 
  G g(i,d); 
} 

If I compile with gcc 7.3.0: g++ testbases1.cpp -o testbases1 -g -std=c++14, 
I get the expected output: 
Root() 
E() 
F() 
MI() 
G() 
I also tried clang++ which gives the correct answer too. But if I compile with
gcc 5.5.0, I get: 
Root() 
Root() 
E() 
Root() 
F() 
MI() 
G() 

The gcc 5.5.0 is obviously giving the wrong answer because one would expect 
the virtual base is only constructed once in this situation.

[Bug c++/84429] [8 Regression] ICE capturing variable-sized array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/68289] Missing diagnostic pragmas

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44054,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64273

--- Comment #6 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #1)
> IMO implementing the diagnostic pragmas in gfortran will just be a waste of
> time. Thus if someone want to close this PR as WONTFIX, I won't object!

That sounds more like material for putting it in SUSPENDED; WONTFIX is more for
a fundamental disagreement with it rather than just lack of interest, and
WAITING is for when the reporter needs to provide more info.

[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)

[egallager at gcc dot gnu.org]

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

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

--- Comment #13 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #8)
> > You might want to double check that it's not a bug in the HP-UX libm.
> 
> AFAIU Joseph (comment 2) the test should be skipped on platforms defaulting
> to -fno-math-errno as Darwin.

There has been discussion on making ALL platforms default to -fno-math-errno
lately on gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01065.html
I assume if that were to happen, it'd make sense just to remove the test
entirely?

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-(1|2).c * execution test on x86_64-apple-darwin1[34]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #32 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #31)
> This PR seems "fixed" (as in silenced) on x86_64-apple-darwin15.

OK I guess I'll close it as FIXED then.

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #3)
> Still present at r220301 (see
> https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the
> patch in comment 2 makes sense or is there a better fix?

Try sending it to gcc-patches for review

[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared

[egallager at gcc dot gnu.org]

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

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

--- Comment #14 from Eric Gallager  ---
(In reply to Francois-Xavier Coudert from comment #13)
> Might this be related with PR63622 (and thus PR63580)?

These have both been closed.

[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #4)
> Created attachment 26187 [details]
> patch to fix some failures with -fdefault-integer-8
> 
> I have this patch in my tree for a quite long time. It fixes some failures
> with -fdefault-integer-8 by replacing some implicit kinds with explicit ones.

patches go to the gcc-patches mailing list

[Bug c++/84423] [6/7/8 Regression] [concepts] ICE with invalid using declaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org
Summary|[concepts] ICE with invalid |[6/7/8 Regression]
   |using declaration   |[concepts] ICE with invalid
   ||using declaration

--- Comment #4 from Martin Sebor  ---
Bisection points to r229629 as the cause of the ICE (gcc 6.0.0):

r229629 | jason | 2015-10-31 12:20:05 -0400 (Sat, 31 Oct 2015) | 15 lines

Implement multiple 'auto' feature from Concepts TS.

Prior to that the code was rejected with:

pr84423.C:1:30: error: invalid use of ‘auto’
 template using A = auto;
  ^
pr84423.C:5:3: error: ‘A’ was not declared in this scope
 B b;
   ^
pr84423.C:5:4: error: template argument 1 is invalid
 B b;
^

[Bug c++/84429] [8 Regression] ICE capturing variable-sized array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-19
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk.  The ICE was introduced in r253265 (gcc
8.0.0):

r253265 | jason | 2017-09-28 15:39:38 -0400 (Thu, 28 Sep 2017) | 16 lines

Use local_specializations to find capture proxies.

[Bug c++/84441] [6/7/8 Regression] Internal compiler error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-19
 CC||msebor at gcc dot gnu.org
Summary|Internal compiler error |[6/7/8 Regression] Internal
   ||compiler error
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk and the stack trace below:

during RTL pass: expand
pr84441.C: In constructor ‘derived::derived(int)’:
pr84441.C:17:15: internal compiler error: in assign_temp, at function.c:977
 (size_t)0-n ) ) { }
   ^
0xe756e6 assign_temp(tree_node*, int, int)
/ssd/src/gcc/svn/gcc/function.c:977
0xc3ab15 expand_call(tree_node*, rtx_def*, int)
/ssd/src/gcc/svn/gcc/calls.c:3434
0xe0b3ee expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/ssd/src/gcc/svn/gcc/expr.c:10990
0xdfd6d6 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/ssd/src/gcc/svn/gcc/expr.c:8227
0xdda6ba expand_normal
/ssd/src/gcc/svn/gcc/expr.h:282
0xdf8521 store_field
/ssd/src/gcc/svn/gcc/expr.c:6975
0xdefba7 expand_assignment(tree_node*, tree_node*, bool)
/ssd/src/gcc/svn/gcc/expr.c:5249
0xc59426 expand_call_stmt
/ssd/src/gcc/svn/gcc/cfgexpand.c:2688
0xc5c911 expand_gimple_stmt_1
/ssd/src/gcc/svn/gcc/cfgexpand.c:3624
0xc5d044 expand_gimple_stmt
/ssd/src/gcc/svn/gcc/cfgexpand.c:3790
0xc65757 expand_gimple_basic_block
/ssd/src/gcc/svn/gcc/cfgexpand.c:5819
0xc67357 execute
/ssd/src/gcc/svn/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.


The first revision to fail is r228704 (gcc 6.0.0):

r228704 | jason | 2015-10-12 03:58:43 -0400 (Mon, 12 Oct 2015) | 5 lines

PR c++/67557

[Bug c++/84444] ICE with __builtin_launder and cast

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk.  Doesn't appear to be be a regression (i.e.,
it was introduced with __builtin_launder in r241506.

[Bug c++/84445] [7/8 Regression] ICE with __builtin_launder and virtual function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 CC||msebor at gcc dot gnu.org
Summary|ICE with __builtin_launder  |[7/8 Regression] ICE with
   |and virtual function|__builtin_launder and
   ||virtual function
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to somewhere between r242708 and r242710.

[Bug bootstrap/84450] New: bootstrap-lto ICE in g-dyntab.adb

[steven at uplinklabs dot net]

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

Bug ID: 84450
   Summary: bootstrap-lto ICE in g-dyntab.adb
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven at uplinklabs dot net
  Target Milestone: ---

This bug has been around for at least a few GCC versions now, but I hadn't
gotten around to reporting it.

My configure flags:

  --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu \
  --prefix=/usr \
  --libdir=/usr/lib \
  --libexecdir=/usr/lib \
  --mandir=/usr/share/man \
  --infodir=/usr/share/info \
  --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ \
  --with-build-config=bootstrap-lto \
  --disable-libssp \
  --disable-libstdcxx-pch \
  --disable-libunwind-exceptions \
  --disable-werror \
  --enable-__cxa_atexit \
  --enable-checking=release \
  --enable-clocale=gnu \
  --enable-gnu-indirect-function \
  --enable-gnu-unique-object \
  --enable-initfini-array \
  --enable-install-libiberty \
  --enable-libmpx \
  --enable-linker-build-id \
  --enable-lto \
  --enable-multilib \
  --enable-plugin \
  --enable-shared \
  --enable-threads=posix \
  --with-isl \
  --with-linker-hash-style=gnu \
  --with-multilib-list=m32,m64,mx32 \
  --with-system-zlib

Non-bootstrap-lto builds work fine, but if I -do- try a bootstrap-lto build, I
get this:

/build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb: In function
‘prep__symbol_table__free’:
/build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb:140:9: internal compiler
error: in gen_typedef_die, at dwarf2out.c:24370
end Free;
 ^
0x8b8125 gen_typedef_die
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24370
0x8ba02b gen_decl_die
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25390
0x8b866b gen_type_die_with_usage
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24547
0x8b8de2 gen_type_die
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24758
0x8ba0aa gen_decl_die
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25410
0x8b9204 process_scope_var
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24903
0x8b9262 decls_for_scope
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24928
0x8b3d1a gen_subprogram_die
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:22465
0x8b9f58 gen_decl_die
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25364
0x8badaa dwarf2out_decl
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25879
0x8bae09 dwarf2out_function_decl
/build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25894
0x939efe rest_of_handle_final
/build/gcc-multilib/src/gcc/gcc/final.c:4520
0x93a06c execute
/build/gcc-multilib/src/gcc/gcc/final.c:4562

This is built from gcc-7-branch@257786.

Any more details I can provide?

[Bug c++/84446] [8 Regression] ICE with broken lambda

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk.  ICE introduced in r251433:

r251433 | jason | 2017-08-29 16:37:15 -0400 (Tue, 29 Aug 2017) | 28 lines

Reimplement handling of lambdas in templates.

[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisected to r251422 (gcc 8.0.0):

r251422 | jason | 2017-08-29 15:40:08 -0400 (Tue, 29 Aug 2017) | 10 lines

Instantiate default arguments/member initializers once.

Prior to that GCC errors out with:

t.C:11:6: error: use of deleted function ‘B::B(T, T) [with T = int][inherited
from A]’
 B b(0);
  ^
t.C:8:12: note: ‘B::B(T, T) [with T = int][inherited from A]’ is implicitly
deleted because the default definition would be ill-formed:
   using A::A;
^
t.C:8:12: error: use of deleted function ‘A::A(T, T) [with T = int]’
t.C:3:24: note: declared here
   template A(T, T = 0) = delete;
^

[Bug c++/84448] [6/7/8 Regression] ICE with broken condition in parallel for loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk.  Bisected to r230365 (gcc 6.0.0):

r230365 | jason | 2015-11-13 19:08:05 -0500 (Fri, 13 Nov 2015) | 59 lines

Merge C++ delayed folding branch.

[Bug c++/84449] [7/8 Regression] ICE with constexpr and deleted destructor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the top of trunk.  The ICE occurs with -std=c++17 as well. 
Bisection points to r245612:

r245612 | jason | 2017-02-20 13:18:30 -0500 (Mon, 20 Feb 2017) | 3 lines

PR c++/78139 - destructor needed by new-expression

* call.c (build_special_member_call): Use tf_no_cleanup.

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-18
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Let me take a look.

[Bug c++/79064] Cannot overload member function templates on type of literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #5 from Martin Sebor  ---
The failure only appears only on some targets (it would be helpful if you
mentioned the target where you see a test fail when posting test results).

The test doesn't fail in my local build on x86_64.

There also is no failure in the results for

hppa-unknown-linux-gnu
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01199.html   <<<

hppa2.0w-hp-hpux11.11:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01220.html

ia64-suse-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01211.html

powerpc64le-unknown-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01224.html

x86_64-pc-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01202.html


I do see failures on the following targets:

powerpc-ibm-aix7.2.0.0
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01225.html

aarch64-suse-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01218.html

hppa-unknown-linux-gnu
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01228.html   <<<

m68k-unknown-linux-gnu
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01215.html

powerpc64-unknown-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01229.html

s390x-ibm-linux-gnu zEC12:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01217.html

s390x-ibm-linux-gnu default
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01212.html


What's interesting is that between two recent hppa-unknown-linux-gnu builds the
test is reported to fail in one but not the other (see <<< above).

[Bug c++/70401] [c++1z] variadic template failed

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
We should add c++17 testing into check-c++, not everybody tests with
check-c++-all.

[Bug c++/70401] [c++1z] variadic template failed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC|paolo.carlini at oracle dot com|
Summary|[c++1z on mingw]compile |[c++1z] variadic template
   |variadic template failed|failed

--- Comment #8 from Paolo Carlini  ---
Ok, I can confirm that we are still rejecting this everywhere (note, not as an
ICE, simply as reported above). Probably, what fooled me back in November, is
that it wasn't clear to me that we got a bunch of issues with C++14 code
rejected with -std=c++1z on the command line. Probably we should also create a
meta-bug.

[Bug c++/84436] Missed optimization with switch on enum constants returning the same value

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-18
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-18
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
From the activity I guess this PR is confirmed.

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Is that fixed in trunk then, or just hidden?

[Bug c++/84423] [concepts] ICE with invalid using declaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Martin Sebor  ---
I can now reproduce it too.

[Bug middle-end/84433] gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Appears this wrong-code was fixed for gcc-8.0 by r251690.

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
r254157 is the culprit (r254156 is OK).

Just how this patch has caused this regression isn't quite
clear at first glance... I'll look.

[Bug c++/84449] New: [7/8 Regression] ICE with constexpr and deleted destructor

[reichelt at gcc dot gnu.org]

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

Bug ID: 84449
   Summary: [7/8 Regression] ICE with constexpr and deleted
destructor
   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++1z")
triggers an ICE since GCC 7.1.0:


struct A
{
  constexpr A(int) {}
  ~A() = delete;
};

struct B
{
  A a;
  constexpr B() : a(0) {}
};


bug.cc: In constructor 'constexpr B::B()':
bug.cc:10:22: error: use of deleted function 'A::~A()'
   constexpr B() : a(0) {}
  ^
bug.cc:4:3: note: declared here
   ~A() = delete;
   ^
bug.cc:10:25: error: use of deleted function 'A::~A()'
   constexpr B() : a(0) {}
 ^
bug.cc:4:3: note: declared here
   ~A() = delete;
   ^
bug.cc:10:25: internal compiler error: tree check: expected target_expr, have
error_mark in bot_manip, at cp/tree.c:2906
   constexpr B() : a(0) {}
 ^
0x78a40a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9335
0x668c3b tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3132
0x668c3b bot_manip
../../gcc/gcc/cp/tree.c:2906
0x115823b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/gcc/tree.c:11400
0x9bd869 break_out_target_exprs(tree_node*)
../../gcc/gcc/cp/tree.c:3028
0x84d8d1 build_data_member_initialization
../../gcc/gcc/cp/constexpr.c:341
0x84e3fd build_constexpr_constructor_member_initializers
../../gcc/gcc/cp/constexpr.c:592
0x84e3fd massage_constexpr_body
../../gcc/gcc/cp/constexpr.c:726
0x858696 register_constexpr_fundef(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:848
0x897f7f maybe_save_function_definition
../../gcc/gcc/cp/decl.c:15544
0x897f7f finish_function(bool)
../../gcc/gcc/cp/decl.c:15675
0x933ec9 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26691
0x935b9c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:27568
0x927fac cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22716
0x929269 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22742
0x929269 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16748
0x936416 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13606
0x93bae0 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12916
0x93ca88 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12863
0x9409e2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12761
Please submit a full bug report, [etc.]

[Bug c++/84448] New: [6/7/8 Regression] ICE with broken condition in parallel for loop

[reichelt at gcc dot gnu.org]

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

Bug ID: 84448
   Summary: [6/7/8 Regression] ICE with broken condition in
parallel for loop
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code, openmp
  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 "-fopenmp")
triggers an ICE since GCC 6.1.0:

=
struct A
{
  operator int() const;
  A& operator +=(int);
  A& operator ++();
};

void foo(A a, A b)
{
  #pragma omp for
  for (A i = a; i <=; ++i)
;
}
=

bug.cc: In function 'void foo(A, A)':
bug.cc:11:21: error: expected primary-expression before ';' token
   for (A i = a; i <=; ++i)
 ^
bug.cc:12:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in element_mode, at tree.c:12977
 ;
 ^
0x78a73c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9385
0x7901e2 tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
../../gcc/gcc/tree.h:3511
0x7901e2 element_mode(tree_node const*)
../../gcc/gcc/tree.c:12977
0xe17198 HONOR_NANS(tree_node const*)
../../gcc/gcc/real.c:5095
0xbe8d2c fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:11132
0xbecd0a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:12328
0xbe4155 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:9310
0xc00bec fold(tree_node*)
../../gcc/gcc/fold-const.c:11965
0x86803a cp_fold
../../gcc/gcc/cp/cp-gimplify.c:2280
0x868e0c cp_fold_maybe_rvalue
../../gcc/gcc/cp/cp-gimplify.c:2006
0x9a75f7 handle_omp_for_class_iterator
../../gcc/gcc/cp/semantics.c:7665
0x9a75f7 finish_omp_for(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, vec*, tree_node*)
../../gcc/gcc/cp/semantics.c:8138
0x917251 cp_parser_omp_for_loop
../../gcc/gcc/cp/parser.c:35164
0x93d7d3 cp_parser_omp_for
../../gcc/gcc/cp/parser.c:35362
0x918d34 cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:38080
0x919c27 cp_parser_pragma
../../gcc/gcc/cp/parser.c:38707
0x91c1ec cp_parser_statement
../../gcc/gcc/cp/parser.c:10877
0x91cdc0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91ce97 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11209
0x933610 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21750
Please submit a full bug report, [etc.]

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[neil.n.carlson at gmail dot com]

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

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #2 from Neil Carlson  ---
One of the corrigenda to F2003 (https://wg5-fortran.org/N1801-N1850/N1823.pdf)
added C447a:

"If component-initialization appears, every type parameter and array
bound of the component shall be an initialization expression."

Corresponds to F08:C458, except "initialization" replaces "colon or constant".
Not sure if there is anything significant between the two (probably is).

[Bug c++/84447] New: [8 Regression] ICE with inherited deleted constructor and default argument

[reichelt at gcc dot gnu.org]

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

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

The following invalid code snippet triggers an ICE on trunk:

=
struct A
{
  template A(T, T = 0) = delete;
};

struct B : A
{
  using A::A;
};

B b(0);
=

bug.cc:11:6: internal compiler error: in tsubst_default_argument, at
cp/pt.c:12184
 B b(0);
  ^
0x6384c6 tsubst_default_argument(tree_node*, int, tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:12184
0x819794 convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7336
0x81a708 build_over_call
../../gcc/gcc/cp/call.c:7949
0x81d803 build_new_method_call_1
../../gcc/gcc/cp/call.c:9280
0x81d803 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:9355
0x81e363 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:8883
0x8cc4e3 expand_default_init
../../gcc/gcc/cp/init.c:1889
0x8cc4e3 expand_aggr_init_1
../../gcc/gcc/cp/init.c:2004
0x8cce49 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1744
0x881b5f build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:6188
0x881b5f check_initializer
../../gcc/gcc/cp/decl.c:6337
0x8996cc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7038
0x934883 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19697
0x93bc78 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13038
0x93ca88 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12863
0x9409e2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12761
0x940df1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12637
0x9410e4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x9410e4 c_parse_file()
../../gcc/gcc/cp/parser.c:38860
0xa3f396 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

The regression was introduced between 2017-08-19 and 2017-09-02.

[Bug c++/84446] New: [8 Regression] ICE with broken lambda

[reichelt at gcc dot gnu.org]

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

Bug ID: 84446
   Summary: [8 Regression] ICE with broken lambda
   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 triggers an ICE on trunk:

===
template void foo()
{
  int i,
  i = [] { virtual }();
}
===

bug.cc: In function 'void foo()':
bug.cc:4:3: error: redeclaration of 'int i'
   i = [] { virtual }();
   ^
bug.cc:3:7: note: 'int i' previously declared here
   int i,
   ^
bug.cc: In lambda function:
bug.cc:4:10: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in template_class_depth, at cp/pt.c:394
   i = [] { virtual }();
  ^
0x78a73c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9385
0x635a64 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3255
0x635a64 template_class_depth(tree_node*)
../../gcc/gcc/cp/pt.c:394
0x90b5c7 cp_parser_function_specifier_opt
../../gcc/gcc/cp/parser.c:13744
0x936708 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13502
0x93bae0 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12916
0x93ca88 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12863
0x93d4b9 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12457
0x91be7b cp_parser_statement
../../gcc/gcc/cp/parser.c:10906
0x91cdc0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91d897 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10669
0x91d897 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10176
0x91d897 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5257
0x9301bc cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x930d90 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91117f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x91198a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x913164 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9476
0x9122bb cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:9760
0x9130e7 cp_parser_initializer_clause
../../gcc/gcc/cp/parser.c:21890
Please submit a full bug report, [etc.]

The regression was introduced between 2017-08-19 and 2017-09-02.

[Bug c++/84445] New: ICE with __builtin_launder and virtual function

[reichelt at gcc dot gnu.org]

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

Bug ID: 84445
   Summary: ICE with __builtin_launder and virtual function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following (valid?) code snippet triggers an ICE since GCC 7.1.0:

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

void bar(A* p)
{
  __builtin_launder(p)->foo();
}
=

bug.cc: In function 'void bar(A*)':
bug.cc:8:29: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have pointer_type in lookup_base, at
cp/search.c:195
   __builtin_launder(p)->foo();
 ^
0x78a40a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9335
0x99b71e tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/gcc/tree.h:3172
0x99b71e lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../gcc/gcc/cp/search.c:195
0x847cf4 build_vtbl_ref_1
../../gcc/gcc/cp/class.c:706
0x847d5b build_vfn_ref(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:737
0x81b76f build_over_call
../../gcc/gcc/cp/call.c:8227
0x81d803 build_new_method_call_1
../../gcc/gcc/cp/call.c:9280
0x81d803 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:9355
0x930636 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7207
0x930d90 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91117f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x91198a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x913164 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9476
0x913878 cp_parser_expression
../../gcc/gcc/cp/parser.c:9645
0x915538 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:2
0x91b8ad cp_parser_statement
../../gcc/gcc/cp/parser.c:10916
0x91cdc0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91ce97 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11209
0x933610 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21750
0x933610 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21787
Please submit a full bug report, [etc.]

[Bug c++/84444] New: ICE with __builtin_launder and cast

[reichelt at gcc dot gnu.org]

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

Bug ID: 8
   Summary: ICE with __builtin_launder and cast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following (valid?) code snippet (compiled with "-O") triggers an ICE
since GCC 7.1.0:

=
struct A {};

__SIZE_TYPE__ foo(A* p)
{
  return (__SIZE_TYPE__)__builtin_launder(p);
}
=

bug.cc: In function 'long unsigned int foo(A*)':
bug.cc:5:44: internal compiler error: Segmentation fault
   return (__SIZE_TYPE__)__builtin_launder(p);
^
0xeb0f4f crash_signal
../../gcc/gcc/toplev.c:325
0xa7fc1a builtin_mathfn_code(tree_node const*)
../../gcc/gcc/builtins.c:7840
0xaf0342 convert_to_integer_1
../../gcc/gcc/convert.c:553
0x8702ef ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:822
0x9e2987 cp_build_c_cast(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:7802
0x9e2ada build_c_cast(unsigned int, tree_node*, cp_expr)
../../gcc/gcc/cp/typeck.c:7706
0x911421 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9075
0x91198a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x913164 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9476
0x913878 cp_parser_expression
../../gcc/gcc/cp/parser.c:9645
0x91c01b cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12396
0x91c01b cp_parser_statement
../../gcc/gcc/cp/parser.c:10810
0x91cdc0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91ce97 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11209
0x933610 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21750
0x933610 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21787
0x933ec0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26688
0x934bd7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26604
0x934bd7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19476
0x93bc78 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13038
Please submit a full bug report, [etc.]

[Bug tree-optimization/84443] New: powerpc suboptimal code generation (shrink wrap unlikely path) for Linux spinlocks

[npiggin at gmail dot com]

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

Bug ID: 84443
   Summary: powerpc suboptimal code generation (shrink wrap
unlikely path) for Linux spinlocks
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---

Created attachment 43452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43452=edit
testcase with comment at the top describing desired output

A small fast path code gets several non-volatile registers saved on stack, and
a sub-optimal restore in the return path.

The example is derived from (but not identical to) the Linux kernel spinlock
implementation.

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

[Bug fortran/83898] [6/7 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7181

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |gfc_conv_expr_descriptor,   |gfc_conv_expr_descriptor,
   |at  |at
   |fortran/trans-array.c:7181  |fortran/trans-array.c:7181

--- Comment #5 from Thomas Koenig  ---
Hi Paul,

do you plan to backport?

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Priority|P4  |P3
  Component|fortran |target

--- Comment #15 from Thomas Koenig  ---
(In reply to rsand...@gcc.gnu.org from comment #13)
> I think this is almost certainly a back-end bug, and the same one that
> caused PR83851

Thus, setting to component "target" (and re-setting the priorty to P3).

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
Fixed on gcc 8, no plan to backport.

[Bug c++/70401] [c++1z on mingw]compile variadic template failed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Paolo Carlini  ---
If that’s the case then apparently this got fixed and then regressed, because
back in November I’m pretty sure x86_64-linux was fine. I’ll double check asap.
In the meanwhile, since the release of 8.1.0 is very close, I’m asking Jakub,
as release manager, to have a look at this from that point of view.

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 18 19:19:47 2018
New Revision: 257795

URL: https://gcc.gnu.org/viewcvs?rev=257795=gcc=rev
Log:
2018-02-18  Jerry DeLisle  

PR fortran/84389
* io.c (check_format): Allow FMT_COLON.

* gfortran.dg/dtio_33.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_33.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/84442] New: FAIL: 30_threads/thread/cons/terminate.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 84442
   Summary: FAIL: 30_threads/thread/cons/terminate.cc (test for
excess errors)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-hpux11*
Target: hppa*-*-hpux11*
 Build: hppa*-*-hpux11*

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-8/h
ppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-8/hppa2.0w-hp-hpux11.11/lib/
-isyst
em /opt/gnu/gcc/gcc-8/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-8/
hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -g -O2 -DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc
-pthread -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/filesystem/.libs
-lm -o ./terminate.exe
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc:
In function 'void handle_terminate()':
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc:31:
error: '_Exit' is not a member of 'std'

[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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

--- Comment #3 from vehre at gcc dot gnu.org ---
Created attachment 43451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43451=edit
Preliminary patch

First shot on fixing the issue. At least for caf_get() it fixes the issue.

[Bug c++/70401] [c++1z on mingw]compile variadic template failed

[jyong at gcc dot gnu.org]

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

--- Comment #6 from jyong at gcc dot gnu.org ---
I don't think this is mingw specific, I get the same error on Linux with
gcc-7.3.

g++ -std=c++1z variadic.cpp -o aa

variadic.cpp: In instantiation of ‘std::ostream& operator<<(std::ostream&,
const std::tuple<_Tps ...>&) [with T = {long unsigned int, long unsigned int,
const char*, long unsigned int, const char*, const char*, long unsigned int,
long unsigned int, const char*, const char*, long unsigned int, const char*,
long unsigned int, long unsigned int, const char*, long unsigned int, long
unsigned int, const char*, long unsigned int, const char*}; std::ostream =
std::basic_ostream]’:
variadic.cpp:134:54:   required from here
variadic.cpp:114:7: error: call of overloaded ‘apply(const
operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long unsigned
int, long unsigned int, const char*, long unsigned int, const char*, const
char*, long unsigned int, long unsigned int, const char*, const char*, long
unsigned int, const char*, long unsigned int, long unsigned int, const char*,
long unsigned int, long unsigned int, const char*, long unsigned int, const
char*}; std::ostream = std::basic_ostream]::&,
const std::tuple&)’ is ambiguous
  apply(printer,toprint);
  ~^
variadic.cpp:106:6: note: candidate: auto apply(F&&, Tuple&&) [with F = const
operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long unsigned
int, long unsigned int, const char*, long unsigned int, const char*, const
char*, long unsigned int, long unsigned int, const char*, const char*, long
unsigned int, const char*, long unsigned int, long unsigned int, const char*,
long unsigned int, long unsigned int, const char*, long unsigned int, const
char*}; std::ostream = std::basic_ostream]::&;
Tuple = const std::tuple&]
 auto apply(F&& f, Tuple&& t) {
  ^
In file included from variadic.cpp:2:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/tuple:1668:5: note:
candidate: constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn =
const operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long
unsigned int, long unsigned int, const char*, long unsigned int, const char*,
const char*, long unsigned int, long unsigned int, const char*, const char*,
long unsigned int, const char*, long unsigned int, long unsigned int, const
char*, long unsigned int, long unsigned int, const char*, long unsigned int,
const char*}; std::ostream = std::basic_ostream]::&; _Tuple = const std::tuple&]
 apply(_Fn&& __f, _Tuple&& __t)
 ^
variadic.cpp: In instantiation of ‘std::ostream& operator<<(std::ostream&,
const std::tuple<_Tps ...>&) [with T = {long unsigned int, long unsigned int,
const char*, long unsigned int, const char*, const char*, long unsigned int,
long unsigned int, const char*, const char*, long unsigned int, const char*,
long unsigned int, long unsigned int, const char*, long unsigned int, long
unsigned int, const char*, long unsigned int, const char*, const char*, long
unsigned int, long unsigned int, const char*, const char*, long unsigned int,
const char*, long unsigned int, long unsigned int, const char*, long unsigned
int, long unsigned int, const char*, long unsigned int, const char*, const
char*, long unsigned int, long unsigned int, const char*, const char*, long
unsigned int, const char*, long unsigned int, long unsigned int, const char*,
long unsigned int, long unsigned int, const char*, long unsigned int, const
char*, const char*, long unsigned int, long unsigned int, const char*, const
char*, long unsigned int, const char*, long unsigned int, long unsigned int,
const char*, long unsigned int, long unsigned int, const char*}; std::ostream =
std::basic_ostream]’:
variadic.cpp:135:53:   required from here
variadic.cpp:114:7: error: call of overloaded ‘apply(const
operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long unsigned
int, long unsigned int, const char*, long unsigned int, const char*, const
char*, long unsigned int, long unsigned int, const char*, const char*, long
unsigned int, const char*, long unsigned int, long unsigned int, const char*,
long unsigned int, long unsigned int, const char*, long unsigned int, const
char*, const char*, long unsigned int, long unsigned int, const char*, const
char*, long unsigned int, const char*, long unsigned int, long unsigned int,
const char*, long unsigned int, long unsigned int, const char*, long unsigned
int, const char*, const char*, long unsigned int, long unsigned int, const
char*, const char*, long unsigned int, const char*, long unsigned int, long
unsigned int, const char*, long unsigned int, long unsigned int, const char*,
long unsigned int, const char*, const char*, long unsigned int, long unsigned
int, const char*, const char*, long unsigned int, const char*, long unsigned
int, long unsigned int, const char*, long unsigned int, 

[Bug c++/84441] New: Internal compiler error

[egil.brendsdal at gmail dot com]

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

Bug ID: 84441
   Summary: Internal compiler error
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egil.brendsdal at gmail dot com
  Target Milestone: ---

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

gcc 4.x and gcc 5.x compiles the following snippet, version 6.x and 7.x fails.

The compiler output is

/tmp/bug_report.cpp: In constructor 'derived::derived(int)':
/tmp/bug_report.cpp:15:84: internal compiler error: in assign_temp, at
function.c:968
 ( int n ) : base( n>=0 ? make_base( 1, n ) : make_base( -1, (size_t)0-n ) ) {
}
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccye5Pzm.out file, please attach this to
your bugreport.

+===+

#include 

struct base
{
  typedef std::string string;

  string r;
  inte;
};

base make_base( int, size_t n );

struct derived : public base
{
  derived( int n ) : base( n>=0 ? make_base( 1, n ) : make_base( -1,
(size_t)0-n ) ) { }
};

derived f() { return derived(1); }

[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #21 from dave.anglin at bell dot net ---
On 2018-02-18 11:12 AM, danglin at gcc dot gnu.org wrote:
> // { dg-additional-options "-latomic" { target libatomic_available } }
>
> doesn't work:
The attached hack does work but it depends on the relative placement of 
the libatomic and
libstdc++ directories.

[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin

[dominiq at lps dot ens.fr]

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

--- Comment #29 from Dominique d'Humieres  ---
> How do the remaining failures look like?

Part of them are darwin specific and several have already been reported (see
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEW_status=WAITING_status=ASSIGNED_status=UNCONFIRMED_status=REOPENED=dominiq%40lps.ens.fr_to1=1=1=exact_id=201803).

Another part is also seen on linux (see
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01178.html).

Digging through ~500 failures is no fun and I'll wait for some fixes for the
above.

However I have restore my testing of the gfortran test suite with -g -flto and
I see the following new failures:

FAIL: gfortran.dg/namelist_14.f90   -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_14.f90   -g -flto  (test for excess errors)
FAIL: gfortran.dg/namelist_69.f90   -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_69.f90   -g -flto  (test for excess errors)
FAIL: gfortran.dg/namelist_70.f90   -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_70.f90   -g -flto  (test for excess errors)

all of them of the kind

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/namelist_14.f90: In function 'foo':
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/namelist_14.f90:96: internal compiler
error: in add_dwarf_attr, at dwarf2out.c:4353

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
I muffed the testsuite changelog on the first commit and have fixed that.

This is now fixed on trunk (8) and 7

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 18 16:30:42 2018
New Revision: 257793

URL: https://gcc.gnu.org/viewcvs?rev=257793=gcc=rev
Log:
2018-02-18  Jerry DeLisle  

Backport from trunk
PR libgfortran/84412
* io/transfer.c (finalize_transfer): After completng an internal unit
I/O operation, clear internal_unit_kind.

* gfortran.dg/inquire_18.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/inquire_18.f90
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/transfer.c

[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[danglin at gcc dot gnu.org]

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

--- Comment #20 from John David Anglin  ---
// { dg-additional-options "-latomic" { target libatomic_available } }

doesn't work:

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-8/h
ppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-8/hppa2.0w-hp-hpux11.11/lib/
-isyst
em /opt/gnu/gcc/gcc-8/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-8/
hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/.
/libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -g -O2
-DLOCALEDIR="
." -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3
/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc+
+-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
libatomic_
available10911.c -latomic -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/fil
esystem/.libs -lm -o libatomic_available10911.exe
/usr/ccs/bin/ld: Can't find library: "atomic"
collect2: error: ld returned 1 exit status

In this build, we the following library path:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libatomic/.libs

[Bug libstdc++/84367] [C++11] std::ostringstream stops inserting after multiple call to move assignment operator

[ftingaud at gmail dot com]

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

--- Comment #2 from Frederic Tingaud  ---
I reran the test with GCC 7.3, but got the same error:

#include 
#include 
#include 

int test()
{
   std::ostringstream oss;
   std::cerr << "\nRunning with GCC v" << __GNUC__ << "." << __GNUC_MINOR__ <<
"." << __GNUC_PATCHLEVEL__ << " - libc++=" << __GLIBCXX__ << std::endl;
   for (int i = 0; i < 100; ++i) {
  oss << "abc";
  std::cerr << i << " ";
  assert(oss.str() == "abc");
  oss = std::ostringstream();
   }
   return 0;
}

output:

Running with GCC v7.3.0 - libc++=20180125
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 
file.cpp:13: int test(): Assertion `oss.str() == "abc"' failed.
Aborted

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 18 15:32:39 2018
New Revision: 257791

URL: https://gcc.gnu.org/viewcvs?rev=257791=gcc=rev
Log:
2018-02-18  Jerry DeLisle  

PR libgfortran/84412
* io/transfer.c (finalize_transfer): After completng an internal unit
I/O operation, clear internal_unit_kind.

Added:
trunk/gcc/testsuite/gfortran.dg/inquire_18.f90
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug driver/84440] New: unrecognized command line option '-Wno-format-invalid-specifier'

[stsp at users dot sourceforge.net]

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

Bug ID: 84440
   Summary: unrecognized command line option
'-Wno-format-invalid-specifier'
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

Format attribute is usually used with
the custom printf-alike funcs. It is not
unusual for those funcs to implement more
format specifiers than printf() does.
clang has '-Wno-format-invalid-specifier'
to avoid checking those, and only check
the printf-compatible subset. But gcc
only says this:
---
cc1: warning: unrecognized command line option '-Wno-format-invalid-specifier'
---

Would be nice to have this option, as
it increases the usability of the
format-checking attributes. Plus the
better compatibility with clang.

[Bug libfortran/84439] call to backtrace fails after about 6000 iterations (32-bit executable)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin17 I get

...
9 calls to backtrace()
#0  0x16919f
#1  0x1691b9
#2  0x3ad0f
#3  0x3ac7a
#4  0x3ac5e
#5  0x3ac42
#6  0x3ac26
#7  0x3ad57
#8  0x3ad9f
* calls to backtrace()

[Bug libfortran/84439] New: call to backtrace fails after about 6000 iterations (32-bit executable)

[kapfell at gmx dot de]

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

Bug ID: 84439
   Summary: call to backtrace fails after about 6000 iterations
(32-bit executable)
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kapfell at gmx dot de
  Target Milestone: ---

Created attachment 43448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43448=edit
Test calling backtrace() repeatedly, fails after about 5600 iteration (32-bit
executable)

There appears to be a memory leak in backtrace(). At about 5500 iterations mmap
complains about insufficient memory and stack trace no longer shows function
names:

[...]
#0  0xf7667245 in ???
#1  0xf7667289 in ???
#2  0x804874b in fun5_
at [...]/gf_backtrace.f:44
#3  0x80486c6 in fun4_
at [...]/gf_backtrace.f:37
#4  0x80486b3 in fun3_
at [...]/gf_backtrace.f:31
#5  0x80486a0 in fun2_
at [...]/gf_backtrace.f:25
#6  0x804868d in fun1_
at [...]/gf_backtrace.f:19
#7  0x804877b in testbacktrace
at [...]/gf_backtrace.f:12
#8  0x80487ce in main
at [...]/gf_backtrace.f:14
 5696 calls to backtrace()
Could not print backtrace: mmap: Cannot allocate memory
#0  0xf7633273
#1  0xf7633289
#2  0x80487bd
#3  0x804871a
#4  0x80486f2
#5  0x80486ca
#6  0x80486a2
#7  0x8048802
#8  0x8048855
#9  0xf73c0672
#10  0x80485a0
[fun5 (  46)]  5697 calls to backtrace()
[...]

System: OpenSUSE 42.3, x86_64, kernel 4.4.114. Test program is attached, 
compile with :
  gfortran -m32 -o bug-report-backtrace -g -Wall -Wextra -std=gnu
bug-report-backtrace.f

Thanks

[Bug target/84438] New: Another code pattern that breaks PDP11 with -m10: including reproducer code

[etchedpixels at gmail dot com]

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

Bug ID: 84438
   Summary: Another code pattern that breaks PDP11 with -m10:
including reproducer code
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etchedpixels at gmail dot com
  Target Milestone: ---

Created attachment 43447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43447=edit
Example showing the bug

The attached function blows up the compiler with -m10

(gcc 7.3.0 pdp11-aout host is linux 64bit)

tmp/5.c: In function ‘div10quickm’:
/tmp/5.c:18:1: error: unrecognizable insn:
 }
 ^
(insn 11 10 12 2 (set (reg:SI 23 [ _2 ])
(ashift:SI (reg:SI 23 [ _2 ])
(const_int -1 [0x]))) "/tmp/5.c":7 -1
 (expr_list:REG_EQUAL (lshiftrt:SI (reg:SI 37)
(const_int 2 [0x2]))
(nil)))
/tmp/5.c:18:1: internal compiler error: in extract_insn, at recog.c:2311
0x8d8b48 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-7.3.0/gcc/rtl-error.c:108
0x8d8b79 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-7.3.0/gcc/rtl-error.c:116
0x8ae40f extract_insn(rtx_insn*)
../../gcc-7.3.0/gcc/recog.c:2311
0x6fe3f3 instantiate_virtual_regs_in_insn
../../gcc-7.3.0/gcc/function.c:1589
0x6fe3f3 instantiate_virtual_regs
../../gcc-7.3.0/gcc/function.c:1957
0x6fe3f3 execute
../../gcc-7.3.0/gcc/function.c:2006

[Bug target/84437] New: long long casting breaks PDP-11 with -m10 model option (includes trivial reproducer)

[etchedpixels at gmail dot com]

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

Bug ID: 84437
   Summary: long long casting breaks PDP-11 with -m10 model option
(includes trivial reproducer)
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etchedpixels at gmail dot com
  Target Milestone: ---

long long x(int y)
{
return y;
}


pdp11-aout-gcc -m10 -S /tmp/3.c
/tmp/3.c: In function ‘x’:
/tmp/3.c:4:1: error: unrecognizable insn:
 }
 ^
(insn 7 6 8 2 (set (reg:HI 24)
(ashift:HI (reg:HI 23)
(const_int -15 [0xfff1]))) "/tmp/3.c":3 -1
 (nil))
/tmp/3.c:4:1: internal compiler error: in extract_insn, at recog.c:2311
0x8d8b48 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-7.3.0/gcc/rtl-error.c:108
0x8d8b79 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-7.3.0/gcc/rtl-error.c:116
0x8ae40f extract_insn(rtx_insn*)
../../gcc-7.3.0/gcc/recog.c:2311
0x6fe3f3 instantiate_virtual_regs_in_insn
../../gcc-7.3.0/gcc/function.c:1589
0x6fe3f3 instantiate_virtual_regs
../../gcc-7.3.0/gcc/function.c:1957
0x6fe3f3 execute
../../gcc-7.3.0/gcc/function.c:2006

[Bug c++/84436] New: Missed optimization with switch on enum constants returning the same value

[mferoldif at gmail dot com]

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

Bug ID: 84436
   Summary: Missed optimization with switch on enum constants
returning the same value
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mferoldif at gmail dot com
  Target Milestone: ---

The following snippet:

enum class E
{
A, B, C,
};

int foo(E e)
{
switch (e)
{
case E::A: return 0;
case E::B: return 1;
case E::C: return 2;
}
}

Produces the following ineffective code:

foo(E):
  cmp edi, 1
  mov eax, 1
  je .L1
  cmp edi, 2
  mov eax, 2
  je .L1
  xor eax, eax
.L1:
  rep ret

There is no reason why it should not produce a single `mov eax, edi`
and ret instruction.

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Feb 18 12:29:09 2018
New Revision: 257789

URL: https://gcc.gnu.org/viewcvs?rev=257789=gcc=rev
Log:
2018-02-18  Janus Weil  

PR fortran/84381
* gfortran.dg/io_real_boz2.f90: Remove option "-fall-intrinsics".
* gfortran.dg/pointer_intent_3.f90: Ditto.
* gfortran.dg/proc_ptr_common_1.f90: Ditto.
* gfortran.dg/protected_3.f90: Ditto.
* gfortran.dg/protected_4.f90: Ditto.
* gfortran.dg/protected_5.f90: Ditto.
* gfortran.dg/protected_6.f90: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/io_real_boz2.f90
trunk/gcc/testsuite/gfortran.dg/pointer_intent_3.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90
trunk/gcc/testsuite/gfortran.dg/protected_3.f90
trunk/gcc/testsuite/gfortran.dg/protected_4.f90
trunk/gcc/testsuite/gfortran.dg/protected_5.f90
trunk/gcc/testsuite/gfortran.dg/protected_6.f90

[Bug c++/84435] New: -Wliteral-suffix warns on a using-directive

[mferoldif at gmail dot com]

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

Bug ID: 84435
   Summary: -Wliteral-suffix warns on a using-directive
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mferoldif at gmail dot com
  Target Milestone: ---

The following brief snippet wrongly triggers `-Wliteral-suffix`:

#include 
using std::string_literals::operator""s;

GCC 7.3.0's output:

:2:37: warning: literal operator suffixes not preceded by '_' are
reserved for future standardization [-Wliteral-suffix]
 using std::string_literals::operator""s;
 ^~~

[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||aaro.koskinen at iki dot fi

--- Comment #13 from Eric Botcazou  ---
*** Bug 67899 has been marked as a duplicate of this bug. ***

[Bug sanitizer/67899] build failure in the sanitizer libs on sparc-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #9 from Eric Botcazou  ---
Fixed a while ago.

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

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
I can confirm that gamess is fixed. In addition tonto's regression from earlier
cost tuning was fixed as well. There is nice improvement to galgel
(15400->15800) which is not fixing earlier regression and apsi (4580->4680)

Zhere is small regression on zeusmp (39.6->39). Apsi is not on best score so
far.
There is also a noticeable code size reduction.
So it looks really good!

>From spec2000 we stll have mgrid, facerec and fma3d. facerec is related to code
size as it went up and down 19% during inliner tuning. It is not up with final
values and may be worth to investigate it.

tfft of polyhedron is aslso still regressing. Martin, perhaps you can bisect
that one as it seems most consistent?

Honza

[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #1 from Marek Polacek  ---
Started with r252005.

The ICE goes away if I remove "~scope_guard();".

[Bug c++/84434] New: [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp

[mpolacek at gcc dot gnu.org]

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

Bug ID: 84434
   Summary: [8 Regression] internal compiler error: tree check:
expected var_decl or field_decl or function_decl or
type_decl or template_decl, have using_decl in
build_deduction_guide, at cp/pt.c:25636
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

namespace std {
template  using decay_t = _Tp;
template  class optional {};
} // namespace std

class RiskAnalysis {
  struct Context;
  void RunAnalysis(std::optional) noexcept;
};
namespace ext {
namespace detail::scope_guard {
template  class A {
  Fn m_fn;

public:
  template  A(Fn_ p1) : m_fn(p1) {}
};
template  class B {
  using callback_type = scope_guard::A;
  callback_type callback;

public:
  template  B(Params_... p1) : callback(p1...) {}
};
template  struct C { using type = T; };
template  using unwrap_decay_t = typename C::type;
} // namespace detail::scope_guard
template 
struct scope_guard : detail::scope_guard::B {
  using base_type = detail::scope_guard::B;
  using base_type::base_type;
  ~scope_guard();
};
template 
scope_guard(Params...)
->scope_guard;
} // namespace ext

void RiskAnalysis::RunAnalysis(std::optional) noexcept {
  ext::scope_guard([] {});
}

$ ./cc1plus -quiet bz.cc -std=c++17
bz.cc: In member function ‘void
RiskAnalysis::RunAnalysis(std::optional)’:
bz.cc:40:25: internal compiler error: tree check: expected var_decl or
field_decl or function_decl or type_decl or template_decl, have using_decl in
build_deduction_guide, at cp/pt.c:25636
   ext::scope_guard([] {});
 ^
0x15d5158 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marek/src/gcc/gcc/tree.c:9335
0x82674b tree_check5(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code, tree_code)
/home/marek/src/gcc/gcc/tree.h:3223
0xa71f40 build_deduction_guide
/home/marek/src/gcc/gcc/cp/pt.c:25636
0xa74140 do_class_deduction
/home/marek/src/gcc/gcc/cp/pt.c:25850
0xa74955 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/marek/src/gcc/gcc/cp/pt.c:25978
0xb110d1 build_functional_cast(tree_node*, tree_node*, int)
/home/marek/src/gcc/gcc/cp/typeck2.c:2088
0x9cefcb cp_parser_functional_cast
/home/marek/src/gcc/gcc/cp/parser.c:27250
0x9a6287 cp_parser_postfix_expression
/home/marek/src/gcc/gcc/cp/parser.c:6952
0x9a9b63 cp_parser_unary_expression
/home/marek/src/gcc/gcc/cp/parser.c:8318
0x9aac7f cp_parser_cast_expression
/home/marek/src/gcc/gcc/cp/parser.c:9086
0x9aad79 cp_parser_binary_expression
/home/marek/src/gcc/gcc/cp/parser.c:9187
0x9abad7 cp_parser_assignment_expression
/home/marek/src/gcc/gcc/cp/parser.c:9476
0x9abe74 cp_parser_expression
/home/marek/src/gcc/gcc/cp/parser.c:9645
0x9aefee cp_parser_expression_statement
/home/marek/src/gcc/gcc/cp/parser.c:2
0x9ae8fb cp_parser_statement
/home/marek/src/gcc/gcc/cp/parser.c:10916
0x9af64d cp_parser_statement_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:11255
0x9af543 cp_parser_compound_statement
/home/marek/src/gcc/gcc/cp/parser.c:11209
0x9c3eaa cp_parser_function_body
/home/marek/src/gcc/gcc/cp/parser.c:21750
0x9c416d cp_parser_ctor_initializer_opt_and_function_body
/home/marek/src/gcc/gcc/cp/parser.c:21787
0x9cdad1 cp_parser_function_definition_after_declarator
/home/marek/src/gcc/gcc/cp/parser.c:26688
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Sun Feb 18 08:59:06 2018
New Revision: 257788

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

PR fortran/80945
* trans-array.c (gfc_conv_expr_descriptor): Set parmtype from
the typenode in the case of deferred length characters.

2018-02-18  Paul Thomas  

PR fortran/80945
* gfortran.dg/associate_35.f90: Remove error, add stop n's and
change to run.


Added:
trunk/gcc/testsuite/gfortran.dg/deferred_character_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog