ASM_SPECS on recent GCC 4.3.3 (4.X)
Hello,
I want to build 4.3.3 on an SVR4 (obviously port is required as its not a
std target) but I have stumble on the following issue regarding ASM_SPEC
extra switches:
On the host's (*.h) file in gcc/config we define
#undef ASM_SPEC
#define ASM_SPEC " \
%{mno-legend:-Wc,off} \
%{g:%{!mno-legend:-Wc,-fix-bb,-s\"%i\" \
%{traditional:,-lc}%{!traditional:,-lansi-c} \
%{mstandard:,-keep-std} \
%{mexternal-legend:,-external}} \
%{mno-legend: -Wc,off}}"
These are switches they should be passed to the native assembler. Eg
wihtout -Wc,off (aka -mno-legend switch on the cc1) the compiler
cannot produce executables. (The native assembler will complain)
Seems that on the latest GCC 4.3.x tree the argumnet asmspecs has
been dropped from the function rest_of_decl_compilation in gcc/toplev.c
(see also make_decl_rtl procedure).
Hence even if ASM_SPEC is clearly "custom defined" on the gcc/config/.h
file still it is completely ignored with result that the bootstaped resulting
cc1 stil complains that it doesnt know what -mno-legend is and aborts
any further compilition.
Am I missing something here? Is there is another define I can use in .h
file that would pass the new (extra) switches I want to the newly build
cc1 4.3.x ?
If not I am not sure why you made these cahnges. ASM_SPEC was always
there so we can customize the build (as with LINK command etc) , so why
now its droppped? As far I am aware still ASM_SPEC stuff exist for OS's on
gcc/config and gcc/config/i386 *.h files even on 4.3.x branch
Regards,
avr.md: best practice to optimize bit manipulations?
In order to improve bit manipulations for avr, patterns like the following can
be used:
+;; [0].log[4] |= [2].log[4]+[3]
+(define_insn "*iorqi2_shiftrt_bit"
+ [(set (match_operand:QI 0 "register_operand" "=d,r")
+(ior:QI (and:QI (match_operator:QI 1 "shiftrt_operator"
+ [(match_operand:QI 2 "register_operand"
"r,r")
+(match_operand:QI 3 "const_int_operand"
"n,n")])
+(match_operand:QI 4 "single_one_operand" "n,n"))
+(match_operand:QI 5 "register_operand" "0,0")))]
+ ""
+ {
+ HOST_WIDE_INT to_bit = exact_log2 (GET_MODE_MASK (QImode) &
INTVAL(operands[4]));
+ HOST_WIDE_INT from_bit = to_bit + INTVAL(operands[3]);
+
+ operands[3] = GEN_INT (from_bit);
+ operands[4] = GEN_INT (to_bit);
+
+ if (0 == which_alternative)
+ return "sbrc %2,%3\;ori %0,(1<<%4)";
+
+ return "bst %2,%3\;sbrs %0,%4\;bld %0,%4";
+ }
+ [(set_attr "length" "2,3")
+ (set_attr "adjust_len" "no,no")
+ (set_attr "cc" "clobber,none")])
+
+;; needs the above pattern as combiner bridge
+;; [0].log[4] = [2].log[4]+[3]
+(define_insn "*movebit_shiftrt"
+ [(set (match_operand:QI 0 "register_operand" "=r")
+(ior:QI (and:QI (match_operator:QI 1 "shiftrt_operator"
+ [(match_operand:QI 2 "register_operand"
"r")
+(match_operand:QI 3 "const_int_operand"
"n")])
+(match_operand:QI 4 "single_one_operand" "n"))
+(and:QI (match_operand:QI 5 "register_operand" "%0")
+(match_operand:QI 6 "single_zero_operand" "n"] ; =
~[4]
+ "GET_MODE_MASK (QImode) == (GET_MODE_MASK (QImode) & (INTVAL(operands[4]) ^
INTVAL(operands[6])))"
+ {
+ HOST_WIDE_INT to_bit = exact_log2 (GET_MODE_MASK (QImode) &
INTVAL(operands[4]));
+ HOST_WIDE_INT from_bit = to_bit + INTVAL(operands[3]);
+
+ operands[3] = GEN_INT (from_bit);
+ operands[4] = GEN_INT (to_bit);
+ return "bst %2,%3\;bld %0,%4";
+ }
+ [(set_attr "length" "2")
+ (set_attr "adjust_len" "no")
+ (set_attr "cc" "none")])
The situation for targets like avr is that jumps are quite cheap (no pileline, no cache),
and shifts are quite expensive (AVR can QI >> 1, QI << 1 and QI rotate 4).
Passes like ifconversion and others transform if-else to arithmetik.
Canonicalization is nice, because there are many ways to express bit
manipulations in C (shifts, masking, if-else, conditionals, bitfields, ...)
However, they are expensive for small targets and therefore backend can help
out of that with patterns like cited above.
The drawback is that these patterns are pretty much complex, so is there a
better place to fix the mess (from a tiny target's perspective) that middle end
produces?
If gcc decides to represent the operations in a slightly different way, the patterns will no more match. That is no problem in itself, but it's hard to test if the patterns are still needed and covered by some source, or if they are dead and just pollute backend. Introducing extzv and insv could bring some effort (I didn't try what impact they have) but basically the problems would remain the same: insn combine stuffs expressions together.
An other drawback of this technique is that the second pattern will never fit without the
first, because the second is too complex for insn combine. If the first pattern matches
but won't get combined into the second (because of source), the pattern that is intended
to serve as a "bridge" for insn combine cannot be undone or rolled back. Note
that the first pattern is more expensive even though the second is more complex. rtx
costs could help out of that, but I think no one wants to write/support the above
patterns as C expressions in rtx_costs...
It is ok to state rtx costs as insn attribute? That would imply to run recog
from within rtx_costs to scan if for some rtx an insn knows about the costs.
This would be nice because then there was /one/ place to describe meta
information about a pattern. This would even help before reload, i.e. if an
insn has more than one alternative but it's not yet known what alternative will
actually be chosen. Or would that slow down compilation too much, as recog
needs time and the pattern to match against must be (re)constructed every time
(SET must be added)?
Even better would be if the backend allowed to write
+ (define_rtx_cost ; cost for *movebit_shiftrt
+ [(ior:QI (and:QI (match_operator:QI 0 "shiftrt_operator"
+ [(match_operand:QI 1 "register_operand"
"")
+ (match_operand:QI 2 "const_int_operand"
"")])
+ (match_operand:QI 3 "single_one_operand" ""))
+ (and:QI (match_operand:QI 4 "register_operand" "")
+ (match_operand:QI 5 "single_zero_operand" ""] ; = ~[
SUBTARGET_SWITCES
Hi,
Also another thing I dont see in GCC 4.x.x but I know it was alive and
kicking on the GCC 3.4.6 branch is the subtarget switches custom macro.
Eg in the gcc.config/.h OS specific file we could define something like
that:
#define MASK_STANDARD0x4000 /* Retain standard information */
#define MASK_NOLEGEND0x2000 /* Discard legend information */
etc ...
#define TARGET_STANDARD (target_flags & MASK_STANDARD)
#define TARGET_NOLEGEND (target_flags & MASK_NOLEGEND)
etc ...
and then do a define as
#undef SUBTARGET_SWITCHES
#define SUBTARGET_SWITCHES \
{ "standard", MASK_STANDARD, \
N_("Retain standard MXDB information") }, \
{ "legend", -MASK_NOLEGEND, \
N_("Retain legend information") },\
{ "warn-passed-structs",MASK_WARN_PASS_STRUCT, \
N_("Warn when a function arg is a structure") },
That could cause cc1 --help as well as gcc --help to list those extra
OS specific added options (two -m above and one -W, an examble).
Is that feature/possiblity also dropped completely from gcc 4.X.X. ?
Regards,
Re: avr.md: best practice to optimize bit manipulations?
Georg-Johann Lay schrieb: source, or if they are dead and just pollute backend. Introducing extzv and insv could bring some effort (I didn't try what impact they have) Sorry for the typo. Please replace "effort" with "improvement" or "relief".
Re: ASM_SPECS on recent GCC 4.3.3 (4.X)
Takis Psarogiannakopoulos wrote: > #undef ASM_SPEC > #define ASM_SPEC " \ > Seems that on the latest GCC 4.3.x tree the argumnet asmspecs has > been dropped from the function rest_of_decl_compilation in gcc/toplev.c > (see also make_decl_rtl procedure). I think there's some confusion here. There is no relationship between the ASM_SPEC definition in a config *.h file regarding options to be passed to the assembler and the old "asmspec" parameter to rest_of_decl_compilation, which related to uses of the "__asm__(...)" extension in the source code. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: ASM_SPECS on recent GCC 4.3.3 (4.X)
Hi Mark, Thanks for answering. On Sun, 1 Mar 2009, Mark Mitchell wrote: > I think there's some confusion here. There is no relationship between > the ASM_SPEC definition in a config *.h file regarding options to be > passed to the assembler and the old "asmspec" parameter to > rest_of_decl_compilation, which related to uses of the "__asm__(...)" > extension in the source code. > Are you sure about that? From a brief look on the code over the 3.4.6 branch I assumed that this is the issue. Well in the ASM_SPEC def as I ve described it in my previous message, in 3.4.6 branch works fine and even if gcc.c is not linked over cc1 still toplev.o contains the ASM_SPEC extra commands. On GCC 4.x.x branch cc1 doesnt get at all those extra options. I also used to document those options in the --help line with SUBTARGET_SWITCHES macro which is also not present anymore. It is my guess that if I pass the above ASM_SPECS as CC1_SPECS it will work but thats not the right thing! ASM_SPECS were always custom extra command line commands to be been passed to the assembler right? So re-stating my question: 1) the old way to do that (3.4.X branch ASM_SPEC) doesnt seem to work anymore 2) How do you do it in the 4.X.X branch... Regards,
Re: ASM_SPECS on recent GCC 4.3.3 (4.X)
Takis Psarogiannakopoulos wrote: >> I think there's some confusion here. There is no relationship between >> the ASM_SPEC definition in a config *.h file regarding options to be >> passed to the assembler and the old "asmspec" parameter to >> rest_of_decl_compilation, which related to uses of the "__asm__(...)" >> extension in the source code. >> > Are you sure about that? Yes. > ASM_SPECS were always custom extra command line commands to be been passed > to the assembler right? So re-stating my question: > 1) the old way to do that (3.4.X branch ASM_SPEC) doesnt seem to work > anymore > 2) How do you do it in the 4.X.X branch... The same basic mechanisms will work. Probably something is #undef'ing the macro after you define it, or you are confused about which header files are being used in your configuration. You will have to get out the debugger and preprocessor to work out what's going on. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GNAT vs DW2/ZCX EH.
Arnaud Charlet wrote: >>> I doubt that this can be deemed an experiment, we know that it works. >> We know that it works with our sources and GCC 4.3. We have no idea how >> well it works with GCC 4.4: we don't do mingw builds there. > > BTW, we have local patches not yet integrated that are needed for proper > ZCX support, in particular the need of a libgcc_s.dll becomes important when > you enable ZCX. That should all be working nicely right now, since Aaron's patch last autumn. Care to post your work-in-progress patches for us all to put our heads together over? cheers, DaveK
PATCH: PR gas/9915: LOCAL_LABELS_DOLLAR doesn't work on Freebsd/x86
Since LOCAL_LABELS_DOLLAR doesn't work on any x86 targets where '$' is used as immediate prefix, I am planning to check in this patch. If I don't get any objections within 2 weeks, I will check it in. Thanks. H.J. --- 2009-03-01 H.J. Lu PR gas/9915 * config/tc-i386.h (LOCAL_LABELS_DOLLAR): New. Defined as 0. (LOCAL_LABELS_FB): Undefine befoe define. --- gas/config/tc-i386.h.foo2009-01-15 06:37:31.0 -0800 +++ gas/config/tc-i386.h2009-03-01 13:45:12.0 -0800 @@ -90,6 +90,10 @@ extern void i386_elf_emit_arch_note (voi #define SUB_SEGMENT_ALIGN(SEG, FRCHAIN) 0 +/* '$' may be used as immediate prefix. */ +#undef LOCAL_LABELS_DOLLAR +#define LOCAL_LABELS_DOLLAR 0 +#undef LOCAL_LABELS_FB #define LOCAL_LABELS_FB 1 extern const char extra_symbol_chars[];
Re: [Ada] Fix Windows merge glitch
On Sat, 2009-02-28 at 18:31 +0100, Eric Botcazou wrote: > * gcc-interface/Makefile.in (cygwin/mingw): Revert accidental > EH_MECHANISM change in r130816. I've seen a few ChangeLog entries like this of late, so thought I would raise something: is it now accepted practice to mention SVN revision numbers in ChangeLog entries? I know it is convenient to do it, but (a) we might switch version control systems again, and (b) people have been known to work with FSF trees off-line or in other version control systems where the FSF repository is not accessible. Just a thought, Ben
Re: [Ada] Fix Windows merge glitch
Ben Elliston writes: > On Sat, 2009-02-28 at 18:31 +0100, Eric Botcazou wrote: > >> * gcc-interface/Makefile.in (cygwin/mingw): Revert accidental >> EH_MECHANISM change in r130816. > > I've seen a few ChangeLog entries like this of late, so thought I would > raise something: is it now accepted practice to mention SVN revision > numbers in ChangeLog entries? I know it is convenient to do it, but (a) > we might switch version control systems again, and (b) people have been > known to work with FSF trees off-line or in other version control > systems where the FSF repository is not accessible. I agree--please put in at least the date of the change being reverted, which should be the date of the ChangeLog entry. Ian
Re: ASM_SPECS on recent GCC 4.3.3 (4.X)
On Sun, 1 Mar 2009, Mark Mitchell wrote:
> >> I think there's some confusion here. There is no relationship between
> >> the ASM_SPEC definition in a config *.h file regarding options to be
> >> passed to the assembler and the old "asmspec" parameter to
> >> rest_of_decl_compilation, which related to uses of the "__asm__(...)"
> >> extension in the source code.
> >>
> > Are you sure about that?
>
> Yes.
OK then should be the missing of the SUBTARGET_SWITCHES macro.
>
> > ASM_SPECS were always custom extra command line commands to be been passed
> > to the assembler right? So re-stating my question:
> > 1) the old way to do that (3.4.X branch ASM_SPEC) doesnt seem to work
> > anymore
> > 2) How do you do it in the 4.X.X branch...
>
> The same basic mechanisms will work. Probably something is #undef'ing
> the macro after you define it, or you are confused about which header
> files are being used in your configuration. You will have to get out
> the debugger and preprocessor to work out what's going on.
>
Configuration is the same as i?86-*-sol2 in gcc/config.gcc
The last file aka sol2.h is custom modified. There is nothing really
undef'ing the ASM_SPEC macro.
Hence the reason that the cc1 cannt get it right is because the
subtarget switches macro is missing.
On the GCC 3.4.6 (aka 3.4 branch) we can see, say, in i386/sco5.h
#undef SUBTARGET_SWITCHES
#define SUBTARGET_SWITCHES \
{ "elf", -MASK_COFF, N_("Generate ELF output") },
Such kind of switches added to the TARGET_SWITCHES has carried through
from GCC 2.6 up to GCC-3.4.6 (inclusive). Then toplev.c picks up those.
It looks all these they have been eliminated on 4.3.3 (why?)
My question will be if anybody knows how you implemnt this type of well
known features on the latest GCC 4.3.X branch?
Regards,
Re: [Ada] Fix Windows merge glitch
> I agree--please put in at least the date of the change being reverted, > which should be the date of the ChangeLog entry. There is no ChangeLog entry at all. I've replaced the rev by the date. -- Eric Botcazou
Re: ASM_SPECS on recent GCC 4.3.3 (4.X)
Takis Psarogiannakopoulos writes:
> On Sun, 1 Mar 2009, Mark Mitchell wrote:
>
>> >> I think there's some confusion here. There is no relationship between
>> >> the ASM_SPEC definition in a config *.h file regarding options to be
>> >> passed to the assembler and the old "asmspec" parameter to
>> >> rest_of_decl_compilation, which related to uses of the "__asm__(...)"
>> >> extension in the source code.
>> >>
>> > Are you sure about that?
>>
>> Yes.
>
> OK then should be the missing of the SUBTARGET_SWITCHES macro.
SUBTARGET_SWITCHES shouldn't have anything to do with ASM_SPEC.
> Configuration is the same as i?86-*-sol2 in gcc/config.gcc
> The last file aka sol2.h is custom modified. There is nothing really
> undef'ing the ASM_SPEC macro.
> Hence the reason that the cc1 cannt get it right is because the
> subtarget switches macro is missing.
> On the GCC 3.4.6 (aka 3.4 branch) we can see, say, in i386/sco5.h
>
> #undef SUBTARGET_SWITCHES
> #define SUBTARGET_SWITCHES \
> { "elf", -MASK_COFF, N_("Generate ELF output") },
>
> Such kind of switches added to the TARGET_SWITCHES has carried through
> from GCC 2.6 up to GCC-3.4.6 (inclusive). Then toplev.c picks up those.
> It looks all these they have been eliminated on 4.3.3 (why?)
> My question will be if anybody knows how you implemnt this type of well
> known features on the latest GCC 4.3.X branch?
The SUBTARGET_SWITCHES macro was removed from the i386 backend in gcc
4.3 because all the uses of it were removed. The only use of
SUBTARGET_SWITCHES was to be expanded by the TARGET_SWITCHES macro.
Nobody promises that internal details of a gcc port will continue to be
the same in each new release. Nobody promises that a private port will
continue to work. If you want to maintain a private port, you have to
do some work with each new gcc release. That's just the way it is.
Ian
