[Bug target/43902] suboptimal MIPS widening multiply accumulate
--- Comment #5 from wilson at gcc dot gnu dot org 2010-05-25 06:30 --- Richard Guenther suggested using DOT_PROD_EXPR. I ran into several problems with that. DOT_PROD_EXPR expands to the sdot_prodM pattern. The mips port is using maddMN. We essentially have two named patterns that are doing the exact same thing, except that one is only used with vector types and one is only used with integer types. The name DOT_PROD_EXPR makes sense for the vector type case, but not so much for the integer type case. sdot_prodM gets installed into the optabs table with mode M. maddMN gets installed into the optabs table with mode N, where N is twice the size of mode M. This complicates lookup, since we need to use different modes for the different operators. All widening integer operations use mode N here, so it seems wrong to change one. sdot_prodM is available in two flavors, signed/unsigned. maddMN is available in 8 flavors, signed/unsigned saturating/non-saturating multiply add/subtract. The subtract part is the hard one, since I can't see any way to get a subtract from a dot product operator. Dot product very strongly implies that you are doing addition, and I know of no equivalent that uses subtraction. dot_prodM patterns are used in 3 md files (i386, ia64, rs6000). maddMN patterns are used in 1 md file (mips). Rather than mess with this, I ended up just adding some new tree operators, WIDEN_MULT_PLUS_EXPR and WIDEN_MULT_MINUS_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug target/43902] suboptimal MIPS widening multiply accumulate
--- Comment #6 from wilson at gcc dot gnu dot org 2010-05-25 06:35 ---
Created an attachment (id=20739)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20739action=view)
second patch attempt, modifying widen_mult tree pass
This removes about 100 lines from expr.c, and adds about 90 lines to
tree-ssa-math, plus unfortunately infrastructure for the new tree codes
WIDEN_MULT_{PLUS,MINUS}_EXPR which is about 70 lines. It works for simple
testcases. Needs a more thorough test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug target/43764] -mrelax-pic-calls fails with complex types
--- Comment #1 from wilson at gcc dot gnu dot org 2010-05-20 06:27 --- Subject: Bug 43764 Author: wilson Date: Thu May 20 06:26:52 2010 New Revision: 159610 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159610 Log: PR target/43764 * mips.c (mips_call_expr_from_insn): New arg second_call. Set it. (mips_annotate_pic_calls): Pass new arg to mips_call_expr_from_insn. Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43764
[Bug target/43764] -mrelax-pic-calls fails with complex types
--- Comment #2 from wilson at gcc dot gnu dot org 2010-05-20 06:27 --- Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-20 06:27:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43764
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #5 from wilson at gcc dot gnu dot org 2010-05-17 20:24 --- A little more debugging. I traced through the true_dependence call that is returning 0 when it should return 1. We end up calling rtx_refs_may_alias_p at the end. This calls refs_may_alias_p_1, which calls indirect_ref_may_alias_decl_p which discovers that we have different non-overlapping alias sets, and it declares that there is no aliasing here. This is last-resort TBAA being used here. We have different alias sets, because one reference is to ... arg 0 var_decl 0xb7d4eba0 vtab$s_bar type record_type 0xb7d4ea80 vtype$s_bar BLK ... and the other is to ... arg 0 indirect_ref 0xb7d74c94 type record_type 0xb7d4e060 vtype$foo BLK ... It appears that the Fortran front end is deliberately confusing the types here, because in the .003t.original dump file I see a.$vptr = (struct vtype$foo *) vtab$s_bar; a.$data = (struct foo *) c; a.$vptr-doit (a); So either the fortran front end needs to get the types right, or else the fortran front end needs to explain to the alias code that these apparently unrelated types do alias. Or maybe the alias code needs to be extended to recognize Fortran OOP types that can alias each other. I didn't look at this. Along the way, I did discover another place where it appears that we can solve the problem. After the get_addr calls in true_dependence, we have mem_addr (if_then_else:DI (eq (value:BI 58:4011 @0x8b22b50/0x8b360e0) (const_int 0 [0])) (plus:DI (value:DI 55:2108434270 @0x8b22b2c/0x8b3608c) (const_int 24 [0x18])) (value:DI 57:57 @0x8b22b44/0x8b360c4)) insn 103 x_addr (plus:DI (value:DI 55:2108434270 @0x8b22b2c/0x8b3608c) (const_int 24 [0x18])) These addresses obviously conflict. Unfortunately, neither memrefs_conflict_p nor rtx_equal_for_memref_p have any support for if_then_else inside an address. If one of them was modified to check for an if_then_else and then recursively compare against both arms of the if_then_else, then that would solve the problem too. This would prevent us from falling through to the last-resort TBAA code that isn't work as desired here. I'm not planning to do any other work on this in the short term, as I have other IA-64 problems I need to try to fix first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #4 from wilson at gcc dot gnu dot org 2010-05-16 02:07 --- The testcase fails with -O2 -funroll-loops. It works with -O2. The problem occurs in main at line 89, which is the second doit call. We get a segfault when dereferencing a null pointer. The code is wrong because of an instruction-scheduling/if-conversion/alias-analysis issue. In the broken assembly output, we have (over simplified) addl r33 = @ltoffx(__s_bar_mod_MOD_vtab$s_bar#), r1 ld8.mov r29 = [r33], __s_bar_mod_MOD_vtab$s_bar# adds r28 = 24, r29 ld8 r26 = [r28] cmp.ne p6, p7 = 0, r31 (p7) adds r31 = 24, r29 (p7) addl r30 = @ltoff(@fptr(__s_bar_mod_MOD_doit#)), gp (p7) ld8 r30 = [r30] (p7) st8 [r31] = r30 ld8 r27 = [r26], 8 And the last instruction segfaults because r26 is 0 when it should be the address of __s_bar_mod_MOD_doit. The load from r28 should not have been moved before the group of conditional instructions. This is correct up to the mach pass, where the IA-64 port runs the second instruction scheduling pass. The first instruction scheduling pass is before if-conversion, so we still have a branch around a block of instructions there. I'm seeing different instruction scheduling and bundle filling with -funroll-loops, though it isn't immediately clear why, as there are no loops here. I'm getting the same code with a x86-linux cross ia64-linux compiler. Just look for the code using __s_bar_mod_MOD_vtab$s_bar and __s_bar_mod_MOD_doit in main. So it should be possible to debug this on an x86-linux machine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-16 02:07:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug target/43902] suboptimal MIPS widening multiply accumulate
--- Comment #4 from wilson at gcc dot gnu dot org 2010-05-03 22:36 --- Created an attachment (id=20552) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20552action=view) trivial solution for original problem This fixes the original problem, but does not fix the new breakage caused by Bernd's patch to add the new optimize_widening_mul pass. So this works at -O but not at -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #5 from wilson at gcc dot gnu dot org 2010-04-26 15:46 --- Created an attachment (id=20495) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20495action=view) initial patch This patch fixes gcc.c-torture/compile/920625-1.c, but unfortunately doesn't fix any of the 3 failures reported in this PR. I will have to revise it and try again. I also noticed that we had support for an obsolete assembler errata warning, and removed that too in this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug target/43897] New: IA-64 asm clobbers are ignored
I noticed this while looking at dependency violations that occur during a gcc
bootstrap. We get two in the libgcc build, both are due to the same problem.
Here is a testcase extracted from libgcc/soft-float/fixunstfti.c.
int
sub (int i)
{
float tmp;
if (i)
__asm__ __volatile__ (frcpa.s0 %0,p1=f0,f0\
: =f (tmp) : : p1 ); \
return i + 10;
}
Compiling this with -O2 gives a DV error because there is a missing stop bit
after the asm. The assembler code has
#APP
// 6 tmp.c 1
frcpa.s0 f6,p1=f0,f0
// 0 2
#NO_APP
.L2:
.mib
adds r8 = 10, r32
mov pr = r2, -1
br.ret.sptk.many b0
The problem is in rtx_needs_barrier in config/ia64/ia64.c, which has
case CLOBBER:
case USE:
/* Clobber use are for earlier compiler-phases only. */
break;
I think this was written in the olden days when we still had reg-no-conflict
blocks and libcall blocks and other stuff that would insert naked clobbers into
the rtl stream. These should be ignored, but I don't think that they will
occur anymore. However, it isn't safe to ignore a clobber inside a parallel,
particularly when that parallel is for an extended asm. This is a serious
problem that needs to be fixed.
The problem can be worked around by using -mvolatile-asm-stop, but this
obviously only works for volatile asms.
--
Summary: IA-64 asm clobbers are ignored
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43897
[Bug target/43902] New: suboptimal MIPS widening multiply accumulate
This testcase
int array1[100], array2[100];
long long
sub (int max)
{
int k;
long long total = 0;
for (k = 0; k max; k++)
total += (long long)array1[k] * (long long)array2[k];
return total;
}
Generates a macc instruction with gcc-3.4.5 when compiled with -O2
-march=sr71000 -mabi=32 -mgp32. This does not generate a macc instruction with
gcc-4.0.0. The difference is that the 32-bit adddi3 pattern was deleted in
between gcc-3.4.5 and gcc-4.0.0. So gcc-3.4.5 generates a 2 insn rtl sequence
which is trivial to combine into a multiply-add insn. But gcc-4.0.0 generates
a 5 insn rtl sequence which will not be combined.
I noticed this on mainline because I should be able to generate widening
multiply-accumulate instructions (madd) with a mipsisa32r2 target with the same
testcase, but I can't.
--
Summary: suboptimal MIPS widening multiply accumulate
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: mips*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug target/43897] [4.4/4.5/4.6 Regression] IA-64 asm clobbers are ignored
--- Comment #2 from wilson at gcc dot gnu dot org 2010-04-26 21:40 --- GCC-4.3 is still broken; my testcase just doesn't happen to fail there. I suspect this is broken all of the way back to gcc-2.95. This does point to where the problem was exposed though. It is the -msched-stop-bits-after-every-cycle patch, which emits stop bits when we hit hardware resource limits. I get accidentally correct code on mainline if I use -mno-sched-stop-bits-after-every-cycle. This patch was added in between gcc-4.3 and gcc-4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43897
[Bug target/43902] suboptimal MIPS widening multiply accumulate
--- Comment #1 from wilson at gcc dot gnu dot org 2010-04-27 01:17 --- Some further investigation shows that there is code in expand_expr_real_2 that is supposed to be able to generate multiply-accumulate instructions, but it isn't general enough. In my gimple, I have D.1999_10 = D.1998_9 * D.1996_7; total_11 = total_19 + D.1999_10; The code in expr.c does - if ((TREE_CODE (type) == INTEGER_TYPE - || TREE_CODE (type) == FIXED_POINT_TYPE) - (subexp0_def = get_def_for_expr (treeop0, - MULT_EXPR))) which fails because the multiply operand is treeop1 not treeop0. We need to check both operands for the multiply here. I have an initial patch that needs testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #8 from wilson at gcc dot gnu dot org 2010-04-21 05:29 --- Subject: Bug 43520 Author: wilson Date: Wed Apr 21 05:29:11 2010 New Revision: 158584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158584 Log: PR rtl-optimization/43520 * ira-lives.c (ira_implicitly_set_insn_hard_regs): Exclude classes with zero available registers. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
-- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-30 23:58:23 |2010-04-21 05:30:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #9 from wilson at gcc dot gnu dot org 2010-04-21 05:31 --- Fixed on mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug rtl-optimization/43809] New: ICE on unconditional divide trap
I originally posted this to the gcc mailing list, and then apparently forgot
about it, so I'm reporting it as a bug before I forget again. This bug report
is a copy of the original message.
http://gcc.gnu.org/ml/gcc/2008-04/msg00336.html
This testcase extracted from libgcc2.c
int
sub (int i)
{
if (i == 0)
return 1 / i;
return i + 2;
}
compiled with -minline-int-divide-min-latency for IA-64 generates an
ICE.
tmp2.c:8: error: flow control insn inside a basic block
(insn 18 17 19 3 tmp2.c:5 (trap_if (const_int 1 [0x1])
(const_int 1 [0x1])) 352 {*trap} (nil))
tmp2.c:8: internal compiler error: in rtl_verify_flow_info_1, at
cfgrtl.c:1920
The problem is that IA-64 ABI specifies that integer divides trap, so we
must emit a conditional trap instruction. cse simplifies the compare.
combine substitutes the compare into the conditional trap changing it to
an unconditional trap. The next pass then fails a consistency check in
cfgrtl.
It seems odd that cfgrtl allows a conditional trap inside a basic block,
but not an unconditional trap. The way things are now, it means we need
to fix up the basic blocks after running combine or any other pass that
might be able to simplify a conditional trap into an unconditional trap.
I can work around this in the IA64 port. For instance I could use
different patterns for conditional and unconditional traps so that one
can't be converted to the other. Or I could try to hide the conditional
trap inside some pattern that doesn't get expanded until after reload.
None of these solutions seems quite right.
But changing the basic block tree during/after combine doesn't seem
quite right either.
The other solution would be to fix cfgbuild to treat all trap
instructions are control flow insns, instead of just the unconditional
ones. I'm not sure why it was written this way though, so I don't know
if this will cause other problems. I see that sibling and noreturn
calls are handled the same way as trap instructions, implying that they
are broken too.
I'm looking for suggestions here as what I should do to fix this.
--
Summary: ICE on unconditional divide trap
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43809
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #2 from wilson at gcc dot gnu dot org 2010-04-19 23:28 --- gcc-c.torture/compiler/920625-1.c would also be failing for the same reason, except it has dg-prune-output hacks to discard the assembler warnings. We should fix the IA-64 compiler, and then eliminate these dg-prune-output hacks in this testcase. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #7 from wilson at gcc dot gnu dot org 2010-04-20 01:17 --- Subject: Bug 43520 Author: wilson Date: Tue Apr 20 01:16:59 2010 New Revision: 158539 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158539 Log: partial fix, make all 'e' class regs fixed PR rtl-optimization/43520 * config/ia64/ia64.h (FIXED_REGISTERS, CALL_USED_REGISTERS): Make ar.lc fixed and call-used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug target/43764] New: -mrelax-pic-calls fails with complex types
Compiling code that calls a function that returns a complex type with
-mrelax-pic-calls results in an ICE.
khazaddum$ cat tmp.c
__complex__ double cd;
__complex__ double foo (void) { return cd; }
void bar (void) { cd = foo (); }
khazaddum$ ./xgcc -B./ -mabicalls -G0 -mrelax-pic-calls -mexplicit-relocs -O -S
tmp.c
tmp.c: In function bar:
tmp.c:3:1: error: could not split insn
(call_insn/i 6 18 7 tmp.c:3 (parallel [
(set (reg:DF 32 $f0)
(call (mem:SI (reg/f:SI 25 $25 [195]) [0 S4 A32])
(unspec [
(const_int 16 [0x10])
(symbol_ref:SI (foo) [flags 0x3] function_decl
0xb74f4000 foo)
] 55)))
(set (reg:DF 34 $f2)
(call (mem:SI (reg/f:SI 25 $25 [195]) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 31 $31))
]) 574 {call_value_multiple_internal} (expr_list:REG_DEAD (reg/f:SI 25
$25 [195])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 79 $fakec))
(nil)))
tmp.c:3:1: internal compiler error: in final_scan_insn, at final.c:2650
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
I used a mipsisa32r2-sde-elf toolchain for this, configured without an
assembler. If you configure properly with an assembler, then it isn't
necessary to give the -mrelax-pic-calls and -mexplicit-relocs options. All you
need it -mabicalls and -G 0.
The problem is in mips_annotate_pic_calls. It looks for a CALL rtx, and then
modifies it. Unfortunately, a function returning complex has a call insn with
2 CALL rtx. Because only one was modified, we end up with unrecognizable RTL.
We either need to disable the optimization in this case, or extend it to work
with a call insn with more than one CALL rtx. The first one is easier, the
second one is preferable.
--
Summary: -mrelax-pic-calls fails with complex types
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: mips*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43764
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #5 from wilson at gcc dot gnu dot org 2010-04-14 21:57 --- I think the first part of the solution here is to make ira stop handling zero-size classes as ones that have a potential register pressure problem. The second part, is that I think we can make ar.lc a fixed register. I think the only reason why it is call-saved is because the ABI says it is call-saved, but the ia64 prologue code has to handle the register specially anyways, so it doesn't matter whether we mark it as call-saved or call-clobbered. Also, all references to it are generated as hard-registers, so it is OK for it to be fixed. There is the off change that someone is incorrectly using a 'e' constraint to put values in the register. We should check for that in a few obvious places like the linux kernel and glibc. If this is true, then we will have to split the 'e' class in two, and ar.lc will have to remain in 'e' and the other two regs will have to move. I did a little checking to see if making ar.lc fixed would work, and I noticed that the handling of doloops is wrong. The default handling is to reject loops with calls, but since ia64 ar.lc is call-saved, we should allow them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #6 from wilson at gcc dot gnu dot org 2010-04-14 21:59 --- Created an attachment (id=20381) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20381action=view) untested patch that works for testcase This is logically 3 different patches that can be handled separately. The doloop hook change needs performance testing to verify that it is useful. The patch to make ar.lc fixed needs to be double checked with the kernel and glibc to make sure we don't break them. The ira patch needs approval from an ira maintainer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #4 from wilson at gcc dot gnu dot org 2010-04-09 21:34 --- I don't think this is documented anywhere. Not in gcc at least. POSIX says that for command line arguments -a -d, -d -a, -da, and -ad are all equivalent. Many GNU tools do not conform to this rule. A long time ago there was a push to try to fix all GNU tools. The GNU solution was based on the idea that POSIX says nothing about command line arguments that start with two dashes, so we only had to ensure that all long options started with two dashes. For GCC, step1 of the solution was to add a translation table to map new --X options to existing options. To make the translation table shorter, there was a default rule added for -f options, so that we didn't have to list them all. Hence any -- option not already in the table is assumed to be a -f option. There was no step2 GCC solution, as people stopped caring, and then people started forgetting why we were even doing this. Anyways, printing the translated option name in an error message is wrong, and should be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
--- Comment #1 from wilson at gcc dot gnu dot org 2010-04-04 01:34 --- This is failing due to invalid rtl unsharing. The asm has two dests. We end up with a parallel with two sets, and the ASM_OPERAND_INPUT_VEC in each SET_SRC is supposed to be the same rtl pointer. This is checked by asm_noperands. This is necessary for reg-alloc to handle the asm correctly. The invalid unsharing happens in the file sel-sched-ir.c in the function create_copy_of_insn_rtx. It has code res = create_insn_rtx_from_pattern (copy_rtx (PATTERN (insn_rtx)), NULL_RTX); This won't work. You can't use copy_rtx to copy an insn. You must use copy_insn. See the code and comments in emit-rtl.c. This problem can be fixed by changing the copy_rtx to copy_insn, but I'm concerned that there may be other places in sel-sched*.c that also need fixing. I don't know the code well enough to be able to easily tell which copy_rtx calls are broken. The testcase works on mainline, but the bug appears to still be there. This testcase just doesn't trigger it. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-04 01:34:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603
[Bug rtl-optimization/43520] gcc.dg/pr43058.c uses way too memory on ia64
--- Comment #4 from wilson at gcc dot gnu dot org 2010-03-30 23:58 --- I've confirmed that Vlad's -fsched-pressure patch is the problem, and done a bit more analysis to see why. The testcase has approximately 20,000 movdi_internal insns, 6000 movsi_internal insns, and 10,000 call_value_gp insns. The ia64 movdi_internal patterns has constraints 'd' for memory pipeline application registers and 'e' for integer pipeline application registers. The 'd' class has 2 regs, both fixed. The 'e' class has 3 regs, two fixed. Since the two classes have only 0 and 1 allocatable register each, the -fsched-pressure patch puts them in implicit_reg_pending_clobbers. The movsi_internal pattern also uses 'd', so it is handled similarly. So we end up with all 26,000 move insns on the reg_last-implicit_sets list. Meanwhile, because we have 4 fixed registers, every call insn is assumes to use these registers. Thus we end up with all 10,000 call insns on reg_last-uses. Since we create a dependency between implicit_sets and uses, that means we end up with approx 260M dependencies, each 40 bytes each, which is 10GB. Plus memory for insns lists and other stuff. The convention is that there is only supposed to be one mov* pattern, since reload does not re-recognize, so it doesn't appear to me that the ia64.md file is doing anything wrong. We could reduce the problem if the fixed registers were split out into separate move insns though. We still have the one not-fixed register (ar.lc), but it isn't call clobbered either, so I think that one might be OK. I haven't tested that theory yet. We would need to split the 'e' class to separate the fixed and non-fixed registers. Another option here would be to have a special letter like '*' and '#' except that it can be used to disable the register-pressure code. We still need to split the 'e' class for this, since we still want the register-pressure code for the non-fixed register (ar.lc). This would require fewer changes to the ia64 port than the above option. Another option here is to throttle the reg_last-use and/or reg_last-implicit_sets lists somehow. We could just keep a count of them and arbitrarily flush them when they get too big. There is already code to do this that uses uses_length and clobbers_length. Adding a implicit_sets_length might help. There is code to free a list when we see a set, but the testcase does not have sets for 4 of the 5 registers, so the lists do not get freed this way. The current code that tests uses_length and clobber_length only triggers if there is a clobber, and again there are no clobbers of any of the 5 registers here. The lists will only get freed if we flush them some how in the implicit_sets handling code. Or maybe we could try to keep trace of reads and writes better. If we have a series of implicit sets followed by a series of uses followed by some more implicit sets, then we can actually flush the implicit_set list when we see the second set of implicit sets. This is because every use will depend on every implicit set in the first group, and every implicit set in the second group will depend on every use, so there is no need to retain the insns in the first group in the implicit set list. Similarly, we can free insns from the use group when we see a second set of uses. Another option here is to make -fno-sched-pressure disable the code that sets implicit_reg_pending_clobbers, though this isn't a fix, just a workaround. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-30 23:58:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #16 from wilson at gcc dot gnu dot org 2010-03-23 00:58 --- The testcase checked into mainline is causing kernel panics on my debian testing ia64-linux machine when I run the gcc testsuite. The kernel panic is coming from the out-of-memory killer, when it runs out of processes to kill. I have 2GB main memory and 2GB swap. I tried a x86-linux hosted cross compiler to ia64-linux, and I see the cc1 process uses 3GB before the kernel kills it. I suspect a 32-bit x86-linux process can't use more than 3GB. I don't know how much memory is needed for this testcase, but it is clearly too much. ia64-linux isn't a primary target, so this is maybe not P1 if only ia64-linux is still broken. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604
--- Comment #9 from wilson at gcc dot gnu dot org 2010-03-23 01:16 --- Subject: Bug 43348 Author: wilson Date: Tue Mar 23 01:16:10 2010 New Revision: 157659 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157659 Log: PR target/43348 * ia64.md (call_nogp, call_value_nogp, sibcall_nogp, call_gp, call_value_gp,sibcall_gp): Use 's' constraint not 'i'. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/ia64/ia64.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348
[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604
--- Comment #10 from wilson at gcc dot gnu dot org 2010-03-23 01:22 --- Subject: Bug 43348 Author: wilson Date: Tue Mar 23 01:22:28 2010 New Revision: 157660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157660 Log: PR target/43348 * ia64.md (call_nogp, call_value_nogp, sibcall_nogp, call_gp, call_value_gp,sibcall_gp): Use 's' constraint not 'i'. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348
[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604
--- Comment #11 from wilson at gcc dot gnu dot org 2010-03-23 01:36 --- Fixed on gcc-4.4 branch and mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348
[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604
--- Comment #7 from wilson at gcc dot gnu dot org 2010-03-17 01:50 --- Created an attachment (id=20121) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20121action=view) untested patch for gcc-4.4 We will also need an equivalent patch for mainline/4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #6 from wilson at gcc dot gnu dot org 2010-03-15 04:08 --- I can reproduce the original problem with 28490 by changing the line in ia64_legitimate_constant_p from return (addend 0x3fff) == 0; to return true; and compiling the testcase with -O. What happens is that in reload.c we see a REG_EQUAL note with symbol+8 and put it in reg_equiv_constant because it is accepted by LEGITIMATE_CONSTANT_P. This then gets substituted into a SET_SRC. Except that this insn now requires a scratch register, and we are after reload, so we end up aborting. The traditional solution for this is to define LEGITIMATE_PIC_OPERAND_P so that it rejects symbol+const when it would require a scratch register. See the sparc port for instance. However, this works only if flag_pic is set. IA-64 is PIC always, and we use flag_pic for shared libraries, so we can't just set it. Or at least, I'm not sure what will happen if we set it, and I don't want to spend that much time looking into it. Another traditional solution is to rewrite pic symbols in such a way that they can't be recognized as constants anymore, for instance, by putting them inside unspecs. This is ugly, and I only mention it for completeness. I don't recommend fixing the problem this way. It might be tempting to check for reload_in_progress, but unfortunately the LEGITIMATE_CONSTANT_P check in reload1.c comes before reload_in_progress is set, so that won't work. And messing with reload isn't a good idea, so we shouldn't try moving where reload_in_progress is set. That leaves the currently_expanding_to_rtl solution. We can accept any constant if that var is true, and we use the current code if that var is false. I think this is the second best solution after the LEGITIMATE_PIC_OPERAND_P solution. I tried this, and found that it is an imperfect solution. I don't get a core dump for 28490, and I don't get a constant pool entry for the 42040 testcase. Unfortunately, I do now get a constant pool entry for the 28490 testcase. Because symbol+8 is no longer a LEGITIMATE_CONSTANT_P, reload decides to call force_const_mem and put it in reg_equiv_memory_loc. So this solution doesn't completely eliminate the constant pool entries, but it will eliminate most of them. To eliminate all of them, we would have to get the LEGITIMATE_PIC_OPERAND_P solution working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #7 from wilson at gcc dot gnu dot org 2010-03-15 04:11 --- Created an attachment (id=20106) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20106action=view) untested patch, imperfect solution -- wilson at gcc dot gnu dot org changed: What|Removed |Added Attachment #20097|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #3 from wilson at gcc dot gnu dot org 2010-03-13 03:06 --- Created an attachment (id=20097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20097action=view) Untested patch that works for sje's testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42953] New: bad epilogue scheduling leads to stack corruption
The svr4 ABI requires that r1 (SP) always be valid, so it must be restored at the end of the epilogue, after the last register restore read from the stack frame. Unfortunately, in some cases, the PPC port is scheduling the epilogue set of r1 before some register restores. If you take an interrupt in between the r1 set and a register restore, and the interrupt handler uses the process stack, the interrupt handler may overwrite saved registers before they can be restored. This causes difficult to debug failures. I can reproduce the failure with -O2 -fno-omit-frame-pointer. I don't know if the problem can be triggered with other optimization options. The PPC port tries to prevent the r1 set from being moved before register restores by emitting a stack_tie instruction. This uses a BLKmode read from the stack frame, which in theory should conflict with the register reads and the set of r1. But this fails because of how reg_base_value works in alias.c. The PPC port is using a temp register r11 in the epilogue. In my testcase, r11 is set in the function body to the address of a variable in data. The code that sets reg_base_value, in init_alias_analysis in alias.c, deliberately ignores instructions in the prologue and epilogue. Thus it sees only one store to r11, and decides that r11 must hold a data variable address everywhere in the function. When we check stack reads (using r11) against the stack_tie insn (using r1), alias analysis decides that they can't conflict because r1 points to the stack and r11 points to data. Thus incorrect insn scheduling occurs. This seems to be a flaw in alias analysis. If we aren't going to count prologue/epilogue insns when computing reg_base_value, then we should not use reg_base_value when disambiguating insns in the prologue/epilogue. Unfortunately, the interface to alias is passing in only MEMs, not insns, so we can't easily tell when we have a prologue/epilogue MEM. A possible simple way to solve the problem is to use a stricter stack_tie insn. I noticed that the ARM port has one that uses (mem:BLK (scratch)). If I hack this into the rs6000 port, then this problem goes away. Testing for this is one of the first things that write_dependence_p does, so this prevents any possible reg_base_value confusion. This only fails if I get a symbol address into r11, and r11 is only set once, so it is a bit tricky to reproduce with small examples. I do have a testcase that works with gcc mainline which I will attach. -- Summary: bad epilogue scheduling leads to stack corruption Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilson at gcc dot gnu dot org GCC target triplet: powerpc-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42953
[Bug target/42953] bad epilogue scheduling leads to stack corruption
--- Comment #1 from wilson at gcc dot gnu dot org 2010-02-04 07:30 --- Created an attachment (id=19801) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19801action=view) testcase for gcc mainline (rev 156310) GCC generates incorrect epilogue code for this testcase with -O2 -fno-omit-frame-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42953
[Bug target/42953] bad epilogue scheduling leads to stack corruption
--- Comment #2 from wilson at gcc dot gnu dot org 2010-02-04 07:34 --- Created an attachment (id=19802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19802action=view) Assembly code showing bad epilogue scheduling. This was generated with -O2 -fno-omit-frame-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42953
[Bug bootstrap/40706] gcc doesn't compile on centos3 64bit
--- Comment #4 from wilson at gcc dot gnu dot org 2009-07-18 20:05 --- build/genmodes -h tmp-modes.h /bin/sh: line 1: build/genmodes: No such file or directory make: *** [s-modes-h] Error 127 This is the error you can get when a program interpreter does not exist. More recent linux versions will print a better error message, but old ones do give this ambiguous message for this problem. For an ELF binary linked against glibc, the program interpreter is ld.so. Maybe you are missing some library files? build/genmodes is incidentally the first binary we will run that was compiled by the just built gcc, so a configure error sometimes shows up as a build/genmodes failure. Try running ldd build/genmodes. You might also try objdump --full-contents --section .interp build/genmodes. If either of these list non-existent files in the output, then that is the problem. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40706
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #6 from wilson at gcc dot gnu dot org 2009-05-09 01:21 --- It looks like this was fixed by Michael Matz here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html This patch was added to gcc-4.3, and the gcc-4.2 branch is closed, so I think this bug should be closed resolved. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide
--- Comment #10 from wilson at gcc dot gnu dot org 2008-04-14 23:47 --- Fixed on mainline and 4.3 branch. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug debug/35925] -g1 causes Error: file number 1 already allocated
--- Comment #1 from wilson at gcc dot gnu dot org 2008-04-14 23:56 --- There is a conflict between the gcc and gas debug info support here. This can't be fixed in gcc. It will have to be fixed in binutils. -g1 tells gcc to emit debug info, but not line number info. We do emit file and line number info for function definitions. This involves emitting a .file 1 tmp.c directive to add an entry to the dwarf2 file table. -g tells gas to try to emit debug info. Gas sees that there is no line number info, and so tries to generate some itself. However, gas is allocating entries from the same dwarf2 file table that gcc is allocating from, leading to conflicts. Since gcc runs first, gcc can't avoid the conflicts. I can make this work for a trivial example if I change gcc to emit the .file directive for function info earlier. However, this doesn't solve the problem, it just delays it. If I change the testcase so that it includes another source file, then it fails again, this time complaining that file number 2 is already used. This one is impossible to fix in gcc. Binutils needs to be changed to either not emit line number debug info for a file compiled with gcc -g1, or else to allocate virtual file numbers for its debug info, and then only give them physical file numbers when it is finished parsing the entire file, and hence knows how many file numbers that gcc used. I suggest filing a bug with the binutils folks pointing back at this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35925
[Bug middle-end/35885] unsigned long long and while loop evaluation regression?
--- Comment #5 from wilson at gcc dot gnu dot org 2008-04-15 00:25 --- Gcc-2.5.8 uses the code I suggested was correct. gcc-2.6.3 does not. The ChangeLog entry is Fri Aug 5 12:29:42 1994 Jim Wilson ([EMAIL PROTECTED]) * expmed.c (expand_mult): Accept DImode for synth_mult only if CONST_DOUBLE_HIGH is zero. Reject negative values for synth_mult if the mode is larger than HOST_BITS_PER_INT. Don't do the negate_variant if the mode is larger than HOST_BITS_PER_INT. So it seems that we used to allow any constant that would fit in a signed HWI, then I found a bug with negative values so I changed it to any constant that would fit in an unsigned HWI. Now we found another bug with a constant that doesn't fit in a signed HWI but does fit in an unsigned HWI. So now the apparent solution is to only accept positive values that fit in a signed HWI. But of course such values should never be found in a CONST_DOUBLE anyways. If they fit in a signed HWI they would have been emitted as a CONST_INT in the first place. I think we should just drop all of this CONST_DOUBLE nonsense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
[Bug translation/35177] Error in the french traduction
--- Comment #1 from wilson at gcc dot gnu dot org 2008-04-15 01:03 --- Translation errors must be reported to the FSF translation team instead of to us. I have forwarded this to the French translation team. See http://translationproject.org/team/index.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35177
[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide
--- Comment #9 from wilson at gcc dot gnu dot org 2008-04-12 16:48 --- Subject: Bug 35695 Author: wilson Date: Sat Apr 12 16:47:55 2008 New Revision: 134222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134222 Log: PR target/35695 * config/ia64/div.md (recip_approx_rf): Use UNSPEC not DIV. * config/ia64/ia64.c (rtx_needs_barrier): Handle UNSPEC_FR_RECIP_APPROX_RES. * config/ia64/ia64.md (UNSPEC_FR_RECIP_APPROX_RES): Define. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/ia64/div.md branches/gcc-4_3-branch/gcc/config/ia64/ia64.c branches/gcc-4_3-branch/gcc/config/ia64/ia64.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide
--- Comment #7 from wilson at gcc dot gnu dot org 2008-04-07 23:48 --- Anyone care whether this gets fixed in 4.3? If so, are you willing to test it? I'll approve it for 4.3 with proper testing, which is not easy for me to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #2 from wilson at gcc dot gnu dot org 2008-04-03 06:27 --- Created an attachment (id=15418) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15418action=view) ia64.h patch to define REGNO_OK_FOR_INDIRECT_JUMP_P Obvious definition of the REGNO_OK_FOR_INDIRECT_JUMP_P macro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #3 from wilson at gcc dot gnu dot org 2008-04-03 06:29 --- Created an attachment (id=15419) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15419action=view) rtl-factoring.c patch to allocate second reg for IA-64 This allocates a second register if REGNO_OK_FOR_INDIRECT_JUMP_P is defined, and then adjusts the code appropriately to use the second reg. This obviously needs some cleanup, I didn't give it much thought. It seems to be working for the simple testcase though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug target/35364] ICE on ia64 with vector declaration inside #pragma omp parallel
--- Comment #5 from wilson at gcc dot gnu dot org 2008-04-01 06:31 --- Created an attachment (id=15401) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15401action=view) tree-eh.c optimize_double_finally patch This patch works for the testcase, but is otherwise untested. My knowledge in this area is limited, so this needs to be reviewed by someone with more tree-ssa and tree-eh knowledge than me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35364
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
--- Comment #6 from wilson at gcc dot gnu dot org 2008-03-31 19:52 --- Subject: Bug 35695 Author: wilson Date: Mon Mar 31 19:51:50 2008 New Revision: 133772 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133772 Log: PR target/35695 * config/ia64/div.md (recip_approx_rf): Use UNSPEC not DIV. * config/ia64/ia64.c (rtx_needs_barrier): Handle UNSPEC_FR_RECIP_APPROX_RES. * config/ia64/ia64.md (UNSPEC_FR_RECIP_APPROX_RES): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/div.md trunk/gcc/config/ia64/ia64.c trunk/gcc/config/ia64/ia64.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
-- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-31 20:22:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug middle-end/35781] [4.4 Regression]: Revision 133759 breaks ia64
--- Comment #4 from wilson at gcc dot gnu dot org 2008-04-01 02:54 --- Created an attachment (id=15400) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15400action=view) patch for cfun-emit rtl.emit changes I tested this patch with a C only bootstrap on an ia64-linux system. The bootstrap completed successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35781
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
--- Comment #3 from wilson at gcc dot gnu dot org 2008-03-27 05:54 --- Created an attachment (id=15385) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15385action=view) Itanium reciprocal approximation bug fix Untested patch produced with wrong (default) svn diff options. Should probably make the same change to the other recip approx patterns in ia64.md. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c
--- Comment #2 from wilson at gcc dot gnu dot org 2008-03-18 04:02 --- Subject: Bug 35512 Author: wilson Date: Tue Mar 18 04:01:21 2008 New Revision: 133301 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133301 Log: PR testsuite/35512 * gcc.target/ia64/visibility-1.c (foo): Change return type to void. Write variables instead of reading them. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/ia64/visibility-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35512
[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c
--- Comment #3 from wilson at gcc dot gnu dot org 2008-03-18 04:06 --- Mine. IA-64. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35512
[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c
--- Comment #4 from wilson at gcc dot gnu dot org 2008-03-18 04:06 --- Fixed. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35512
[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include
--- Comment #6 from wilson at gcc dot gnu dot org 2008-02-01 23:39 --- Configuring --without-x is a possible workaround. I haven't tried it. I also haven't tried to reproduce the problem. The problem comes from the AC_PATH_XTRA call in libjava/configure.ac. This is a documented autoconf feature to get info about X header files and libraries. So now we have to look in the autoconf sources. AC_PATH_XTRA calls AC_PATH_X. If X is enabled, and x_includes/x_libraries have not already been specified, then _AC_PATH_X is called. _AC_PATH_X then calls _AC_PATH_X_XMKMF. _AC_PATH_X_XMKMF then does something clever. It creates an Imakefile that just echos the value of some Imakefile variables, it runs xmkmf to convert the Imakefile into an X makefile, then it runs make to echo out the expanded values of the X Imakefile variable values, and uses them to set x_includes and x_libraries. The problem here of course is that xmkmf is a host tool, which is being run directly (i.e. no macro to override), and will always return paths valid on the host. Which is wrong for a cross compiler. Though I suppose we could try overriding the _AC_PATH_X_XMKMF function itself. I only took a quick look at this, so I don't know why this is breaking for some and working for others. Perhaps it matters whether you have X headers and libraries in your sysroot. Perhaps it matters whether you use a sysroot. It clearly does matter whether you have xmkmf installed on your host machine. If you don't have xmkmf installed (which is part of the imake package), then you presumably won't have this problem. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug target/34637] ICE in rws_insn_set, at config/ia64/ia64.c:5335
--- Comment #3 from wilson at gcc dot gnu dot org 2008-01-11 21:23 --- The ia64 code to insert stop bits has a built-in assumption that if we see a register set twice in the same instruction, then we goofed, and must ICE. The testcase has an extended asm with 3 outputs and 4 inputs. None of the outputs are used after the asm. The register allocator decided to assign two of the outputs to the same hard register which is OK if they are never used. But they are used inside the asm, so this won't work. If I mark the outputs as early clobber, i.e. change : =r (compare_value) , =r (exchange_value) , =r (sum) to : =r (compare_value) , =r (exchange_value) , =r (sum) Then there is no ICE, and I also get correct code. So we need to fix the asm at a minimum. It doesn't appear to be from gcc code. We might also need to fix the ia64 backend to allow the same reg to be written twice by the same insn, since it can occur as this testcase shows. Though this testcase is broken, there might be some valid way that this can occur. Maybe just allowing this for asms is OK. Or maybe just emitting a friendlier error message here is OK. That was for mainline. I checked the gcc-4.1 branch, and this is the same problem, except that all 3 outputs got assigned to the same hard register. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-11 21:23:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34637
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #10 from wilson at gcc dot gnu dot org 2008-01-11 21:42 --- Subject: Bug 26015 Author: wilson Date: Fri Jan 11 21:42:03 2008 New Revision: 131477 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131477 Log: PR target/26015 * config/vax/elf.h (FRAME_POINTER_CFA_OFFSET): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/vax/elf.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #12 from wilson at gcc dot gnu dot org 2008-01-11 21:52 --- Fixed on mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #11 from wilson at gcc dot gnu dot org 2008-01-11 21:50 --- Mine, as I wrote a patch for it. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/34266] ICE
--- Comment #1 from wilson at gcc dot gnu dot org 2008-01-09 19:11 --- This is the same problem as PR 31684, which is fixed on mainline (pre-release gcc-4.3) but not on the gcc-4.2 branch. *** This bug has been marked as a duplicate of 31684 *** -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34266
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #8 from wilson at gcc dot gnu dot org 2008-01-09 19:11 --- *** Bug 34266 has been marked as a duplicate of this bug. *** -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||kate01123 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug bootstrap/34259] Compile gcc 3.4.6 on tru64 unix v5.1b problem with yacc syntax
--- Comment #2 from wilson at gcc dot gnu dot org 2008-01-08 23:20 --- GCC is assuming use of GNU bison instead of yacc here. Install GNU bison, reconfigure, and the problem will go away. GCC release tar balls have pre-generated output files with appropriate file time stamps, so that end users do not need bison or other tools in order to do a build. If you use one of these unchanged, then you should not have this problem. However, if you extract a release, and then do anything that changes file timestamps (make a copy, check it into a Source Code Management repository, etc), then you will need bison and other tools in order to do a build. If you check out a release from the GNU GCC repository, then the same rules apply. If you use a snapshot from the GNU GCC ftp site, then the same rules apply. Etc. Alternatively, you can always do something like touch intl/plural.c to fix the timestamps, and prevent make from trying to rebuild the file. You might have to do this for multiple files. The command contrib/gcc_update --touch should do this for you, but I haven't tried it. Information about tools needed to work on gcc can be found here: http://gcc.gnu.org/install/prerequisites.html Bison is mentioned as necessary for *.y files. gcc-3.4 is no longer maintained from GNU GCC developers, so if there is a bug here, we aren't going to fix it, unless it also exists in a current GCC release. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34259
[Bug bootstrap/34126] [4.3 regression] bootstrap: build/genmodes missing
--- Comment #4 from wilson at gcc dot gnu dot org 2007-11-16 22:37 --- This problem occurs if you accidentally run ../gcc/gcc/configure instead of ../gcc/configure I've tried looking at make -d output, and there isn't enough info there to see what is going wrong. In the second case, the implicit rule build/gen%$(build_exeext) is found. If the first case, the implicit rule is not found, and hence we perform no action when making build/genmodes, resulting in a non-existent file when we later try to run it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34126
[Bug tree-optimization/33655] [4.3 Regression] ICE in bitfield_overlaps_p, at tree-sra.c:2901
--- Comment #7 from wilson at gcc dot gnu dot org 2007-10-08 22:19 --- Created an attachment (id=14324) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14324action=view) add another conversion to bitsizetype Here is an patch to fix the IA-64 failure for this testcase. This makes the testcase work (i.e. gcc doesn't ICE), but has not been otherwise tested as yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33655
[Bug target/33532] bogus escape
--- Comment #5 from wilson at gcc dot gnu dot org 2007-09-24 22:53 --- Echoing what Andrew Pinski already said, this isn't C code, this is RTL code, the format of which is specified by the read-rtl.c file. Specifically, see the read_brace_string function, which accepts backslash quoting exactly the same as the read_quoted_string function. Unless you are proposing a change to the read_brace_string function, there is nothing wrong with this code. Though I will admit that the backslashes are unnecessary here and could optionally be removed without harm. If you are proposing changes to the read_brace_string function, it would have been nice to mention that. If you want to find all such problems, changing this function is probably the easiest way to do that. If you want to prevent such problems from being reintroduced later, then you would definitely have to change this function. Maybe add an argument to the read_escape function so that we can handle calls from read_quoted_string differently than calls from read_brace_string? I have no idea at the moment why this matters to you. A little context might be helpful. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-24 22:53:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33532
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #7 from wilson at gcc dot gnu dot org 2007-07-02 20:34 --- Created an attachment (id=13831) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13831action=view) enable INCOMING_RETURN_ADDR_RTX for ia64 This is a patch based on Kenny's suggestion. I think this patch solves the problem nicely, but it hasn't been tested with an ia64 build yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #1 from wilson at gcc dot gnu dot org 2007-05-01 01:53 --- It dies in recog because of an invalid extended asm insn rtl. In an asm with 2 or more outputs, we end up with 2 or more copies of the input vector. These vectors must be shared. They are not in this case. The problem occurs in haifa-sched, in the speculative instruction support. It uses copy_rtx to make a copy of an insn when speculatively scheduling it. However, copy_rtx does not preserve the special sharing semantics of asm operands, so the result is a corrupted insn. There exists a special routine copy_insn to solve this problem. So the solution here is to just replace the copy_rtx call with a copy_insn call. This works on mainline for this testcase but is not otherwise tested. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-01 01:53:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #2 from wilson at gcc dot gnu dot org 2007-05-01 01:56 --- Created an attachment (id=13466) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13466action=view) Replace copy_rtx call with copy_insn call. This works on mainline for the testcase, but has not otherwise been tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug debug/31230] debug information depends on gc parameters
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-30 22:44 --- I can reproduce the problem using the provided testcase. It looks like all we have to do is mark the array type TYPE_DOMAIN as used, to prevent it from being garbage collected. This just requires adding an equate_type_number_to_die call, which should be harmless by itself, I think. This solves the problem for the provided testcase. I haven't done a bootstrap or gdb testsuite run to test the patch yet. It might be nice to try to reuse this info, via lookup_type_die, now that we have saved it. Unfortunately, the dwarf3 standard doesn't have any provision for this. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-30 22:44:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
[Bug debug/31230] debug information depends on gc parameters
--- Comment #3 from wilson at gcc dot gnu dot org 2007-03-30 22:49 --- Created an attachment (id=13304) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13304action=view) Add equate_type_number_to_die call to prevent garbage collection. This patch is untested, but works for the testcase in the bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
[Bug bootstrap/31235] Bootstrap comparison failure with -gstabs
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-31 02:23 --- I was able to reproduce this on an x86_64-linux machine following the instructions. Assuming this is the same conceptual problem as 31230, I tried the same patch, in another file. Just marking the array type domain type as used so it wouldn't be garbage collected. It was a little harder here since we didn't have a convenient subroutine to call, so I had to move some code out of dbxout_type into a new function, but effectively there is only a one line actual code change here. This survived a C-only BOOT_CFLAGS=-gstabs bootstrap, which seems to be good evidence that it is working. This patch is otherwise untested. It needs a full bootstrap, gcc testsuite run, and gdb testsuite run. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-31 02:23:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31235
[Bug bootstrap/31235] Bootstrap comparison failure with -gstabs
--- Comment #3 from wilson at gcc dot gnu dot org 2007-03-31 02:24 --- Created an attachment (id=13305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13305action=view) Mark array TYPE_DOMAIN as used to prevent garbage collection. This has been tested with a C only BOOT_CFLAGS=-gstabs bootstrap. It needs a full bootstrap, gcc testsuite run, and gdb testsuite run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31235
[Bug c/31233] obstack.h typo
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 21:32 --- In theory, obstack.h is imported from the FSF gnulib package, though unfortunately that isn't documented in our codingconventions.html web page, and it looks like people have just been modifying it in place. The parent package is here http://savannah.gnu.org/projects/gnulib#options Looking at the cvs history, it looks like this was broken in revision 1.24 and fixed in revision 1.32, so we should be able to import a fixed version of this file to fix this bug report. Except that we will have to deal with local changes somehow. They really should be pushed to the FSF is they aren't already there. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 21:32:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31233
[Bug c/31273] Erroneous bitfield conversions to boolean values
--- Comment #1 from wilson at gcc dot gnu dot org 2007-03-19 23:49 --- I'm not a C++ expert, so I'm not the right person to say for sure, but this looks like an accidental bug to me. There were patches added to change the bitfield type representation, the is_bitfield_expr_with_lowered_type change, which is for PR 26534. I believe these patches have a bug. It looks to me like the bug is in standard_conversion in cp/calls.c at these lines if (bitfield_type) from = strip_top_quals (bitfield_type); This sets from, but fails to set fcode, resulting in an inconsistency. In this case, fcode is INTEGER_TYPE and from is now an enumeral type after originally being an integer type. This causes a failure further down in the tcode == BOOLEAN_TYPE code where we fail to match the conditions due to this inconsistency. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c/31273] Erroneous bitfield conversions to boolean values
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 23:52 --- Created an attachment (id=13236) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13236action=view) proposed cp/call.c patch for suspected standard_conversion bug This is the proposed patch I referred to in my analysis. It works for the testcase, but has not otherwise been tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug target/30687] undocumented attributes on ia64
--- Comment #1 from wilson at gcc dot gnu dot org 2007-02-05 22:10 --- Model and version_id are already documented. It is only syscall_linkage that is undocmented, and that would be my fault. Meanwhile, you can find info about it in the gcc sources, in the file gcc/config/ia64/ia64.c. The overlapping register windows implemented by the IA-64 architecture can cause kernel internal data to leak out to user processes if one is not careful. The syscall_linkage attribute modies the ABI slightly to prevent this, and it should be used on user entry points to the kernel. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-05 22:10:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30687
[Bug c/30592] New: -fmudflap and -Wnested-externs conflict
Using both -fmudflap and -Wnested-externs generates spurious errors. localhost$ touch tmp.c localhost$ gcc -fmudflap -Wnested-externs -S tmp.c built-in:0: warning: nested extern declaration of __mf_lookup_cache built-in:0: warning: nested extern declaration of __mf_lc_shift built-in:0: warning: nested extern declaration of __mf_lc_mask built-in:0: warning: nested extern declaration of __mf_check built-in:0: warning: nested extern declaration of __mf_register built-in:0: warning: nested extern declaration of __mf_unregister built-in:0: warning: nested extern declaration of __mf_init built-in:0: warning: nested extern declaration of __mf_set_options cc1: error: mf-runtime.h: No such file or directory You can ignore the mf-runtime.h error. The ones I'm concerned about here are all of the false nested extern warnings. I can reproduce the problem with all gcc versions from 4.0.x to mainline 4.3. This problem exists only with the C (and maybe C++) front end because of how the C front end handles scoping. The problem here is that the function mudflap_init creates some variables via pushdecl. However, the C front end has an implicit assumption that no variables will be created until after we start parsing, at which time push_file_scope is called. Since mudflap creates variables before push_file_scope is called, they end up being placed in the wrong scope, and the C front end gets confused and emits the warning. A possible solution is to add a builtin_variable hook similar to the existing builtin_function hook. Note that the C front end builtin_function hook calls bind directly, instead of calling pushdecl which then calls bind. A builtin_variable hook could do something similar which would solve the problem. There are also other simpler but less elegant ways to solve the problem. We could mark these mudflap variables with the DECL_IN_SYSTEM_HEADER bit to disable the -Wnested-externs warning for them. Or we could maybe disable the warning for variables in the external_scope, which I think can only happen in this case, though I haven't tried to verify that. -- Summary: -fmudflap and -Wnested-externs conflict Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilson at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30592
[Bug target/30230] Incorrect ia64 EH info when an EH region ends in the middle of a bundle
--- Comment #4 from wilson at gcc dot gnu dot org 2007-01-01 21:00 --- Fixed by Jakub's patch for 4.1, 4.2, and mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30230
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #24 from wilson at gcc dot gnu dot org 2006-10-02 19:23 --- Created an attachment (id=12372) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12372action=view) improved patch for inline warning Works for simple testcases. Needs full bootstrap regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #17 from wilson at gcc dot gnu dot org 2006-09-15 23:05 --- Subject: Bug 28490 Author: wilson Date: Fri Sep 15 23:05:40 2006 New Revision: 116983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116983 Log: Short term fix for PR 28490. * config/ia64/ia64.c (ia64_legitimate_constant_p, cast CONST): Handle symbol offsets same as they are handled in ia64_expand_move and move_operand. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #10 from wilson at gcc dot gnu dot org 2006-08-04 01:49 --- This is the same bug as PR 28490. I verified that my prototype patch for PR 28490 fixes it. *** This bug has been marked as a duplicate of 28490 *** -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #13 from wilson at gcc dot gnu dot org 2006-08-04 01:49 --- *** Bug 28495 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #14 from wilson at gcc dot gnu dot org 2006-08-04 01:55 --- Steve Ellcey posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00016.html I posted a better patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00054.html This patch has not been tested yet. There are also some follow up questions raised in this thread that need to be answered. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #5 from wilson at gcc dot gnu dot org 2006-07-11 01:32 --- This is already fixed on dataflow-branch. At the end of combine_instructions, it runs a global dataflow pass that removes all REG_DEAD and REG_UNUSED notes before creating new ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #6 from wilson at gcc dot gnu dot org 2006-07-11 01:41 --- Created an attachment (id=11857) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11857action=view) Delete old REG_DEAD notes before creating new ones. This works for the testcase, but is otherwise untested. This just deletes the old REG_DEAD notes for a local life update before creating new ones. I believe this could be made simpler by eliminating UPDATE_LIFE_GLOBAL_RM_NOTES, and then calling count_or_remove_death_notes if PROP_DEATH_NOTES is set for both global and local updates. However, assuming we want what is on dataflow-branch, it seems better to go with a safer non-conflicting patch for now, and let dataflow-branch be the long term fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/27883] [4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #4 from wilson at gcc dot gnu dot org 2006-06-27 03:02 ---
This only fails for --enable-checking builds, which is the default for
mainline, but not release branches. I was able to reproduce this with gcc-4.0,
but not gcc-3.4. The difference between the two is that gcc-4.0 has the
__builtin_copysign support, which emits the RTL that triggers the error. The
error has probably been latent for a while.
The insn that causes the problem is
(jump_insn 99 98 113 15 (set (pc)
(if_then_else (ge:SI (subreg:SI (reg:DF 32 $f0) 4)
(const_int 0 [0x0]))
(label_ref 101)
(pc))) 261 {*branch_zerosi} (insn_list:REG_DEP_TRUE 94 (nil))
(expr_list:REG_DEAD (reg:SI 33 $f1)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil
On a 32-bit mips target, DFmode $f0 is a register pair $f0/$f1, so technically
this is correct. There is a corresponding REG_UNUSED for $f0 on the insn that
sets (reg:DF 32 $f0).
However, flow doesn't track individual regs in subregs, it only tracks the
whole subreg. Note that mark_used_reg ignores subregs. So when we execute the
second life pass, we end up with
(jump_insn 98 97 112 17 (set (pc)
(if_then_else (ge (subreg:SI (reg:DF 32 $f0) 4)
(const_int 0 [0x0]))
(label_ref 100)
(pc))) 271 {*branch_ordersi} (insn_list:REG_DEP_TRUE 93 (nil))
(expr_list:REG_DEAD (reg:DF 32 $f0)
(expr_list:REG_DEAD (reg:SI 33 $f1)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)
Note that we now have two overlapping REG_DEAD notes plus an overlapping
REG_UNUSED note on a previous insn. When sched runs, it deletes both REG_DEAD
notes, but only readds one, resulting in the abort for a REG_DEAD note
consistency problem.
A subreg of a hard register is normally not allowed, but it is created in this
case because CANNOT_CHANGE_CLASS_MODE is defined, and HARD_REGNO_MODE_OK says
that an SImode $f1 is not OK. The result is that simplify_subreg doesn't
simplify this. The other part is that register_operand says it is OK.
Eventually, this gets fixed by reload.
Fixing combine to get this right looks complicated. Combine has to know that
the register was used inside a subreg, and then figure out that the subreg
wasn't simplified because of CANNOT_CHANGE_CLASS_MODE, etc.
I think a simpler solution here is to note that the life2 pass would have
worked correctly if it deleted all prior REG_UNUSED/REG_DEAD notes before it
started. Incidentally, the comments for the life2 pass say it was explicitly
added to fix REG_UNUSED/REG_DEAD problems with distribute_notes in combine, so
it was apparently added to fix a related problem. It just isn't working the
way it was originally intended.
It is curious that life2 is running immediately before sched, instead of
immediately after combine. If we ran it immediately after combine, we could
get rid of the REG_DEAD/REG_UNUSED support in distribute_notes, which is
probably the most complicated, and most buggy, part of combine. This would
also speed up the compiler a little bit.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC||wilson at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-27 03:02:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug debug/27851] Hour-long segfault with -O1 -g on gcc.dg/parm-impl-decl-1.c
--- Comment #3 from wilson at gcc dot gnu dot org 2006-06-10 01:19 ---
This is a C front end bug. The C front end is creating a circular symbol
table, where the function h is defined both in the external scope and inside
itself. The dwarf2out.c code then goes into an infinite recursion trying to
tree walk the circular symbol table.
The syntax error is not needed to reproduce the problem. You just need two
functions with implicit function declarations in their parameter list. For
instance:
foo (int (*p)[sizeof(j())])
{
}
h (int (*p)[sizeof(i())])
{
}
The C front end problem can be reproduced with only one function, but you need
two to trigger the dwarf2out.c failure.
You also don't need a checking enabled build to reproduce this.
The dwarf code works in the presence of a single circular reference in the
symbol table because there is code in gen_subprogram_die that catches the case
where we try to define a function twice. This doesn't work when we have two
circular references. Now the function h is defined in 3 places, externally,
inside itself, and inside foo. The one inside foo is turned into a
declaration, and now the short circuit code in gen_subprogram_die doesn't work,
and we get the infinite recursion.
The problem occurs in get_parm_info and store_parm_decls_newstyle in c-decl.c.
The first function tears apart the binding scope for parameters. When it sees
a function, it puts it on the others list. Then store_parm_decls_newstyle
reinserts it in the proper place in the proper scope with nested=0 regardless
of what the original value of nested was. This appears to be the bug.
When the function i, for instance, was inserted into binding scopes, it was put
in two of them. It was put in the external scope with nested=0, and it was put
in the param scope with nested=1. If this info was preserved by get_parm_info
and store_parm_decls_newstyle, then the bug would not occur.
The circular refernence is created in pop_scope. When popping the scope for
the function h, i is inserted into the BLOCK_VARS for the function body because
nested is 0. When popping the external scope, i is inserted into the
BLOCK_VARS for the external scope, because nested is 0. Now we have the same
decl in two places in the symbol table. When we handle the function h for the
external scope, it is chained to i, and now since i is also declared inside the
function h, the function h is also declared inside itself. When we add foo, h
is now also declared inside foo, and foo inside h.
I don't see an easy way to fix this without adding aanother datastructure. We
could change the others field to be a structure containing a tree and the
nested info, and then store_parm_decls_newstyle can get the nested value
correct when it reinserts the tree into the symbol table.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC||wilson at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-10 01:19:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27851
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #5 from wilson at gcc dot gnu dot org 2006-06-10 02:49 --- If a combination is successful, we will delete i1 and i2, so it doesn't matter if they changed accidentally. If a combination fails, then we go through undobuf and revert all changes, so it doesn't matter if i1 or i2 changed accidentally. They will be restored to their original values when we are done. The only case where it matters is if added_sets_2 or added_sets_1 is true. In this case, we will re-add the patterns from i1 and/or i2 after the combination. So in this case, we need to make sure we still have the original patterns. We already make a copy of the i2 pattern for this purpose. i2pat is a copy, and is only used if added_sets_2 is true. So we just need to do the same for i1pat. I agree the comment before the i2pat is a bit confusing. It looks like the copy was originally added to fix an obscure problem, but it also happens to fix this one too. It looks like there is an unnecessary gen_rtx_SET call, as i2pat will only be used if added_sets_2 is true. So the code setting i2pat should be moved inside the added_sets_2 if statement. The new i1pat code should work the same way. The actual modification of the if_then_else rtl happens inside force_to_mode, as called from simplify_and_const_int. See the uses of SUBST in the if_then_else case in force_to_mode. This problem could be fixed if we generated new rtl here instead of using SUBST, but I don't think that is helpful, as there are other places that also call SUBST. It is safer to make the i1pat copy. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-10 02:49:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #22 from wilson at gcc dot gnu dot org 2006-06-01 22:36 --- Subject: Bug 26483 Author: wilson Date: Thu Jun 1 22:36:19 2006 New Revision: 114319 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114319 Log: Fix broken denorm support. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: branches/gcc-4_1-branch/libffi/ChangeLog branches/gcc-4_1-branch/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #18 from wilson at gcc dot gnu dot org 2006-04-12 22:10 --- Subject: Bug 26483 Author: wilson Date: Wed Apr 12 22:10:49 2006 New Revision: 112900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112900 Log: Fix IA-64 problems with denorms getting clobbered by type conversions. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: trunk/libffi/ChangeLog trunk/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #19 from wilson at gcc dot gnu dot org 2006-04-12 22:21 --- IA-64. Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:21:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #20 from wilson at gcc dot gnu dot org 2006-04-12 22:22 --- Fixed on mainline. Testcase added to mainline. The fix should probably be backported to one or more active release branches. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC|wilson at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #17 from wilson at gcc dot gnu dot org 2006-04-07 23:04 --- Subject: Bug 26483 Author: wilson Date: Fri Apr 7 23:04:15 2006 New Revision: 112768 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112768 Log: For PR 26483, IA-64 denorm failure due to unwanted rounding. * testsuite/libffi.call/float4.c: New testcase. Added: trunk/libffi/testsuite/libffi.call/float4.c Modified: trunk/libffi/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #14 from wilson at gcc dot gnu dot org 2006-04-04 20:24 --- Created an attachment (id=11208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11208action=view) proposed testcase, based on float1.c This reproduces the denorm failure for me with unpatched sources, and worked with my proposed unfinished patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #10 from wilson at gcc dot gnu dot org 2006-03-08 00:46 --- I missed the denorm angle obviously. And the answer to the question about what is different between native and interpreted execution would of course be libffi, which took me far longer to remember than it should have. Anyways, looking at libffi, the issue appears to be the stf_spill function in the src/ia64/ffi.c file. This function spills an FP value to the stack, taking as argument a _float80 value, which is effectively a long double. So when we pass the denorm double to stf_spill, it gets normalized to a long double, and this normalization appears to be causing all of the trouble. This long double value then gets passed to dtoa in fdlibm which expects a double argument. dtoa then fails. I didn't debug dtoa to see why it fails, but it seems clear if we pass it an argument of the wrong type, we are asking for trouble. On IA-64, FP values are always stored in FP regs as a long double value rounded to the appropriate type, so the normalization will have no effect except on denorm values I think. This means only single-denorm and double-denorm arguments values are broken, which is something that would be easy to miss without a testcase. Stepping through ffi_call in gdb at the point whjere stf_spill is called, I see the incoming value is f6 4.9406564584124654417656879286822137e-324(raw 0xfc010800) which has the minimum double exponent (fc01) and a denorm fraction (0...800). After the conversion to _float80, we have f6 4.9406564584124654417656879286822137e-324(raw 0xfbcd8000) This now has an exponent invalid for double (fbcd) and a normal fraction (800...0). If I rewrite stf_spill to be a macro instead of a function, to avoid the argument type conversion, then the testcase works for both gcj and gij. ldf_spill appears to have the same problem, and is in need of the same solution. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #11 from wilson at gcc dot gnu dot org 2006-03-08 00:51 --- Created an attachment (id=10989) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10989action=view) unfinished untested patch to fix stf_spill bug in ia64 libffi port This is unfinished. It needs to be a bit cleaner, and also ldf_spill appears to need the same fix. This is untested, except for the testcase. It does make the testcase work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug target/26436] [3.4 only] Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 14
--- Comment #15 from wilson at gcc dot gnu dot org 2006-03-02 00:06 --- Created an attachment (id=10952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10952action=view) not recommended prototype patch to avoid assembler bug I have a gcc-3.4.x patch that silences the assembler warnings for the testcase. However, I am not particularly happy about it. It doesn't handle every possible case. Also, it doesn't attempt to verify that the predicate registers are mutex. It just emits a directive to disable the assembler warning. In the worst case, this could mask a gcc bug that would otherwise be found by the assembler DV checks. I haven't done any testing on this, other than running it on the testcase. I think it would be best if the problem was fixed in the assembler. Meanwhile, if you get suspicious assembler warnings, you can check the assembly code yourself to see if there is a real problem, or if this is an assembler bug. Or if you are desperate, you can try using this patch. I don't plan to do any further work on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
[Bug target/26436] [3.4 only] Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 14
--- Comment #12 from wilson at gcc dot gnu dot org 2006-02-28 02:13 --- This looks like an assembler problem to me, and a known one at that. The assembly code in question, somewhat simplified, is .pred.rel.mutex p8, p9 (p9) cmp4.lt p6, p7 = 1, r38 (p8) cmp4.gt p6, p7 = -1, r38 ;; (p6) addl r14 = 1, r0 (p7) mov r14 = r0 The assembler should be able to figure out that this is safe. Unfortunately, the dependency violation checking code in the assembler was never finished. The problem is far harder than we originally thought, and the current code can't handle complicated nested cases like this. I estimate that fixing the general problem is 1 month of work if I do the job, and 2 months if anyone else does it. Since IA-64 work is a hobby for me, it is unlikely I will tackle a job this large. Maybe this specific problem is simpler to fix than the general case, but I'm reluctant to go that way. I would prefer that the code be rewritten from scratch, properly, rather than add hacks for special cases. I suspect that the problem does not occur with gcc-4.x, because somewhere along the line, someone made it stupider in order to fix a bug, and it no longer generates the complicated nested DV cases that the assembler can't handle. Trying grep ') cmp' test.s | wc with the two testcases to find predicated compare instructions gives 32 for the gcc-3.4 compiled one, and 11 for the gcc-4.0 compiled one. Actually, looking closely, I do see one possible problematic sequence in the gcc-4.0 output, but it is immediately followed by a branch, and this forces the compiler to insert a .pred.rel.mutex directive at the target label. Thus the gcc-4.0 output assembles cleanly, but this may just be a happy accident. As a workaround, we could modify the compiler to try to detect nested DV cases, and emit extra unnecessary .pred.rel.mutex directives for them. This would work around the assembler bug. This isn't the best solution, but may be simpler than trying to fix the assembler. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
[Bug libgcj/26483] Wrong parsing of doubles when interpreted
--- Comment #4 from wilson at gcc dot gnu dot org 2006-02-28 03:25 --- The number 5e-324 exceeds the range of the (C language) double type. So the result you get will depend on how overflow is handled. If I use a number within the range of double, it works fine. I don't know what Java is supposed to do in the presence of overflow here. Compile this with -E #include float.h DBL_MIN_10_EXP and we get a result of -307. So 5e-324 is an out-of-range number. The number is within range of an IA-64/x86 80-bit FP long double number. LDBL_MIN_10_EXP is -4931. So if long doubles are being used, intentionally or accidentally, this could work. On an x86_64 system, I get an answer of 0.0 for both the compiled and interpreted tests. If I use -m32 when compiling, I get the answer 5E-324. I don't have a 32-bit compiled interpreter, so I can't check that. Without access to a copy of the Java standard, it isn't clear to me what the correct answer is here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug java/21206] gcj seems not to pass the option to ld correctly
--- Comment #12 from wilson at gcc dot gnu dot org 2006-02-24 00:49 --- It appears that the LT stands for libtool. So the first one (LIBICONV) is supposed to be used for linking if you aren't using libtool, and the second one (LTLIBICONV) is used for linking if you are using libtool. It is a happy accident that libtool is using linker options, where the non-libtool one is using gcc options. Misusing libtool support this way probably isn't the best possible solution, but it does look to me like it will work fine. So, yes, this looks OK to me. We could at least get this on mainline even if we can't fix the release branches yet. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206
[Bug debug/26364] [4.0/4.1/4.2 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined
--- Comment #4 from wilson at gcc dot gnu dot org 2006-02-22 00:28 --- The debug info looks OK to me, though it is more verbose than it needs to be. I think you may be reading the debug info wrong. The entry you are looking at is the abstract origin for pageout. If you take the offset of this entry, 9aee in your case, and search for that, you will find the real debug info for pageout, which has an abstract origin attribute pointing at the 9aee entry. I get slightly different addresses, but here is what I get .uleb128 0x4e # (DIE (0x9af3) DW_TAG_subprogram) .long 0x9bd6 # DW_AT_sibling .long .LASF1677 # DW_AT_name: pageout .byte 0x1 # DW_AT_decl_file .value 0x13e # DW_AT_decl_line .byte 0x1 # DW_AT_prototyped .long 0x8df5 # DW_AT_type .byte 0x1 # DW_AT_inline ... .uleb128 0x3e # (DIE (0x9bd6) DW_TAG_subprogram) .long 0x9d39 # DW_AT_sibling .long 0x9af3 # DW_AT_abstract_origin .long .LFB813 # DW_AT_low_pc .long .LFE813 # DW_AT_high_pc .long .LLST34 # DW_AT_frame_base So the debug info is correct, in the sense it correctly describes the program. The debug is more verbose than it should be though, since there is no need for the abstract origin if the function was never inlined. This is due to problems with cgraph. Now that cgraph controls when and how we emit code for functions, we really need to move the debug output calls into cgraph, so that functions are finalized by cgraph before we try to emit debug info for them. There are a few other bugzilla bug reports concerning the same issue, though it may not be easy to find them. It is probably also not easy to fix this. See cgraph_function_possibly_inlined_p. What is the real bug that you are trying to report here? Are you complaining because the debug info is unnecessarily verbose? Do you have a debugger that doesn't handle this debug info correctly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
