[Bug target/69576] New: tailcall could use a conditional branch on x86, but doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69576
Bug ID: 69576
Summary: tailcall could use a conditional branch on x86, but
doesn't
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Target: i386-*, x86_64-*
In x86, both jmp and jcc can use either a rel8 or rel32 displacement. Unless
I'm misunderstanding something, the rel32 displacement in a jcc can be
relocated at link time identically to the way the rel32 in a jmp can be.
void ext(void);
void foo(int x) {
if (x > 10) ext();
}
compiles to (gcc 5.3 -O3 -mtune=haswell)
cmpl$10, %edi
jg .L4
ret
.L4:
jmp ext
Is this a missed optimization, or is there some reason gcc must avoid
conditional branches for tail-calls that makes this not a bug? This sequence
is clearly better, if it's safe:
cmpl$10, %edi
jg ext
ret
If targeting a CPU which statically predicts unknown forward branches as
not-taken, and you can statically predict the tail-call as strongly taken, then
it could make sense to use clang 3.7.1's sequence:
cmpl$11, %edi
jl .LBB0_1
jmp ext # TAILCALL
.LBB0_1:
retq
According to Agner Fog's microarch guide, AMD CPUs use this static prediction
strategy, but Pentium M / Core2 assign a BTB entry and use whatever prediction
was in that entry already. He doesn't specifically mention static prediction
for later Intel CPUs, but they're probably similar. (So using clang's
sequence only helps on (some?) AMD CPUs, even if the call to ext() always
happens.)
AFAICT, gcc's sequence has no advantages in any case.
Note that the code for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69569
demonstrates this bug as well, but is a separate issue. It's pure coincidence
that I noticed this the day after that bug was filed.
[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553
--- Comment #6 from Markus Trippelsdorf ---
markus@x4 tmp % cat array.ii
template struct A {
typedef _Tp _Type[_Nm];
static _Tp &_S_ref(const _Type &p1, int p2) {
return const_cast<_Tp &>(p1[p2]);
}
};
template struct B {
typedef A<_Tp, _Nm> _AT_Type;
typename _AT_Type::_Type _M_elems;
_Tp &operator[](long p1) const { return _AT_Type::_S_ref(_M_elems, p1); }
};
int t;
void foo(int p1, int &p2) {
if ((t & 1) == 0) {
if (p1 != 1)
__builtin_abort();
if (p2 != 2)
__builtin_abort();
}
t++;
}
__attribute__((noinline))
void test1(const B &p1) { foo(p1[0], p1[1]); }
void test(B, 2> &p1) {
test1(p1[0]);
test1(p1[1]);
foo(p1[0][0], p1[0][1]);
}
int main() {
B, 2> t;
t[0][0] = 1;
t[0][1] = 2;
test(t);
}
[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564 --- Comment #4 from Paul Thomas --- Created attachment 37530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37530&action=edit Patch to be committed For whatever reason that I cannot uncover, the part of the original patch in trans-array.c is no longer necessary. The remainder (attached) is down to being 'obvious' and so I will commit it as soon as the regtesting is done. Thanks for your test of the original, Dominique! Paul PS I will check to see if it does the job for 5-branch.
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #13)
> (In reply to Dominique d'Humieres from comment #11)
> > I think you need to add a line
> >
> > ! { dg-options "-pedantic" }
> >
> > to elemental_optional_args_6.f90 (untested).
>
> I'd suggest to use -Wpedantic, since this is the "modern" name
Thanks for the clarifications to both of you. Indeed that addition does the
trick, and I agree that -Wpedantic should be preferred.
However, I noticed that -Wpedantic is not documented at all in the gfortran
manual (see
https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options).
Only -pedantic is mentioned.
The (non-Fortran) GCC documentation properly shows both forms.
[Bug fortran/61420] [4.9/5/6 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61420 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9/5/6 Regression] type |[4.9/5/6 Regression] [OOP] |bound procedure with pass |type-bound procedure |attribute, that returns a |returning a procedure |procedure pointer, fails to |pointer fails to compile |compile | --- Comment #7 from janus at gcc dot gnu.org --- Two further observations: 1) The failure persists even if the type binding is named differently from the actual function. 2) The argument 'f' does not need to be a PASS argument, it does not even need to be a dummy argument at all, but some "class(functions)" variable must be declared somewhere to trigger the error. Test case modified accordingly: module test implicit none type functions contains procedure, nopass :: get_pf => get_it end type class(functions), allocatable :: f contains function get_it() procedure (real), pointer :: get_it end function end module The error actually concerns the function name, not the type binding: function get_it() 1 Error: Symbol ‘get_it’ at (1) has no IMPLICIT type
[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564 --- Comment #5 from Paul Thomas --- Author: pault Date: Sun Jan 31 10:22:05 2016 New Revision: 233016 URL: https://gcc.gnu.org/viewcvs?rev=233016&root=gcc&view=rev Log: 2016-01-31 Paul Thomas PR fortran/67564 * trans-expr.c (gfc_conv_procedure_call): For the vtable copy subroutines, add a string length argument, when the actual argument is an unlimited polymorphic class object. 2016-01-31 Paul Thomas PR fortran/67564 * gfortran.dg/allocate_with_source_17.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_17.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268 --- Comment #5 from janus at gcc dot gnu.org --- Anything left to do here? Is there a particular reason the status is "WAITING"? What are we waiting for?
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Known to work||5.2.1 --- Comment #51 from janus at gcc dot gnu.org --- This version ... gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ... works fine for both comment 41 and comment 47, giving the expected error about "no IMPLICIT type". (The test case in comment 41 needs to be fixed by adding "module calc_param_mod" up front.)
[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564 --- Comment #6 from Paul Thomas --- Created attachment 37531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37531&action=edit Fix for 5-branch 5-branch requires a slightly different fix. For some reason, the argument to copy is not being given the unlimited polymorphic attribute. Even the symbol doesn't have it. Logically, the only way that a character can be copied to a class object is that it is unlimited polymorphic and so the requirement is ignored in this case. My inclination is to commit this patch to 5-branch since it regtests OK and is minimalist. Cheers Paul
[Bug target/69577] New: [5/6 Regression] wrong code with -fno-forward-propagate -fno-split-wide-types -mavx and 128bit modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577 Bug ID: 69577 Summary: [5/6 Regression] wrong code with -fno-forward-propagate -fno-split-wide-types -mavx and 128bit modulo Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 37532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37532&action=edit reduced testcase Output (Intel Software Development Emulator is used to emulate unsupported instructions): $ gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233015-checking-yes-rtl-df-nobootstrap-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-checking=yes,rtl,df --disable-bootstrap --without-cloog --without-ppl --without-isl --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-233015-checking-yes-rtl-df-nobootstrap-nographite Thread model: posix gcc version 6.0.0 20160131 (experimental) (GCC) $ gcc -O -fno-forward-propagate -fno-split-wide-types -mavx testcase.c $ sde64 -- ./a.out Aborted Tested revisions: trunk r233015 - FAIL trunk r232998 - FAIL 5-branch r232545 - FAIL 4_9-branch r232544 - OK 4_[876]-branch - OK
[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -fno-split-wide-types -mavx and 128bit modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-31 CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Target Milestone|--- |5.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Broken with r215450.
[Bug tree-optimization/69574] [4.9/5/6 Regression] gcc ICE at -O2 and -O3 on x86_64-linux-gnu in hide_evolution_in_other_loops_than_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69574 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-31 CC||jakub at gcc dot gnu.org Target Milestone|6.0 |4.9.4 Summary|gcc ICE at -O2 and -O3 on |[4.9/5/6 Regression] gcc |x86_64-linux-gnu in |ICE at -O2 and -O3 on |hide_evolution_in_other_loo |x86_64-linux-gnu in |ps_than_loop|hide_evolution_in_other_loo ||ps_than_loop Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- With -O2 started with r193882, with -O3 started with r228650.
[Bug c++/69009] [5/6 Regression] ICE in instantiate_decl, at cp/pt.c:21511
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69009 --- Comment #6 from Jason Merrill --- Author: jason Date: Sun Jan 31 11:53:04 2016 New Revision: 233019 URL: https://gcc.gnu.org/viewcvs?rev=233019&root=gcc&view=rev Log: PR c++/69009 * pt.c (partial_specialization_p, impartial_args): New. (instantiate_decl): Call impartial_args. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ47.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268 --- Comment #6 from vehre at gcc dot gnu.org --- I am waiting for one week to pass without complaints before closing the pr as resolved fixed to prevent resolved -> reopened cycles. Will mark as resolved -> fixed on Feb. 3,. Sorry for not communicating more precisely.
[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I guess ifcvt only triggers some latent bug, either RA or more likely in reg-stack. That said, all the comments about the r229822 changes say its purpose is to handle multiple sets in the conditional block, but clearly the patch as implemented considers one set to be also multiple sets. The problem with that is that it handles it worse than the code later on in ifcvt - it uses temporaries and hopes later passes get rid of those temporaries, but they actually affect the register allocation. By restricting the ifcvt multiple sets coversion to actually multiple sets like: --- gcc/ifcvt.c.jj 2016-01-21 17:53:32.0 +0100 +++ gcc/ifcvt.c 2016-01-31 13:47:34.171323086 +0100 @@ -3295,7 +3295,7 @@ bb_ok_for_noce_convert_multiple_sets (ba if (count > limit) return false; - return count > 0; + return count > 1; } /* Given a simple IF-THEN-JOIN or IF-THEN-ELSE-JOIN block, attempt to convert the test passes again, after ifcvt there are no additional unneeded temporaries and e.g. postreload dump contains 5 fewer instruction, and has fewer spills/fills. Of course we really need to figure out what the bug actually is, but unless there is some strong reason (which should be documented), IMHO the above patch is right too.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #21 from Jason Merrill --- Author: jason Date: Sun Jan 31 14:53:26 2016 New Revision: 233020 URL: https://gcc.gnu.org/viewcvs?rev=233020&root=gcc&view=rev Log: PR c++/68763 * tree.c (strip_typedefs) [FUNCTION_TYPE]: Avoid building a new function type if nothing is changing. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug target/69575] [interrupt] The direction flag DF in the FLAGS register may be wrong in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69575 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from H.J. Lu --- Fixed on hjl/interrupt/stage1 and hjl/interrupt/gcc-5-branch.
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552 Bug 67552 depends on bug 69575, which changed state. Bug 69575 Summary: [interrupt] The direction flag DF in the FLAGS register may be wrong in interrupt handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69575 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/66960] Add interrupt attribute to x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #4 from H.J. Lu ---
The current specification:
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.
The design goals of interrupt and exception handlers for x86 processors
are:
1. Support both 32-bit and 64-bit modes.
2. Flexible for compilers to optimize.
3. Easy to use by programmers.
To implement interrupt and exception handlers for x86 processors, a
compiler should support:
'interrupt' attribute
Use this attribute to indicate that the specified function with
mandatory arguments is an interrupt or exception handler. The compiler
generates function entry and exit sequences suitable for use in an
interrupt handler when this attribute is present. The 'IRET' instruction,
instead of the 'RET' instruction, is used to return from interrupt or
exception handlers. All registers, except for the EFLAGS register which
is restored by the 'IRET' instruction, are preserved by the compiler.
Since the direction flag in the FLAGS register in interrupt (exception)
handlers is undetermined, cld instruction must be emitted in function
prologue if rep string instructions are used in interrupt (exception)
handler or interrupt (exception) handler isn't a leaf function.
Any interruptible-without-stack-switch code must be compiled with
-mno-red-zone since interrupt handlers can and will, because of the
hardware design, touch the red zone.
1. interrupt handler must be declared with a mandatory pointer argument:
struct interrupt_frame;
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame)
{
...
}
and user must properly define the structure the pointer pointing to.
2. exception handler:
The exception handler is very similar to the interrupt handler with
a different mandatory function signature:
typedef unsigned int uword_t __attribute__ ((mode (__word__)));
struct interrupt_frame;
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame, uword_t error_code)
{
...
}
and compiler pops the error code off stack before the 'IRET' instruction.
The exception handler should only be used for exceptions which push an
error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.
'no_caller_saved_registers' attribute
Use this attribute to indicate that the specified function has no
caller-saved registers. That is, all registers are callee-saved.
The compiler generates proper function entry and exit sequences to
save and restore any modified registers.
The user can call functions specified with 'no_caller_saved_registers'
attribute from an interrupt handler without saving and restoring all
call clobbered registers.
On x86, interrupt handlers are only called by processors which push
interrupt data onto stack at the address where the normal return address
is. Interrupt handlers must access interrupt data via pointers so that
they can update interrupt data.
[Bug rtl-optimization/69567] PowerPC64: cstore optimisation produces bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567 Segher Boessenkool changed: What|Removed |Added Component|target |rtl-optimization --- Comment #4 from Segher Boessenkool --- This is caused by the patch for PR64682.
[Bug c/69578] New: -Wuninitialized not issuing warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69578
Bug ID: 69578
Summary: -Wuninitialized not issuing warning.
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lvenkatakumarchakka at gmail dot com
Target Milestone: ---
int main()
{
int i, j;
for( j=0; j<10; j++ )
{
printf( "%d\n", i );
for( i=0; i<10;i++ );
}
return 0;
}
compiling above code with -Wuninitialized is supposed to issue warning which is
not happening.
[Bug tree-optimization/69579] New: gcc ICE at -O3 on x86_64-linux-gnu with “tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
Bug ID: 69579
Summary: gcc ICE at -O3 on x86_64-linux-gnu with “tree check:
expected ssa_name, have integer_cst in
compute_optimized_partition_bases”
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It might be a 4.9 regression.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160131 (experimental) [trunk revision 233019] (GCC)
$ gcc-trunk abc.c -O3
abc.c: In function 'fun2':
abc.c:7:5: warning: implicit declaration of function '__sigsetjmp'
[-Wimplicit-function-declaration]
__sigsetjmp();
^~~
abc.c:4:5: internal compiler error: tree check: expected ssa_name, have
integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1572
int fun2(struct str *p1) {
^~~~
0xdda56c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9637
0xc6a97e tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3006
0xc6a97e compute_optimized_partition_bases
../../gcc/gcc/tree-ssa-coalesce.c:1572
0xc6bed7 coalesce_ssa_name()
../../gcc/gcc/tree-ssa-coalesce.c:1779
0xc027f0 remove_ssa_form
../../gcc/gcc/tree-outof-ssa.c:974
0xc027f0 rewrite_out_of_ssa(ssaexpand*)
../../gcc/gcc/tree-outof-ssa.c:1198
0x753560 execute
../../gcc/gcc/cfgexpand.c:6124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ cat abc.c
struct str {
int Count;
};
int fun2(struct str *p1) {
int i = 1;
while (1) {
__sigsetjmp();
break;
}
for (; i;) {
i = 0;
for (; i < (p1 ? p1->Count : 1); i++)
fun2(p1);
}
return 1;
}
[Bug tree-optimization/69579] gcc ICE at -O3 and __sigsetjmp with “tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-31
Target Milestone|--- |6.0
Summary|gcc ICE at -O3 on |gcc ICE at -O3 and
|x86_64-linux-gnu with “tree |__sigsetjmp with “tree
|check: expected ssa_name, |check: expected ssa_name,
|have integer_cst in |have integer_cst in
|compute_optimized_partition |compute_optimized_partition
|_bases” |_bases”
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed also on aarch64=linux-gnu.
t00.c:4:5: internal compiler error: tree check: expected ssa_name, have
integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1572
int fun2(struct str *p1) {
^~~~
0xd83d27 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/apinski/src/local/gcc/gcc/tree.c:9605
0xc1721f tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/apinski/src/local/gcc/gcc/tree.h:3006
0xc1721f compute_optimized_partition_bases
/home/apinski/src/local/gcc/gcc/tree-ssa-coalesce.c:1572
0xc18e27 coalesce_ssa_name()
/home/apinski/src/local/gcc/gcc/tree-ssa-coalesce.c:1779
0xbacb33 remove_ssa_form
/home/apinski/src/local/gcc/gcc/tree-outof-ssa.c:974
0xbacb33 rewrite_out_of_ssa(ssaexpand*)
/home/apinski/src/local/gcc/gcc/tree-outof-ssa.c:1198
0x6f82d3 execute
/home/apinski/src/local/gcc/gcc/cfgexpand.c:6124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c++/69572] [C++11] invalid alignas accepted in many contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69572
--- Comment #1 from Martin Sebor ---
Another invalid case that's accepted:
$ cat x.cpp && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall
-Wextra -Wpedantic -std=c++11 x.cpp
struct alignas (1) B;
struct alignas (2) B;
struct alignas (4) B { int i; };
This is required to be rejected by the following text in 7.6.2 Alignment
specifier, para 6:
If the defining declaration of an entity has an alignment-specifier, any
non-defining declaration of that entity shall either specify equivalent
alignment or have no alignment-specifier. Conversely, if any declaration of an
entity has an alignment-specifier, every defining declaration of that entity
shall specify an equivalent alignment. No diagnostic is required if
declarations of an entity have different alignment-specifiers in different
translation units.
[Bug c/69580] New: From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69580 Bug ID: 69580 Summary: From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 37533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37533&action=edit gzipped C source code The attached C code seems to take about ten minutes on a recent version of gcc trunk. $ (ulimit -t 1200; time ~/gcc/results.release/bin/gcc -c -O2 bug271.c) real10m3.565s user9m56.967s sys 0m0.846s $ ~/gcc/results.release/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results.release/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.release/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../src/trunk/configure --prefix=/home/dcb/gcc/results.release --disable-bootstrap --disable-multilib --disable-werror --enable-checking=release --enable-languages=c,c++,fortran Thread model: posix gcc version 6.0.0 20160130 (experimental) (GCC) Compared to much less time on 5.3.1 $ (ulimit -t 1200; time gcc -c -O2 bug271.c) real0m27.110s user0m26.533s sys 0m0.372s $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) $
[Bug c/69580] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69580 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog Target Milestone|--- |6.0
[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69580 Andrew Pinski changed: What|Removed |Added CC||law at gcc dot gnu.org, ||pinskia at gcc dot gnu.org Component|c |tree-optimization --- Comment #1 from Andrew Pinski --- Looks like fsm_find_thread_path and fsm_find_control_statement_thread_paths is causing the compile time hog.
[Bug tree-optimization/69579] [4.9/5/6 Regression] gcc ICE at -O3 and __sigsetjmp with “tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69579 H.J. Lu changed: What|Removed |Added CC||rguenther at suse dot de Summary|gcc ICE at -O3 and |[4.9/5/6 Regression] gcc |__sigsetjmp with “tree |ICE at -O3 and __sigsetjmp |check: expected ssa_name, |with “tree check: expected |have integer_cst in |ssa_name, have integer_cst |compute_optimized_partition |in |_bases” |compute_optimized_partition ||_bases” --- Comment #2 from H.J. Lu --- It is caused by r198681.
[Bug c++/69581] New: r232586 broke arm-cross-compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581 Bug ID: 69581 Summary: r232586 broke arm-cross-compiler bootstrap Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- I'm using glibc 2.15 at $prefix/$target/include this works: ../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64 --target=arm-linux-gnueabihf --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard --enable-languages=c,c++,ada,fortran but this fails: ../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard --enable-languages=c,ada,c++,fortran make used to work previously, but now it aborts with: libtool: compile: arm-linux-gnueabihf-c++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I. -I../../../../gcc-trunk/libsanitizer/sanitizer_common -I.. -I ../../../../gcc-trunk/libsanitizer/include -isystem ../../../../gcc-trunk/libsanitizer/include/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/arm-linux-gnueabihf -I../../../../gcc-trunk/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../gcc-trunk/libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../gcc-trunk/libsanitizer/../include -include ../../../../gcc-trunk/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o In file included from ../../libstdc++-v3/include/stdlib.h:35:0, from /home/ed/gnu/arm-linux-gnueabihf-linux64/arm-linux-gnueabihf/include/rpc/types.h:60, from /home/ed/gnu/arm-linux-gnueabihf-linux64/arm-linux-gnueabihf/include/rpc/xdr.h:39, from ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:144: ../../libstdc++-v3/include/cstdlib:124:11: error: '::div_t' has not been declared using ::div_t; ^ ../../libstdc++-v3/include/cstdlib:125:11: error: '::ldiv_t' has not been declared using ::ldiv_t; ^~ ../../libstdc++-v3/include/cstdlib:127:11: error: '::abort' has not been declared using ::abort; ^ ../../libstdc++-v3/include/cstdlib:128:11: error: '::abs' has not been declared using ::abs; ^~~ ../../libstdc++-v3/include/cstdlib:129:11: error: '::atexit' has not been declared using ::atexit; ^~ ../../libstdc++-v3/include/cstdlib:132:11: error: '::at_quick_exit' has not been declared using ::at_quick_exit; ^ ../../libstdc++-v3/include/cstdlib:135:11: error: '::atof' has not been declared using ::atof; ^~~~ ../../libstdc++-v3/include/cstdlib:136:11: error: '::atoi' has not been declared using ::atoi; ^~~~ ../../libstdc++-v3/include/cstdlib:137:11: error: '::atol' has not been declared using ::atol; ^~~~ ../../libstdc++-v3/include/cstdlib:138:11: error: '::bsearch' has not been declared using ::bsearch; ^~~ ../../libstdc++-v3/include/cstdlib:140:11: error: '::div' has not been declared using ::div; ^~~ ../../libstdc++-v3/include/cstdlib:141:11: error: '::exit' has not been declared using ::exit; ^~~~ ../../libstdc++-v3/include/cstdlib:143:11: error: '::getenv' has not been declared using ::getenv; ^~ ../../libstdc++-v3/include/cstdlib:144:11: error: '::labs' has not been declared using ::labs; ^~~~ ../../libstdc++-v3/include/cstdlib:145:11: error: '::ldiv' has not been declared using ::ldiv; ^~~~ ../../libstdc++-v3/include/cstdlib:148:11: error: '::mblen' has not been declared using ::mblen; ^ ../../libstdc++-v3/include/cstdlib:149:11: error: '::mbstowcs' has not been declared using ::mbstowcs; ^~~~ ../../libstdc++-v3/include/cstdlib:150:11: error: '::mbtowc' has not been declared using ::mbtowc; ^~ ../../libstdc++-v3/include/cstdlib:152:11: error: '::qsort' has not been declared using ::qsort; ^ ../../libstdc++-v3/include/cstdlib:155:11: error: '::quick_exit' has not been declared using ::quick_exit; ^~ ../../
[Bug other/69582] New: [meta-bug] Cilk+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582 Bug ID: 69582 Summary: [meta-bug] Cilk+ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: law at redhat dot com Target Milestone: --- Tracker for all Cilk+ bugs, there's far more of them than I realized.
[Bug libstdc++/69581] r232586 broke arm-cross-compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Andrew Pinski --- I am surprised you are not using a sysroot.
[Bug libstdc++/69581] [6 Regression] r232586 broke arm-cross-compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |6.0 Summary|r232586 broke |[6 Regression] r232586 |arm-cross-compiler |broke arm-cross-compiler |bootstrap |bootstrap
[Bug libstdc++/69581] [6 Regression] r232586 broke arm-cross-compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581 --- Comment #2 from Bernd Edlinger --- Created attachment 37534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37534&action=edit preprocessed source code
[Bug libstdc++/69581] [6 Regression] r232586 broke arm-cross-compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581 --- Comment #3 from Bernd Edlinger --- (In reply to Andrew Pinski from comment #1) > I am surprised you are not using a sysroot. Hmm, I kind of stole the include/lib files from the target, and install them to the prefix tree at the right place. I just have to get rid of the absolute path in libc.so and libpthread.so using vi for instance that is about the easiest way to do it.
[Bug tree-optimization/69583] New: FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "Removing load: a = \\*\\.?LC\\.?\\.?0;" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69583 Bug ID: 69583 Summary: FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "Removing load: a = \\*\\.?LC\\.?\\.?0;" 1 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c -fno-diagnostics-show-caret -fdiagnosti cs-color=never -O2 -fdump-tree-esra --param sra-max-scalarization-size-Ospeed=32 -lm -o ./sra-17.exe PASS: gcc.dg/tree-ssa/sra-17.c (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2. 0w-hp-hpux11.11/./libatomic/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir /hppa2.0w-hp-hpux11.11/./libatomic/.libs spawn [open ...] PASS: gcc.dg/tree-ssa/sra-17.c execution test FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "Removing load: a = \\* \\.?LC\\.?\\.?0;" 1 FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*\\.? LC\\.?\\.?0\\[" 4 Similar fail: spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c -fno-diagnostics-show-caret -fdiagnosti cs-color=never -O2 -fdump-tree-esra --param sra-max-scalarization-size-Ospeed=32 -lm -o ./sra-18.exePASS: gcc.dg/tree-ssa/sra-18.c (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2. 0w-hp-hpux11.11/./libatomic/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir /hppa2.0w-hp-hpux11.11/./libatomic/.libsspawn [open ...] PASS: gcc.dg/tree-ssa/sra-18.c execution testFAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "Removing load: a = \\* \\.?LC\\.?\\.?0;" 1FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*\\.? LC\\.?\\.?0\\.b\\[0\\]\\.f\\[0\\]\\.x" 1FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*\\.? LC\\.?\\.?0\\.b\\[0\\]\\.f\\[1\\]\\.x" 1FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*\\.? LC\\.?\\.?0\\.b\\[1\\]\\.f\\[0\\]\\.x" 1FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*\\.?LC\\.?\\.?0\\.b\\[1\\]\\.f\\[1\\]\\.x" 1
[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535 --- Comment #7 from Richard Henderson --- (In reply to Segher Boessenkool from comment #6) > But are the SCALAR_INT_MODE_P checks necessary? I don't know. I wondered if we'd ever see something like (and:DI (subreg:DI (reg:SF X) 0) (const_int 0x)) which isn't too far off of the DI/SI mode pair seen here. I thought about asserting SCALAR_INT, but then thought better and just made them normal checks so that we'd just fail the operation. I suppose, since this is make_compound_operation, that we can take the SCALAR_INT_MODE_P-ness of the outer mode for granted. I could take away that half of the check.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #27 from Jeffrey A. Law --- Balaji fixed the ICE a while back. Based on c#26, I don't think we should hide the functions from being used/called from user code. So the only issue left is the doc fix, right?
[Bug testsuite/69583] FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "Removing load: a = \\*\\.?LC\\.?\\.?0;" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69583 John David Anglin changed: What|Removed |Added Component|tree-optimization |testsuite --- Comment #1 from John David Anglin --- Looks like a regexp issue.
[Bug target/68228] [4.9 Only] __builtin_ia32_pbroadcastd256 generates wrong insn at >= -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #5 from Mikael Pettersson --- This test case got fixed for gcc-5 by r216541.
[Bug middle-end/60586] [Cilk+] Parameters evaluation happens inside spawn worker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60586 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk months ago.
[Bug bootstrap/60644] [4.9/5/6 Regression] Build of i686-pc-linux-android is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #15 from Jeffrey A. Law --- Fixed and backported to the release branch nearly 2 years ago.
[Bug bootstrap/60644] [4.9/5/6 Regression] Build of i686-pc-linux-android is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jeffrey A. Law --- Fixed on the trunk & release branch nearly 2 years ago.
[Bug other/61962] GCC seems to enter an infinite loop when compiling the above cilk+ code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk and release branch over a year ago.
[Bug other/62008] CilkPlus Array Notation ICE in build_array_notation_ref when trying to build a multidimensional array from a pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62008 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed long ago on the trunk and release branch.
[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570 --- Comment #2 from James Greenhalgh --- (In reply to Jakub Jelinek from comment #1) > I guess ifcvt only triggers some latent bug, either RA or more likely in > reg-stack. That said, all the comments about the r229822 changes say its > purpose is to handle multiple sets in the conditional block, but clearly the > patch as implemented considers one set to be also multiple sets. The > problem with that is that it handles it worse than the code later on in > ifcvt - it uses temporaries and hopes later passes get rid of those > temporaries, but they actually affect the register allocation. > By restricting the ifcvt multiple sets coversion to actually multiple sets > like: > --- gcc/ifcvt.c.jj2016-01-21 17:53:32.0 +0100 > +++ gcc/ifcvt.c 2016-01-31 13:47:34.171323086 +0100 > @@ -3295,7 +3295,7 @@ bb_ok_for_noce_convert_multiple_sets (ba >if (count > limit) > return false; > > - return count > 0; > + return count > 1; > } > > /* Given a simple IF-THEN-JOIN or IF-THEN-ELSE-JOIN block, attempt to > convert > the test passes again, after ifcvt there are no additional unneeded > temporaries and e.g. postreload dump contains 5 fewer instruction, and has > fewer spills/fills. Of course we really need to figure out what the bug > actually is, but unless there is some strong reason (which should be > documented), IMHO the above patch is right too. Yes, that patch makes sense to me. If other ifcvt paths are doing a better job of handling a single register move than the multiple-set code, then we should use them.
[Bug c++/62048] -fcilkplus warning for noreturn attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62048 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #1 from Jeffrey A. Law --- Fix a while ago on the trunk.
[Bug libstdc++/69581] [6 Regression] r232586 broke arm-cross-compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581 --- Comment #4 from Bernd Edlinger --- this fixes it for me: Index: libstdc++-v3/include/c_compatibility/math.h === --- libstdc++-v3/include/c_compatibility/math.h (revision 233023) +++ libstdc++-v3/include/c_compatibility/math.h (working copy) @@ -27,12 +27,12 @@ */ +#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS +# include_next +#else #ifndef _GLIBCXX_MATH_H #define _GLIBCXX_MATH_H 1 -#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS -# include_next -#else # include using std::abs; Index: libstdc++-v3/include/c_compatibility/stdlib.h === --- libstdc++-v3/include/c_compatibility/stdlib.h (revision 233023) +++ libstdc++-v3/include/c_compatibility/stdlib.h (working copy) @@ -26,12 +26,12 @@ * This is a Standard C++ Library header. */ +#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS +# include_next +#else #ifndef _GLIBCXX_STDLIB_H #define _GLIBCXX_STDLIB_H 1 -#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS -# include_next -#else # include using std::abort;
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #18 from Jeffrey A. Law --- Fixed long ago on the trunk.
[Bug target/66326] Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Fixed on the trunk a few months ago.
[Bug testsuite/69584] New: FAIL: gcc.dg/pr67964.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69584 Bug ID: 69584 Summary: FAIL: gcc.dg/pr67964.c (test for excess errors) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 FAIL: gcc.dg/pr67964.c (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr67964.c:19:12: error: alias definitions not supported in this configuration /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr67964.c:20:12: error: alias definitions not supported in this configuration
[Bug c++/66859] [cilk+] internal compiler error: in lower_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66859 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law --- Duplicate. *** This bug has been marked as a duplicate of bug 65960 ***
[Bug middle-end/65960] ICE in Cilk spawn with argument with non-trivial constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65960 Jeffrey A. Law changed: What|Removed |Added CC||t at sharklasers dot com --- Comment #1 from Jeffrey A. Law --- *** Bug 66859 has been marked as a duplicate of this bug. ***
[Bug middle-end/65960] ICE in Cilk spawn with argument with non-trivial constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65960 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-31 CC||law at redhat dot com Ever confirmed|0 |1
[Bug c++/68001] [cilkplus] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68001 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk a few months ago.
[Bug c++/62047] --coverage segfault in libcilkrts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62047 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law --- Looks like a duplicate to me. *** This bug has been marked as a duplicate of bug 69028 ***
[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: -fcilkplus is incompatible with -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69028 Jeffrey A. Law changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #1 from Jeffrey A. Law --- *** Bug 62047 has been marked as a duplicate of this bug. ***
[Bug other/69582] [meta-bug] Cilk+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582 Bug 69582 depends on bug 62047, which changed state. Bug 62047 Summary: --coverage segfault in libcilkrts https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62047 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug other/69582] [meta-bug] Cilk+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582 --- Comment #1 from Jeffrey A. Law --- I think I got all the Cilk+ bugs on the tracker. Along the way I marked some duplicates and closed some that were fixed. There are some on the list above which may actually be fixed. I'll do another run through them shortly.
[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69580 --- Comment #2 from Andrew Pinski --- With checking turned on aarch64-linux-gnu: tree VRP: 804.96 (61%) usr 0.28 ( 9%) sys 805.19 (61%) wall 35850 kB (14%) ggc dominator optimization : 286.56 (22%) usr 0.19 ( 6%) sys 286.66 (22%) wall 24718 kB (10%) ggc I don't have a compiler right now without checking but this seems huge even for checking case.
[Bug c++/69098] [6.0 regression] Member function pointer template flagged with 'is not a function template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69098
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
(In reply to Martin Sebor from comment #2)
> Confirmed. The following simplified test case also reproduces the error
> with today's top of trunk. 5.1.0 compiles the test case successfully so
> this is a regression.
>
> $ cat u.cpp && /home/msebor/build/gcc-trunk-svn/gcc/xg++
> -B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -o/dev/null
> -std=c++14 u.cpp
> struct A
> {
> template
> static void (*pf)();
> };
>
> template
> void foo () {
> (void)A::pf;
> }
>
> void bar () {
> foo<0>();
> }
> u.cpp: In instantiation of ‘void foo() [with int = 0]’:
> u.cpp:13:10: required from here
> u.cpp:9:9: error: ‘template > void (* A::pf)()<
> >’ is not a function template
>(void)A::pf;
> ^
>
> u.cpp:9:9: error: ‘pf’ is not a member of ‘A’
This test seems to regress between 5.2 and 5.3.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #28 from Eric Botcazou --- > Balaji fixed the ICE a while back. Based on c#26, I don't think we should > hide the functions from being used/called from user code. So the only issue > left is the doc fix, right? That's my understanding, yes.
[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69580 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-31 Ever confirmed|0 |1 --- Comment #3 from Jeffrey A. Law --- We've got join points with > 1k incoming edges and the FSM bits try to walk up the CFG for each edge. A limiter seems to help considerably dropping the compilation time from ~4 minutes to ~19 seconds. I want to look at it a bit deeper before deciding that's the best way to go. At the least I'll want to do some instrumentation to help select a reasonable limiter.
[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535 --- Comment #8 from Segher Boessenkool --- Yeah I don't know either. Some things here do check, others don't, it looks like there are either too many or too few checks. Just keep them if you're not confident about removing them, stage 4 etc.
[Bug debug/68244] FAIL: g++.dg/parse/parens3.C -std=gnu++98 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68244 --- Comment #3 from John David Anglin --- Author: danglin Date: Mon Feb 1 00:38:17 2016 New Revision: 233028 URL: https://gcc.gnu.org/viewcvs?rev=233028&root=gcc&view=rev Log: PR debug/68244 * g++.dg/parse/parens3.C: Use register "4" on hppa. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/parens3.C
[Bug c++/69585] New: [C++ 11] parser errors mixing alignas, C++ 11 and GNU attributes on class declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69585
Bug ID: 69585
Summary: [C++ 11] parser errors mixing alignas, C++ 11 and GNU
attributes on class declaration
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The C++ parser seems to have trouble combining the C++11 alignas specifier and
the GNU __attribute__ specifier in the same class declaration. It also doesn't
like pairing C++11 attribute specifiers with GNU __attribute__. Pairing
alignas and the C++ 11 [[attribute]] syntax seems to work.
Clang does somewhat better (it handles GNU __attribute__ and C++11
[[attribute]] but it too chokes on alignas and GNU attributes and on C++
[[attribute]] and GNU __attribute__.
The following example shows the problematic interactions between C++ 11
alignas, C++ 11 [[gnu::may_alias]], and GNU __attribute__((mayalias)).
Since other similar syntactic combinations are accepted (such as the common
inline and __attribute__((always_inline))), I expected alignas and
__attribute__((whatever)) to be as well. I couldn't find anything about this
restriction is in manual.
$ cat v.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall
-Wextra -Wpedantic -Wuninitialized -std=c++11 -xc++ v.c
struct __attribute__ ((aligned (2))) __attribute__ ((may_alias))
S1 { };
struct __attribute__ ((aligned (2))) [[gnu::may_alias]]
S2 { };
struct alignas (2) __attribute__ ((may_alias))
S3 { };
struct alignas (2) [[gnu::may_alias]]
S4 { };
struct __attribute__ ((may_alias)) __attribute__ ((aligned (2)))
S1_2 { };
struct [[gnu::may_alias]] __attribute__ ((aligned (2)))
S2_2 { };
struct __attribute__ ((may_alias)) alignas (2)
S3_2 { };
struct [[gnu::may_alias]] alignas (2)
S4_2 { };
v.c:4:38: error: expected identifier before ‘[’ token
struct __attribute__ ((aligned (2))) [[gnu::may_alias]]
^
v.c:4:38: warning: attribute ignored [-Wattributes]
v.c:4:38: note: an attribute that appertains to a type-specifier is ignored
v.c:7:20: error: expected identifier before ‘__attribute__’
struct alignas (2) __attribute__ ((may_alias))
^
v.c:17:27: error: expected identifier before ‘__attribute__’
struct [[gnu::may_alias]] __attribute__ ((aligned (2)))
^
v.c:20:36: error: expected identifier before ‘alignas’
struct __attribute__ ((may_alias)) alignas (2)
^~~
v.c:20:36: warning: attribute ignored [-Wattributes]
v.c:20:36: note: an attribute that appertains to a type-specifier is ignored
[Bug c++/69585] [C++ 11] parser errors mixing alignas, C++ 11 and GNU attributes on class declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69585 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Blocks||58601 Known to fail||4.9.3, 5.3.0, 6.0 --- Comment #1 from Martin Sebor --- As far as I can tell this never worked. Adding rejects-valid since at least some of the combinations in the test case seem like they should be accepted. If the decision is made to reject some or all of them, it would be nice to do it more gracefully that by a parse error, and document the restriction in the manual. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601 [Bug 58601] [meta-bug] alignas
[Bug target/68741] FAIL: tr1/8_c_compatibility/cstdio/functions.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68741 --- Comment #2 from John David Anglin --- Author: danglin Date: Mon Feb 1 00:54:22 2016 New Revision: 233029 URL: https://gcc.gnu.org/viewcvs?rev=233029&root=gcc&view=rev Log: PR target/68741 * inclhack.def (hpux_vsscanf): New fix. * fixincl.x: Regenerated. * tests/base/stdio.h [HPUX_VSSCANF_CHECK]: New test. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def trunk/fixincludes/tests/base/stdio.h
[Bug c++/55402] Compiling large initializer lists never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55402 Hasnain Lakhani changed: What|Removed |Added CC||m.hasnain.lakhani at gmail dot com --- Comment #13 from Hasnain Lakhani --- I ran into this just now with GCC 4.8; and a coworker verified that the problem is still there in gcc-6.0-pre. My file (slow.cpp), which contains a huge map literal takes 630 seconds to compile with gcc 4.8, while the same code would compile in 16 seconds with clang. Additionally it seems to compile fine if changing the generated code to instead use assignment (which was fine for our purposes as a workaround) rather than a huge initializer list; which suggests exponential behaviour. That would compile in 30 seconds with gcc 4.8 and under a second with clang. I'm attaching the two above mentioned files.
[Bug c++/55402] Compiling large initializer lists never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55402 --- Comment #14 from Hasnain Lakhani --- Created attachment 37535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37535&action=edit The slow code file with a huge initializer list
[Bug c++/55402] Compiling large initializer lists never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55402 --- Comment #15 from Hasnain Lakhani --- Created attachment 37536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37536&action=edit Faster version assigning each pair directly to the map
[Bug testsuite/69584] FAIL: gcc.dg/pr67964.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69584 --- Comment #1 from John David Anglin --- Author: danglin Date: Mon Feb 1 01:12:23 2016 New Revision: 233030 URL: https://gcc.gnu.org/viewcvs?rev=233030&root=gcc&view=rev Log: PR testsuite/69584 * gcc.dg/tree-ssa/sra-17.c: Fix regexps to work on hpux. * gcc.dg/tree-ssa/sra-18.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c
[Bug target/68741] FAIL: tr1/8_c_compatibility/cstdio/functions.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68741 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed.
[Bug testsuite/69584] FAIL: gcc.dg/pr67964.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69584 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Should be fixed.
[Bug testsuite/69586] New: FAIL: gcc.dg/uninit-21.c for target defaulting to short enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586 Bug ID: 69586 Summary: FAIL: gcc.dg/uninit-21.c for target defaulting to short enum Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: rguenther at suse dot de Target Milestone: --- Target: arm-none-eabi Created attachment 37537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37537&action=edit Dump of failing uninit1 pass Hi, The new gcc.dg/uninit-21.c fails on arm-none-eabi with the following error: gcc/testsuite/gcc.dg/uninit-21.c: In function 'yp_update': gcc/testsuite/gcc.dg/uninit-21.c:31:3: warning: 'master' may be used uninitialized in this function [-Wmaybe-uninitialized] FAIL: gcc.dg/uninit-21.c (test for bogus messages, line 31) The test succeeds if passing -fno-short-enum or giving RPC_CANTENCODEARGS a value to big to represent with an unsigned short (65536 or higher) due to the cast creating confusing. See attached dump of uninit1 pass. The second cast using a bitwise and with 255 starts from forwprop1. Best regards.
[Bug c++/69098] [6.0 regression] Member function pointer template flagged with 'is not a function template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69098 --- Comment #5 from Martin Sebor --- I looks like it was introduced in r186681. The last good commit before that is r186667, and none of those in between touch the C++ front end. Though the changes in r186681 look very mechanical and not related to templates at all so I'm not sure.
[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -fno-split-wide-types -mavx and 128bit modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577 --- Comment #2 from Zdenek Sojka --- Created attachment 37538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37538&action=edit another testcase Output: $ gcc -O -fno-forward-propagate -mavx testcase.c $ sde64 -- ./a.out 0002 Aborted
[Bug target/69305] [5 Regression] wrong code with -O and int128 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305 --- Comment #15 from Richard Henderson --- Author: rth Date: Mon Feb 1 07:06:53 2016 New Revision: 233031 URL: https://gcc.gnu.org/viewcvs?rev=233031&root=gcc&view=rev Log: PR target/69305 * config/aarch64/aarch64-modes.def (CC_Cmode): New * config/aarch64/aarch64-protos.h: Update. * config/aarch64/aarch64.c (aarch64_zero_extend_const_eq): New. (aarch64_select_cc_mode): Add check for use of CC_Cmode. (aarch64_get_condition_code_1): Handle CC_Cmode. * config/aarch64/aarch64.md (addti3): Use adddi3_compareC. (*add3_compareC_cconly_imm): New. (*add3_compareC_cconly): New. (*add3_compareC_imm): New. (add3_compareC): New. (add3_carryin, *addsi3_carryin_uxtw): Sort compare operand to be first. Use aarch64_carry_operation. (*add3_carryin_alt1, *addsi3_carryin_alt1_uxtw): Remove. (*add3_carryin_alt2, *addsi3_carryin_alt2_uxtw): Remove. (*add3_carryin_alt3, *addsi3_carryin_alt3_uxtw): Remove. (subti3): Use subdi3_compare1. (*sub3_compare0): Rename from sub3_compare0. (sub3_compare1): New. (*sub3_carryin0, *subsi3_carryin_uxtw): New. (*sub3_carryin): Use aarch64_borrow_operation. (*subsi3_carryin_uxtw): Likewise. (*ngc, *ngcsi_uxtw): Likewise. (*sub3_carryin_alt, *subsi3_carryin_alt_uxtw): New. * config/aarch64/iterators.md (DWI): New. * config/aarch64/predicates.md (aarch64_carry_operation): New. (aarch64_borrow_operation): New. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64-modes.def branches/gcc-5-branch/gcc/config/aarch64/aarch64-protos.h branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/config/aarch64/aarch64.md branches/gcc-5-branch/gcc/config/aarch64/iterators.md branches/gcc-5-branch/gcc/config/aarch64/predicates.md
[Bug target/69305] [5 Regression] wrong code with -O and int128 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Henderson --- Fixed for gcc-5 too.
[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69548 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2016-01/msg02378.ht ||ml Last reconfirmed||2016-02-01 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug fortran/25071] dummy argument larger than actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 --- Comment #18 from Janne Blomqvist --- (In reply to janus from comment #16) > Any opinions on this? +1
[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535 --- Comment #9 from Richard Henderson --- Author: rth Date: Mon Feb 1 07:32:01 2016 New Revision: 233032 URL: https://gcc.gnu.org/viewcvs?rev=233032&root=gcc&view=rev Log: PR rtl-opt/69535 * combine.c (make_compound_operation): When looking through a subreg, make sure to re-extend to the width of the outer mode. Added: trunk/gcc/testsuite/gcc.dg/pr69535.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Janne Blomqvist --- I think this issue has been fixed now that we use libbacktrace to show backtraces.
[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Henderson --- Fixed.
[Bug target/69587] New: -mhle documentation missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69587 Bug ID: 69587 Summary: -mhle documentation missing Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vapier at gcc dot gnu.org CC: kirill.yukhin at intel dot com Target Milestone: --- Target: x86_64-* the -mhle option is missing from invoke.texi & extend.texi. i'm not familiar enough with this option to suggest a patch.
