[Bug c++/89994] New: [8 Regression] ICE (segfault) in compare_ics
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 c++/89994] [8 Regression] ICE (segfault) in compare_ics
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 fortran/79842] i18n: subword translation in "Can't use the same %smodule"
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 fortran/82055] segfault compiling F2003 functionality
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/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
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 c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w
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
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/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
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&root=gcc&view=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 fortran/89981] [8 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
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/79842] i18n: subword translation in "Can't use the same %smodule"
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 rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case
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 c++/89995] New: Misleading error message 'this' was not captured for this lambda function
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 fortran/57262] Optimize bound intrinsics with dim=var for rank one arrays
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 middle-end/89996] New: [avr] ICE in expand_expr_real_2 with -O3
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 c
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
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 fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
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&root=gcc&view=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 c++/89997] New: Garbled expression in error message with -fconcepts
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 rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
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 target/88839] [SVE] Poor implementation of blend-like permutes
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 c/448] -related issues (C99 issues)
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
