Re: gcc with arm -vfp instructions
Hi Aram, i like to know whether gcc can generate vfp instructions.. This is a GCC question not a binutils question. Please ask it on the gcc mailing list: [EMAIL PROTECTED] if then, whether it will be supported on binutils and the gdb simulator The assembler and linker will support vfp instructions if they are generated by the compiler, or indeed if they are in hand written assembler source files. Cheers Nick
Re: A question about java/lang.c:java_get_callee_fndecl.
Kazu Hirata writes:
> Hi,
>
> I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java
> always returns NULL (at least for the time being).
>
> static tree
> java_get_callee_fndecl (tree call_expr)
> {
> tree method, table, element, atable_methods;
>
> HOST_WIDE_INT index;
>
> /* FIXME: This is disabled because we end up passing calls through
> the PLT, and we do NOT want to do that. */
> return NULL;
>
> :
> :
>
> Is anybody planning to fix this?
Yes.
The problem is that I want to expose opportunities for inlining but I
do not want calls to global functions to go through the PLT as
required by C semantics. To do that causes endless problems.
We now generate local aliases for all global functions, so my
intention is to call those aliases, rather than the global functions
themselves. But I do need to give inlining a chance to work, and for
that to happen the middle end needs to see the _real_ function decl.
> If not, I'm thinking about removing this language hook. The reason
> is not just clean up. Rather it is because I need to change the
> prototype of get_callee_fndecl and
> LANG_HOOKS_GET_CALLEE_FNDECL.. Currently, fold_ternary has the
> following call tree.
>
> fold_ternary
> get_callee_fndecl
> java_get_callee_fndecl
>
> If I change fold_ternary to take components of CALL_EXPR like the
> address expression of CALL_EXPR and the argument list, instead of
> CALL_EXPR itself, I would have to change java_get_callee_fndecl to
> take the first operand of a CALL_EXPR, instead of a CALL_EXPR.
So do that.
> It's not that the change is so involved, but it doesn't make much
> sense to keep something dead up to date.
It's not dead, it's resting.
> In other words, when I posted the following patch
>
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02038.html
>
> Roger Sayle requested to keep the call to get_callee_fndecl so that we
> can "fold" the first operand of a CALL_EXPR to a FUNCTION_DECL.
That's a good thing to do.
> FYI, the above FIXME comes from
>
> http://gcc.gnu.org/ml/java-patches/2004-q2/msg00083.html
Andrew.
gcc and vfp instructions
hi,
i like to know whether gcc can generate vfp instructions..
main()
{
float a=88.88,b=99.99,c=0;
c=a+b;
printf("%f",c);
}
i used the following option to compile the above program
arm-elf-gcc -mfp=2 -S new.c
but it produces the new.s file without any special kind of (vfp
instructions) instructions
how to generate them using gcc
or i have to use inline assembly for this operation for this
if then, whether it will be supported on binutils and the gdb simulator
thanks
--
__
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
gcc and vfp instructions
hi,
i like to know whether gcc can generate vfp instructions..
main()
{
float a=88.88,b=99.99,c=0;
c=a+b;
printf("%f",c);
}
i used the following option to compile the above program
arm-elf-gcc -mfp=2 -S new.c
but it produces the new.s file without any special kind of (vfp
instructions) instructions
how to generate them using gcc
or i have to use inline assembly for this operation
thanks
--
__
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
Re: A question about java/lang.c:java_get_callee_fndecl.
On Tuesday 22 March 2005 09:11, Andrew Haley wrote:
> Kazu Hirata writes:
> > Hi,
> >
> > I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java
> > always returns NULL (at least for the time being).
> >
> > static tree
> > java_get_callee_fndecl (tree call_expr)
> > {
> > tree method, table, element, atable_methods;
> >
> > HOST_WIDE_INT index;
> >
> > /* FIXME: This is disabled because we end up passing calls through
> > the PLT, and we do NOT want to do that. */
> > return NULL;
> >
> >
> >
> >
> > Is anybody planning to fix this?
>
> Yes.
>
> The problem is that I want to expose opportunities for inlining but I
> do not want calls to global functions to go through the PLT as
> required by C semantics. To do that causes endless problems.
Ehm, inline how? We currently inline GIMPLE, but your langhook is
looking for FUNCTION_DECLs in something that is not GIMPLE.
The langhook currently looks inside ARRAY_REFs right now. Apparently
Java has calls of the form CALL_EXPR, >,
which is very much *not* GIMPLE. So if you enable the lang hook, you
are either going to need a GIMPLE extension (bad), or figure out some
different way to represent this kind of call such that the CALL_EXPR
is proper GIMPLE.
IMHO it is Bad Taste(tm) anyway if get_callee_fndecl must look in
language specific data structures even when it is call from language
independent parts of the compiler, like the tree optimizers.
Gr.
Steven
Re: A question about java/lang.c:java_get_callee_fndecl.
Steven Bosscher writes:
> On Tuesday 22 March 2005 09:11, Andrew Haley wrote:
> > Kazu Hirata writes:
> > > Hi,
> > >
> > > I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java
> > > always returns NULL (at least for the time being).
> > >
> > > static tree
> > > java_get_callee_fndecl (tree call_expr)
> > > {
> > > tree method, table, element, atable_methods;
> > >
> > > HOST_WIDE_INT index;
> > >
> > > /* FIXME: This is disabled because we end up passing calls through
> > > the PLT, and we do NOT want to do that. */
> > > return NULL;
> > >
> > >
> > >
> > >
> > > Is anybody planning to fix this?
> >
> > Yes.
> >
> > The problem is that I want to expose opportunities for inlining but I
> > do not want calls to global functions to go through the PLT as
> > required by C semantics. To do that causes endless problems.
>
> Ehm, inline how? We currently inline GIMPLE, but your langhook is
> looking for FUNCTION_DECLs in something that is not GIMPLE.
That's right; it's disabled.
> The langhook currently looks inside ARRAY_REFs right now.
No, it doesn't. That's what it used to do but it's currently
disabled.
> Apparently Java has calls of the form
> CALL_EXPR, >, which is very much *not*
> GIMPLE.
OK.
> So if you enable the lang hook, you are either going to need a
> GIMPLE extension (bad), or figure out some different way to
> represent this kind of call such that the CALL_EXPR is proper
> GIMPLE.
Sure, that's fine.
> IMHO it is Bad Taste(tm) anyway if get_callee_fndecl must look in
> language specific data structures even when it is call from language
> independent parts of the compiler, like the tree optimizers.
The whole point of get_callee_fndecl is to look in language specific
data structures.
Andrew.
Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF
Hello, Please find the name of the organization, the name and title of the person who will sign on the contract: Name of the Organization: Sankhya Technologies Private Limited Name : A.R.S.Kumar Title : Asst.Manager - Legal Compliances Mailing Address: Sankhya Technologies Private Limited #30-15-58, Third Floor, "Silver Willow", Dabagardens, Visakhapatnam 530 020, INDIA Ph: +91 (0891) 554 2666 Fax:+91 (0891) 554 2665 --- Best Regards, Swami On Wed, 16 Mar 2005, Ted Teah via RT wrote: > Hello, > > > Please provide me with the name of the corporation, the name and title > of the person who is to sign the contract and the mailing address. I > will then draft and mail the assignment to you. > > All the best, > Ted Teah >
Re: gcc and vfp instructions
On Tue, 2005-03-22 at 08:51, aram bharathi wrote:
> hi,
>i like to know whether gcc can generate vfp instructions..
>
> main()
> {
> float a=88.88,b=99.99,c=0;
> c=a+b;
> printf("%f",c);
> }
>
> i used the following option to compile the above program
>
> arm-elf-gcc -mfp=2 -S new.c
>
> but it produces the new.s file without any special kind of (vfp
> instructions) instructions
> how to generate them using gcc
>
> or i have to use inline assembly for this operation for this
>
> if then, whether it will be supported on binutils and the gdb simulator
>
> thanks
gcc-4.0 will be the first FSF release to have VFP support. CodeSourcery
have a build of gcc-3.4 on their web site which has VFP support
included. The options needed to generate the VFP code are described in
the manual.
R.
Re: removal of -mflat in GCC 4.0 (sparc)
> The reason this particular register model is important to me is that I > use GCC on the microSPARC-IIep (actually, a SoC variant produced by > Infineon called the "copernicus") to build firmware for Sun Ray > appliances (ultra-thin client). These SparcV8 processors only have two > register windows, so the -mflat option is required for performance. > (The Sun Ray kernel also doesn't have a handler for register window > over/underflow traps.) The register windows are used exclusively for > entry into the interrupt handler. > > [...] > > Note also that these parts (Copernicus at least) are real, currently > shipping products. This is *not* a legacy product, and active new > development is continuing on this stuff. OK, there appears to be a real niche. > I do realize (and am very grateful) that GCC is a free project, and that > the needs of the many may outweigh the needs of the few. (I am also > asking my company to make a donation to the FSF in support of GCC, > independent of the decision about -mflat. Whether such a donation is > made or not depends on management though, so I can't promise anything.) Thanks for doing that. > But I also thought it was a real possibility that the GCC team might not > be aware of anyone who had a real requirement for the -mflat option. I > certainly appreciate the value of trimming support for defunct > architectures and such from a product to reduce code size and > complexity. However, in this case such a trim does potentially impact > otherwise happy GCC users. The -mflat support code in the SPARC back-end was identified as an absolescent, untested and unmaintained code. I personally gave it a whirl in the 3.4 timeframe and the testsuite results were abysmal (a few fixes were added as a result, so 3.4.x is supposed to be less broken than earlier compilers). We basically had 0 bugreport in years. Moreover, it was in the way of a major technical transition for the SPARC back-end. It was, therefore, advertised as deprecated in 3.4.x: http://gcc.gnu.org/gcc-3.4/changes.html and its support code was immediately removed when 4.x development started, one year ago. > I'd be grateful if the team could consider reversing the decision on > -mflat. While I can continue to use older versions of GCC, I'd like the > ability to update to new compilers later if possible. (It certainly > seems like some of the new optimizations in GCC 4.0 might be very useful > to us.) Because of the aforementioned technical transition, -mflat cannot be simply reinstated in 4.x. It must be rewritten from scratch. It's definitely too late to do that for 4.0, so the compiler will be released without -mflat support. But it is not too late for the next release cycle, 4.1, whose development just started. There is probably a 6-month window for the -mflat support to be reimplemented in the back-end and be released with 4.1. The amount of work is not overwhelming but, as GCC is a volunteer project, your company might consider hiring someone to do the work if it deems the feature a requirement for 4.1. -- Eric Botcazou
inefficient code output?
is there a reason for code output like the following or is this a bug? if it is I can try to provide a simple example. movl %ebx, -200(%ebp) movl %ebx, -196(%ebp) movl %eax, 4(%esp) movl -200(%ebp), %edx movl -196(%ebp), %ecx gcc 3.4.3, -O3 -march=pentium4 -mtune=pentium4 -mfpmatch=sse -msse2 no "volatile" involved. -- Stefan Strasser
Question regarding MIPS_GPREL_16 relocation
Hello all I am using gcc for MIPS ( 3.3.x, target mips-elf). I had problem during linking, (MIPS_GPREL_16 relocation truncated to fit error occurs). I set value of gp registers to appropriate value and used -mlong-calls and -G0 switch to prevent this problem. However problem arise again depending on section size (bss, sbss, data, sdata). Every time that heppends I have to move gp again. I believe that this reloation is used in gcc libraries (libgcc, stdc++, ...). Is that any chance these libraries to be build without mention relocation? Best regards Mile
Re: Obsoleting more ports for 4.0.
Hi,
Resending for the archives, since the spam bot on sourceware
did not like so many recipients with my address. Hope it
works this time and apologies for duplicate messages .
cheers
Ramana
Original Message
Subject: Re: Obsoleting more ports for 4.0.
Date: Tue, 22 Mar 2005 18:38:49 +0530
From: Ramana Radhakrishnan <[EMAIL PROTECTED]>
To: Kazu Hirata <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Saurabh Verma <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Hi Kazu,
> If you are working on these ports, please send us real
patches.
>
> If you would like to work on these ports privately,
please refrain
> from telling us that port xxx should be kept. More ports
we have,
> more work we would have to do to clean up the infrastructure
> connecting the middle end and the backends.
>
> arc
> ---
>
> No maintainer.
>
> PR 8972 hasn't been fixed. GCC miscompiles a function
as simple as.
>
> int
> f (int x, int i)
> {
> return x << i;
> }
PR8972 has been fixed in our tree and we should be pushing
the patch upstream soon. We had got the FSF tree building
with patches to fix PR17317 / PR11476 / PR17240 .We have
also been making fixes with binutils which can be found in
the corresponding archives.
We at Codito are working on the GNU Tools for the ARC
platform and support processors more recent than the
ARCtangent A4 core. We are currently upgrading the 2.95
based tools we have to a 3.4.x based tools (drawn off the
3.4 branch) (The changes involved are only backend
specific). (http://www.codito.com/arc).
We would like to merge our changes with mainline, 4.0 branch
and the 3.4 branch and continue work in the FSF domain. What
would be the best way to go about this ?
I was able to build mainstream CVS today just fine. The only
issue with building newlib was a ctype_b alias problem which
got resolved by upgrading to cvs head of newlib.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
Re: Obsoleting more ports for 4.0.
Hi Ramana, > PR8972 has been fixed in our tree and we should be pushing > the patch upstream soon. We had got the FSF tree building > with patches to fix PR17317 / PR11476 / PR17240 .We have > also been making fixes with binutils which can be found in > the corresponding archives. If that's the case, you might want to assign those bugs to yourself and leave some comments on each of them, saying that you've got a patch and will be posting it soon. Doing so will prevent several people from independently working on the same problem (although it may be unlikely in particular this case). Also, note that our bugmasters go through open bugs from time to time. If you merge your fix into mainline in a timely manner, they wouldn't have to spend extra time to see if bugs still exist. > We would like to merge our changes with mainline, 4.0 branch > and the 3.4 branch and continue work in the FSF domain. What > would be the best way to go about this ? Send patches to [EMAIL PROTECTED] If you are familiar with ARC and willing to continue to work on the port, you may want to become a maintainer. That will speed up the process of merging your work into the FSF tree. Kazu Hirata
Re: Obsoleting more ports for 4.0.
On Tue, 22 Mar 2005, Kazu Hirata wrote: > > We would like to merge our changes with mainline, 4.0 branch > > and the 3.4 branch and continue work in the FSF domain. What > > would be the best way to go about this ? > > Send patches to [EMAIL PROTECTED] If you are familiar with ARC > and willing to continue to work on the port, you may want to become a > maintainer. That will speed up the process of merging your work into > the FSF tree. In addition, run a regression tester which builds unmodified mainline for ARC daily or more frequently and runs the GCC testsuites, sends results to gcc-testresults and sends differences between daily results to you so you can quickly fix or file bugs for regressions that occur. (If you consider 4.0 and 3.4 branches of significance for this port, then run regression testers on them as well.) Optionally also send regression reports to the people who checked in patches between the runs, but this requires a higher degree of reliability of the tester and comparisons and also higher frequency to be of enough use. If a target has a regression tester, or simply an individual doing frequent builds, sending results to gcc-testresults on a frequent basis, that is an indication that the target is live. If it doesn't, this doesn't itself indicate that the target is dead but may tend to suggest that interest in the target is limited. If you think there is a danger of your target being mistaken for dead because of insufficient development activity on the GCC lists, keeping testresults going to gcc-testresults provides the evidence that the target is not dead after all. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: RFA; DFP and REAL_TYPE?
Mark Mitchell wrote: Robert Dewar wrote: Mark Mitchell wrote: I would expect that some decimal floating point values are not precisely representable in the binary format. OK, I agree that decimal floating-point needs its own format. But still you can store the decimal mantissa and decimal exponent in binary format without any problem, and that's probably what you want to do on a machine that does not have native decimal format support. I would think that, as elsewhere in real.c, you would probably want to use the same exact bit representation that will be used on the target. This is useful so that you can easily emit assembly literals by simply printing the bytes in hex, for example. Of course, you could do as you suggest (storing the various fields of the decimal number in binary formats), and, yes, on many host machines that would in more efficient internal computations. But, I'm not confident that the savings you would get out of that would outweigh the appeal of having bit-for-bit consistency between the host and target. In full disclosure, the 754r encoding is pretty ugly: high order bits from exponent and coefficient are packed into one field. The remaining bits of the exponent are in a second field, and the remaining bits of the coeffecient are compressed decimal encodings. So you pretty much have to come out of that encoding to do much useful with it. Honestly, I've been most just used the real decimal128 encoding as it was easiest to integrate with decNumber. decNumber has yet another architecture neutral format it does its computations in, but that didn't fit in the real_type, so I just used decimal128 as it 'fit' and decNumber could internally deal with that format already. In any case, this is rather a detail; the key decision Jon is trying to make is whether or not he has to introduce a new format in real.c, together with new routines to perform oeprations on that format, to which I think we agree the answer is in the affirmative. Yes. Thanks! This is exactly the discussion I was interested in (and to validate that my thinking was not totally off kilter). The specific internal representation can change once real.c is safe for some different representation. -- Jon Grimm <[EMAIL PROTECTED]>
Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!.
On 16 Mar 2005, Joe Buck stated:
> On Wed, Mar 16, 2005 at 02:41:12AM +0100, [EMAIL PROTECTED] wrote:
>> Writing Hand-written recursive-descent parser miss-cleans the source code
>> and goes hardfully to maintain it!!!
>
> Not if you know how to write one correctly.
... and I must say that Mark's parser is a joy to behold.
>> The best option is a clean grammar in Yacc/Bison!.
>
> GCC had such parsers for over a decade, and yet they are being replaced.
Well, actually, the C++ parser was never *clean*, and the C/ObjC parser
wasn't/isn't exactly nice to look at either. :)
The best option is a clean and maintainable parser. Whether it uses a
parser generator or not is comparatively academic...
--
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
--- Peter da Silva
Do we still need get_callee_fndecl?
Hi,
I am wondering if we still need get_callee_fndecl in the presence of
tree optimizers. I think this function performs a form of constant
propagation at a rather strange place.
Currently, given an address expression of CALL_EXPR, get_callee_fndecl
tries to get to its DECL_INITIAL like so.
STRIP_NOPS (addr);
/* If this is a readonly function pointer, extract its initial value. */
if (DECL_P (addr) && TREE_CODE (addr) != FUNCTION_DECL
&& TREE_READONLY (addr) && ! TREE_THIS_VOLATILE (addr)
&& DECL_INITIAL (addr))
addr = DECL_INITIAL (addr);
This is a constant propagation in that we are propagating the value of
DECL_INITIAL (addr) into a call site.
In fact, even if I remove the block of code above from
get_callee_fndecl, the tree optimizers can still turn an indirect call
into a direct one "bar ()" in the following test case.
extern int bar (void);
typedef int (*bar_type) (void);
const bar_type g = &bar;
int
foo_1 (void)
{
/* Call through a function pointer stored in a const global
variable. */
return (*g)();
}
A call through a function pointer stored in a local variable would be
fine, too.
int
foo_2 (void)
{
/* Call through a function pointer stored in a local variable. */
bar_type h = &bar;
return (*h)();
}
But a call through a function pointer stored in a constant global
array is not optimized. Currently, we don't dig that deep.
const bar_type array[3] = { bar, bar, bar };
int
foo_3 (void)
{
/* Call through a function pointer stored in a constant global
array. */
bar_type h = array[2];
return (*h)();
}
All of the above should illustrate my point.
If we improve our constant/copy propagator to dig into a constant
array and structures, we would get foo_3 optimized for free. After
all, a function pointer is just a variable, and if we have an
assignment of a constant, we can propagate the constant into its uses.
The Java front end used to look into an array, but it doesn't
nowadays. I wonder if there is any data structure that a front end
does not expose to the middle for the purpose of constant propagation.
After all, all we need in get_callee_fndecl seems to be
addr = TREE_OPERAND (call_expr, 0);
return ((TREE_CODE (addr) == ADDR_EXPR
&& TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL)
? TREE_OPERAND (addr, 0) : NULL_TREE;
Thoughts?
Kazu Hirata
Re: Do we still need get_callee_fndecl?
Hi Andrew, > I am wondering if we still need get_callee_fndecl in the presence of > tree optimizers. I think this function performs a form of constant > propagation at a rather strange place. Sorry for omitting you in the CC. Once you fix java_get_callee_fndecl, perhaps we only need to call it during inlining? Kazu Hirata
Re: Do we still need get_callee_fndecl?
Kazu Hirata writes: > > > I am wondering if we still need get_callee_fndecl in the presence of > > tree optimizers. I think this function performs a form of constant > > propagation at a rather strange place. > > Sorry for omitting you in the CC. > > Once you fix java_get_callee_fndecl, perhaps we only need to call it > during inlining? I guess that may be true, yes. I'm not absolutely sure, but it sounds right. Andrew.
Re: reload question
Miles Bader <[EMAIL PROTECTED]> writes: > I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help > things along), and am now running into more understandable reload > problems: "unable to find a register to spill in class" :-/ > > The problem, as I understand, is that reload doesn't deal with conflicts > between secondary and primary reloads -- which are common with my arch > because it's an accumulator architecture. > > For instance, slightly modifying my previous example: > >Say I've got a mov instruction that only works via an accumulator A, >and a two-operand add instruction. "r" regclass includes regs A,X,Y, >and "a" regclass only includes reg A. > >mov has constraints like: 0 = "g,a" 1 = "a,gi" >and add3 has constraints: 0 = "a" 1 = "0"2 = "ri" (say) > > So if before reload you've got an instruction like: > >add temp, [sp + 4], [sp + 6] > > and v2 and v3 are in memory, it will have to have generate something like: > >mov A, [sp + 4]; primary reload 1 in X, with secondary reload 0 A >mov X, A ; "" >mov A, [sp + 6]; primary reload 2 in A, with no secondary reload >add A, X >mov temp, A > > There's really only _one_ register that can be used for many reloads, A. I don't think there is any way that reload can cope with this directly. reload would have to get a lot smarter about ordering the reloads. Since you need the accumulator for so much, one approach you should consider is not exposing the accumulator register until after reload. You could do this by writing pretty much every insn as a define_insn_and_split, with reload_completed as the split condition. Then you split into code that uses the accumulator. Your add instruction permits you to add any two general registers, and you split into moving one into the accumulator, doing the add, and moving the result whereever it should go. If you then split all the insns before the postreload pass, perhaps the generated code won't even be too horrible. Ian
Conversion from fold (buildN (...)) to fold_buildN.
Hi,
I would like to announce that fold_buildN are now ready.
What's this?
Put shortly, this is a tree equivalent of
simplify_build_{unary,binary,ternary}. For example, we could replace
fold (build2 (MULT_EXPR, type, op0, op1));
with
fold_build2 (MULT_EXPR, type, op0, op1);
while avoiding a scratch node that build2 would create when folding is
possible.
What's so good about this?
--
Reduced memory usage. Here is some quantitative justification for
this change:
http://gcc.gnu.org/ml/gcc/2005-03/msg00277.html
It's my my turn to ask you a question
-
When and how do we want to do these conversion?
Currently, I am thinking about doing converting all of
"fold (buildN (...))" and "fold (build (...))" to fold_buildN as soon
as stage 2 starts, which is about one month away, so that I won't
annoy people as much. I don't mind people starting to use fold_buildN
on new code or doing conversions on what they maintain, but I don't
think now is the right time to do the wholesale conversion.
Would you like fold_{unary,binary,ternary} exported?
These are equivalent to simplify_{unary,binary,ternary}. They return
a folded tree if folding is possible. Otherwise, they return
NULL_TREE. If need arises, I am happy to export them for you.
Kazu Hirata
Re: Do we still need get_callee_fndecl?
On Mar 22, 2005, at 8:14 AM, Kazu Hirata wrote: After all, all we need in get_callee_fndecl seems to be addr = TREE_OPERAND (call_expr, 0); return ((TREE_CODE (addr) == ADDR_EXPR && TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL) ? TREE_OPERAND (addr, 0) : NULL_TREE; Thoughts? In Objective C (and ObjC++) it's also a good idea to look under OBJ_TYPE_REF. See this patch, which was deferred to 4.1 and I'm going to resubmit RSN: http://gcc.gnu.org/ml/gcc-patches/2004-12/txt00122.txt
Re: Do we still need get_callee_fndecl?
Hi Dale, > > After all, all we need in get_callee_fndecl seems to be > > > > addr = TREE_OPERAND (call_expr, 0); > > return ((TREE_CODE (addr) == ADDR_EXPR > >&& TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL) > > ? TREE_OPERAND (addr, 0) : NULL_TREE; > > > > Thoughts? > > In Objective C (and ObjC++) it's also a good idea to look under > OBJ_TYPE_REF. > See this patch, which was deferred to 4.1 and I'm going to resubmit RSN: > http://gcc.gnu.org/ml/gcc-patches/2004-12/txt00122.txt Thanks for the information. Does OBJ_TYPE_REF_EXPR only apply to a CALL_EXPR? In other words, are there other forms of constants that are exposed by looking into OBJ_TYPE_REF_EXPR? Kazu Hirata
Re: Do we still need get_callee_fndecl?
On Mar 22, 2005, at 10:21 AM, Kazu Hirata wrote: Hi Dale, After all, all we need in get_callee_fndecl seems to be addr = TREE_OPERAND (call_expr, 0); return ((TREE_CODE (addr) == ADDR_EXPR && TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL) ? TREE_OPERAND (addr, 0) : NULL_TREE; Thoughts? In Objective C (and ObjC++) it's also a good idea to look under OBJ_TYPE_REF. See this patch, which was deferred to 4.1 and I'm going to resubmit RSN: http://gcc.gnu.org/ml/gcc-patches/2004-12/txt00122.txt Thanks for the information. Does OBJ_TYPE_REF_EXPR only apply to a CALL_EXPR? In other words, are there other forms of constants that are exposed by looking into OBJ_TYPE_REF_EXPR? I believe the usage here is the only one relevant to ObjC. It is used for other things in C++, but I don't know how.
Re: Question regarding MIPS_GPREL_16 relocation
On Tue, 2005-03-22 at 13:21 +0100, Mile Davidovic wrote: > Hello all > I am using gcc for MIPS ( 3.3.x, target mips-elf). > I had problem during linking, (MIPS_GPREL_16 relocation truncated to fit > error occurs). > I set value of gp registers to appropriate value and used -mlong-calls and > -G0 switch to > prevent this problem. > > However problem arise again depending on section size (bss, sbss, data, > sdata). Every time > that heppends I have to move gp again. I believe that this reloation is used > in gcc > libraries (libgcc, stdc++, ...). Is that any chance these libraries to be > build without > mention relocation? You could also try upgrading your gcc and binutils. Without a testcase I'm not certain what's happening, but we've fixed a number of problems with such over the years. -eric
Re: PRE in GCC-3.3.3
Rajesh Babu wrote: The target I used is i686-linux. For the same example gcc-3.4.1 eliminated the redundant expression, where as gcc-3.3.3 didn't do it. I observed it by dumping RTL with -dG switch. I didnt get abt the flaw you were talking about. The optimization is done on the pseudo registers, where is the question of forcing into memory there. Your example has int c, d; d = c++ which is both a use of c while uninitialized, and a set of c to an uninitialized value. The rest of this isn't very interesting, as gcc-3.3 is way too old to be looking at optimizations. Looking at the RTL, I don't see the optimization being performed in gcc-3.4. I still see two adds for c. But since it already works in mainline I don't care. By the way, x86 is not a good target to use for looking at gcse performance, because of all of the condition code clobbers, which make it difficult for gcse to move instructions around. It will only eliminate a redundant add if it can convert it to a leal instruction which does not clobber the condition code register. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
GCC 4.0 pragma interface/implementation regression with templates
Hello,
The attached implementation/header issues a warning when
$ gcc-4.0-c -o test_undefined.o test_undefined.cpp
undefined_constructor.hpp:13: warning: inline function 'Base::Base()' used but
never defined
This does not happen with 3.x compilers. If you remove the
#pragma interface, the warning disapears. It does also not happen
if you write
#pragma implementation "undefined_constructor.hpp"
in the cpp file.
It apears to be triggered when using a template class with a base class.
I had similar warnings for a missing destructor.
Peter Soetens
#pragma interface
struct Base
{
};
template< class T>
struct Sub
: public Base
{
Sub() {}
};
#pragma implementation
#include "undefined_constructor.hpp"
void foo()
{
Sub sub;
}
Re: GCC 4.0 pragma interface/implementation regression with templates
On Mar 22, 2005, at 2:54 PM, Peter Soetens wrote: Hello, The attached implementation/header issues a warning when $ gcc-4.0-c -o test_undefined.o test_undefined.cpp undefined_constructor.hpp:13: warning: inline function 'Base::Base()' used but never defined This is PR 20584 -- Pinski
Re: CC0 to CCmode conversion
Denis Chertykov wrote: I think that sequence of compare + cond-jump will exists in any compiler pass. Combine can optimize away compares, if you have other instructions that set the condition code register to useful values. This optimization will only work correctly if instructions that set or clobber the cc are properly marked. If no instructions are marked as setting the cc (other than compares), then this will probably work, but you won't get any optimization from combine, and may get worse code than before. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: AVR: CC0 to CCmode conversion
> They (load, store, add) can modify flags before reload. > (while no reload_in_progress) > Is this OK ? Yes. r~
Re: Useless vectorization of small loops
On Mon, Mar 21, 2005 at 01:45:19PM +0100, Richard Guenther wrote: > I also cannot > see why we zero the mm registers before loading and why we > load them high/low separated: We load hi/lo separate because movlps+movhps is faster than movups. We zero first to break the insn dependency chain before doing two half-register modifies. IIRC such chain breaking is only relevant to the p4. r~
Re: Specifying alignment of pointer targets
On Mon, Mar 21, 2005 at 02:28:49PM +0100, Richard Guenther wrote: > I'd like to specify (for vectorization) the alignment of the > target of a pointer. This is not possible in gcc at present. r~
Keep dwarf.h in sync?
Nick Clifton and I have been discussing the idea of keeping GCC and binutils' copy of dwarf.h in sync. I've just resolved all of the differences with the binutils version of the file. Perhaps DJ's merge script could keep gcc/gcc/dwarf.h in sync with src/include/elf/dwarf.h as it does for, say, libiberty source files? Ben signature.asc Description: OpenPGP digital signature
Re: Keep dwarf.h in sync?
> Nick Clifton and I have been discussing the idea of keeping GCC and > binutils' copy of dwarf.h in sync. I've just resolved all of the > differences with the binutils version of the file. Perhaps DJ's > merge script could keep gcc/gcc/dwarf.h in sync with > src/include/elf/dwarf.h as it does for, say, libiberty source files? DJ's script isn't really geared towards files in different places in the two repositories. Otherwise, keep in mind that setting up such an automated sync requires that the binutils folks cede all control over the file to the gcc maintainers. It's probably easier to just arrange for at least one person to have commit privs for that file in both places.
Re: Obsoleting more ports for 4.0.
Kazu Hirata wrote: ip2k This is an Ubicom cpu, and they maintain a GNU port in house. There are references to it on their web site, though I didn't see a convenient link to download it. Probably not much worth to the FSF version of this port if they aren't contributing patches to it. ns32k Everytime we have tried to get rid of ns32k, some NetBSD users have complained. There is still a maintained NetBSD port for this. http://www.netbsd.org/Ports/pc532/ There are probably only about a dozen working machines left in existence, though. Not really worth our trouble if they aren't interested in maintaining the gcc port themselves. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
RFA: PR 19225
I'm interested in fixing this, but could use some help from somebody knowledgeable about how x86 EH is supposed to work. In particular, what's the expected relationship between SP at the point of a throwing call, and when it gets back to the landing pad?
Re: expand_binop misplacing results?
> On Mon, 21 Mar 2005, DJ Delorie wrote: > > 2005-03-21 DJ Delorie <[EMAIL PROTECTED]> > > > > * optabs.c (expand_binop): Make sure the first subword's result > > gets stored. > > This is OK for mainline, provided that you bootstrap and regression > test it somewhere. Bootstrapped with no regressions on X86_64 FC3, so committed. Thanks!
Re: converting Ada to handle USE_MAPPED_LOCATION
Geert Bosch wrote: Of the three proposals: [...] The ideal solution I think is for Ada to use line-map's source_location for Sloc in its lexer. [...] translate Sloc integers to source_location when we translate the Ada intermal format to Gcc trees. [...] the location_t in the shared Gcc should be a language-defined opaque time, and have language call-backs. The first one really is out for the Ada maintainers, as this would couple the front end far too tightly to the back end Ok. and lose the nice property that the exact same front end sources (excluding the few C files for tree conversion) > can be used for any GCC back end from 2.8.1 to 4.1 Does this help with boostrapping? Otherwise, I'm not sure why this is important. But anyway, I'm not going to push for this approach. The second one wouldn't be my preferred choice, as it adds complexity I think this solution is *less* complex than your preferred solution. A simple translaton can be done in just a few lines of code, which are localized to a single file - maybe a single function. (Adding a linemap_get_location as I suggested is not strictly needed, but is probably a good idea.) Making location_t an opaque type seems to have a lot more ramifications, including adding language hooks and making sure they're used where needed. > for no gain, I think call-backs are generally to be avoided. They make the system more fragile and less flexible. Consider a hypothetical Gcc that would allow opimizing modules from multiple languages. After inlining, you might have tree nodes and rtl from either C or Ada, all mixed together. In that environment a language-dependent opaque type isn't going to work; locations have to be translated to a common representation. > but because the code can remain localized to the few C files interfacing the front end to the back end, this would be acceptable. Good. The last would be far preferred, as it would not tie in front ends so much to the back end, Translating locations at the same time you translate to generic tree nodes doesn't seem to involve any extra tying. As it both seems easiest to implement, I suspect not. Simple-seeming changes can end up being quite a pain to implement when multiple modules are involved. Just look at Zack's recent work to clean up version number management. and cleanest. Of course that's in the eye of the beholder. I think a local translation is cleaner and more robust/safer than a global opaque type/call-back. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
