regsiter_tm_clones in crtbegin.o
Since 4.7 register_tm_clones and deregister_tm_clones are added in crtbegin.o. Built for ARM they eat 80 precious bytes of flash for each application. They seem to be for transaction memory only and my build doesn't need it. I can simple disable them by -DUSE_TM_CLONE_REGISTERY=0 in a tmake_file. But I'm not sure if I should put it just under config/arm, or make it more general under config. Anybody else share same problem? Thanks - Joey
Re: Double word left shift optimisation
Hi Jon,
I'd like to try to optimise double word left shifts of sign/zero
extended
operands if a widening multiply instruction is available. For the
following
code:
long long f(long a, long b)
{
return (long long)a << b;
}
I'd like to optimise this to something like:
(long long) a * (1 << b)
Which should just be 3 or so instructions.
Only if b < bits_per_long; it is quite a bit more otherwise
(you then need 1LL << b).
If your pattern actually works for b <= bits_per_long, you
can do b1 = b >> 1; b2 = b - b1; return (a << b1) << b2;
reasonably cheaply.
Segher
Re: Integer promotion for register based arguments
> The documentation for this comes under the " Passing Function Arguments on > the Stack" section, which says: > > "This target hook returns true if an argument declared in a prototype as an > integral type smaller than int should actually be passed as an int. In > addition to avoiding errors in certain cases of mismatch, it also makes for > better code on certain machines." > > I would have thought if the args smaller than an int are actually passed as > an int, that would have meant the promotion had already taken place and so > wasn't needed in the callee. It could also be said that it makes worse code > on other machines :) Yes, that's a bit counter-intuitive, but might have been intended and hinted at by the "avoiding errors in certain cases of mismatch". In any case, the hook should probably not be set to true if the ABI already promotes arguments. -- Eric Botcazou
Re: build6_stat removed?
> I have a question regarding build6_stat. I saw that in 7/25 merge, > someone removed this function. Why was it removed? Because it has been unused for a while, as TARGET_MEM_REF has 5 operands now. > I am currently using it in my Cilk Plus branch. What is a work around > for this? Am I allowed to put this function back in? Sure, if you use it; but you are thus encouraged to trim down the number of operands of your new tree codes. ;-) -- Eric Botcazou
RE: build6_stat removed?
I think I am ok without it. I did find a workaround. Thanks, Balaji V. Iyer. -Original Message- From: Eric Botcazou [mailto:ebotca...@adacore.com] Sent: Friday, July 27, 2012 10:26 AM To: Iyer, Balaji V Cc: gcc@gcc.gnu.org Subject: Re: build6_stat removed? > I have a question regarding build6_stat. I saw that in 7/25 merge, > someone removed this function. Why was it removed? Because it has been unused for a while, as TARGET_MEM_REF has 5 operands now. > I am currently using it in my Cilk Plus branch. What is a work around > for this? Am I allowed to put this function back in? Sure, if you use it; but you are thus encouraged to trim down the number of operands of your new tree codes. ;-) -- Eric Botcazou
Shared librares dependency at compile time
Hi All, I have two existing shared libraries liba.so, libb.so. Liba.so depends on libb.so(liba.so is dynamically linked with libb.so ). Now I want to compile an application which uses both liba.so and libb.so. 1. On Linux, following command can pass gcc -Wall -o app app.c -L.. -la Note: -lb is not specified in the command I have several questions: 1). How is libb.so also linked actually while dynamic linking liba.so? It seems the linker knows libb.so according to the NEEDED entry in dynamic section of liba.so(which contains the name of libb.so)? Dynamic symbol table is also used to resolved symbols during linkage stage of compile, right?(since the program still can compile if the shared libraries are stripped) Explanation of detailed workflow is welcomed. 2) With -la or without -la We have two choices: i) gcc -Wall -o app app.c -L.. -la ii) gcc -Wall -o app app.c -L.. -la -lb Which one is more preferred? ii) is better for me, since it can indicate the dependency clearly; another reason is, make sure it can compile on different platforms, which I will address in the following section. 2. On Cygwin, while, the same command can not pass gcc -Wall -o app app.c -L.. -la (same as on Linux, no -lb ) The error report reads like this: undefined reference to xxx(symbols defined in libb.so) Questions: What's the difference between gcc's behaviors on Linux and Cygwin? Thank you, Ly
Re: Shared librares dependency at compile time
On Fri, Jul 27, 2012 at 12:10 PM, LiLy wrote: > > I have two existing shared libraries liba.so, libb.so. > Liba.so depends on libb.so(liba.so is dynamically linked with libb.so > ). Now I want to compile an application which uses both liba.so and > libb.so. Please never send e-mail to both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org. This message should only have gone to gcc-h...@gcc.gnu.org. Please take any followups to gcc-help only. Thanks. > 1. On Linux, following command can pass > gcc -Wall -o app app.c -L.. -la > Note: -lb is not specified in the command > > I have several questions: >1). How is libb.so also linked actually while dynamic linking liba.so? There are two answers, one using GNU ld, one using gold. > It seems the linker knows libb.so according to the NEEDED entry in > dynamic section of liba.so(which contains the name of libb.so)? That is how GNU ld works, yes. > Dynamic > symbol table is also used to resolved symbols during linkage stage of > compile, right?(since the program still can compile if the shared > libraries are stripped) Correct. >2) With -la or without -la > We have two choices: > i) gcc -Wall -o app app.c -L.. -la > ii) gcc -Wall -o app app.c -L.. -la -lb > Which one is more preferred? If your application refers to symbols in libb, then the second one is preferred. If your application only uses symbols in liba, then the first one is preferred. In general you should link your application against the libraries that your application refers to directly. > 2. On Cygwin, while, the same command can not pass > gcc -Wall -o app app.c -L.. -la > (same as on Linux, no -lb ) > The error report reads like this: undefined reference to xxx(symbols > defined in libb.so) > > Questions: > What's the difference between gcc's behaviors on Linux and Cygwin? The shared library implementations on GNU/Linux and cygwin are completely different. Ian
gcc-4.6-20120727 is now available
Snapshot gcc-4.6-20120727 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120727/ 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/branches/gcc-4_6-branch revision 189920 You'll find: gcc-4.6-20120727.tar.bz2 Complete GCC MD5=a461a31e8ba33b1fc91ff62c2ab72d19 SHA1=a506c75a1717af82445c1a056a264eb440971a6d Diffs from 4.6-20120720 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.
MiddleEnd ifunc attribute
Hello everybody.
I've already written that to the gcc-help list but there was no answer.
I want to use the "ifunc" Attribute within my GCC plugin. The code should
look like:
typedef void (bar_fn_t)(uint32_t *);
bar_fn_t bar __attribute__((ifunc("resolve_bar")));
I think I know how to build and assign attributes. It should be
something like:
DECL_ATTRIBUTES(decl) = tree_cons(get_identifier("ifunc"), args,
DECL_ATTRIBUTES(decl));
DECL_ATTRIBUTES(decl) = tree_cons(get_identifier("alias"), args,
DECL_ATTRIBUTES(decl));
It just compiles fine, but bar is no "gnu_indirect_function".
Thanks for your help!
Johannes Z.
