This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (3).
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Chung-Ju Wu <jasonwucj at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 01 Oct 2013 18:47:18 +0100
- Subject: Re: [PATCH 2/6] Andes nds32: machine description of nds32 porting (3).
- Authentication-results: sourceware.org; auth=none
- References: <CADj25HPo9YyrJGBUTHcZqY=Hpj2zMY-Khk6km5ODRSJx+izugQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307092351210 dot 29921 at digraph dot polyomino dot org dot uk> <51EFF82C dot 5050501 at gmail dot com> <51F0F38C dot 2020802 at gmail dot com> <522CA277 dot 2040806 at gmail dot com> <87ob7ujrxe dot fsf at talisman dot default> <5245CB2F dot 1070604 at gmail dot com>
Chung-Ju Wu <jasonwucj@gmail.com> writes:
>>> +mno-ctor-dtor
>>> +Target Report RejectNegative
>>> +Disable constructor/destructor feature.
>>
>> How is this option used?
>>
>
> It effects how we link crt stuff. Refer to nds32.h:
>
> /* The option -mno-ctor-dtor can disable constructor/destructor feature
> by applying different crt stuff. In the convention, crt0.o is the
> startup file without constructor/destructor;
> crt1.o, crti.o, crtbegin.o, crtend.o, and crtn.o are the
> startup files with constructor/destructor.
> Note that crt0.o, crt1.o, crti.o, and crtn.o are provided
> by newlib/mculib/glibc/ublic, while crtbegin.o and crtend.o are
> currently provided by GCC for nds32 target.
>
> For nds32 target so far:
> If -mno-ctor-dtor, we are going to link
> "crt0.o [user objects]".
> If general cases, we are going to link
> "crt1.o crtbegin1.o [user objects] crtend1.o". */
> #define STARTFILE_SPEC \
> " %{!mno-ctor-dtor:crt1.o%s;:crt0.o%s}" \
> " %{!mno-ctor-dtor:crtbegin1.o%s}"
> #define ENDFILE_SPEC \
> " %{!mno-ctor-dtor:crtend1.o%s}"
Oops, sorry, I forgot to check the specs.
> +mforce-fp-as-gp
> +Target Report Mask(FORCE_FP_AS_GP)
> +Prevent $fp being allocated during register allocation so that compiler is able to force performing fp-as-gp optimization.
Maybe:
Prevent $fp from being used by the register allocator, so that it is always available for the fp-as-gp optimization.
Looks good otherwise, thanks.
Richard