[Bug c/448] -related issues (C99 issues)

2019-04-06 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448

Eric Gallager  changed:

   What|Removed |Added

 Target|netbsd, VxWorks, SymbianOS, |netbsd, SymbianOS, LynxOS,
   |LynxOS, QNX, TPF|QNX, TPF

--- Comment #42 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #40)
> The definitions have been added for VxWorks at some point.

(In reply to hain...@adacore.com from comment #41)
> > On 2 Jan 2019, at 23:33, joseph at codesourcery dot com 
> >  wrote:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
> > 
> > --- Comment #40 from joseph at codesourcery dot com  > dot com> ---
> > The definitions have been added for VxWorks at some point.
> 
> Yes, https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00761.html
> I think.

OK, removing it from the list of targets then

[Bug target/88839] [SVE] Poor implementation of blend-like permutes

2019-04-06 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88839

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Fix committed to sve-acle-branch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2cd1f397ed5a155e74719977823b28777caa8312


Thanks,
Prathamesh

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

2019-04-06 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763

--- Comment #42 from Segher Boessenkool  ---
The "movk" failures...  This is from insv_1.c:

Trying 7, 6 -> 8:
7: r95:DI=0x1d6b
6: r93:DI=r97:DI&0x
  REG_DEAD r97:DI
8: r94:DI=r93:DI|r95:DI
  REG_DEAD r95:DI
  REG_DEAD r93:DI
  REG_EQUAL r93:DI|0x1d6b
Failed to match this instruction:
(set (reg:DI 94)
(ior:DI (and:DI (reg:DI 97)
(const_int -281470681743361 [0x]))
(const_int 32345398706176 [0x1d6b])))
Successfully matched this instruction:
(set (reg:DI 95)
(and:DI (reg:DI 97)
(const_int -281470681743361 [0x])))
Failed to match this instruction:
(set (reg:DI 94)
(ior:DI (reg:DI 95)
(const_int 32345398706176 [0x1d6b])))

It should have matched what it originally cam up with, afaics?  This is
exactly what movk does?  (Don't rely on the input and output regs to agree,
like with insv; that only happens by chance.  Instead, use separate operands,
with "0" constraint, etc.)

[Bug c++/89997] New: Garbled expression in error message with -fconcepts

2019-04-06 Thread redbeard0531 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997

Bug ID: 89997
   Summary: Garbled expression in error message with -fconcepts
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

Usually -fconcepts delivers excellent error messages, but this one is pretty
bad. It looks like this goes back to 6.2, when it first started to show the
expression.

https://godbolt.org/z/m9DlOZ

struct Y;

struct X {
Y operator<< (const char*);
};

struct Y {
X operator<< (void*);
};

template 
void check() requires requires (X x, T val) { x << "hello" << val; } {}

void test() {
check(); // no error
check(); // mangled error
}

-

: In function 'void test()':
:16:16: error: cannot call function 'void check() requires (> [with T =
int]'
   16 | check(); // mangled error
  |^
:12:6: note:   constraints not satisfied
   12 | void check() requires requires (X x, T val) { x << "hello" << val; } {}
  |  ^
:12:6: note: with 'X x'
:12:6: note: with 'int val'
:12:6: note: the required expression '("hello"->x.X::operator<<() <<
val)' would be ill-formed


What is that expression? How did it end up applying -> to a string literal!?

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-06 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Apr  6 22:10:28 2019
New Revision: 270184

URL: https://gcc.gnu.org/viewcvs?rev=270184=gcc=rev
Log:
2019-04-06  Thomas Koenig  

PR fortran/87352
* gfortran.h (gfc_component): Add finalized field.
* class.c (finalize_component): If the component is already
finalized, return early.  Set component->finalized on exit.

2019-04-06  Thomas Koenig  

PR fortran/87352
* gfortran.dg/finalize_28.f90: Adjust count of __builtin_free.
* gfortran.dg/finalize_33.f90: Likewise.
* gfortran.dg/finalize_34.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/finalize_34.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/finalize_28.f90
trunk/gcc/testsuite/gfortran.dg/finalize_33.f90

