[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56935 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2013-04-16 07:48:47 UTC --- On Mon, 15 Apr 2013, ysrumyan at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56935 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-04-15 14:54:50 UTC --- Richard, both subq's are accessed the same cash line and it means that after 1st store tthe 2nd load will stall till finish updating data cash (this is not exact explanation but if you'd like I can find out more strong and correct definition of memory conflict). In result non-vectorizable code will run much slower adn we saw such slowdown on 253.perl from cpu2000. I fear this is beyond the scope of the vectorizer cost model in its current form. Clearly what it computes is correct if the cost is defined as a sum of individual stmt costs (which is how the scalar cost is computed). The vectorizer cost model now gives the target the power to look at the whole vectorized sequence and compute something better than the sum of the individual vectorized stmt costs, but currently the x86 target does not use this power. Factoring in instruction cache it's still not clear that a possible extra cache miss for ifetch is worth avoiding the stall due to the store forwarding issue. (btw, your explanation looks odd - there is no dependency between the two - yes, if the share the same slot as the store buffers granularity then maybe a failed store forward (due to _no_ dependency) may cause that issue?) Note that for basic-block vectorization we want to even more keep an eye on code-size, and the same cost model is used for basic-block and loop SLP. Richard.
[Bug target/56975] New: [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
Bug #: 56975
Summary: [regression] dllimport broken on i686-pc-cygwin
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@gcc.gnu.org
Created attachment 29880
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29880
preprocessed testcase
Attempting to reference a dllimported symbol with current HEAD causes an ICE
with an unrecognized insn. This breaks bootstrap at stage1 building libgcc.
Here's a testcase using stage1 cc1.exe from a failed build dir:
$ cat foo.i
void *foo (void);
__attribute__((dllimport)) void * __attribute__((__stdcall__)) bar(const char *
lpModuleName);
void *
foo (void)
{
void *ptr = bar ((const char *)0);
return ptr;
}
DKAdmin@ubik /gnu/gcc/obj/i686-pc-cygwin/libgcc
$ /gnu/gcc/obj/./gcc/cc1.exe -fpreprocessed foo.i -quiet -mtune=generic
-march=i686 -auxbase-strip crtbegin.o -g -g -g0 -O2 -O2 -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -version -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fno-stack-protector -fno-omit-frame-pointer -o foo.s
GNU C (GCC) version 4.9.0 20130416 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20130416 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 31da135ea647c81f0b254283fbd2bab6
foo.i: In function ‘foo’:
foo.i:11:1: error: unrecognizable insn:
}
^
(insn 6 5 7 2 (set (reg:SI 61)
(symbol_ref:SI (bar@4) [flags 0x441] function_decl 0x7fdf9c00 bar))
foo.i:9 -1
(nil))
foo.i:11:1: internal compiler error: in extract_insn, at recog.c:2150
foo.i:11:1: internal compiler error: Aborted
Aborted (core dumped)
DKAdmin@ubik /gnu/gcc/obj/i686-pc-cygwin/libgcc
$
[Bug fortran/50410] [4.7/4.8/4.9 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #14 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:47:09 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/50406] ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #1 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:48:14 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/44348] ICE in build_function_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.5.0 |4.8.0 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:49:29 UTC --- I still have the same bug on gfortran 4.8.0. And a tree check if gfortran built with -fsanitize.
[Bug fortran/44350] accepts illegal fortran in BLOCK DATA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44350 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.5.0 |4.8.0 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:50:22 UTC --- I still have the same bug on gfortran 4.8.0. This is same as 50516.
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968
--- Comment #7 from janus at gcc dot gnu.org 2013-04-16 08:50:35 UTC ---
(In reply to comment #6)
I think you should directly use
if (rvalue-value.function.esym)
s2 = rvalue-value.function.esym-result;
yes, I also thought about this variant. Might indeed be the better choice.
Ok, I have verified that this also regtests cleanly and fixes the test case (as
expected). Will commit the following patch later today (unless further
suggestions come up):
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 197988)
+++ gcc/fortran/expr.c(working copy)
@@ -3540,7 +3540,11 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
}
else if (rvalue-expr_type == EXPR_FUNCTION)
{
- s2 = rvalue-symtree-n.sym-result;
+ if (rvalue-value.function.esym)
+s2 = rvalue-value.function.esym-result;
+ else
+s2 = rvalue-symtree-n.sym-result;
+
name = s2-name;
}
else
[Bug fortran/50069] FORALL fails on a character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.6.1 |4.8.0 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:50:50 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #6 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:51:08 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/50402] ICE in gfc_conv_expr_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #1 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:51:27 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #1 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:52:43 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 08:53:16 UTC --- I still have the same bug on gfortran 4.8.0.
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 08:54:19 UTC --- (In reply to comment #7) Ok, I have verified that this also regtests cleanly and fixes the test case (as expected). Will commit the following patch later today (unless further suggestions come up): Looks good to me (with a test case ;-). After committal, please copy the output from your commit message at http://gcc.gnu.org/ml/gcc-cvs/current to the PR. Thanks for the patch!
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2013-04-16 09:37:38 UTC --- Hmm, as this bug seems not to happen for mingw 32-bit, it might be related to definition of DEFAULT_ABI for 32-bit. Does it help to set in cygming.h header the line '#define DEFAULT_ABI (TARGET_64BIT ? MS_ABI : SYSV_ABI)' to '#define DEFAULT_ABI (TARGET_64BIT ? MS_ABI : MS_ABI)' ? If so, we need an new definition to indicate pe-coff ABI instead. At some places we are using here check DEFAULT_ABI == MS_ABI etc, which might cause for 32-bit here the issue. See for example the code in predicate.md, i386.c, etc.
[Bug target/55144] opening glibc-c.o: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55144
Mans Rullgard mans at mansr dot com changed:
What|Removed |Added
CC||mans at mansr dot com
--- Comment #1 from Mans Rullgard mans at mansr dot com 2013-04-16 10:15:55
UTC ---
This fixes this problem (still fails building libgcc) for bfin-uclibc:
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -966,7 +966,7 @@ bfin*-uclinux*)
;;
bfin*-linux-uclibc*)
tm_file=${tm_file} dbxelf.h elfos.h bfin/elf.h gnu-user.h linux.h
glibc-stdint.h bfin/linux.h ./linux-sysroot-suffix.h
- tmake_file=bfin/t-bfin-linux t-slibgcc
+ tmake_file=${tmake_file} bfin/t-bfin-linux t-slibgcc
use_collect2=no
;;
bfin*-rtems*)
[Bug c++/56976] New: using braces to initialize a reference forces copy construction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
Bug #: 56976
Summary: using braces to initialize a reference forces copy
construction
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com
Hi all,
I hope this is not yet another buggy bug report. I have browsed the draft (I
don't have the current standard), and saw nothing clear cut, yet the principle
of least surprise tends to think this is really a bug.
Below, using braces to initialize a const-ref forces a call to a
copy-constructor. clang compiles this without error/warning. Cheers!
$ cat bar.cc
struct bar
{
bar() = default;
bar(const bar) = delete;
};
int main()
{
bar b;
const bar b1_(b);
const bar b2_{b};
}
$ g++-mp-4.8 -std=c++11 -Wall -Wno-unused-variable bar.cc
bar.cc: In function 'int main()':
bar.cc:11:19: error: use of deleted function 'bar::bar(const bar)'
const bar b2_{b};
^
bar.cc:4:3: error: declared here
bar(const bar) = delete;
^
$ clang++-mp-3.2 -std=c++11 -Wall bar.cc -Wno-unused-variable
$
[Bug c/56977] New: gcc -Og incorrectly warns about 'constant zero length parameter'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Bug #: 56977
Summary: gcc -Og incorrectly warns about 'constant zero length
parameter'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bauge...@cisco.com
Created attachment 29881
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29881
Preprocessed version of snippet in the Description field.
Compiling this tiny snippet with the command 'gcc -v -Og' produces an incorrect
warning about zero length parameter:
#include string.h
void foo(char *buf, size_t w, size_t h)
{
size_t n = w * h;
if (n 0)
memset(buf, 123, n);
}
The warning looks like this:
/usr/include/bits/string3.h:81:30: warning: call to ‘__warn_memset_zero_len’
declared with attribute warning: memset used with constant zero length
parameter; this could be due to transposed parameters [enabled by default]
__warn_memset_zero_len ();
Output from gcc -v:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--disable-libquadmath --enable-languages=c,c++,objc --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.0 p1.1, pie-0.5.5'
Thread model: posix
gcc version 4.8.0 (Gentoo 4.8.0 p1.1, pie-0.5.5)
[Bug middle-end/56978] New: memset-chk.c failure since r197671
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56978 Bug #: 56978 Summary: memset-chk.c failure since r197671 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org /home/andreas/clean/gcc-head-build/gcc/xgcc -B/home/andreas/clean/gcc-head-build/gcc/ /home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c /home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk-lib.c /home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -fno-diagnostics-show-caret -w -O3 -fomit-frame-pointer -funroll-loops -fno-tree-loop-distribute-patterns -lm -o /home/andreas/clean/gcc-head-build/gcc/testsuite/gcc5/memset-chk.x /home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c: In function ‘test5’: /home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:552:1: internal compiler error: in emit_move_insn_1, at expr.c:3428 0x802f712b emit_move_insn_1(rtx_def*, rtx_def*) /home/andreas/clean/gcc-head/gcc/expr.c:3428 0x802f71c5 emit_move_insn(rtx_def*, rtx_def*) /home/andreas/clean/gcc-head/gcc/expr.c:3526 0x802d68bb force_reg /home/andreas/clean/gcc-head/gcc/explow.c:676 0x802f8053 convert_move(rtx_def*, rtx_def*, int) /home/andreas/clean/gcc-head/gcc/expr.c:590 0x802f87b9 convert_modes(machine_mode, machine_mode, rtx_def*, int) /home/andreas/clean/gcc-head/gcc/expr.c:781 0x804bd919 expand_binop_directly /home/andreas/clean/gcc-head/gcc/optabs.c:1427 0x804bb57f expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/andreas/clean/gcc-head/gcc/optabs.c:1543 0x804bd70d expand_simple_binop(machine_mode, rtx_code, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/andreas/clean/gcc-head/gcc/optabs.c:1291 0x802fb645 force_operand(rtx_def*, rtx_def*) /home/andreas/clean/gcc-head/gcc/expr.c:7054 0x8094d3c3 doloop_modify /home/andreas/clean/gcc-head/gcc/loop-doloop.c:480 0x8094d3c3 doloop_optimize /home/andreas/clean/gcc-head/gcc/loop-doloop.c:750 0x8094d3c3 doloop_optimize_loops() /home/andreas/clean/gcc-head/gcc/loop-doloop.c:764 0x804549d7 rtl_doloop /home/andreas/clean/gcc-head/gcc/loop-init.c:543 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. Reghunt indicates that the error has been introduced with: 2013-04-10 Richard Biener rguent...@suse.de * passes.c (execute_todo): Do not call ggc_collect conditional here. (execute_one_ipa_transform_pass): But unconditionally here. (execute_one_pass): And here. (init_optimization_passes): Remove reload pass. * tree-pass.h (TODO_ggc_collect): Remove. (pass_reload): Likewise. * ira.c (do_reload): Merge into ... (ira): ... this. (rest_of_handle_reload): Remove. (pass_reload): Likewise. * config/i386/i386.c (ix86_option_override): Refer to ira instead of reload for vzeroupper pass placement. * everywhere: Remove TODO_ggc_collect from todo_flags_start and todo_flags_finish of all passes. * g++.dg/pr55604.C: Use -fdump-rtl-ira.
[Bug fortran/56969] [4.9 Regression] ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 11:13:34 UTC --- Draft patch: --- a/gcc/fortran/intrinsic.c +++ b/gcc/fortran/intrinsic.c @@ -4238,3 +4238,4 @@ got_specific: expr-value.function.isym = specific; - gfc_intrinsic_symbol (expr-symtree-n.sym); + if (!expr-symtree-n.sym-module) +gfc_intrinsic_symbol (expr-symtree-n.sym);
[Bug middle-end/56978] memset-chk.c failure since r197671
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56978 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-16 11:13:46 UTC --- Related to PR56921? Can you try the attached patch?
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-04-16
11:56:26 UTC ---
The issue is that
static void
execute_sm (struct loop *loop, vecedge exits, mem_ref_p ref)
{
...
/* Emit the load code into the latch, so that we are sure it will
be processed after all dependencies. */
latch_edge = loop_latch_edge (loop);
is no longer working. It wasn't working by design before either.
We temporarily create
header ---\
| |
if () |
/ \ |
_17 = *q_8(D); |
\ / |
D__lsm.5 = *_17;-
that is invalid SSA form and expect a dominator walk to visit
_17 = *q_8(D) before visiting D__lsm.5 = *_17;
So a simpler fix than the attached one finds a better temporary
insertion place for D__lsm.5 = *_17;
Placing the load at a random existing load or store would be the
best. I'm reworking the patch to do that.
[Bug target/56979] New: ICE in output_operand: invalid operand for code 'P'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979 Bug #: 56979 Summary: ICE in output_operand: invalid operand for code 'P' Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mgret...@gcc.gnu.org Created attachment 29882 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29882 Reduced testcase The attached testcase causes the following ICE when compiled as shown: $ arm-none-linux-gnueabi-g++ -fsigned-char -march=armv7-a -mfloat-abi=hard -mfpu=neon -ftree-vectorize -fPIC besttry.c besttry.c: In function ‘float2 operator-(float, float2)’: besttry.c:7:1: internal compiler error: output_operand: invalid operand for code 'P' } ^ 0x86acde output_operand_lossage(char const*, ...) /work/sources/gcc-fsf/master/gcc/final.c:3303 0xcdf7ba arm_print_operand /work/sources/gcc-fsf/master/gcc/config/arm/arm.c:18336 0x86ad2e output_operand(rtx_def*, int) /work/sources/gcc-fsf/master/gcc/final.c:3725 0x86b70b output_asm_insn /work/sources/gcc-fsf/master/gcc/final.c:3604 0x86b70b output_asm_insn(char const*, rtx_def**) /work/sources/gcc-fsf/master/gcc/final.c:3493 0xcd6864 output_move_vfp(rtx_def**) /work/sources/gcc-fsf/master/gcc/config/arm/arm.c:15383 0x86c6e8 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*) /work/sources/gcc-fsf/master/gcc/final.c:2853 0x86da15 final(rtx_def*, _IO_FILE*, int) /work/sources/gcc-fsf/master/gcc/final.c:1957 0x86de29 rest_of_handle_final /work/sources/gcc-fsf/master/gcc/final.c:4332 Issue also seen on 4.7, and 4.8. arm-none-linux-g++ -v: Using built-in specs. COLLECT_GCC=/work/builds/gcc-fsf-master/tools/bin/arm-none-linux-gnueabi-g++ COLLECT_LTO_WRAPPER=/work/builds/gcc-fsf-master/tools/libexec/gcc/arm-none-linux-gnueabi/4.9.0/lto-wrapper Target: arm-none-linux-gnueabi Configured with: /work/sources/gcc-fsf/master/configure --target=arm-none-linux-gnueabi --prefix=/work/builds/gcc-fsf-master/tools --with-sysroot=/work/builds/gcc-fsf-master/sysroot-arm-none-linux-gnueabi --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb : (reconfigured) /work/sources/gcc-fsf/master/configure --target=arm-none-linux-gnueabi --prefix=/work/builds/gcc-fsf-master/tools --with-sysroot=/work/builds/gcc-fsf-master/sysroot-arm-none-linux-gnueabi --disable-libssp --disable-libgomp --disable-libmudflap --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb target_alias=arm-none-linux-gnueabi CC=gcc --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 4.9.0 20130416 (experimental) (GCC)
[Bug target/56979] ICE in output_operand: invalid operand for code 'P'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979 --- Comment #1 from mgretton at gcc dot gnu.org 2013-04-16 12:45:38 UTC --- Command line can be further reduced to $ arm-none-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon reduced-testcase.c
[Bug target/56979] ICE in output_operand: invalid operand for code 'P'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 CC||ktkachov at gcc dot gnu.org Known to work||4.6.4 Ever Confirmed|0 |1 Known to fail||4.7.3, 4.8.0, 4.9.0 --- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-16 13:13:42 UTC --- Reproduced on arm-none-eabi with trunk, 4.8, 4.7. 4.6 does not ICE.
[Bug c++/56857] Crash in resolve_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56857 --- Comment #3 from Ryan Mansfield rmansfield at qnx dot com 2013-04-16 13:35:47 UTC --- (In reply to comment #2) ICE started happening at rev196747 http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=196747 ICE no longer happens after rev197811 http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=197811
[Bug ada/40986] [4.6 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 --- Comment #13 from Markus Schöpflin markus.schoepflin at comsoft dot de 2013-04-16 13:38:21 UTC --- I get a different result for the 4.7 branch (built from gcc.git with configure --disable-bootstrap --disable-nls --enable-languages=ada): - PATH=/var/tmp/build/gcc:$PATH ADA_INCLUDE_PATH=/var/tmp/build/gcc/ada/rts xgcc -v -c -I/var/tmp/test -gnato -gnatwl -gnatwauJF -gnatef -g -fno-strict-aliasing -gnatwA -I- /var/tmp/test/test.adb Using built-in specs. COLLECT_GCC=xgcc Target: i686-pc-linux-gnu Configured with: /var/tmp/gcc.git/configure --disable-bootstrap --disable-nls --enable-languages=ada Thread model: posix gcc version 4.7.4 20130415 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-I' '/var/tmp/test' '-gnato' '-gnatwl' '-gnatwauJF' '-gnatef' '-g' '-fno-strict-aliasing' '-gnatwA' '-I' '-' '-mtune=generic' '-march=pentiumpro' gnat1 -I /var/tmp/test -I - -quiet -dumpbase test.adb -auxbase test -fno-strict-aliasing -gnato -gnatwl -gnatwauJF -gnatef -g -gnatwA -mtune=generic -march=pentiumpro /var/tmp/test/test.adb -o /tmp/cckbceia.s +===GNAT BUG DETECTED==+ | 4.7.4 20130415 (prerelease) (i686-pc-linux-gnu) Assert_Failure sinfo.adb:388| | Error detected at a-unccon.ads:23:27 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /var/tmp/build/gcc/ada/rts/system.ads /var/tmp/test/test.adb /var/tmp/test/language.ads /var/tmp/build/gcc/ada/rts/s-auxdec.ads /var/tmp/build/gcc/ada/rts/ada.ads /var/tmp/build/gcc/ada/rts/a-unccon.ads compilation abandoned
[Bug middle-end/56978] memset-chk.c failure since r197671
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56978 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-04-16 13:40:27 UTC --- The patch from PR56921 fixes the issue on S/390. Thanks! *** This bug has been marked as a duplicate of bug 56921 ***
[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #14 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-04-16 13:40:27 UTC --- *** Bug 56978 has been marked as a duplicate of this bug. ***
[Bug ada/40986] [4.6 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 --- Comment #14 from Markus Schöpflin markus.schoepflin at comsoft dot de 2013-04-16 13:45:13 UTC --- Note that the error only shows up when language.ads contains the two pragmas as given in the first note. They are removed when the test case is processed by gnatchop, so you have to make sure that you are using a valid test case.
[Bug c/56980] New: Misleading note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980
Bug #: 56980
Summary: Misleading note
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: m...@gcc.gnu.org
Starting with http://gcc.gnu.org/r139729 we get:
typedef struct A { int i; } B;
void foo (B *);
void bar (B *x)
{
foo ((struct B *) x);
}
rh952692.c:2:6: note: expected ‘struct B *’ but argument is of type ‘struct B
*’
which is misleading, it should be either B * or struct A * in the first case.
[Bug fortran/56981] New: Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Bug #: 56981 Summary: Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: j...@gcc.gnu.org, jvdeli...@gcc.gnu.org Found at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/ORw0Y2k2CI4 The following examples are taken from Robert Corbett. The large amount spend in system for unformatted I/O is surprising, compared with other compilers. But in general, unformatted I/O is much slower. (Formatted I/O is slow as well.) Timing in sec Unformatted Formatted real / user real / user Compiler --- --- - 1.467/0.448 3.205/2.780 GCC 4.8.0 (-Ofast, 20130308, Rev. 196547) 0.309/0.308 1.297/1.296 g95 4.0.3 (g95 0.93!) Aug 17 2010 (-O3) 0.199/0.188 0.562/0.548 Sun Fortran 95 8.3 Linux_i386 2007/05/03 0.177/0.172 0.904/0.900 PathScale 3.2.99 0.177/0.176 2.201/2.200 NAGWare Fortran 5.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0.578/0.205 1.229/1.121 GCC 4.9 (trunk, -Ofast) 0.115/0.113 0.517/0.513 g95 4.0.3 (g95 0.94!) Dec 17 2012 0.130/0.129 0.522/0.517 PathScale EKOPath 4.9.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.035/0.524 3.014/2.928 GCC 4.7.2 20120920 (Cray Inc.) 0.194/0.184 0.634/0.632 Cray Fortran : Version 8.1.6 0.372/0.260 0.703/0.564 Intel 64, Version 13.1.1.163 0.437/0.432 0.938/0.932 pgf90 12.10-0 --- PROGRAM MAIN REAL X OPEN (10, FILE='/dev/null', FORM='FORMATTED') X = 0.0 DO 10 I = 1, 100 WRITE (10, '(E13.7)') X X = X + 1.0 10 CONTINUE END --- PROGRAM MAIN REAL X OPEN (10, FILE='/dev/null', FORM='UNFORMATTED') X = 0.0 DO 10 I = 1, 100 WRITE (10) X X = X + 1.0 10 CONTINUE END
[Bug fortran/56969] [4.9 Regression] ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 14:18:12 UTC --- Author: burnus Date: Tue Apr 16 14:17:15 2013 New Revision: 198000 URL: http://gcc.gnu.org/viewcvs?rev=198000root=gccview=rev Log: 2013-04-16 Tobias Burnus bur...@net-b.de PR fortran/56969 * intrinsic.c (gfc_intrinsic_func_interface): Don't set module name to (intrinsic) for intrinsics from intrinsic modules. 2013-04-16 Tobias Burnus bur...@net-b.de PR fortran/56969 * gfortran.dg/c_assoc_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_assoc_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56969] [4.9 Regression] ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 14:18:35 UTC --- FIXED. Thanks for the report!
[Bug tree-optimization/56982] New: Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 Bug #: 56982 Summary: Bad optimization with setjmp() Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: jdeme...@cage.ugent.be Target: x86_64-pc-linux-gnu Created attachment 29883 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29883 Bug program Compile the example program with gcc -Og jmp.c -o jmp Run the program ./jmp and the output is Returning 1 x = 0, n = 1 Returning 0 x = 42, n = 1 Aborted The function g() is returning 0 the second time (after longjmp()) but the return value, assigned to n, equals 1. With other optimization levels or with earlier versions of gcc or with -Og -fno-tree-dominator-opts, the output is what I expect: Returning 1 x = 0, n = 1 Returning 0 x = 42, n = 0 This is with gcc version 4.8.0, GNU libc version 2.15.
[Bug tree-optimization/56982] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 --- Comment #1 from Jeroen Demeyer jdemeyer at cage dot ugent.be 2013-04-16 14:31:54 UTC --- Created attachment 29884 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29884 Bug program (preprocessed)
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2013-04-16 15:15:14 UTC --- (In reply to comment #4) Hi, (In reply to comment #3) Please create a self-sufficient executable testcase, following the instructions at [1]. I was not able to confirm the problem from the lines you posted. Thanks for the feedback, Uros. Did you try it together with the frame growing downwards diff posted in #56898? If so, the locals are actually at the negative offsets and unaligned loads like foo%8-5 will expose this, instead of foo%8-1. No, I am using unpatched compiler. Compiling your ab-pre.tgz test, I got: ~/gcc-build-47/gcc/xgcc -B ~/gcc-build-47/gcc -O a.c uros@monolith ~/test $ ./a.out 0d0a 0d0a0401 0d0a0401 ~/gcc-build-47/gcc/xgcc -B ~/gcc-build-47/gcc -O -mcpu=ev4 a.c uros@monolith ~/test $ ./a.out 0d0a 0d0a0401 0d0a0401 with: GNU C (GCC) version 4.7.3 20130228 (prerelease) [gcc-4_7-branch revision 196343] (alphaev68-unknown-linux-gnu) and the same result (with the same flags) with: GNU C (GCC) version 4.9.0 20130407 (experimental) [trunk revision 197551] (alphaev68-unknown-linux-gnu) The compilers imply -mcpu=ev67 when invoked without -mcpu command.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 15:20:20 UTC --- For unformatted pathf95 and g95 have (top 10 entries of strace): 3 brk 4 close 3 getrlimit 4 ioctl 8 read 4 rt_sigaction 10 close 6 fstat 13 fstat 6 mprotect 20 mprotect 7 brk 21 stat 10 mmap 22 mmap 17 stat 46 open 23 open 367 write 734 write gfortran has the following syscalls, which are at least invoked twice: 3 brk 5 read 7 close 10 rt_sigaction 11 access 11 fstat 12 mprotect 16 stat 18 mmap 26 open 200 lseek 400 write
[Bug c/56980] Misleading note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16 15:24:46 UTC --- Confirmed, but I seriously doubt it has anything to do with my patch. At the moment of warning we get: (gdb) p debug_tree(type) pointer_type 0x77511540 type record_type 0x77511498 B type_0 SI size integer_cst 0x7740f0c0 constant 32 unit size integer_cst 0x7740f0e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x775113f0 fields field_decl 0x774195f0 i type integer_type 0x7740c5e8 int SI file /home/manuel/pr56980.c line 1 col 24 size integer_cst 0x7740f0c0 32 unit size integer_cst 0x7740f0e0 4 align 32 offset_align 128 offset integer_cst 0x773f7d80 constant 0 bit offset integer_cst 0x773f7e00 constant 0 context record_type 0x775113f0 A pointer_to_this pointer_type 0x77511540 chain type_decl 0x7752a000 D.1714 unsigned DI size integer_cst 0x773f7d40 type integer_type 0x7740c0a8 bitsizetype constant 64 unit size integer_cst 0x773f7d60 type integer_type 0x7740c000 sizetype constant 8 align 64 symtab 0 alias set -1 canonical type 0x775115e8 $9 = void (gdb) p debug_tree(rhstype) pointer_type 0x775119d8 type record_type 0x77511930 B VOID align 8 symtab 0 alias set -1 canonical type 0x77511930 context function_decl 0x77510a00 bar pointer_to_this pointer_type 0x775119d8 chain type_decl 0x7752a170 D.1722 unsigned DI size integer_cst 0x773f7d40 type integer_type 0x7740c0a8 bitsizetype constant 64 unit size integer_cst 0x773f7d60 type integer_type 0x7740c000 sizetype constant 8 align 64 symtab 0 alias set -1 canonical type 0x775119d8 which seem correct to me, so the pretty-printer is printing the wrong thing and not unwrapping the typedef as it should.
[Bug c/56980] Misleading note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16 15:25:58 UTC --- I think I have seen similar bugs in the pretty-printer with typedefs. BTW, Clang gets it perfect: pr56980.c:6:8: warning: incompatible pointer types passing 'struct B *' to parameter of type 'B *' (aka 'struct A *') [-Wincompatible-pointer-types] foo ((struct B *) x); ^~ pr56980.c:2:14: note: passing argument to parameter here void foo (B *); ^ pr56980.c:11:7: warning: incompatible pointer types initializing 'B *' (aka 'struct A *') with an expression of type 'struct B *' [-Wincompatible-pointer-types] B * y = (struct B *) x; ^ ~~
[Bug c/56980] Misleading note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16
15:33:16 UTC ---
void baz (B *x)
{
int y = x x;
}
/home/manuel/pr56980.c:11:13: error: invalid operands to binary (have
‘struct B *’ and ‘struct B *’)
int y = x x;
^
The C pretty-printer cannot deal correctly with pointers to typedefs of
structs.
[Bug c/56980] Misleading note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16
15:34:56 UTC ---
while the C++ pretty-printer can:
pr56980.c:4:16: error: invalid operands of types ‘B* {aka A*}’ and ‘B* {aka
A*}’ to binary ‘operator’
int y = x x;
^
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-04-16 15:41:05 UTC --- Author: rguenth Date: Tue Apr 16 15:32:26 2013 New Revision: 198001 URL: http://gcc.gnu.org/viewcvs?rev=198001root=gccview=rev Log: 2013-04-16 Richard Biener rguent...@suse.de PR tree-optimization/56756 * tree-ssa-loop-im.c (struct first_mem_ref_loc_1): New functor. (first_mem_ref_loc): New. (execute_sm): Place the load temporarily before a previous access instead of in the latch edge to ensure its SSA dependencies are defined at points dominating the load. * gcc.dg/torture/pr56756.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr56756.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug c/48778] gcc 4.6 -Waddress adds unhelpful new warning case when using from a macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16 15:41:37 UTC --- We have the capability to do this now since GCC 4.7, but someone needs to implement it for this case.
[Bug c/52825] incorrect message for incompatible pointer type with extra struct for a typedeffed struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52825 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16 15:41:51 UTC --- Dup *** This bug has been marked as a duplicate of bug 56980 ***
[Bug c/56980] Misleading note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||guest at mailinator dot com --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16 15:41:51 UTC --- *** Bug 52825 has been marked as a duplicate of this bug. ***
[Bug c++/53822] Diagnostic: spell out type in ambiguous call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-16 15:46:30 UTC --- We could say something like 'f(NT) with [NT = unsigned]' like we do for templates.
[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.1 Summary|Bad optimization with |[4.8/4.9 Regression] Bad |setjmp()|optimization with setjmp() Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-16 15:46:43 UTC --- Also happens with -Os. Started with http://gcc.gnu.org/r190284 Eyeballing the difference between r190283 and r190284 -Os dumps, I see that *.copyrename4 is still the same appart from losing some SSA_NAME_VARs, but *.uncprop has one difference: - # n_13 = PHI 0(5), 1(6) + # _13 = PHI _3(5), 1(6) The missing n is fine, but _3 instead of 0 there supposedly isn't. _3 is set before the setjmp call, while this PHI is after the returns-twice function, and while for non-zero _3 the code before setjmp exits early, so _3 should contain 0, perhaps while extending the lifetime of _3 over the returns twice function it should have added SSA_NAME_OCCURS_IN_ABNORMAL_PHI or give up on it. Richard, can you please have a look?
[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-16 16:04:10 UTC --- At RTL time (besides it being a pessimization), the thing is that _3 is assigned a pseudo (compared to before the change, where it had only a single use and thus has been TERed), that pseudo is initialized from *e, and initialized to 1 in the bb where the PHI had 1, and the pseudo is spilled to the stack. So it will initially contain the 0 value (correct), then that is overwritten with 1 (fine for the first setjmp returning case), but when setjmp returns second time, the value is still 1 rather than 0. So the questions are: - is it desirable that uncprop does anything to SSA_NAME_VAR == NULL phis? - shouldn't something like that be not performed if current function calls setjmp (or more narrowly, if there is a returns twice function somewhere in between the considered setter and user)? - what other optimizations might be similarly problematic across returns twice calls?
[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 17:17:52 UTC --- Related test case by the bug reporterm https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/UvBX1kfuFqs This time rejecting the code instead of ICEing: print *,x%i 1 Error: Symbol 'x' at (1) has no IMPLICIT type program p type t integer :: i = 0 end type associate (x=f()) print *,x%i end associate contains function f() type(t) f f%i = 5 end function end program
[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386 --- Comment #3 from Vladimir Fuka vladimir.fuka at gmail dot com 2013-04-16 17:40:04 UTC --- Thanks, I didn't realize they might be connected. I even forgotten I have this bug opened when I asked. Vladimir Dne 16.4.2013 19:17 burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org napsal(a): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 17:17:52 UTC --- Related test case by the bug reporterm https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/UvBX1kfuFqs This time rejecting the code instead of ICEing: print *,x%i 1 Error: Symbol 'x' at (1) has no IMPLICIT type program p type t integer :: i = 0 end type associate (x=f()) print *,x%i end associate contains function f() type(t) f f%i = 5 end function end program -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You reported the bug.
[Bug c/56983] New: Label in asm deleted after call to non-returning function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56983 Bug #: 56983 Summary: Label in asm deleted after call to non-returning function Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: silvioricar...@gmail.com gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) uname -a: Linux silvioricardoc-laptop 3.5.0-27-generic #46-Ubuntu SMP Mon Mar 25 20:00:05 UTC 2013 i686 i686 i686 GNU/Linux Command-line: gcc -Wall -Wextra code.c Description: GCC eliminates all code following a call to a non-returning function, even if this code includes an asm label that can be jumped to. In the latter case, it will generate the jump-to-label assembly output, but the code will fail to link due to the missing label. The problem may be the fact that GCC does not know when an asm label can be jumped into, but in this case, the correct solution should be to act conservatively and keep that part of the code intact.
[Bug c/56983] Label in asm deleted after call to non-returning function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56983 --- Comment #1 from silvioricardoc at gmail dot com 2013-04-16 18:39:50 UTC --- Created attachment 29885 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29885 Sample bug-causing code.
[Bug c/56983] Label in asm deleted after call to non-returning function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56983 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-16 18:42:41 UTC --- The testcase is of course invalid, you can't jump out of inline asm without telling the compiler about it. You can use asm goto to tell the compiler about it, then it wouldn't optimize it away (of course, the label is then a C label, not one hidden in assembly).
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968 --- Comment #9 from janus at gcc dot gnu.org 2013-04-16 19:14:33 UTC --- Fixed on trunk with: Author: janus Date: Tue Apr 16 19:07:34 2013 New Revision: 198008 URL: http://gcc.gnu.org/viewcvs?rev=198008root=gccview=rev Log: 2013-04-16 Janus Weil ja...@gcc.gnu.org PR fortran/56968 * expr.c (gfc_check_pointer_assign): Handle generic functions returning procedure pointers. 2013-04-16 Janus Weil ja...@gcc.gnu.org PR fortran/56968 * gfortran.dg/proc_ptr_41.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_41.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog Will backport to 4.8 and 4.7 in a few days if no problems show up.
[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2013-04-16 19:48:53 UTC --- r197942 should have fixed this properly. I'm testing powerpc64 unix/-m32 to confirm.
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #25 from Steven Bosscher steven at gcc dot gnu.org 2013-04-16 20:12:47 UTC --- Three years. Three years! Apparently wrong-debug is more important to fix than wrong compiler... But oh well. Fixed now. var-tracking.c now runs with TODO_verify_flow_info, so that the machine dependent reorg passes don't inherit the messy excuse for a CFG that var-tracking used to leave behind!
[Bug rtl-optimization/52139] [4.5 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC|steven at gcc dot gnu.org | Resolution||FIXED Target Milestone|4.5.4 |4.9.0 --- Comment #13 from Steven Bosscher steven at gcc dot gnu.org 2013-04-16 20:15:41 UTC --- Now properly fixed, xf. r197995
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-16 CC|steven at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/56388] [4.7/4.8/4.9 regression] catch(...) in lambda rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56388 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-16 20:30:12 UTC --- Fixed for 4.7.4/4.8.1/4.9.0.
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957
--- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2013-04-16
20:35:02 UTC ---
Bug in the selective scheduler, merely exposed by my patch:
Breakpoint 1, fancy_abort (file=0x11017130 ../../trunk/gcc/emit-rtl.c,
line=3840, function=0x110174f8 add_insn_after_nobb(rtx_def*,
rtx_def*)::__FUNCTION__ add_insn_after_nobb) at
../../trunk/gcc/diagnostic.c:1177
1177 internal_error (in %s, at %s:%d, function, trim_filename (file),
line);
(gdb) up
#1 0x103e616c in add_insn_after_nobb (insn=0x3fffb5da6150,
after=0x3fffb5da4e78) at ../../trunk/gcc/emit-rtl.c:3840
3840 gcc_assert (!optimize || !INSN_DELETED_P (after));
(gdb) p after
$1 = (rtx) 0x3fffb5da4e78
(gdb) p debug_rtx(after)
(insn/v 303 30 32 10 (set (reg:DF 165 f37 [421])
(unspec:DF [
(mem:DF (reg/f:DI 18 r18 [420]) [2 *a_7(D) S8 A64])
] UNSPEC_LDA)) 13 {movdf_advanced}
(nil))
$2 = void
(gdb) p INSN_DELETED_P (after)
$3 = 1
(gdb)
The selective scheduler is trying to re-emit an insn it had previously
deleted permanently.
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||abel at gcc dot gnu.org
AssignedTo|steven at gcc dot gnu.org |unassigned at gcc dot
||gnu.org
--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2013-04-16
20:54:17 UTC ---
Breakpoint 5, sel_remove_insn (insn=0x3fffb5da4e78, only_disconnect=false,
full_tidying=false) at ../../trunk/gcc/sel-sched-ir.c:3938
3938 delete_insn (insn);
1: debug_rtx(insn) = (insn 303 190 191 10 (set (reg:DF 165 f37 [421])
(unspec:DF [
(mem:DF (reg/f:DI 18 r18 [420]) [2 *a_7(D) S8 A64])
] UNSPEC_LDA)) 13 {movdf_advanced}
(nil))
void
(gdb) up
#1 0x10843984 in remove_insn_from_stream (insn=0x3fffb5da4e78,
only_disconnect=false) at ../../trunk/gcc/sel-sched.c:6042
6042 sel_remove_insn (insn, only_disconnect, false);
(gdb) up
#2 0x10843af0 in move_op_orig_expr_found (insn=0x3fffb5da4e78,
expr=0x115f9fd8, lparams=0x3fffda78, static_params=0x3fffdaa8) at
../../trunk/gcc/sel-sched.c:6066
6066 remove_insn_from_stream (insn, only_disconnect);
gdb) p only_disconnect
$19 = false
(gdb) l 6060
6055 moveop_static_params_p params = (moveop_static_params_p)
static_params;
6056
6057 copy_expr_onside (params-c_expr, INSN_EXPR (insn));
6058 track_scheduled_insns_and_blocks (insn);
6059 insn_emitted = handle_emitting_transformations (insn, expr, params);
6060 only_disconnect = (params-uid == INSN_UID (insn)
6061 ! insn_emitted ! EXPR_WAS_CHANGED (expr));
6062
6063 /* Mark that we've disconnected an insn. */
6064 if (only_disconnect)
(gdb) p params-uid
$20 = 303
(gdb) p insn_emitted
$21 = false
(gdb) p EXPR_WAS_CHANGED(expr)
$22 = true
No idea what to make of this. sel-sched deliberately chooses to discard
the insn instead of only disconnecting it, but it re-emits the insn
later anyway. That's wrong.
CC sel-sched guru.
[Bug c++/15272] lookup, dependent base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15272 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-16 21:08:40 UTC --- Jason, we apparently still do lookup in dependent bases inside virtual functions.
[Bug c++/56189] Infinite recursion with noexcept when instantiating function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56189 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 Ever Confirmed|0 |1 Known to fail||4.7.3, 4.8.1, 4.9.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-16 21:16:08 UTC --- name lookup in the noexcept(noexcept(...)) seems to be ignoring the namespace qualificiation
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #18 from Jason Merrill jason at gcc dot gnu.org 2013-04-16 21:24:12 UTC --- Fixed.
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2013-04-16
21:36:32 UTC ---
Work-around:
--- sel-sched-ir.c 2013-04-16 21:51:48.0 +0200
+++ sel-sched-ir.c 2013-04-16 23:35:30.0 +0200
@@ -3935,7 +3935,7 @@
remove_insn (insn);
else
{
- delete_insn (insn);
+ remove_insn (insn);
clear_expr (INSN_EXPR (insn));
}
But that makes sel-sched leak DF caches again...
[Bug fortran/39505] Consider a 'no arg check' directive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 21:39:36 UTC --- Author: burnus Date: Tue Apr 16 20:54:21 2013 New Revision: 198011 URL: http://gcc.gnu.org/viewcvs?rev=198011root=gccview=rev Log: 2013-04-12 Tobias Burnus bur...@net-b.de PR fortran/39505 * decl.c (ext_attr_list): Add EXT_ATTR_NO_ARG_CHECK. * gfortran.h (ext_attr_id_t): Ditto. * gfortran.texi (GNU Fortran Compiler Directives): Document it. * interface.c (compare_type_rank): Ignore rank for NO_ARG_CHECK. (compare_parameter): Ditto - and regard as unlimited polymorphic. * resolve.c (resolve_symbol, resolve_variable): Add same * constraint checks as for TYPE(*); turn dummy to TYPE(*),dimension(*). (gfc_explicit_interface_required): Require explicit interface for NO_ARG_CHECK. 2013-04-12 Tobias Burnus bur...@net-b.de PR fortran/39505 * gfortran.dg/no_arg_check_1.f90: New. * gfortran.dg/no_arg_check_2.f90: New. * gfortran.dg/no_arg_check_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/no_arg_check_1.f90 trunk/gcc/testsuite/gfortran.dg/no_arg_check_2.f90 trunk/gcc/testsuite/gfortran.dg/no_arg_check_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/56857] Crash in resolve_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56857 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-04-16 21:43:38 UTC --- Dup of 56901. *** This bug has been marked as a duplicate of bug 56901 ***
[Bug c++/56901] [4.9 regression] lambda with implicit capture by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56901 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||rmansfield at qnx dot com --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-16 21:43:38 UTC --- *** Bug 56857 has been marked as a duplicate of this bug. ***
[Bug fortran/39505] Consider a 'no arg check' directive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-16 21:44:29 UTC --- Re-close as FIXED. This feature is now supported on the GCC 4.9 trunk: !GCC$ attributes no_arg_check::buf Contrary to TYPE(*), which is supported since GCC 4.8, this attribute not only disables the T(ype) and K(ind) checking but also the rank check (= full TKR). To be used with TYPE(*) [recommended; integer, real, complex and logical are also fine]; the dummy argument can be either a scalar or an assumed-size array. Such dummies may only be passed on or used as argument to C_LOC. See http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-04-17 00:58:02 UTC --- There is a seek inside next_record_w_unf. That function is used for DIRECT I/O. Looks conceptually wrong to me for sequential unformatted. I won't have time for a few days to look at this further.
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 Alexey Pavlov alexpux at gmail dot com changed: What|Removed |Added CC||alexpux at gmail dot com --- Comment #2 from Alexey Pavlov alexpux at gmail dot com 2013-04-17 02:31:41 UTC --- I try to change line in cygming.h. Now It doesn't show error but xgcc processes freezing alltime and build cannot be done.
[Bug c/56984] New: GCC-4.8.0 ICE in tree_vrp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56984
Bug #: 56984
Summary: GCC-4.8.0 ICE in tree_vrp.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ishiura-compi...@ml.kwansei.ac.jp
GCC 4.8.0 with -O1 -ftree-vrp option ICEs on
the following code where sizeof(int) == 4.
The failure occurs in Linux (x86_64 and i686)
and Mac OS X (x86_64).
$ cat error.c
int g = 0;
int main(void)
{
if ( (g31) -1 ) { g++; }
return 0;
}
$ x86_64-unknown-linux-gnu-gcc-4.8.0 error.c -O1 -ftree-vrp
error.c: In function 'main':
error.c:3:5: internal compiler error: in remove_range_assertions, at
tree-vrp.c:6276
int main(void)
^
0x936e7e remove_range_assertions
../../gcc/tree-vrp.c:6276
0x936e7e execute_vrp
../../gcc/tree-vrp.c:9299
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.
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957
--- Comment #4 from Andrey Belevantsev abel at gcc dot gnu.org 2013-04-17
05:14:44 UTC ---
(In reply to comment #2)
Breakpoint 5, sel_remove_insn (insn=0x3fffb5da4e78, only_disconnect=false,
full_tidying=false) at ../../trunk/gcc/sel-sched-ir.c:3938
3938 delete_insn (insn);
1: debug_rtx(insn) = (insn 303 190 191 10 (set (reg:DF 165 f37 [421])
(unspec:DF [
(mem:DF (reg/f:DI 18 r18 [420]) [2 *a_7(D) S8 A64])
] UNSPEC_LDA)) 13 {movdf_advanced}
(nil))
You are right, this is not supposed to happen. The only_disconnect business is
for the unification and transformation support, when you have possibly several
insns as sources of the one chosen for scheduling. Thus, you need to delete
all sources but the one you're going to move upwards, and even this chosen one
should be deleted if it was changed while moving.
The insn in question is a speculative insn possibly generated earlier, so ...
(gdb) p EXPR_WAS_CHANGED(expr)
$22 = true
... if this is true, we are supposed to emit the new insn obviously with the
new id. The issue is that we then decide to emit the very same insn. I will
take a look.
