[Bug c++/57419] Access control doesn't stop referring to a deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419 --- Comment #2 from David Krauss potswa at mac dot com --- I guess the proper terminology would be taking its pointer. Nonstatic members don't really have addresses. Anyway what I was doing was determining the argument of a functor with one operator() overload using ftor::operator() . Calling or otherwise referencing a deleted function does not result in substitution failure; it results in an error. Access control applies to the name rather than the referent so it should stop before it sees the =delete definition. This makes sense because the inaccessible name is part of the immediate context of the declaration under substitution but =delete is not.
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #9 from Andreas Schwab sch...@linux-m68k.org --- Not enough. Executing on host: /daten/aranym/gcc/gcc-20130529/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130529/Build/gcc/ /daten/aranym/gcc/gcc-20130529/gcc/testsuite/gcc.c-torture/execute/pr42721.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -Og -g -lm -o /daten/aranym/gcc/gcc-20130529/Build/gcc/testsuite/gcc/pr42721.x6(timeout = 300) spawn /daten/aranym/gcc/gcc-20130529/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130529/Build/gcc/ /daten/aranym/gcc/gcc-20130529/gcc/testsuite/gcc.c-torture/execute/pr42721.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -Og -g -lm -o /daten/aranym/gcc/gcc-20130529/Build/gcc/testsuite/gcc/pr42721.x6 PASS: gcc.c-torture/execute/pr42721.c compilation, -Og -g Executing on aranym: LD_LIBRARY_PATH=:/daten/aranym/gcc/gcc-20130529/Build/gcc:/daten/aranym/gcc/gcc-20130529/Build/gcc timeout 600 /daten/aranym/gcc/gcc-20130529/Build/gcc/testsuite/gcc/pr42721.x6 (timeout = 300) Executed /daten/aranym/gcc/gcc-20130529/Build/gcc/testsuite/gcc/pr42721.x6, status 1 Output: bash: line 1: 32610 Aborted LD_LIBRARY_PATH=:/daten/aranym/gcc/gcc-20130529/Build/gcc:/daten/aranym/gcc/gcc-20130529/Build/gcc timeout 600 /daten/aranym/gcc/gcc-20130529/Build/gcc/testsuite/gcc/pr42721.x6 child process exited abnormally FAIL: gcc.c-torture/execute/pr42721.c execution, -Og -g --- /daten/aranym/gcc/gcc-20130527/Build/gcc/testsuite/gcc/pr42721.s 2013-05-29 10:05:31.865578609 +0200 +++ /daten/aranym/gcc/gcc-20130529/Build/gcc/testsuite/gcc/pr42721.s 2013-05-29 10:05:40.025528853 +0200 @@ -42,7 +42,6 @@ main: move.l b,%d1 eor.l %d1,%d0 move.l %d0,b -moveq #1,%d2 cmp.l %d0,%d2 jeq .L4 jsr abort
[Bug middle-end/57446] New: [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57446 Bug ID: 57446 Summary: [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: bviyer at gcc dot gnu.org Target: m68k-*-* Executing on host: /daten/aranym/gcc/gcc-20130529/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130529/Build/gcc/ /daten/aranym/gcc/gcc-20130529/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c -fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -std=c99 -S -o builtin_func_double.s(timeout = 300) spawn /daten/aranym/gcc/gcc-20130529/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130529/Build/gcc/ /daten/aranym/gcc/gcc-20130529/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c -fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -std=c99 -S -o builtin_func_double.s /daten/aranym/gcc/gcc-20130529/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c: In function 'main': /daten/aranym/gcc/gcc-20130529/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c:7:5: error: mismatching comparison operand types double long double if (D.1294 D.1382) goto D.1383; else goto D.1384; /daten/aranym/gcc/gcc-20130529/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c:7:5: error: mismatching comparison operand types double long double if (D.1308 D.1448) goto D.1449; else goto D.1450; /daten/aranym/gcc/gcc-20130529/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c:7:5: internal compiler error: verify_gimple failed 0x8f4b76 verify_gimple_in_seq(gimple_statement_d*) ../../gcc/tree-cfg.c:4465 0x75b231 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:8240 0x75b54d gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:8325 0x5fd2d7 cgraph_analyze_function ../../gcc/cgraphunit.c:658 0x5ffb43 cgraph_analyze_functions ../../gcc/cgraphunit.c:964 0x600cd0 finalize_compilation_unit() ../../gcc/cgraphunit.c:2118 0x4db152 c_write_global_declarations() ../../gcc/c/c-decl.c:10118
[Bug fortran/57365] [OOP] Sourced allocation fails with unlimited polymorphism
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57365 --- Comment #2 from rxs at hotmail dot de --- Thank you for the suggested workaround. But it is not a solution, a non unlimited polymorphic variable can not hold intrinsic data types like character. There also seems to be a problem with dummy arguments of type CLASS(*) in general: program bug implicit none call dummy_test(A test case) contains subroutine dummy_test(var) class(*) :: var select type (var) type is (character(len=*)) print*, len(var), var end select end subroutine end program bug Compiled with ifort this program has the output: 11 A test case That is correct. Compiled with gfortran 4.8 this program has the output: 0 That is obviously not correct.
[Bug middle-end/57446] [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57446 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- This is the full list of failing cilk-plus tests (all fail in the same way). All other tests pass. c-c++-common/cilk-plus/AN/builtin_func_double.c -O3 -ftree-vectorize -std=c99 -g -fcilkplus c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O0 -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O1 -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O2 -ftree-vectorize -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O3 -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O0 -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O1 -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O2 -ftree-vectorize -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O3 -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -std=c99 c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99
[Bug middle-end/57446] [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57446 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I also see FAILs on x86_64-linux and i686-linux.
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-29 CC||eraman at google dot com Ever confirmed|0 |1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Re-confirmed to be reassoc.
[Bug fortran/57445] [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug tree-optimization/57441] [4.9 Regression] ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-29 CC||wschmidt at linux dot vnet.ibm.com Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/57446] [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57446 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|m68k-*-*|m68k-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-29 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- On i?86-linux (testing x86_64 with -m32): Running target unix/-m32 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /space/rguenther/src/svn/trunk/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/cilk-plus/cilk-plus.exp ... FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/if_test.c -O0 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -O3 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -O0 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -g -O3 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -O3 -ftree-vectorize -fcilkplus -g execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -fcilkplus -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -fcilkplus -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -fcilkplus -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -fcilkplus -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O0 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O0 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O1 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O1 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O2 -ftree-vectorize -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O2 -ftree-vectorize -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O3 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -O3 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -fcilkplus -g -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -fcilkplus -g -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -fcilkplus -g -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -fcilkplus -g -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O0 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O0 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O1 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O1 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O2 -ftree-vectorize -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O2 -ftree-vectorize -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O3 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -g -O3 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -O3 -ftree-vectorize -std=c99 -g -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -O3 -ftree-vectorize -std=c99 -g -fcilkplus
[Bug middle-end/57427] ICE in gimplify_init_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57427 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-29 CC||mpolacek at gcc dot gnu.org Component|c++ |middle-end Target Milestone|--- |4.8.2 Ever confirmed|0 |1 Known to fail||4.8.0, 4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7-4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57315 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra CC||vmakarov at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- The tree opt code is quite the same for 4.8 and 4.7 at -O3 -fwhole-program, so I believe this boils down to spilling/register allocation (LRA vs. reload). We inline everything into main () (even at -O2) and we don't vectorize anything at -O3.
[Bug rtl-optimization/57447] New: [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57447 Bug ID: 57447 Summary: [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com CC: vmakarov at redhat dot com Target: x86_64 Happens only on x86_64 with just -O2 -ffast-math flags: comlib.c: In function 'put_serverbyte': comlib.c:49:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3007 } ^ 0x80d66b curr_insn_transform ../../gcc/lra-constraints.c:3006 0x80e2a4 lra_constraints(bool) ../../gcc/lra-constraints.c:3785 0x800bf4 lra(_IO_FILE*) ../../gcc/lra.c:2278 0x7c7688 do_reload ../../gcc/ira.c:4641 0x7c7688 rest_of_handle_reload ../../gcc/ira.c:4753
[Bug rtl-optimization/57448] New: GCSE generates incorrect code with acquire barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57448
Bug ID: 57448
Summary: GCSE generates incorrect code with acquire barrier
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jleahy+gcc at gmail dot com
The following code:
extern int seq;
extern int data;
int reader() {
int data_copy;
int seq_copy;
for (int i=0; i10; ++i) {
__atomic_load(seq, seq_copy, __ATOMIC_ACQUIRE);
data_copy = data;
}
return data_copy + seq_copy;
}
Compiled with g++ -masm=intel -std=c++11 -S -O -fgcse test.cpp using gcc
4.8.0 on x86_64 Linux, generates the following assembler:
.file test.cpp
.intel_syntax noprefix
.text
.globl _Z6readerv
.type _Z6readerv, @function
_Z6readerv:
.LFB0:
.cfi_startproc
mov edx, 10
mov ecx, DWORD PTR data[rip]
.L3:
mov eax, DWORD PTR seq[rip]
sub edx, 1
jne .L3
add eax, ecx
ret
.cfi_endproc
.LFE0:
.size _Z6readerv, .-_Z6readerv
.ident GCC: (GNU) 4.8.0
.section.note.GNU-stack,,@progbits
Here the load of data was hoisted above the load of seq, which is in violation
of the acquire memory ordering.
On the wiki here (http://gcc.gnu.org/wiki/Atomic/GCCMM/Optimizations/Details)
it says acquire is a barrier to hoisting code and CSE basically hoists
subexpressions into temporaries, so it would have the same logic apply as PRE:
valid across release, invalid across an acquire.
[Bug rtl-optimization/57447] [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57447 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/57448] GCSE generates incorrect code with acquire barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57448 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-29 CC||stevenb.gcc at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- ;; _7 = __atomic_load_4 (seq, 2); (insn 13 12 0 (set (reg:SI 61 [ D.2227 ]) (mem/v:SI (symbol_ref:DI (seq) [flags 0x40] var_decl 0x76e67558 seq) [-1 S4 A32])) t.c:8 -1 (nil)) the MEM alias-set of -1 (ALIAS_SET_MEMORY_BARRIER) is supposed to prevent this, but PRE does not know about this special property (it should kill all refs crossing it).
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC||ktkachov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to jules from comment #9)
This appears to have regressed on mainline. I now get the following assembly
output for the test case added by Maxim:
longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r4, r5}
umull r4, r5, r0, r2
mul r3, r0, r3
mla r1, r2, r1, r3
mov r0, r4
add r1, r1, r5
ldmfd sp!, {r4, r5}
bx lr
Current trunk (r199375) gives, I think this can be closed.
longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mul r3, r0, r3
mla r3, r2, r1, r3
umull r0, r1, r0, r2
add r1, r3, r1
bx lr
[Bug target/56863] cmpnltpd recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56863 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Currently, -ffast-math generates cmplepd, -fno-trapping-math generates cmpnltpd. That's better, but we should have cmpnltpd even with -ftrapping-math. Besides, if we manage to have an unlt with -ftrapping-math, we will still generate wrong code (but then the x86 back-end already generates the same code for ab and isless(a,b), so it is more unsupported than wrong).
[Bug middle-end/57446] [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57446 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- These are the failures on ia64. c-c++-common/cilk-plus/AN/if_test.c -O2 -ftree-vectorize -fcilkplus execution test c-c++-common/cilk-plus/AN/if_test.c -O3 -fcilkplus execution test c-c++-common/cilk-plus/AN/if_test.c -O3 -ftree-vectorize -fcilkplus -g execution test c-c++-common/cilk-plus/AN/if_test.c -O3 -ftree-vectorize -std=c99 -g -fcilkplus execution test c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O2 -ftree-vectorize -std=c99 execution test c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O3 -std=c99 execution test c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O2 -ftree-vectorize -std=c99 execution test c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O3 -std=c99 execution test c-c++-common/cilk-plus/AN/if_test.c -g -O2 -ftree-vectorize -fcilkplus execution test c-c++-common/cilk-plus/AN/if_test.c -g -O3 -fcilkplus execution test
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #10 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 30212 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30212action=edit experimental patch for execute/pr42721.c failure
[Bug c++/57449] New: name lookup of conversions-function-id differs from clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57449
Bug ID: 57449
Summary: name lookup of conversions-function-id differs from
clang
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
On the code below the behavior of clang and gcc differ. Clang accepts this
code, while gcc reject it:
13.cpp: In function 'int main()':
13.cpp:19:21: error: no matching function for call to 'b::operator int()'
13.cpp:19:21: note: candidate is:
13.cpp:13:5: note: templateclass T b::operator templT()
13.cpp:13:5: note: template argument deduction/substitution failed:
13.cpp:19:21: note: mismatched types 'templT' and 'int'
I don't know which behavior is correct, but the one of clang seems reasonable
to me.
template typename T
struct templ
{};
struct a
{
operator int();
};
struct b : a
{
template typename T
operator templT();
};
int main()
{
b bb;
bb.operator int();
}
[Bug bootstrap/57450] New: c/c-array-notation.c compilation failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57450 Bug ID: 57450 Summary: c/c-array-notation.c compilation failure Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: bviyer at gcc dot gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* The c-array-notation.c patch broke Solaris bootstrap. Noticed on Solaris 10/x86, but almost guaranteed to affect every Solaris version: % g++ -c -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic -I/vol/gcc/src/hg/trunk/local/gcc -I/vol/gcc/src/hg/trunk/local/gcc/c -I/vol/gcc/src/hg/trunk/local/gcc/../include -I./../intl -I/vol/gcc/src/hg/trunk/local/gcc/../libcpp/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/src/hg/trunk/local/gcc/../libdecnumber -I/vol/gcc/src/hg/trunk/local/gcc/../libdecnumber/dpd -I../libdecnumber -I/vol/gcc/src/hg/trunk/local/gcc/../libbacktrace -DCLOOG_INT_GMP -I/vol/gcc/include -I/vol/gcc/include /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c -o c/c-array-notation.o /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c: In function 'bool length_mismatch_in_expr_p(location_t, tree_node***, uint_t, uint_t)': /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:119:21: error: call of overloaded 'abs(long long int)' is ambiguous /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:119:21: note: candidates are: In file included from /usr/include/stdlib.h:17:0, from /vol/gcc/src/hg/trunk/local/gcc/system.h:226, from /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:69: /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:163:16: note: long int std::abs(long int) /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:117:12: note: int std::abs(int) /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:119:37: error: call of overloaded 'abs(long long int)' is ambiguous /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:119:37: note: candidates are: In file included from /usr/include/stdlib.h:17:0, from /vol/gcc/src/hg/trunk/local/gcc/system.h:226, from /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:69: /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:163:16: note: long int std::abs(long int) /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:117:12: note: int std::abs(int) /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c: In function 'tree_node* build_array_notation_expr(location_t, tree, tree, tree_code, location_t, tree, tree)': /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:1564:24: error: call of overloaded 'abs(long long int)' is ambiguous /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:1564:24: note: candidates are: In file included from /usr/include/stdlib.h:17:0, from /vol/gcc/src/hg/trunk/local/gcc/system.h:226, from /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:69: /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:163:16: note: long int std::abs(long int) /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:117:12: note: int std::abs(int) /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:1564:42: error: call of overloaded 'abs(long long int)' is ambiguous /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:1564:42: note: candidates are: In file included from /usr/include/stdlib.h:17:0, from /vol/gcc/src/hg/trunk/local/gcc/system.h:226, from /vol/gcc/src/hg/trunk/local/gcc/c/c-array-notation.c:69: /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:163:16: note: long int std::abs(long int) /vol/gcc-4.7/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/iso/stdlib_iso.h:117:12: note: int std::abs(int) g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/vol/gcc/src/hg/trunk/local/gcc -I/vol/gcc/src/hg/trunk/local/gcc/. -I/vol/gcc/src/hg/trunk/local/gcc/../include -I./../intl -I/vol/gcc/src/hg/trunk/local/gcc/../libcpp/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/src/hg/trunk/local/gcc/../libdecnumber -I/vol/gcc/src/hg/trunk/local/gcc/../libdecnumber/dpd -I../libdecnumber
[Bug bootstrap/57450] c/c-array-notation.c compilation failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57450 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/57449] name lookup of conversions-function-id differs from clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57449 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-29 Ever confirmed|0 |1
[Bug bootstrap/57450] [4.9 Regression] c/c-array-notation.c compilation failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57450 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|c/c-array-notation.c|[4.9 Regression] |compilation failure |c/c-array-notation.c ||compilation failure --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Use absu_hwi
[Bug bootstrap/57450] [4.9 Regression] c/c-array-notation.c compilation failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57450 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Use absu_hwi That works, getting me into stage 2. I'll let the bootstrap finish to see if anything else crops up, then commit that patch as obvious. Thanks. Rainer
[Bug rtl-optimization/57430] Redundant move instruction is produced after function inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57430
--- Comment #2 from Yuri Rumyantsev ysrumyan at gmail dot com ---
I don't believe that this is related to rtl optimizations, but rather to
inlining phase. To prove it I did small changes in t.c for remove.c (it now has
type void):
void remove (node ** head, node* elt)
{
node* curr;
node* prev;
if (*head == 0)
{
return;
}
prev = 0;
curr = *head;
while (curr)
{
if (curr != elt)
{
prev = curr;
curr = curr-next;
}
else
{
if (prev == 0)
{
*head = (*head)-next;
break;
}
else
{
prev-next = curr-next;
break;
}
}
}
}
For modified test we still have the same issue with redundant move instruction.
Now we can do another test modification that performs manual partial inlining
for 'remove' (full source will be attached):
Move test on zero head out of function to its call, i.e. call of 'remove' is
guarded by test on non-null head in 'find' and remove this test out of
function, i.e. we have
if (head)
remove (head, first)
For this modofied test we have optimal 6 instructions for innermost loop.
I assume that a problem related to phi-function construction after inlining,
namely for original test we have recurrent chain of phi's:
bb 14:
# prev_47 = PHI prev_37(16), prev_51(13)
# prev_54 = PHI prev_47(16), prev_25(13)
(before expand phase)
but for modified test we have an ordinary phi:
bb 16:
# prev_52 = PHI prev_38(15), prev_26(13)
[Bug rtl-optimization/57430] Redundant move instruction is produced after function inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57430 --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 30213 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30213action=edit modified testcase This is modified testcase which does not have a problem with redundant move instruction in innermost loop.
[Bug tree-optimization/57441] [4.9 Regression] ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt wschmidt at gcc dot gnu.org --- Mine.
[Bug rtl-optimization/57268] [4.9 Regression] c nested loops hang compiler in sched-deps.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268 --- Comment #4 from Dinar Temirbulatov dtemirbulatov at gmail dot com --- proposed fix posted here http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01713.html
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org --- Indeed, this is generic problem with weakref implementation that for some very entertaining reason use the CHAIN pointer of identifier nodes in undocumented way. I will try to debug today who clears the pointer and why. Honza
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #21 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed May 29 13:15:16 2013 New Revision: 199409 URL: http://gcc.gnu.org/viewcvs?rev=199409root=gccview=rev Log: 2013-05-28 Tobias Burnus bur...@net-b.de PR fortran/37336 * class.c (finalize_component): Fix coarray array refs. (generate_finalization_wrapper): Only gfc_convert_type_warn when the kind value is different. (gfc_find_intrinsic_vtab): _copy's dst is now intent(inout). (gfc_find_derived_vtab): Ditto. Enable finalization-wrapper generation. * module.c (MOD_VERSION): Bump. (gfc_dump_module, gfc_use_module): Remove empty line in .mod. * trans-array.c (gfc_conv_descriptor_token): Accept * nonrestricted void pointer. (gfc_array_allocate, structure_alloc_comps): Don't nullify for BT_CLASS allocations. * trans-stmt.c (gfc_trans_allocate): Ditto. 2013-05-28 Tobias Burnus bur...@net-b.de PR fortran/37336 * gfortran.dg/auto_dealloc_2.f90: Update _free count in the * dump. * gfortran.dg/class_19.f03: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/auto_dealloc_2.f90 trunk/gcc/testsuite/gfortran.dg/class_19.f03
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org --- The patch in comment 21 enables the generation of the finalization wrapper, which is at the heart of finalization. Note: No actual finalization is done, yet. Still missing are calls to the finalization wrapper. That will be a lengthier process. The first patch of that series is available at http://gcc.gnu.org/ml/fortran/2013-05/msg00107.html
[Bug rtl-optimization/57439] [4.9 regression] FAIL: gcc.c-torture/execute/920501-6.c execution, -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57439 --- Comment #11 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Jorn Wolfgang Rennecke from comment #10) Created attachment 30212 [details] experimental patch for execute/pr42721.c failure bootstrapped / regtested on i686-pc-linux-gnu build / regtested for i686-pc-linux-gnu X sh-elf
[Bug tree-optimization/57441] [4.9 Regression] ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441 --- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org --- Pending patch available at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01723.html.
[Bug rtl-optimization/57451] New: Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
Bug ID: 57451
Summary: Incorrect debug ranges emitted for
-freorder-blocks-and-partition -g
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tejohnson at google dot com
Created attachment 30214
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30214action=edit
pr49115.C
While fixing problems with -freorder-blocks-and-partition, I found that the
debug ranges being emitted for split functions with -g are incorrect and
leading to assembler errors. I've attached a simple reproducer
(gcc/testsuite/g++.dg/torture/pr49115.C). To reproduce:
$ g++ pr49115.C -O2 -o pr49115 -fprofile-generate
$ pr49115
$ g++ pr49115.C -O2 -o pr49115 -fprofile-use -g -freorder-blocks-and-partition
/tmp/ccStx78Y.s: Assembler messages:
/tmp/ccStx78Y.s:325: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LBB14' {.text.startup section}
The problem is hidden if the last compile step is changed to drop either -g or
-freorder-blocks-and-partition, or by adding -gdwarf-2 (which doesn't trigger
debug_range support).
[Bug middle-end/57446] [4.9 regression] FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57446 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #5 from Rainer Orth ro at gcc dot gnu.org --- Once Solaris bootstrap was restored, I see the following failures on i386-pc-solaris2.10, both 32- and 64-bit: FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -O0 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -O0 -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -O0 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -O1 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -O1 -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -O1 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -O2 -ftree-vectorize -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -O2 -ftree-vectorize -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -O2 -ftree-vectorize -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -O3 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -O3 -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -O3 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -O3 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -g -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O0 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O0 -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -g -O0 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O1 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O1 -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -g -O1 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O2 -ftree-vectorize -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O2 -ftree-vectorize -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -g -O2 -ftree-vectorize -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O3 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -g -O3 -fcilkplus (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -g -O3 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -g -O3 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/an-if.c -O3 -ftree-vectorize -fcilkplus -g (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -O3 -ftree-vectorize -fcilkplus -g (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -O3 -ftree-vectorize -fcilkplus -g compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -O3 -ftree-vectorize -fcilkplus -g execution test FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus -std=c99 (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus -std=c99 compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -fcilkplus -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -fcilkplus -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/builtin_func_double.c -fcilkplus -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus -O0 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus -O0 -std=c99 (test for excess errors) WARNING: c-c++-common/cilk-plus/AN/an-if.c -fcilkplus -O0 -std=c99 compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -fcilkplus -O0 -std=c99 execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_mutating.c -fcilkplus -O0 -std=c99 execution test FAIL:
[Bug bootstrap/57450] [4.9 Regression] c/c-array-notation.c compilation failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57450 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-05/msg01725.htm ||l Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- Fixed for 4.9.0. Rainer
[Bug c/57452] New: FAIL: c-c++-common/cilk-plus/AN/if_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57452
Bug ID: 57452
Summary: FAIL: c-c++-common/cilk-plus/AN/if_test.c
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On Linux/x32, I got
FAIL: c-c++-common/cilk-plus/AN/if_test.c -O0 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -std=c99 execution
test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -std=c99 execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -O0 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -fcilkplus execution test
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -m32 -o ./if_test.exe
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -mx32 -o ./if_test.exe
[x32@gnu-35 gcc]$ ./if_test.exe
[x32@gnu-35 gcc]$ echo $?
5
[x32@gnu-35 gcc]$
(gdb) r
Starting program:
/export/gnu/import/git/gcc-test-x32/bld/gcc/testsuite/gcc/if_test.exe
Breakpoint 1, main2 (argc=3, argv=0xd240)
at
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c:131
131 return 5;
Missing separate debuginfos, use: debuginfo-install glibc-2.16-30.1.fc18.x32
(gdb) p ii
$1 = 0
(gdb) p array2_check
$2 = {5, 5, 5, 5, 5, 5, 5, 5, 5, 5}
(gdb) p array2
$3 = {10, 10, 10, 10, 10, 10, 10, 10, 10, 10}
(gdb)
Does cilkplus assume ptr_mode == word_mode? On x32, ptr_mode == SImode
and word_mode == DImode.
[Bug c/57452] FAIL: c-c++-common/cilk-plus/AN/if_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57452 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Also fails on ia64 for the same reason.
[Bug tree-optimization/57441] [4.9 Regression] ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org --- Fixed as r199414. 2013-05-29 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/57441 * gimple-ssa-strength-reduction.c (analyze_candidates_and_replace): Don't limit size of incr_vec to number of candidates. 2013-05-29 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/57441 * gcc.c-torture/compile/pr57441.c: New.
[Bug middle-end/57453] New: [4.9 Regression] ICE: in operator[], at vec.h:815 with gcc -O3 -fno-strict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57453 Bug ID: 57453 Summary: [4.9 Regression] ICE: in operator[], at vec.h:815 with gcc -O3 -fno-strict-aliasing Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Created attachment 30215 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30215action=edit Test case: gcc -O3 -fno-strict-aliasing -c test9.i The attached test case fails with: $ gcc -O3 -fno-strict-aliasing -c test9.i test9.i: In function 'mca_btl_tcp_frag_send': test9.i:13:7: internal compiler error: in operator[], at vec.h:815 _Bool mca_btl_tcp_frag_send(mca_btl_tcp_frag_t* frag, int sd) ^ 0x52bc5c vecvoid*, va_heap, vl_embed::operator[](unsigned int) ../../gcc/vec.h:815 0x52bc5c vecvoid*, va_heap, vl_ptr::operator[](unsigned int) ../../gcc/vec.h:1244 0xb17354 vecvoid*, va_heap, vl_ptr::operator[](unsigned int) ../../gcc/gimple.h:1849 0xb17354 vinfo_for_stmt ../../gcc/tree-vectorizer.h:654 0xb17354 vect_bb_slp_scalar_cost ../../gcc/tree-vect-slp.c:1936
[Bug c/57452] FAIL: c-c++-common/cilk-plus/AN/if_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57452
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
We have
int main2 (int argc, char **argv);
int main(int argc, char **argv)
{
int x = 0;
if (argc == 1)
{
const char *array[] = {a.out, 10, 15};
x = main2 (3, (char **) array);
}
else if (argc == 3)
x = main2 (argc, argv);
else
return 1;
return x;
}
int main2 (int argc, char **argv)
{
int x = 3, y, z, array[10], array2[10], TwodArray[10][10], jj,kk,ll ;
...
/* This if loop will change all the 10's to 5's */
if (array[atoi(argv[1])-10:atoi(argv[1]): atoi(argv[1])/5])
array2[:] = 5;
else
array2[:] = 10;
for (ii = atoi(argv[1])-10; ii atoi(argv[1]) + (atoi (argv[1])-10);
ii +=atoi(argv[1])/5)
if (array[ii])
array2_check[ii] = 5;
else
array2_check[ii] = 10;
In array notation, the first element is the lower bound,
the second element is the length, which is NOT the size of
array, and the third element is the stride. The size of array
for
array[atoi(argv[1])-10:atoi(argv[1]): atoi(argv[1])/5]
is
atoi(argv[1])-10 + atoi(argv[1])/5 * (atoi(argv[1]) - 1) + 1
Since argv[1] == 10, the size of array is 10 - 10 + (10 / 5) * 9 + 1,
which is 19 and larger than int array[10]. This is invalid.
Shouldn't GCC detect it?
[Bug middle-end/57453] [4.9 Regression] ICE: in operator[], at vec.h:815 with gcc -O3 -fno-strict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57453 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Known to work||4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Seems to be caused by: http://gcc.gnu.org/r199402 2013-05-29 Richard Biener rguent...@suse.de * tree-vect-slp.c (vect_bb_slp_scalar_cost): New function computing scalar cost offsetted by stmts that are kept live by scalar uses. (vect_bb_vectorization_profitable_p): Use vect_bb_slp_scalar_cost for computation of scalar cost.
[Bug c++/57454] New: scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Bug ID: 57454 Summary: scrnsaver bug Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dima.sergeevich at gmail dot com I am compiling(trying) a screen saver. Yes, a I have included scrnsaver.h and compiling with -lscrnsaver. And getting an error: mingw32-g++.exe -o bin\Debug\ScrDemo.exe obj\Debug\main.o -lscrnsave - lgdi32 -lopengl32 -lglu32 c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/../../../libscrnsave.a(scrnsave.o):scrnsave.c:(.text+0x191): undefined reference to `RegisterDialogClasses@4' c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/../../../libscrnsave.a(scrnsave.o):scrnsave.c:(.text+0x50f): undefined reference to `RegisterDialogClasses@4' c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/../../../libscrnsave.a(scrnsave.o):scrnsave.c:(.text+0x527): undefined reference to `ScreenSaverConfigureDialog@16' As you can see i am not using this procedures they are used inside a lib. So i think that it is a bug and waiting for your response. Thank you.
[Bug c++/57404] [4.9 Regression] [C++11] ICE: SIGSEGV in cp_classify_record with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57404 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Started with http://gcc.gnu.org/r198745
[Bug c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is not a GCC bug, the error you get is not even from GCC, it's from the linker, but the problem is almost certainly due to you not linking to a required library, or the order of libraries passed to the linker.
[Bug c/57455] New: internal compiler error: Floating point exception, in seemingly random places
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57455 Bug ID: 57455 Summary: internal compiler error: Floating point exception, in seemingly random places Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: theartlav at gmail dot com Created attachment 30216 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30216action=edit Bug examples System is Intel Atom CPU (eeepc 901 laptop), 32 bit LFS Linux, 3.9.3 kernel. Tried GCC 4.8.0, compiled by itself, GCC 4.7.2 compiled with 4.8.0 and GCC 4.7.2 compiled by itself. During compilation of several different projects, including GCC itself, the compiler produces a internal compiler error: Floating point exception error. This error can often be worked around by reshuffling the statements in the C code being compiled (i.e. changing z=a/(b+c); to x=b+c; z=a/x;). I thought it was a GCC 4.8.0 bug at first, so i compiled GCC 4.7.2, and tried it, but am getting exactly the same errors. Included are reproduction examples from compiling gcc 4.7.2 with itself, and compiling Python 2.7.5 with gcc 4.7.2. With 4.7.2 the errors happen in exactly the same way as with 4.8.0, but i no longer have 4.8.0. If it's critical, i can build it again, and report from it. GCC configuration options: configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --with-system-zlib Full output for cmathmodule.i (comes from Python 2.7.5): gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include -I/usr/local/include -I/mnt/sdc1/bld/Python-2.7.5/Include -I/mnt/sdc1/bld/Python-2.7.5 -c /mnt/sdc1/bld/Python-2.7.5/Modules/cmathmodule.c -o build/temp.linux-i686-2.7/mnt/sdc1/bld/Python-2.7.5/Modules/cmathmodule.o -save-temps -v Using built-in specs. COLLECT_GCC=gcc Target: i686-pc-linux-gnu Configured with: ../gcc-4.7.2/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --with-system-zlib Thread model: posix gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-pthread' '-fPIC' '-fno-strict-aliasing' '-D' 'NDEBUG' '-g' '-fwrapv' '-O0' '-Wall' '-Wstrict-prototypes' '-I' '.' '-I' 'Include' '-I' './Include' '-I' '/usr/include' '-I' '/usr/local/include' '-I' '/mnt/sdc1/bld/Python-2.7.5/Include' '-I' '/mnt/sdc1/bld/Python-2.7.5' '-c' '-o' 'build/temp.linux-i686-2.7/mnt/sdc1/bld/Python-2.7.5/Modules/cmathmodule.o' '-save-temps' '-v' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/cc1 -E -quiet -v -I . -I Include -I ./Include -I /usr/include -I /usr/local/include -I /mnt/sdc1/bld/Python-2.7.5/Include -I /mnt/sdc1/bld/Python-2.7.5 -D_REENTRANT -D NDEBUG /mnt/sdc1/bld/Python-2.7.5/Modules/cmathmodule.c -mtune=generic -march=pentiumpro -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -fwrapv -g -fworking-directory -O0 -fpch-preprocess -o cmathmodule.i ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/include ignoring duplicate directory ./Include ignoring duplicate directory /usr/include as it is a non-system directory that duplicates a system directory ignoring duplicate directory /usr/local/include as it is a non-system directory that duplicates a system directory ignoring duplicate directory /mnt/sdc1/bld/Python-2.7.5/Include ignoring duplicate directory /mnt/sdc1/bld/Python-2.7.5 #include ... search starts here: #include ... search starts here: . Include /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-pthread' '-fPIC' '-fno-strict-aliasing' '-D' 'NDEBUG' '-g' '-fwrapv' '-O0' '-Wall' '-Wstrict-prototypes' '-I' '.' '-I' 'Include' '-I' './Include' '-I' '/usr/include' '-I' '/usr/local/include' '-I' '/mnt/sdc1/bld/Python-2.7.5/Include' '-I' '/mnt/sdc1/bld/Python-2.7.5' '-c' '-o' 'build/temp.linux-i686-2.7/mnt/sdc1/bld/Python-2.7.5/Modules/cmathmodule.o' '-save-temps' '-v' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/cc1 -fpreprocessed cmathmodule.i -quiet -dumpbase cmathmodule.c -mtune=generic -march=pentiumpro -auxbase-strip build/temp.linux-i686-2.7/mnt/sdc1/bld/Python-2.7.5/Modules/cmathmodule.o -g -O0 -Wall -Wstrict-prototypes -version -fPIC -fno-strict-aliasing -fwrapv -o cmathmodule.s GNU C (GCC) version 4.7.2 (i686-pc-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.1.1, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.7.2 (i686-pc-linux-gnu) compiled by
[Bug c++/57402] [4.9 Regression] ICE: in make_decl_rtl, at varasm.c:1147 when initializing variable-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57402 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I somehow can't reproduce this. Yes, I'm using --enable-checking=yes,rtl,df.
[Bug c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 --- Comment #2 from Dmitry dima.sergeevich at gmail dot com --- (In reply to Jonathan Wakely from comment #1) This is not a GCC bug, the error you get is not even from GCC, it's from the linker, but the problem is almost certainly due to you not linking to a required library, or the order of libraries passed to the linker. Wait, i have checked it, the functions as RegisterDialogClasses are declared in scrnsaver. Also, i tried using different order of linking, but it doesn't changes something. And I am thinking that the problem is in libscrnsaver
[Bug fortran/57456] New: [OOP] CLASS ALLOCATE with typespec: Too little memory allocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 Bug ID: 57456 Summary: [OOP] CLASS ALLOCATE with typespec: Too little memory allocated Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following seems to ignore the typespec (t2::) when calculating how much memory is required to allocate: module m implicit none type t integer :: i end type t type, extends(t) :: t2 integer :: j end type t2 end module m program test use m implicit none integer :: i class(t), save, allocatable :: y(:) allocate (t2 :: y(5)) ! Should malloc 2*4*5 = 40 bytes, mallocs only 20 select type(y) type is (t2) do i = 1, 5 y(i)%i = i ! Invalid write of size 4 end do end select deallocate(y) ! SIGABRT: Process abort signal. end
[Bug fortran/57456] [OOP] CLASS ALLOCATE with typespec: Too little memory allocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Note: It works if one uses a scalar instead of an array.
[Bug c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- The functions must be defined in the libscrnsaver; declaring is not enough.
[Bug c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Dmitry dima.sergeevich at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Dmitry dima.sergeevich at gmail dot com --- Marek Polacek, Yes, that is what i wanted to say.
[Bug c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Changing the state back to INVALID.
[Bug c++/57402] [4.9 Regression] ICE: in make_decl_rtl, at varasm.c:1147 when initializing variable-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57402 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz --- Strange, I can still reproduce it with r199397. However, this might be related to PR57404.
[Bug fortran/57456] [OOP] CLASS ALLOCATE with typespec: Too little memory allocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- There is a similar problem for: character(len=:), allocatable :: str(:) allocate (character(len=5) :: str(5)) end * * * To solve this properly, one should put all the logic into gfc_trans_allocate - and avoid duplicating it in gfc_array_init_size (which is called from gfc_array_allocate, which is called from the mentioned gfc_trans_allocate). Note: Also the evaluation of the type-spec length should be done only once for allocate (character(len = f()) :: str(5), str2, str3, str4(10))
[Bug c/57457] New: cilk tests ICE in c-array-notation.c (is_cilkplus_reduce_builtin) on mips*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57457 Bug ID: 57457 Summary: cilk tests ICE in c-array-notation.c (is_cilkplus_reduce_builtin) on mips*-*-* Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Created attachment 30217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30217action=edit Test case to reproduce error A number of cilk tests fail on mips*-*-* due to an ICE. The ICE happens when processing the bsearch function from the system include files and is because we call is_cilkplus_reduce_builtin with a NULL tree. I am not sure if is_cilkplus_reduce_builtin should be checking for NULL or if the fact that it is called with a NULL tree is the problem. Failure: mips-mti-linux-gnu-gcc -c -O1 -fcilkplus y.c y.c: In function 'bsearch': y.c:19:7: internal compiler error: Segmentation fault __comparison = (*__compar) (__key, __p); ^ 0x904fc5 crash_signal /local/home/sellcey/gcc/cilk/src/gcc/gcc/toplev.c:333 0x5176d4 is_cilkplus_reduce_builtin(tree_node*) /local/home/sellcey/gcc/cilk/src/gcc/gcc/c/c-array-notation.c:143 0x4f6ca6 convert_arguments /local/home/sellcey/gcc/cilk/src/gcc/gcc/c/c-typeck.c:2969 0x4f7e8c build_function_call_vec(unsigned int, tree_node*, vectree_node*, va_gc, vl_embed*, vectree_node*, va_gc, vl_embed*) /local/home/sellcey/gcc/cilk/src/gcc/gcc/c/c-typeck.c:2786 0x56db44 c_common_parse_file() /local/home/sellcey/gcc/cilk/src/gcc/gcc/c-family/c-opts.c:1046 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 c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Dmitry dima.sergeevich at gmail dot com changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|INVALID |WONTFIX --- Comment #6 from Dmitry dima.sergeevich at gmail dot com --- Thank you very much for information you hive to me. It helped me VERY much and momently solved the problem. -==- There is no reason for continuing discussion because you don't understand simple thing: the functions SHOULD BE in lib. But they AREN'T defined there.
[Bug c++/57454] scrnsaver bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57454 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|CLOSED |RESOLVED Resolution|WONTFIX |INVALID --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- .
[Bug rtl-optimization/57448] GCSE generates incorrect code with acquire barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57448 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|jleahy+gcc at gmail dot com, |steven at gcc dot gnu.org |stevenb.gcc at gmail dot com | Assignee|unassigned at gcc dot gnu.org |steven at gcc dot gnu.org
[Bug rtl-optimization/54900] write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Aldy Hernandez from comment #5) I am leaving this PR open while I address the corner case presented by Jakub somewhere in this thread: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01763.html ...though technically the testcase in this PR has been fixed :). Maybe open a new PR for those corner cases, and put some test cases in it? Leaving this open without further reference to an actual problem is confusing...
[Bug fortran/57458] New: TS29113: Wrongly rejects noncontiguous argument to assumed-rank when both are volatile/asynchronous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57458
Bug ID: 57458
Summary: TS29113: Wrongly rejects noncontiguous argument to
assumed-rank when both are volatile/asynchronous
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Fortran 2008 has:
'C1239 (R1223) If an actual argument is a nonpointer array that has the
ASYNCHRONOUS or VOLATILE attribute but is not simply contiguous (6.5.4), and
the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS
attribute, that dummy argument shall be an assumed-shape array that does not
have the CONTIGUOUS attribute.'
'C1240 (R1223) If an actual argument is an array pointer that has the
ASYNCHRONOUS or VOLATILE attribute but does not have the CONTIGUOUS attribute,
and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS
attribute, that dummy argument shall be an array pointer or an assumed-shape
array that does not have the CONTIGUOUS attribute.'
TS29113 changes that as follows (pp.36f):
'{In 12.5.2.4 Ordinary dummy variables, paragraph 18, constraint C1239}
Change or an assumed-shape ... attribute to , an assumed-shape array without
the CONTIGUOUS attribute, or an assumed-rank array without the CONTIGUOUS
attribute.'
'{In 12.5.2.4 Ordinary dummy variables, paragraph 18, constraint C1240}
Change or an assumed-shape ... attribute to , an assumed-shape array without
the CONTIGUOUS attribute, or an assumed-rank array without the CONTIGUOUS
attribute.
The edit has not yet been implemented as the following bogus error message
shows:
call foo2(i)
1
Error: Dummy argument 'x' has to be a pointer or assumed-shape array without
CONTIGUOUS attribute - as actual argument at (1) is not simply contiguous and
both are ASYNCHRONOUS or VOLATILE
integer, pointer, asynchronous :: i(:)
call foo(i)
contains
subroutine foo(x)
type(*), dimension(:), asynchronous :: x
end subroutine foo
subroutine foo2(x)
type(*), dimension(..), asynchronous :: x
end subroutine foo2
end
[Bug fortran/57458] TS29113: Wrongly rejects noncontiguous argument to assumed-rank when both are volatile/asynchronous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57458 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Draft patch --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -2033,3 +2033,4 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, actual-rank !gfc_is_simply_contiguous (actual, true) - ((formal-as-type != AS_ASSUMED_SHAPE !formal-attr.pointer) + ((formal-as-type != AS_ASSUMED_SHAPE + formal-as-type != AS_ASSUMED_RANK !formal-attr.pointer) || formal-attr.contiguous)) @@ -2037,6 +2038,6 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, if (where) - gfc_error (Dummy argument '%s' has to be a pointer or assumed-shape - array without CONTIGUOUS attribute - as actual argument at - %L is not simply contiguous and both are ASYNCHRONOUS - or VOLATILE, formal-name, actual-where); + gfc_error (Dummy argument '%s' has to be a pointer, assumed-shape or + assumed-rank array without CONTIGUOUS attribute - as actual + argument at %L is not simply contiguous and both are + ASYNCHRONOUS or VOLATILE, formal-name, actual-where); return 0;
[Bug fortran/54189] ICE (segfault) with invalid assumed-size dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54189
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-05-29
CC||janus at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org ---
Trivial patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 199388)
+++ gcc/fortran/resolve.c(working copy)
@@ -1459,7 +1459,7 @@ check_assumed_size_reference (gfc_symbol *sym, gfc
/* FIXME: The comparison e-ref-u.ar.type == AR_FULL is wrong.
What should it be? */
- if ((e-ref-u.ar.end[e-ref-u.ar.as-rank - 1] == NULL)
+ if (e-ref (e-ref-u.ar.end[e-ref-u.ar.as-rank - 1] == NULL)
(e-ref-u.ar.as-type == AS_ASSUMED_SIZE)
(e-ref-u.ar.type == AR_FULL))
{
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 --- Comment #5 from Dara Hazeghi dhazeghi at yahoo dot com --- Sorry to ask again on this, but after re-reading, I'm not sure I understand the type-punning argument here: **ppll = ll; // write to u.ll *k = 0; // write to u.i j = *ppa; // u not touched ia[0][0] = *j; // u not touched printf(%d\n, u.i); // read from u.i From what I can tell, this is in fact reading the last member written to (so not falling under the unspecified behaviors listed in annex J / 6.2.6.1). Perhaps there is an additional restriction I am missing?
[Bug fortran/57217] [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) * fix assumed-type/rank cases (http://gcc.gnu.org/ml/fortran/2013-05/msg00089.html) cf. also PR 54190
[Bug rtl-optimization/57459] New: LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459
Bug ID: 57459
Summary: LRA inheritance bug
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Created attachment 30218
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30218action=edit
small testcase
To reproduce the bug on using 1.c attached:
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130529 (experimental) (GCC)
$~/workarea/gcc-r199418/build/install/bin/gcc -fno-inline -O2
-minline-all-stringops -fno-omit-frame-pointer -m32 1.c
$./a.out
len = 9
$~/workarea/gcc-r199418/build/install/bin/gcc -O2 -m32 1.c
$./a.out
len = 8
The expanded __builtin_strlen is wrong:
80484c3: 8b 07 mov(%edi),%eax
80484c5: 83 c7 04add$0x4,%edi
80484c8: 8d 90 ff fe fe fe lea-0x1010101(%eax),%edx
80484ce: f7 d0 not%eax
80484d0: 21 c2 and%eax,%edx
80484d2: 81 e2 80 80 80 80 and$0x80808080,%edx
80484d8: 74 e9 je 80484c3 foo+0x63
80484da: 89 d0 mov%edx,%eax
80484dc: 8b 55 ecmov-0x14(%ebp),%edx
80484df: 89 55 e8mov%edx,-0x18(%ebp)
80484e2: 89 c2 mov%eax,%edx
80484e4: c1 e8 10shr$0x10,%eax
80484e7: f7 c2 80 80 00 00 test $0x8080,%edx
80484ed: 89 45 ecmov%eax,-0x14(%ebp)
80484f0: 89 d0 mov%edx,%eax
80484f2: 8d 57 02lea0x2(%edi),%edx
80484f5: 0f 44 facmove %edx,%edi
80484f8: 8b 55 e8mov-0x18(%ebp),%edx
80484fb: 0f 44 45 ec cmove -0x14(%ebp),%eax
80484ff: 00 45 e4add%al,-0x1c(%ebp) Wrong
here, the correct insn is: add %al, %al. %al is either 0x80 or 0x0 here. The
insn add %al, %al is used to check whether %al is 0x80, and it will produce
carry bit for the following sbb. (The lowest 0x80 in %eax shows where the first
'\0' is in the input string)
8048502: 83 df 03sbb$0x3,%edi
8048505: 8b 45 08mov0x8(%ebp),%eax
8048508: 2b 7d 08sub0x8(%ebp),%edi
The IR after IRA and before LRA:
(insn 51 50 52 12 (parallel [
(set (reg:CC 17 flags)
(unspec:CC [
(subreg:QI (reg:SI 79) 0)
(subreg:QI (re(insn 292 50 51 12 (set (reg:QI 118)
(subreg:QI (reg:SI 79) 0)) 1.c:16 87 {*movqi_internal}
(nil))
(insn 51 292 52 12 (parallel [
(set (reg:CC 17 flags)
(unspec:CC [
(subreg:QI (reg:SI 79) 0)
(reg:QI 118)
] UNSPEC_ADD_CARRY))
(set (subreg:QI (reg:SI 79) 0)
(plus:QI (subreg:QI (reg:SI 79) 0)
(reg:QI 118)))
]) 1.c:16 259 {addqi3_cc}
(expr_list:REG_UNUSED (reg:SI 79)
(nil)))g:SI 79) 0)
] UNSPEC_ADD_CARRY))
(set (subreg:QI (reg:SI 79) 0)
(plus:QI (subreg:QI (reg:SI 79) 0)
(subreg:QI (reg:SI 79) 0)))
]) 1.c:16 259 {addqi3_cc}
(expr_list:REG_UNUSED (reg:SI 79)
(nil)))
The IR is correct till now. insn 51 will produce the problematic add
%al,-0x1c(%ebp) finally. All the input and output operands of insn 51 are
reg79. The reg79 gets no hardreg in IRA phase.
The IR after lra_constraints:
(insn 292 50 51 12 (set (reg:QI 118)
(subreg:QI (reg:SI 79) 0)) 1.c:16 87 {*movqi_internal}
(nil))
(insn 51 292 52 12 (parallel [
(set (reg:CC 17 flags)
(unspec:CC [
(subreg:QI (reg:SI 79) 0)
(reg:QI 118)
] UNSPEC_ADD_CARRY))
(set (subreg:QI (reg:SI 79) 0)
(plus:QI (subreg:QI (reg:SI 79) 0)
(reg:QI 118)))
]) 1.c:16 259 {addqi3_cc}
(expr_list:REG_UNUSED (reg:SI 79)
(nil)))
The IR is still correct.
The choosen constraints of insn 51 are rm 0 rn. reg79 get no hardreg in
IRA, so the output operand and the first input operand satisfy the constraint
(staying in mem), but the second input operand should stay in register. That is
why reg118 is introduced and insn 292 is inserted.
The IR after lra_inheritance:
(insn 289 47 48 12 (set (reg:SI 116 [79])
(reg:SI 121 [79])) 1.c:16 85 {*movsi_internal}
(nil))
(insn 48 289 290 12 (set (reg:SI 116 [79])
(if_then_else:SI (eq (reg:CCNO 17 flags)
(const_int 0 [0]))
(reg:SI 122 [83
[Bug rtl-optimization/57459] LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/9070967 This is a 4.8/4.9 regression. We have ~300 test cases (out of 500,000) that are all failing (in i386 mode only) due to this bug.
[Bug fortran/57217] [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) * remove duplication in gfc_check_pointer_assign? (http://gcc.gnu.org/ml/fortran/2013-05/msg00046.html) This apparently does not work: Removing the second call to gfc_compare_interfaces in gfc_check_pointer_assign results (at least) in the following failure: FAIL: gfortran.dg/proc_ptr_result_8.f90 -O (test for errors, line 44)
[Bug rtl-optimization/57459] [4.8/4.9 Regression] LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ra, wrong-code Target Milestone|--- |4.8.1 Summary|LRA inheritance bug |[4.8/4.9 Regression] LRA ||inheritance bug
[Bug c++/57460] New: [C++11] Sfinae doesn't respect dependent context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57460 Bug ID: 57460 Summary: [C++11] Sfinae doesn't respect dependent context Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.kruegler at googlemail dot com gcc 4.9.0 20130519 (experimental) compiled with the flags -std=c++11 -Wall -pedantic-errors rejects the following code: // int get_int(); #define EXPR get_int() templateint static void check(); templateclass T static auto test(decltype(check(EXPR, T())(), T())) - char()[1]; templateclass static auto test(...) - char()[2]; static_assert(sizeof(testint(0)) != 1, Ouch); // complaining: main.cpp|3|error: call to non-constexpr function 'int get_int()'| main.cpp|9|note: in expansion of macro 'EXPR'| Albeit EXPR itself is a non-dependent expression, the overall decltype type declaration in the declaration of the first test overload should be. clang 3.4 accepts the code as well.
[Bug rtl-optimization/57448] GCSE generates incorrect code with acquire barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57448 --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- Created attachment 30219 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30219action=edit Handle ALIAS_SET_MEMORY_BARRIER loads and stores It feels like too-big-a-hammer but I don't see any other way...
[Bug fortran/57461] New: Ice on valid: lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461 Bug ID: 57461 Summary: Ice on valid: lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bugs at stellardeath dot org Created attachment 30220 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30220action=edit Minimal test case, has to be named e.g. input.f90 (or another 5char + .f90 name) to trigger the ICE Trying out a self-compiled gfortran from a few days ago (see below for --version), I stumbled upon an ICE on the attached (apparently) valid code. The ice only happens with _all_ of the following flags: -fbounds-check -finit-real=snan -g3 -fopenmp Unfortunately, the minimal example I reduced out of our code (~1 lines) with delta is with 484 lines still rather large. Is seems mostly to contain an object-oriented module used for timings and some of our helper functions to abort the program with debug prints. Note that the ICE seems incredibly sensitive, when I tried to manually simplify the example code, I discovered that if I do any of the following, the ICE disappears: - Remove the empty and unused module foomod in the first few lines - Rewrite the subroutine raise_warning_x to only accept one argument - Change the name of the subroutine foobar_pwr2 to foobar_pwr - Remove any of the compilation flags given above What struck me as most odd: - If I renamed the file from input.f90 to minimal.f90, it compiled! I experimented a bit with this, and the filename seems to have to be 5 characters + .f90, otherwise it compiles... I really hope anyone can reproduce this bug :) (I could trigger it on at least 3 different machines, however it was always a self-compiled version from trunk, maybe I screwed something up there.) Here is the output of a compilation (see attached file for input.f90): gfortran -fbounds-check -finit-real=snan -g3 -fopenmp -c input.f90 input.f90:293.16: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer input.f90:235.16: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer input.f90:258.22: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer input.f90: In function ‘btr_solve’: input.f90:438:0: internal compiler error: Segmentation fault end subroutine btr_solve ^ 0x9f09ef crash_signal ../.././gcc/toplev.c:333 0x6ab923 lookup_page_table_entry ../.././gcc/ggc-page.c:593 0x6ab923 ggc_set_mark(void const*) ../.././gcc/ggc-page.c:1467 0x89e311 gt_ggc_mx_loop(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:893 0x89da69 gt_ggc_mx_basic_block_def(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:1415 0x89dfc9 gt_ggc_mx_gimple_statement_d(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:1515 0x89f561 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:612 0x89f545 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:610 0x89f545 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:610 0x89f545 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:610 0x89f183 gt_ggc_mx_symtab_node_def(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:717 0x89f630 gt_ggc_m_P15symtab_node_def4htab(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:2908 0x850bd5 ggc_mark_root_tab ../.././gcc/ggc-common.c:133 0x850ed0 ggc_mark_roots() ../.././gcc/ggc-common.c:152 0x6abffe ggc_collect() ../.././gcc/ggc-page.c:2077 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. gfortran --version GNU Fortran (GCC) 4.9.0 20130523 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING This is what happens for a non 5char + .f90 filename: cp input.f90 minimal.f90 gfortran -fbounds-check -finit-real=snan -g3 -fopenmp -c minimal.f90 minimal.f90:293.16: !$ do i = 0, omp_get_level()
[Bug rtl-optimization/57462] New: ira-costs considers only a single register at a time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462
Bug ID: 57462
Summary: ira-costs considers only a single register at a time
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: josh.m.conner at gmail dot com
In this code:
int PopCnt(unsigned long long a, unsigned long long b)
{
register int c=0;
while(a) {
c++;
a = a + b;
}
return(c);
}
Built for ARM with:
gcc test.c -O2 -S -o test.s
The code generated for the loop is:
.L3:
fmdrr d18, r0, r1 @ int
vadd.i64d16, d18, d17
fmrrd r4, r5, d16 @ int
and r0, r0, r4
and r1, r1, r5
orrsr5, r0, r1
add r3, r3, #1
bne .L3
There is quite a bit of gymnastics in order to use the FP registers for the add
instruction. The code is simpler if all registers are allocated to integer
registers:
.L3:
addsr2, r4, r6
adc r3, r5, r7
and r4, r4, r2
and r5, r5, r3
orrsr3, r4, r5
add r0, r0, #1
bne .L3
The code is shorter, and doesn't include the potentially-expensive FP=INT
register move operations.
*** The rest of this bug is my analysis, providing an explanation of why I have
put this bug into the rtl-optimization category.
The problem I see is that the register classifier (ira-costs.c) makes decisions
on register classes for each register in relative isolation, without adequately
considering the impact of that decision on other registers. In this example,
we have 3 main registers we're concerned with: a, b, and a temporary register
(ignoring c, which we don't need to consider). The code when costs are
calculated is roughly:
tmp = a + b
a = a tmp
CC = compare (a, 0)
Both the adddi3 and anddi3 operations can be performed in either integer or FP
regs, with a preference for the FP regs because the sequence is shorter (1 insn
instead of 2).
The compare operation can only be performed in an integer register.
In the first pass of the cost analysis:
a is assigned to the integer registers, since the cheaper adddi/anddi
operations are outweighed by the cost of having to move the value from FP=INT
for the compare.
b and tmp are both assigned to FP registers, since they are only involved
in operations that are cheaper with the FP hardware.
In the second pass of the cost analysis, each register is again analyzed
independently:
a is left in the integer register because moving it to a FP register would
add an additional FP=INT move for the compare.
b and tmp are both left in FP registers because moving either one would
still leave us with mixed FP/INT operations.
The biggest problem I see is that the first pass should recognize that since
a must be in an integer register, there is an unconsidered cost to putting
b and tmp in FP registers since they are involved in instructions where the
operands must be in the same register class.
A lesser, and probably more difficult, problem is that the second pass could do
better if it would consider changing register classes of more than one register
at a time. This seems potentially complex, but perhaps we could just consider
register pairs that are involved in instructions with mismatched operand
classes, where the combination is invalid for the instruction.