[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming

2019-04-06 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459

Marc Glisse  changed:

   What|Removed |Added

Summary|[8/9 Regression] Larger |[8 Regression] Larger code
   |code generated from GMP |generated from GMP template
   |template meta-programming   |meta-programming

--- Comment #11 from Marc Glisse  ---
Seems fixed on trunk.

[Bug middle-end/89996] New: [avr] ICE in expand_expr_real_2 with -O3

2019-04-06 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996

Bug ID: 89996
   Summary: [avr] ICE in expand_expr_real_2 with -O3
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

The following fails with GCC 8.2 and 8.3 on AVR. The below output is from 8.3:

# avr-gcc -v -O3 -mmcu=atmega1284p -c test2.c -o test2.o
Using built-in specs.
Reading specs from
/usr/local/avr/lib/gcc/avr/8.3.0/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 8.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3'  '-c' '-o' 'test2.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/8.3.0/cc1 -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p test2.c -mn-flash=2
-mno-skip-bug -quiet -dumpbase test2.c -mmcu=avr51 -auxbase-strip test2.o -O3
-version -o /tmp/ccYds885.s
GNU C17 (GCC) version 8.3.0 (avr)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/8.3.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/8.3.0/include
 /usr/local/avr/lib/gcc/avr/8.3.0/include-fixed
 /usr/local/avr/lib/gcc/avr/8.3.0/../../../../avr/include
End of search list.
GNU C17 (GCC) version 8.3.0 (avr)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e17ca263eb8b0996b4ab7dcf63f27ece
during RTL pass: expand
test2.c: In function 'send_document.isra.0.constprop':
test2.c:33:11: internal compiler error: in expand_expr_real_2, at expr.c:8573
0x51269b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8573
0x70e9a0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9968
0x71c001 expand_expr
../../gcc/expr.h:280
0x71c001 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8575
0x70e9a0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9968
0x6195f1 expand_normal
../../gcc/expr.h:286
0x6195f1 precompute_register_parameters
../../gcc/calls.c:989
0x6195f1 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4127
0x70e2e6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11050
0x71734b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5651
0x718189 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5419
0x718189 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:4954
0x626e38 expand_call_stmt
../../gcc/cfgexpand.c:2702
0x626e38 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3638
0x626e38 expand_gimple_stmt
../../gcc/cfgexpand.c:3804
0x628c4f expand_gimple_basic_block
../../gcc/cfgexpand.c:5833
0x62dcc6 execute
../../gcc/cfgexpand.c:6439
Please submit a full bug report.



Code to reproduce:

extern char *strrchr(const char *, int) __attribute__((__pure__));
extern int strcasecmp_P(const char *, const char *) __attribute__((__pure__));

static const struct {
  char ext[5];
  const char __flash *desc;
  _Bool subst;
} __flash mime_types[]={
  {"txt", ((const char __flash []){("text/plain; charset=utf-8")}), 1},
  {"html", ((const char __flash []){("text/html; charset=utf-8")}), 1},
  {"htm", ((const char __flash []){("text/html; charset=utf-8")}), 1},
};

struct http {
  char uri[128];
  _Bool sendfile_subst;
};

typedef struct {
  unsigned char user[sizeof(struct http)];
} DESC;

static void send_document(DESC *d, short err, const char __flash *err_string,
  const char *file, _Bool conn_close)
{
  struct http *hd=(void *)d->user;
  const char *ext;
  unsigned char i;
  _Bool subst=0;

  if((ext=strrchr(file, '.'))) {
for(i=0;i < (int)(sizeof(mime_types)/sizeof(mime_types[0]));i++)
  if(!strcasecmp_P(ext, mime_types[i].ext)) {
subst=mime_types[i].subst;
break;
  }
  }

  hd->sendfile_subst=subst;
}

static void http_do_uri_request(DESC *d)
{
  struct http *hd=(void *)d->user;
  char *uri=hd->uri;

  if(*uri != '/') {
send_document(d, 400, ({ static const 

[Bug fortran/57262] Optimize bound intrinsics with dim=var for rank one arrays

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57262

--- Comment #4 from Dominique d'Humieres  ---
> Not convinced, but let me move it to NEW.

More than three years later I am still not convince that such nano-optimisation
has any interest. What about closing this PR as WONTFIX.

[Bug c++/89995] New: Misleading error message 'this' was not captured for this lambda function

2019-04-06 Thread gabriel.aubut-lussier at outlook dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89995

Bug ID: 89995
   Summary: Misleading error message 'this' was not captured for
this lambda function
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel.aubut-lussier at outlook dot com
  Target Milestone: ---

The error message given when 'this' cannot be captured is misleading in the
sense that it points the user to the lambda that fails to capture 'this' rather
than raise questions about why it fails to do so.

The icc compiler does the best job of giving context with this error. MSVC also
displays a bit more information. Clang has the worst offender. GCC could use a
bit of improvement. Aiming for an error message that is closer to icc seems
like the ideal solution. The error message given by icc is the following:
error: this enclosing-function local variable cannot be referenced in this
lambda body because an enclosing lambda does not allow implicit captures

Godbolt : https://gcc.godbolt.org/z/rmefHT
Sample code for the issue:

struct S
{
void f() {
[]() {
[this]() {

}();
}();
}
};

int main()
{
S s;
s.f();
}

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960

--- Comment #20 from Dominique d'Humieres  ---
Updated timings

% gfc6 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report
...
 combiner:  81.12 (55%) usr   1.17 (41%) sys  82.31 (54%) wall
2700699 kB (60%) ggc
...
 TOTAL : 148.83 2.87   151.88   
4503753 kB
% gfc7 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report
...
 combiner: 153.49 (67%) usr   1.64 (44%) sys 155.24 (67%) wall
2700699 kB (60%) ggc
...
 TOTAL : 228.22 3.77   232.32   
4508399 kB
% gfc8 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report
...
 combiner   : 427.57 ( 85%)   2.17 ( 53%) 430.01 ( 84%)
2700709 kB ( 60%)
...
 TOTAL  : 505.59  4.06510.13   
4499127 kB
% gfcp -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report
...
 combiner   : 426.78 ( 85%)   1.55 ( 47%) 428.43 ( 85%)
2700713 kB ( 60%)
...
 TOTAL  : 502.36  3.31505.81   
4501068 kB

[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842

--- Comment #5 from Dominique d'Humieres  ---
The patch in comment 4 does not bootstrap:

../../work/gcc/fortran/module.c: In function 'void
gfc_use_module(gfc_use_list*)':
../../work/gcc/fortran/module.c:7145:8: error: suggest explicit braces to avoid
ambiguous 'else' [-Werror=dangling-else]
 7145 | if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
  |^
cc1plus: all warnings being treated as errors

This one does

--- ../_clean/gcc/fortran/module.c  2019-03-21 20:46:46.0 +0100
+++ gcc/fortran/module.c2019-04-06 16:39:02.0 +0200
@@ -7144,8 +7144,12 @@ gfc_use_module (gfc_use_list *module)
   for (p = gfc_state_stack; p; p = p->previous)
 if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
 && strcmp (p->sym->name, module_name) == 0)
-  gfc_fatal_error ("Cannot USE the same %smodule we're building",
-  p->state == COMP_SUBMODULE ? "sub" : "");
+  {
+   if (p->state == COMP_SUBMODULE)
+ gfc_fatal_error ("Cannot USE a submodule that is currently built");
+   else
+ gfc_fatal_error ("Cannot USE a module that is currently built");
+  }

   init_pi_tree ();
   init_true_name_tree ();

[Bug fortran/89981] [8 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0

2019-04-06 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981

Thomas Koenig  changed:

   What|Removed |Added

Summary|[8/9 Regression] gfortran   |[8 Regression] gfortran
   |-pedantic rejects code in   |-pedantic rejects code in
   |8.3.1 that is accepted with |8.3.1 that is accepted with
   |8.3.0   |8.3.0

--- Comment #5 from Thomas Koenig  ---
Fixed on trunk so far.

[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0

2019-04-06 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Apr  6 14:16:01 2019
New Revision: 270182

URL: https://gcc.gnu.org/viewcvs?rev=270182=gcc=rev
Log:
2019-04-06  Thomas Koenig  

PR fortran/89981
* resolve.c (resolve_global_procedure): If the global symbol is an
ENTRY, also look up its name among the entries.

2019-04-06  Thomas Koenig  

PR fortran/89981
* gfortran.dg/entry_22.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/entry_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w

2019-04-06 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> since the issue of calls to inform being done without checking the return
> value of warning[_at] first seems to keep coming up, I almost wonder if it's
> worth adding __attribute__((unused_result)) to warning[_at]...

er __attribute__((warn_unused_result)) I mean

[Bug c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w

2019-04-06 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
since the issue of calls to inform being done without checking the return value
of warning[_at] first seems to keep coming up, I almost wonder if it's worth
adding __attribute__((unused_result)) to warning[_at]...

[Bug fortran/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||janus at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
> What is allocate supposed to do if the array and the mold are not
> conformable?

No answer after more than six years!-(Shall I close the PR as INVALID to get
one?).

[Bug fortran/82055] segfault compiling F2003 functionality

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82055

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|segfault compiling F2003|segfault compiling F2003
   |functionality:  4.9.3,  |functionality
   |5.3.0 and 6.3.0 |

--- Comment #5 from Dominique d'Humieres  ---
Compiling the test with my recent instrumented compiler (9.0) gives

../../work/gcc/tree.h:3289:28: runtime error: member access within null pointer
of type 'union tree_node'

thus I have removed the references to unsupported versions.

[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #4 from Dominique d'Humieres  ---
Updated patch I am planning to commit

--- ../_clean/gcc/fortran/module.c  2019-03-21 20:46:46.0 +0100
+++ gcc/fortran/module.c2019-04-06 12:40:17.0 +0200
@@ -7144,8 +7144,10 @@ gfc_use_module (gfc_use_list *module)
   for (p = gfc_state_stack; p; p = p->previous)
 if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
 && strcmp (p->sym->name, module_name) == 0)
-  gfc_fatal_error ("Cannot USE the same %smodule we're building",
-  p->state == COMP_SUBMODULE ? "sub" : "");
+  if (p->state == COMP_SUBMODULE)
+gfc_fatal_error ("Cannot USE a submodule that is currently built");
+  else
+gfc_fatal_error ("Cannot USE a module that is currently built");

   init_pi_tree ();
   init_true_name_tree ();

AFAICT the errors are not covered by the test suite.

[Bug c++/89994] [8 Regression] ICE (segfault) in compare_ics

2019-04-06 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89994

Matthias Klose  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to work||7.4.1, 9.0
  Known to fail||8.3.1

--- Comment #1 from Matthias Klose  ---
works on the gcc-7 branch and the trunk, ICEs on the gcc-8-branch.

[Bug c++/89994] New: [8 Regression] ICE (segfault) in compare_ics

2019-04-06 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89994

Bug ID: 89994
   Summary: [8 Regression] ICE (segfault) in compare_ics
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

$ cat test.ii
template  class a;
namespace b {
template  class b;
template  struct c;
template 
struct c> {
  using e = typename c>>::e;
};
template 
struct c<0, b> {
  using e = b;
};
template  class baseclass, int g, int h,
  typename i, typename... j>
class b, j...> {
  b(long);
  b(const long (&)[]);
};
} // namespace b
template 
using blaspp = typename b::c>::e;
blaspp<1> k({4})

$ g++ -c test.ii 
test.ii:23:16: internal compiler error: Segmentation fault
 blaspp<1> k({4})
^
0x8a0698 crash_signal
../../src/gcc/toplev.c:325
0x5aa51e compare_ics
../../src/gcc/cp/call.c:9684
0xe8cbe1 joust
../../src/gcc/cp/call.c:10124
0xe8a7f6 tourney
../../src/gcc/cp/call.c:10526
0xe8a7f6 build_new_method_call_1
../../src/gcc/cp/call.c:9295
0xe8a7f6 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:9462
0xe8a7f6 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:8989
0xede19b expand_default_init
../../src/gcc/cp/init.c:1906
0xede19b expand_aggr_init_1
../../src/gcc/cp/init.c:2021
0xede19b build_aggr_init(tree_node*, tree_node*, int, int)
../../src/gcc/cp/init.c:1761
0xec44b8 build_aggr_init_full_exprs
../../src/gcc/cp/decl.c:6292
0xec44b8 check_initializer
../../src/gcc/cp/decl.c:6441
0xec2cbf cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../src/gcc/cp/decl.c:7154
0xf03597 cp_parser_init_declarator
../../src/gcc/cp/parser.c:19819
0xefec29 cp_parser_simple_declaration
../../src/gcc/cp/parser.c:13058
0xefe415 cp_parser_block_declaration
../../src/gcc/cp/parser.c:12877
0xefd737 cp_parser_declaration
../../src/gcc/cp/parser.c:12775
0xefd54a cp_parser_declaration_seq_opt
../../src/gcc/cp/parser.c:12651
0x14ba85b cp_parser_translation_unit
../../src/gcc/cp/parser.c:4563
0x14ba85b c_parse_file()
../../src/gcc/cp/parser.c:39118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

$ g++-7 -c test.ii 
test.ii:18:21: error: parameter '' includes reference to array of
unknown bound 'const long int []'
   b(const long (&)[]);
 ^
test.ii:23: confused by earlier errors, bailing out

$ g++-9 -c test.ii 
test.ii:23:16: error: call of overloaded 'b()'
is ambiguous
   23 | blaspp<1> k({4})
  |^
test.ii:18:3: note: candidate: 'b::b, j
...>::b(const long int (&)[]) [with l = double; long unsigned int f = 1;
baseclass = a; int g = 0; int h = 1; i = void; j = {}]'
   18 |   b(const long (&)[]);
  |   ^
test.ii:17:3: note: candidate: 'b::b, j
...>::b(long int) [with l = double; long unsigned int f = 1; baseclass = a; int
g = 0; int h = 1; i = void; j = {}]'
   17 |   b(long);
  |   ^
test.ii:16:7: note: candidate: 'constexpr b::b >::b(const b::b >&)'
   16 | class b, j...> {
  |   ^
test.ii:16:7: note: candidate: 'constexpr b::b >::b(b::b >&&)'
test.ii:23:16: error: expected ',' or ';' at end of input
   23 | blaspp<1> k({4})
  |^

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

2019-04-06 Thread t.sprodowski at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991

--- Comment #3 from t.sprodowski at web dot de ---
Octave 4.2.2: ans = 2.6284e-20 + 4.2924e-04i