Status of GCC 4.3 on Alpha (Debian)
I recently compiled the Debian archive on Alpha using trunk to identify new issues before GCC 4.3 is released. I actually started a first attempt in the middle of November but had to stop after about 2500 packages because of hardware problems. During my first attempt, I found the following Alpha related compiler bugs: - PR34132: internal consistency failure (invalid rtl sharing found in the insn) Fixed by Jakub Jelinek - PR34171: Segfault in df_chain_remove_problem with -O3 on alpha Fixed by Seongbae Park My second attempt was more successful and I compiled the entire Debian archive (over 7000 packages that need to be compiled). I compiled the archive with optimization set to -O3 and found the following ICEs with trunk from 20071212: - PR34571: Segfault in alpha_expand_mov at -O3 (1 failure) Filed two days ago so no progress yet - PR33410: ICE in iv_analyze_expr, at loop-iv.c (14 failures) This is actually a known regression from 4.1 that has became a problem for us when we moved to GCC 4.2. Unfortunately, nobody seems to be investigating this issue. - PR34467: ICE in lookup_subvars_for_var, at tree-flow-inline.h:1586 (5 failures) Aldy has a patch but I'm not sure what the status is. - PR34585: ICE in remove_useless_stmts_1, at tree-cfg.c:1863 (1 failure) Probably the same issue - PR34465: verify_stmts failed (incorrect sharing of tree nodes) (1 failure) I believe this is fixed by Aldy's patch too If someone can look at PR34571 and particularly at PR33410, Alpha will be in pretty good shape for 4.3. I should also note that a couple of software packages failed to build because of problems with their testsuites. I still have to investigate these failures. The testing was done with 4.3.0 20071212 r130789 from 2007-12-12 to 2007-12-24. Thanks to Alexander Wong of St Hugh's College, Oxford for giving me remote access to an Alpha, and to Florian Lohoff for hosting two DS25 Alpha servers that Richard Higson kindly donated to Debian. -- Martin Michlmayr http://www.cyrius.com/
Re: How to describe a FMAC insn
> Could someone give some hints of how to describe a FMAC (float mult and > add) insn in machine description, it matches d = b*c+a, which is a four > operands float instrution. With a glimp through the array optabs[] in > genopinit.c, it seems no OP handler could match FMAC operation? Correct. It isn't generated directly during RTL generation, but instead created by the optimizer (combine) from add and multiply insns.
Re: How to describe a FMAC insn
I tried by referring the ia64.md, unfortunately it does not work. The
insn I wrote for FMAC is as follows,
(define_insn "maddsi4"
[(set (match_operand:SI 0 "register_operand" "=r")
(plus:SI (mult:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r"))
(match_operand:SI 3 "register_operand" "r")))]
""
"fma %0, %1, %2, %3")
And besides this, I defined other two insns for dedicated add and mult
operations as follows,
(define_insn "addsi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(plus:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r"))
)]
""
"add %0, %1, %2")
(define_insn "mulsi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(mult:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r"))
)]
""
"mul %0, %1, %2")
It seems trivial. But after I rebuilt GCC for this new target, I found
that no optabs entry is initialized for maddsi4 in insn-opinit.c which
is generated by genopinit. However, the add_optab and smul_optab do be
initialized with Code_for_addsi3/mulsi3. As a result, when I test the
following simple program, cc1 produces separate add and mul instructions
rather than fma, where the problem is? Thanks.
void f(int s1[], int s2[], int s3[], int s4[])
{
int j;
for (j = 0; j < 16; j++)
s4[j] = s1[j]*s2[j]+s3[j];
}
Qing
>> Could someone give some hints of how to describe a FMAC (float mult and
>> add) insn in machine description, it matches d = b*c+a, which is a four
>> operands float instrution.
>>
> There are plenty of examples in ia64.md and rs6000.md.
>
Re: How to describe a FMAC insn
On Wed, Dec 26, 2007 at 06:59:39AM -0800, Qing Wei wrote: > I tried by referring the ia64.md, unfortunately it does not work. The > insn I wrote for FMAC is as follows, > > (define_insn "maddsi4" > [(set (match_operand:SI 0 "register_operand" "=r") > (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r")) > (match_operand:SI 3 "register_operand" "r")))] > "" > "fma %0, %1, %2, %3") [...] > It seems trivial. But after I rebuilt GCC for this new target, I found > that no optabs entry is initialized for maddsi4 in insn-opinit.c which > is generated by genopinit. It would be called maddhisi4, maddsidi4 or so for a sign-extending instruction. If your instruction is a plain multiply-add instruction (which is how you've defined it above), then there is no optab for it. > However, the add_optab and smul_optab do be > initialized with Code_for_addsi3/mulsi3. As a result, when I test the > following simple program, cc1 produces separate add and mul instructions > rather than fma, where the problem is? Thanks. Look at the dump file produced by -fdump-rtl-combine-details. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: __builtin_expect for indirect function calls
Hans-Peter Nilsson wrote: > On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote: >> When we can't hint the real target, we want to hint the most common >> target. There are potentially clever ways for the compiler to do this >> automatically, but I'm most interested in giving the user some way to do >> it explicitly. One possiblity is to have something similar to >> __builtin_expect, but for functions. For example, I propose: >> >> __builtin_expect_call (FP, PFP) > > Is there a hidden benefit? I mean, isn't this really > expressable using builtin_expect as-is, at least when it comes > to the syntax? That was my first thought as well. Before we add __builtin_expect_call, I think there needs to be a justification of why this can't be done with __builtin_expect as-is. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Regression count, and how to keep bugs around forever
Joseph S. Myers wrote: > On Wed, 19 Dec 2007, Steven Bosscher wrote: > >> The bigger issue here, is that people seem to be using Bugzilla as a >> kind-of TODO list for things may some day work on, but probably will > > I don't see any problem with that. Me neither. In fact, I think there's a lot of value in a central database of "all known bugs"; it helps users figure out whether something they're running into is something they've run into before. However, I am sympathetic to the idea that we need ways to see what's important to work on now. The problem there is that importance is in the eye of the beholder. The PN system expressions something about regressions that's moderately useful, but nothing else. I suspect that we need more database fields, so that people could run more interesting searches. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Problem with ARM_DOUBLEWORD_ALIGN on ARM
Geert Bosch wrote:
> Nested functions aren't used that much in C indeed... :)
Paul, would you please review this patch?
> --- arm.c.orig 2007-11-20 16:27:04.0 -0500
> +++ arm.c 2007-11-21 18:15:18.0 -0500
> @@ -10448,6 +10448,14 @@ arm_get_frame_offsets (void)
>/* Saved registers include the stack frame. */
>offsets->saved_regs = offsets->saved_args + saved;
>offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE;
> +
> + /* Allow for storage of static chain when it needs its own space in the
> + frame. */
> + if (IS_NESTED (arm_current_func_type ())
> + && regs_ever_live[3]
> + && offsets->saved_args == 0)
> +offsets->soft_frame += 4;
> +
>/* A leaf function does not need any stack alignment if it has nothing
> on the stack. */
>if (leaf && frame_size == 0)
> @@ -10569,6 +10577,7 @@ arm_expand_prologue (void)
>unsigned long live_regs_mask;
>unsigned long func_type;
>int fp_offset = 0;
> + int static_chain_size = 0;
>int saved_pretend_args = 0;
>int saved_regs = 0;
>unsigned HOST_WIDE_INT args_to_push;
> @@ -10643,6 +10652,7 @@ arm_expand_prologue (void)
> insn = emit_insn (insn);
>
> fp_offset = 4;
> + static_chain_size = 4;
>
> /* Just tell the dwarf backend that we adjusted SP. */
> dwarf = gen_rtx_SET (VOIDmode, stack_pointer_rtx,
> @@ -10836,14 +10846,15 @@ arm_expand_prologue (void)
> }
>
>offsets = arm_get_frame_offsets ();
> - if (offsets->outgoing_args != offsets->saved_args + saved_regs)
> + if (offsets->outgoing_args != offsets->saved_args + saved_regs
> + + static_chain_size)
> {
>/* This add can produce multiple insns for a large constant, so we
> need to get tricky. */
>rtx last = get_last_insn ();
>
>amount = GEN_INT (offsets->saved_args + saved_regs
> - - offsets->outgoing_args);
> ++ static_chain_size - offsets->outgoing_args);
>
>insn = emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
> amount));
>
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Problem with ARM_DOUBLEWORD_ALIGN on ARM
On Dec 26, 2007, at 14:24, Mark Mitchell wrote: Geert Bosch wrote: Nested functions aren't used that much in C indeed... :) Paul, would you please review this patch? This patch isn't good. While it addressed the alignment issue, it didn't correctly adjust all necessary offset computations. One of the problems is that this port has grown many magic adjustments and mostly similar recalculations. Olivier Hainque has refactored some of the code and has a proper patch that has had a good amount of testing now. We also have a testcase in C. We'll submit this for review soon. In the meantime, please consider this patch withdrawm. -Geert
gcc-4.2-20071226 is now available
Snapshot gcc-4.2-20071226 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071226/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 131189 You'll find: gcc-4.2-20071226.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20071226.tar.bz2 C front end and core compiler gcc-ada-4.2-20071226.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20071226.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20071226.tar.bz2 C++ front end and runtime gcc-java-4.2-20071226.tar.bz2 Java front end and runtime gcc-objc-4.2-20071226.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20071226.tar.bz2The GCC testsuite Diffs from 4.2-20071219 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
