Re: gcc.3.4.6 vs. gcc-4.3.2 re: pseudo instructions & bus error
"SHANE MILLER, BLOOMBERG/ 731 LEXIN" writes: > Hi, I compile .c files using both gcc.3.4.6 and gcc-4.3.2 chaining to Sun's > assembler "Sun Compiler Common 10 Patch 09/04/2007" in both cases: > > gcc -O3 -D_SOLARIS -D_SPARC -Wall -Wa,-xarch=v8plus -fexceptions -c ... > How can I turn pseudo assembler instructions off and/or what switch can I add > to the gcc line to make this BUS error go away? Either the assembler is wrong > and/or gcc aligned a variable on the wrong boundary. Details follow. > stx %g0, [%i0+56] <- BUS ERROR HERE. 8 byte operation > mov %i1, %o0 on memory on a non-8 byte boundary > Contrast with the 3.4.6 output: > mov 0, %o4 <- no stx: this works > mov 0, %o5 This message is inappropriate for the gcc@gcc.gnu.org mailing list, which is for gcc development. It would be appropriate for the gcc-h...@gcc.gnu.org mailing list. Please take any followups to gcc-help. Thanks. gcc will only use the stx instruction when it believes that the input is 8 byte aligned. So either gcc is confused or your code is incorrect. It's hard to say anything else without seeing some of your code. A possibly relevant command line option is -mno-unaligned-doubles, q.v. I note that you are using -Wa,-xarch=v8plus. I don't know too much about SPARC, but: why are you only passing the option to the assembler? Is there any reason that you are not simply using -mv8plus? Also, how is your gcc configured? Ian
Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
> > Vortex needs -fno-strict-aliasing. It casts between two record types > with one record being a 'prefix' of another. So today runs are complette. Thanks to Richi who fixed ICE in symtab merging that affected perl and GCC. With vortex problem was that in addition to -fno-strict-aliasing it is writting to closed files that cause ICE depending on partiuclar glibc version. Comparing http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-fdo-64-FDO/recent.html vortex is 2036 with -O2 -flto, 2438 with -O2 -flto and FDO (so about 20% improvement) http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64/list.html has -O2 runs without LTO that is 1859, so 31% for LTO+FDO, 10% LTO. Any idea if it is one of value transforms or just edge profile making the difference? There are some cases of write only globals we can constant propagate with -fwhole-program in SPEC, but I think it is parser. Honza > > David > > > > > Honza > >
Re: The usage of the "clobber "match_scratch""
Thanks.
And for
>>But I can't see any reason to allocate a fixed scratch register.
The ACC register here I use is not a fixed register for GCC. I make
ACC register to be suitable for QImode operands only.
2010/4/27 Ian Lance Taylor :
> redriver jiang writes:
>
>> test3.c:27: error: insn does not satisfy its constraints:
>> (insn 52 51 32 0 (parallel [
>> (set (reg:HI 16 BASE0)
>> (plus:HI (reg:HI 16 BASE0)
>> (const_int -2 [0xfffe])))
>> (clobber (scratch:QI))
>> ]) 9 {*addhi3} (nil)
>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 20 BASE2)
>> (const_int -2 [0xfffe]))
>> (nil)))
>> test3.c:27: internal compiler error: in reload_cse_simplify_operands,
>> at postreload.c:391
>
> Looks like this insn didn't get a register at all. Reload can
> sometimes generate add insns directly, which could perhaps cause this
> to happen.
>
>
>> I think I may not understand the usage of "match_scratch" properly,
>> and I make the ACC hard register to be clobbered in rtl generation
>> pass:
>>
>> (define_expand "addhi3"
>> [(parallel [(set (match_operand:HI 0 "nonimmediate_operand" "")
>> (plus:HI (match_operand:HI 1 "nonimmediate_operand" "")
>> (match_operand:HI 2 "general_operand"
>> "")))
>> (clobber (reg: QI REG_ACC))])]
>> ""
>> "")
>>
>> the former problem disappeared.
>
> I would do it that way. There isn't too much point to forcing the
> register allocator to allocate a scratch register when you already
> know what the register has to be. It can make sense to allocate a
> normal register even if the register is fixed, because that will let
> reload move the value onto the stack if necessary. But I can't see
> any reason to allocate a fixed scratch register.
>
> Ian
>
Re: split lui_movf pattern on mips?
"Amker.Cheng" writes:
> HI:
>There is comment on lui_movf in mips.md like following,
>
> ;; because we don't split it. FIXME: we should split instead.
>
> I can split it into a move and a condmove(movesi_on_cc) insns , like
>
> (define_split
> [(set (match_operand:CC 0 "d_operand" "")
>(match_operand:CC 1 "fcc_reload_operand" ""))]
> "reload_completed && ISA_HAS_8CC && TARGET_HARD_FLOAT && ISA_HAS_CONDMOVE
> && !CANNOT_CHANGE_MODE_CLASS(CCmode, SImode,
>
> REGNO_REG_CLASS(REGNO(operands[0])))"
> [(set (match_dup 2) (match_dup 3))
> (set (match_dup 2)
>(if_then_else:SI
> (eq:SI (match_dup 1)
> (match_dup 4))
> (match_dup 2)
> (match_dup 4)))]
> "
> {
>operands[2] = gen_rtx_REG(SImode, REGNO(operands[0]));
>operands[3] = GEN_INT(0x3f80);
>operands[4] = const0_rtx;
> }
> ")
>
> But I have two questions.
>
> Firstly, the lui_movf pattern is output as
> "lui\t%0,0x3f80\n\tmovf\t%0,%.,%1" in mips_output_move,
> why 0x3f80? is it some kind of magic number, or anything else important?
It's the encoding of 1.0f (single precision). The point is that we want
something we can safely compare with 0.0f using floating-point instructions.
"Safe" means "without generating any kind of exception", so a subnormal
representation like 0x0001 isn't acceptable. 1.0f seems as good a
value as any.
> Secondly, I have to change mode of operands[0] into SImode when
> splitting, otherwise there is no
> insn pattern matching the first insn generated.
> Since no new REG generated I assuming the mode transforming is OK
> here, any suggestion?
Yes, this is OK. Your split looks good, but I don't see any reason
for the !CANNOT_CHANGE_MODE_CLASS condition.
Couple of minor suggestions:
- There is no need for the double quotes around the { ... }.
Plain { ... } is better. (Support for plain { ... } was
added a few years ago, so you can still see some older code
that uses "{ ... }". But { ... } is better for new code.)
- It's generally better to restrict match_dups to things
that depend on the operands of the original insn.
In the above, it'd be better to replace (match_dup 4)
with (const_int 0) and then not set operands[4] in the
C code. (match_dup 3) is OK as an exception because
read-rtl.c doesn't support hex constants yet...
Richard
gcc-4.6-20100501 is now available
Snapshot gcc-4.6-20100501 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100501/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 158965 You'll find: gcc-4.6-20100501.tar.bz2 Complete GCC (includes all of below) gcc-core-4.6-20100501.tar.bz2 C front end and core compiler gcc-ada-4.6-20100501.tar.bz2 Ada front end and runtime gcc-fortran-4.6-20100501.tar.bz2 Fortran front end and runtime gcc-g++-4.6-20100501.tar.bz2 C++ front end and runtime gcc-java-4.6-20100501.tar.bz2 Java front end and runtime gcc-objc-4.6-20100501.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.6-20100501.tar.bz2The GCC testsuite Diffs from 4.6-20100424 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
