Providing default option to GAS through gcc driver

Hello all,

I would like to know if there is any way to control the gcc driver
program to pass a default option  to the assembler if no option/switch
is given.
say
-march=arch1
if no -march option is provided by the user.

The macro TARGET_OPTION_TRANSLATE_TABLE does something like this but
with this, one can only override the option and cannot provide one if
none is given

Is there anyway to do this?

Regards,
Shafi.

Re: Providing default option to GAS through gcc driver

On 2/28/07, Mohamed Shafi <shafitvm <at> gmail.com> wrote:
> Is there anyway to do this?

Yes look at config/rs6000/rs6000.h and ASM_CPU_SPEC and EXTRA_SPECS
and ASM_SPEC.

Thanks,
Andrew Pinski

REG_ALLOC_ORDER and Altivec registers

Hello,

I wonder why this order (non-consecutive, decreasing) of Altivec registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.

(taken from rs6000.h)

   /* AltiVec registers.  */                                    \
   77, 78,                                                      \
   90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80,                  \
   79,                                                          \
   96, 95, 94, 93, 92, 91,                                      \
   108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97,     \
   109, 110,                                                    \
   111, 112, 113                                                \

Thanks,
Revital

Re: REG_ALLOC_ORDER and Altivec registers

Revital Eres  wrote on 01/03/2007 10:37:36:

>
> Hello,
>
> I wonder why this order (non-consecutive, decreasing) of Altivec
registers
> was chosen when specifying the allocation order in REG_ALLOC_ORDER.
>
> (taken from rs6000.h)
>
>    /* AltiVec registers.  */                                    \
>    77, 78,                                                      \
>    90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80,                  \
>    79,                                                          \
>    96, 95, 94, 93, 92, 91,                                      \
>    108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97,     \
>    109, 110,                                                    \
>    111, 112, 113                                                \
>

I think part of the answer can be found here:
http://gcc.gnu.org/ml/gcc/2003-06/msg00902.html
"We have found that re-arranging the REG_ALLOC_ORDER in rs6000.h so that
all
the FP registers come after the integer registers greatly reduces the
tendency of the compiler to generate code that moves 8-byte quantites
through
the FP registers."

About Loop Pattern ----GCC porting

Hello:
       I am Jiang Hongjiang and recently I am porting the GCC backend
to a DSP, and get puzzled about the "decrement_and_branch_until_zero"
pattern.By Reading the GCC source, I find that this pattern is used in
loop optimization, and it's used under the condition of defining the
"doloop_end" pattern. Inspired by the c4x machine description file(
c4x.md), I defined the "doloop_end" pattern using "define_expand", and
generate the "decrement_and_branch_until_zero" insn in the preparation
statements. Right now the GCC can generate the
"decrement_and_branch_until_zero" insns and its related assemble
insn(in my platform it is "DJNZ Rn,lable"), but I find that the GCC
remains other insns(the cmp insns and other) unchanged. How do you
delete the "CMP" insn and other insn in the loop while using the
"decrement_and_branch_until_zero" pattern? The accessory demonstrates
a example.

Thanks!

Given the C code:
              int i;
	      for(i = 0 ; i < 5; i++)
		;
the C4x generates assemble insn as follows:
	lda 4,ar0
  L2:
    	dbu ar0,L2

and in my platform, it generates such assemble:

What tells the coding style about whitespaces at end of lines or in *empty* lines ?

Hi,

I noticed while editing gcc files, that there are a lot of *useless* 
whitespaces at the end of lines or within empty lines, which are getting 
automatic removed by some *smarter* editors as I am common to use *sigh*. 
This leads to huge diff files and the real change is getting veiled. I 
think it would be nice to eliminate these *usesless* whitespaces.

Regards,
 i.A. Kai Tietz

----------------------------------------
  Kai Tietz - Software engineering
  OneVision Software Entwicklungs GmbH & Co KG
  Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
  Phone: +49-941-78004-0
  FAX:   +49-941-78004-489
  WWW:   http://www.OneVision.com

Re: What tells the coding style about whitespaces at end of lines or in *empty* lines ?

> It also forbids embedded horizontal tabs for similar reasons (avoiding
> junk difs).

That would be a problem with GCC, due to emacs being so heavily used,
but a similar convention *requiring* horizontal tabs would solve the
issue in question.

Re: What tells the coding style about whitespaces at end of lines or in *empty* lines ?

Thanks, that is what I want to hear. May it would be good point to run 
over the source to be as the GNAT standard demands ?

Regards,
 i.A. Kai Tietz

Re: What tells the coding style about whitespaces at end of lines or in *empty* lines ?

> > I noticed while editing gcc files, that there are a lot of *useless* 
> > whitespaces at the end of lines or within empty lines, which are getting 
> > automatic removed by some *smarter* editors as I am common to use *sigh*. 
> > This leads to huge diff files and the real change is getting veiled. I 
> > think it would be nice to eliminate these *usesless* whitespaces.
> 
> Note that the coding standard for GNAT forbids trailing white spaces.
> It also forbids embedded horizontal tabs for similar reasons (avoiding
> junk difs).

And the compiler enforces this, which is an important point.

Duncan.

Re: What tells the coding style about whitespaces at end of lines or in *empty* lines ?

Kai Tietz wrote:
> Hi,
> 
> I noticed while editing gcc files, that there are a lot of *useless* 
> whitespaces at the end of lines or within empty lines, which are getting 
> automatic removed by some *smarter* editors as I am common to use *sigh*. 
> This leads to huge diff files and the real change is getting veiled. I 
> think it would be nice to eliminate these *usesless* whitespaces.

Note that the coding standard for GNAT forbids trailing white spaces.
It also forbids embedded horizontal tabs for similar reasons (avoiding
junk difs).