C Parser

[Paulo J. Matos]

Hi all,

I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.

I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountable task and
not very logic given the parser generators in existence today.

Can someone comment this? (which issues led to this decision?)

Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Where the languages meet...

[Paulo J. Matos]

Hello all,

After reading the internals of gcc wikibooks some questions come up.
So, gcc has front end for C, C++, java, fortran, etc..
All these languages have a frontend which parse into AST and then
GIMPLE which is converted to RTX and then assembly. Now, my guess is
that GIMPLE is the _common_ ground for all languages. No matter which
language, all will go through GIMPLE, so if I wished to implement some
language analysis / optimizations, I should do it in GIMPLE to be able
to implement in one go the optimization for all languages, right?

Is there any formal syntax/semantics for GIMPLE? Or the SIMPLE paper
is the only thing with this stuff? Any reference to the differences
between GIMPLE and SIMPLE?

Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Dumping gimple tree

[Paulo J. Matos]

Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire
Functions" by Jason Merrill it says there's a flag -fdump-tree-simple
to get the gimple tree (page 3). However, this doesn't exist in gcc
4.1:
$ gcc -fdump-tree-simple bigger3.c
cc1: error: unrecognized command line option "-fdump-tree-simple"

Is there anything similar for gcc4.1?

Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Dumping gimple tree

[Paulo J. Matos]

Argh, forget it!

Found the answer in:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Debugging-Options.html#Debugging-Options

Regards,

Paulo Matos

On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:

Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire
Functions" by Jason Merrill it says there's a flag -fdump-tree-simple
to get the gimple tree (page 3). However, this doesn't exist in gcc
4.1:
$ gcc -fdump-tree-simple bigger3.c
cc1: error: unrecognized command line option "-fdump-tree-simple"

Is there anything similar for gcc4.1?

Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Where the languages meet...

[Paulo J. Matos]

On 18 Jan 2007 07:42:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

"Paulo J. Matos" <[EMAIL PROTECTED]> writes:

> After reading the internals of gcc wikibooks some questions come up.
> So, gcc has front end for C, C++, java, fortran, etc..
> All these languages have a frontend which parse into AST and then
> GIMPLE which is converted to RTX and then assembly. Now, my guess is
> that GIMPLE is the _common_ ground for all languages. No matter which
> language, all will go through GIMPLE, so if I wished to implement some
> language analysis / optimizations, I should do it in GIMPLE to be able
> to implement in one go the optimization for all languages, right?

Yes.

> Is there any formal syntax/semantics for GIMPLE? Or the SIMPLE paper
> is the only thing with this stuff? Any reference to the differences
> between GIMPLE and SIMPLE?

GIMPLE is more-or-less documented in the gcc internals manual.

Ian



Many thanks for the concise, direct answer.

Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Which optimization levels affect gimple?

[Paulo J. Matos]

Hi all,

Which optimization levels affect gimple?
I've tried for a program to check what kind of gimple code you get
with -fdump-tree-gimple and -O0 and -O3 have different results,
however, -O3 and -O9 have exactly the same output. Will -Ox for x > 3,
generate the same gimple trees? (i.e., are done in backend of gcc?)

Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 01/24/07 12:44:

> check what kind of gimple code you get with -fdump-tree-gimple and
> -O0 and -O3 have different results,
>
-fdump-tree-gimple is the first dump *before* any optimizations occur.
To see the effect of all the GIMPLE optimizations you should use
-fdump-tree-optimized.



Is the output of -fdump-tree-optimized a subset of GIMPLE?


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 24 Jan 2007 09:56:55 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

"Paulo J. Matos" <[EMAIL PROTECTED]> writes:

> Which optimization levels affect gimple?
> I've tried for a program to check what kind of gimple code you get
> with -fdump-tree-gimple and -O0 and -O3 have different results,
> however, -O3 and -O9 have exactly the same output. Will -Ox for x > 3,
> generate the same gimple trees? (i.e., are done in backend of gcc?)

At present, as far as I know, the highest defined optimization level
is -O3.  -ONUMBER where NUMBER > 3 is equivalent to -O3.  There is no
particular guarantee that will remain true in the future, although
there are also no current plans to change it.


That's quite curious. I always thought that O3 was different to O4,
O5, ... O9. Still, beyond O3 optimizations were not safe... maybe an
old gcc myth! :-)

Thanks for clearing that up to me.



Ian




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 01/24/07 12:44:

> check what kind of gimple code you get with -fdump-tree-gimple and
> -O0 and -O3 have different results,
>
-fdump-tree-gimple is the first dump *before* any optimizations occur.
To see the effect of all the GIMPLE optimizations you should use
-fdump-tree-optimized.



So the dump-tree-optimized will also return GIMPLE? a subset of... GIMPLE?

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/26/07, Richard Guenther <[EMAIL PROTECTED]> wrote:

On 1/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Paulo J. Matos wrote on 01/26/07 06:52:
>
> > Is the output of -fdump-tree-optimized a subset of GIMPLE?
> >
> Yes.  The output is an incomplete textual representation of the GIMPLE
> form of the program.

It's after doing TER, so the statements are no longer valid GIMPLE statements.



What do you mean by TER?


Richard.




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/28/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:

On 1/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Paulo J. Matos wrote on 01/24/07 12:44:
>
> > check what kind of gimple code you get with -fdump-tree-gimple and
> > -O0 and -O3 have different results,
> >
> -fdump-tree-gimple is the first dump *before* any optimizations occur.
> To see the effect of all the GIMPLE optimizations you should use
> -fdump-tree-optimized.
>

So the dump-tree-optimized will also return GIMPLE? a subset of... GIMPLE?



Agrh, forget it... this was already replied to!


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Richard Guenther wrote on 01/26/07 07:28:

> It's after doing TER, so the statements are no longer valid GIMPLE statements.
>
Silly me.  Richard's right.  You want the output of -fdump-tree-uncprop.
  That's the last GIMPLE dump (if my memory doesn't fail me again).



Ok, so, I guess that being GIMPLE a language, there's somewhere a
specification of possible constructs, right? Where can I find it? I
tried to search in the inside gcc manual but there seems to be nothing
like a formal specification of the nodes in the GIMPLE AST.

Moreover, is there anything referencing which optimizations are
performed between fdump-tree-gimple and fdump-tree-uncprop (being
those, afaik, the first and last gimple dumps)?

If reading source code could help me understand GIMPLE, could please
someone tell me where to start looking at it. I've svn'ed gcc and it's
huge so I'm quite lost. Where is the output of fdump-tree-gimple done?

Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/29/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

-fdump-tree-all gives you all the dumps by the high-level optimizers.
-fdump-all-all gives you all the dumps by both GIMPLE and RTL optimizers.



Is this -fdump-all-all version specific? Doesn't work on 4.1.1:
$ g++ -fdump-all-all allocation.cpp
cc1plus: error: unrecognized command line option "-fdump-all-all"

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

After GIMPLE...

[Paulo J. Matos]

Hi all,

I've been looking into the gcc sources and I'm somewhat confused.
Are gcc/g++ comepletely independent programs or do they share a backend?

This question comes from the fact that I was trying to find a point in
the source where I could get the GIMPLE tree and do with it what ever
I wished to, without modifying too many files but it seems that gcc,
g++ and other frontends have different program flows and only share
some data structures and backend sources. So probably I need to
eliminate the backend call in every frontend and after GIMPLE is
created call my own functions which get the GIMPLE tree  and then
compile my files against every frontend. Right?

Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Which optimization levels affect gimple?

[Paulo J. Matos]

On 1/29/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:


-fdump-tree-all-all will work
as will -fdump-rtl-all-all

I never added support for -fdump-all-all-all :)



Thank you!

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 29 Jan 2007 11:38:15 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

"Paulo J. Matos" <[EMAIL PROTECTED]> writes:

> I've been looking into the gcc sources and I'm somewhat confused.
> Are gcc/g++ comepletely independent programs or do they share a backend?

In the source code, they share a backend.  As executables, they are
different programs: cc1 and cc1plus.



OK, thanks, that was the idea I got from looking at the code.


> This question comes from the fact that I was trying to find a point in
> the source where I could get the GIMPLE tree and do with it what ever
> I wished to, without modifying too many files but it seems that gcc,
> g++ and other frontends have different program flows and only share
> some data structures and backend sources. So probably I need to
> eliminate the backend call in every frontend and after GIMPLE is
> created call my own functions which get the GIMPLE tree  and then
> compile my files against every frontend. Right?

I don't see why you would have to modify any code in the frontend.
You would modify the middle-end code.  Rebuilding the compiler would
rebuild cc1, cc1plus, etc.



You're right... middle-end code... that's what I need to change, not
frontend. I keep forgetting some concepts and vocabulary!

Thank you,

Paulo Matos


Ian




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 29 Jan 2007 11:38:15 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

I don't see why you would have to modify any code in the frontend.
You would modify the middle-end code.  Rebuilding the compiler would
rebuild cc1, cc1plus, etc.



Well, I spent the morning looking at the code and since what I need is
only the flow of gcc up until I have the GIMPLE tree, I could add a
pass after the pass which generates the gimple tree, in that pass I do
what I need with the gimple tree and then call exit(). Would this be a
good idea?

If yes, then the idea would be to create a pass and add it in passes.c
after the line
NEXT_PASS (pass_lower_cf);

since from what I heard in #gcc, this is where the gimple tree is
created, right?


Ian




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 01/30/07 10:11:

> Well, I spent the morning looking at the code and since what I need is
> only the flow of gcc up until I have the GIMPLE tree, I could add a
> pass after the pass which generates the gimple tree, in that pass I do
> what I need with the gimple tree and then call exit(). Would this be a
> good idea?
>
It would probably not be a good idea.  Passes are called for each
function in the callgraph.  If you stop immediately after your pass, you
will leave all the other functions unprocessed.

What is it that you want to do?  If you need dataflow information, you
probably also need to have the GIMPLE code in SSA form.



Yes, only after some search I understood that passes are done on a
function by function basis which doesn't suit as is.

Well, I want to get a tree representation of the source (why gimple?
because it's language indep, so if I do it in gimple, I don't need to
worry about the language in which the source was written) and analyse
it. This analysis is not really specified at the moment. Is part of my
PhD and will certainly evolve but it would start with something like
telling the users how many variables of which type are defined in the
given source code, how many if blocks there are, etc. and then exit.
The choice of gimple is two-fold. First you get language independence,
that's why I just don't do it in C or C++ directly, or Java or
Fortran. The reason why I don't do it in a lower language is because
some constructs would be lost with some optimization details.
Constructs which might later be useful for my analysis. So, ideally, I
would like just the gcc part until the first part of the middleend
where you have a 'no optimizations', language independent AST of the
source file.
The reason why I just don't parse the gimple output of dump is
because, as it was said, there's information regarding the source
which it's not represented in the dump and which might be useful to
me.


> If yes, then the idea would be to create a pass and add it in passes.c
> after the line
> NEXT_PASS (pass_lower_cf);
>
> since from what I heard in #gcc, this is where the gimple tree is
> created, right?
>
Well, it depends on what you need.  If your pass can work in high GIMPLE
then you can insert it before that.  pass_lower_cf lowers control flow
and lexical scopes, but not EH.

Perhaps if you describe a little bit what you are trying to do, we can
give you a better idea.



I've described it above. Any suggestions regarding the best way to
taylor gcc to fit my needs?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Fwd: Compiling GCC

[Paulo J. Matos]

I forgot to send to the mailing list that the --disable-multilib from
Andrew worked. Thank you all.

:)

-- Forwarded message --
From: Paulo J. Matos <[EMAIL PROTECTED]>
Date: Jan 31, 2007 3:41 PM
Subject: Re: Compiling GCC
To: Andrew Haley <[EMAIL PROTECTED]>


On 1/31/07, Andrew Haley <[EMAIL PROTECTED]> wrote:

The problem might be that you don't have the target libs installed for
a multilib build.  Try --disable-multilib.



Done! :) Working now, thank you!


Andrew.




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 01/31/07 11:26:

> So, ideally, I would like just the gcc part until the first part of
> the middleend where you have a 'no optimizations', language
> independent AST of the source file.
>
OK, so you probably want to inject your pass right before pass_build_ssa
(in init_optimization_passes).  All the facilities to traverse the IL
and flowgraph described in the Tree SSA section of the internals manual
should apply.



What can I do then to stop gcc to further process things? After
informing the user there's no more reason on my site to continue.


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 2/1/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 02/01/07 04:37:

> What can I do then to stop gcc to further process things? After
> informing the user there's no more reason on my site to continue.
>
Stop gracefully or just stop?  The latter is easy.  The former involves
writing code to skip all passes after a certain point, or just don't
schedule the passes don't want to run.  See init_optimization_passes.



Well, I guessed the answer would be something like that... :)

I've already started working on it and everything seems ok up until
now so I'm on the right track. :)

Regards and thanks very much,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Disabling bootstrap

[Paulo J. Matos]

Hi all,

I've changed gcc by adding a new pass, however, when I compile gcc,
during compilation it calls itself, so I disabled bootstrap but that
is still happening even during bootstrap. Is there any way to compile
gcc without the final gcc compiling something?

Moreover, how can I add a flag to gcc so that it enables/disables a given pass?

Regards,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Disabling bootstrap

[Paulo J. Matos]

On 2/2/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:

Hello,

> I've changed gcc by adding a new pass, however, when I compile gcc,
> during compilation it calls itself, so I disabled bootstrap but that
> is still happening even during bootstrap. Is there any way to compile
> gcc without the final gcc compiling something?

make stage1-bubble.  See also
http://gcc.gnu.org/wiki/Top-Level_Bootstrap

> Moreover, how can I add a flag to gcc so that it enables/disables a given
> pass?

Add the flag to common.opt, and test it in the gate function of your
pass.



Thank you!


Zdenek




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 01/31/07 11:26:

> So, ideally, I would like just the gcc part until the first part of
> the middleend where you have a 'no optimizations', language
> independent AST of the source file.
>
OK, so you probably want to inject your pass right before pass_build_ssa


Why before pass_build_ssa? (version 4.1.1)
I've tried this but for some reason my pass is not called unless I use
-On where n > 0. Well, I guess it is because my pass is inside
pass_all_optimizations.sub.  So I guess the right thing would be to
have it run in all_passes, after pass_init_datastructures. Is it or is
it not a good idea to have it here. Was there any special reason for
you to suggest me to put it before pass_build_ssa, inside optimization
passes?

Cheers,

Paulo Matos


(in init_optimization_passes).  All the facilities to traverse the IL
and flowgraph described in the Tree SSA section of the internals manual
should apply.




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: After GIMPLE...

[Paulo J. Matos]

On 2/6/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 02/06/07 14:19:

> Why before pass_build_ssa? (version 4.1.1)
>
It depends on the properties your pass requires.  If you ask for
PROP_cfg and PROP_gimple_any then you should schedule it after the CFG
has been built, but if you need PROP_ssa, then you must be after
pass_build_ssa which implies that your pass only gets enabled at -O1+.



Ok, thank you very much.

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Finalizer after pass?

[Paulo J. Matos]

Hello,

I have stumbled upon a very problematic issue. I have been, through a
pass, creating a structure of the gimple tree which fits my interests.
However, my final need is _after_ all gimple functions are processed,
to process that structure to give interesting reports to the user.
Now, I stumbled upon the fact that since passes are called
per-function, I'm generating a structure I'll not be able to access
because I don't know if the function I'm in at a given call is the
last one, nor am I able (afaik) to install a function somewhere to be
called after all functions have been processed. I'd appreciate any
input on this.
Is there a way to install a finalizing function? (to be called after
all functions in the pass have been processed)
Or to know if the current function being processed is the last one?
(maybe if I know the number of times my pass will be called!)

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Finalizer after pass?

[Paulo J. Matos]

On 2/28/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 02/28/07 11:07:

> Is there a way to install a finalizing function? (to be called after
> all functions in the pass have been processed)
> Or to know if the current function being processed is the last one?
> (maybe if I know the number of times my pass will be called!)
>
Perhaps it's easier to implement your feature as an IPA pass.  For IPA
passes, you are not called with a specific function.  Instead, you get
to traverse the callgraph yourself.  See passes like ipa-cp.c for details.



My IPA pass seems to be run only for -On, n>=1, is there a way to make
it ran even for -O0?

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Finalizer after pass?

[Paulo J. Matos]

On 3/1/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 03/01/07 10:41:

> My IPA pass seems to be run only for -On, n>=1, is there a way to make
> it ran even for -O0?

No, we only run IPA passes if flag_unit_at_a_time is set.  That only is
set when optimizing.  At -O0, we simply emit functions individually.



OK, thank you.

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Accessing function code from CFG

[Paulo J. Matos]

Hi all,

In an IPA pass, for each CFG node, I have a tree decl member from
which I can access the return type, name of the function, argument
names and its types, but I can't seem to find a way to get the
function code. I would guess it would be a basic block list but I
don't know where I can get it.

Any suggestions?

Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Accessing function code from CFG

[Paulo J. Matos]

On 3/2/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 03/02/07 10:12:

> In an IPA pass, for each CFG node, I have a tree decl member from
> which I can access the return type, name of the function, argument
> names and its types, but I can't seem to find a way to get the
> function code. I would guess it would be a basic block list but I
> don't know where I can get it.

You need to get at the function structure from the cgraph node with
DECL_STRUCT_FUNCTION (cgraph_node->decl).  Then you can use one of the
CFG accessors like basic_block_info_for_function().



Great! :-) Thank you!


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Adding a new gcc dir

[Paulo J. Matos]

Hi all,

I've just added a new gcc subdir : head/gcc/myproj with structures and
utilities for my ipa pass which lives in head/gcc. Now I have to tell
gcc to compile the files inside myproj. Is there a standard way to do
this? I've looked into head/gcc/Makefile.in but it seem quite
cluttered and I don't really know where to begin since the gcc build
is quite complex.

Any suggestions? (Probably I can have my Makefile.in in myproj dir)
but then where should I tell gcc to compile them)

Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: BUG: wrong function call

[Paulo J. Matos]

On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote:

Hi, I use multiple inheritance in my project. In the child class i have
functions GetParam() and SetParam().
In the cpp-file I call GetParam() function, but I fell to SetParam()
function.
Can You help me?



Don't take me wrong but it is most likely a bug in your code. Still,
you might want to inform the developers (not me) through this mailing
list which code you're compiling and which version of gcc you're
using.

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/6/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:

Hi all,

I've just added a new gcc subdir : head/gcc/myproj with structures and
utilities for my ipa pass which lives in head/gcc. Now I have to tell
gcc to compile the files inside myproj. Is there a standard way to do
this? I've looked into head/gcc/Makefile.in but it seem quite
cluttered and I don't really know where to begin since the gcc build
is quite complex.

Any suggestions? (Probably I can have my Makefile.in in myproj dir)
but then where should I tell gcc to compile them)



Well, added a couple of lines to gcc/Makefile.in referring to files in
myproj. Still, although it is partly working one thing is annoying me.
It's using these flags by default:
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute

Which means using C90, which means no mixed declarations and code, no
C++ comments, etc. Is there any way to compile at least, my files with
c99 constructs?
Or all gcc code should be built like this??

Regards,

Paulo Matos


Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:

On 06 March 2007 16:07, Paulo J. Matos wrote:


> Well, added a couple of lines to gcc/Makefile.in referring to files in
> myproj. Still, although it is partly working one thing is annoying me.
> It's using these flags by default:
> -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
> -Wmissing-format-attribute
>
> Which means using C90, which means no mixed declarations and code, no
> C++ comments, etc. Is there any way to compile at least, my files with
> c99 constructs?

  Take a look at the section of gcc/Makefile.in beginning "# Various ways of
specifying flags for compilations:" and go from there.

> Or all gcc code should be built like this??

  Well, for your own personal purposes, you can do whatever you like, but it
is part of the coding standard that all gcc code should be bog-standard C90,
so that it is possible for end-users to build gcc on any machine, even a very
old one with a very old compiler.



OK, thank you. I'll adhere to this standard them. :-)


cheers,
  DaveK
--
Can't think of a witty .sigline today





--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/6/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:

Hi all,

I've just added a new gcc subdir : head/gcc/myproj with structures and
utilities for my ipa pass which lives in head/gcc. Now I have to tell
gcc to compile the files inside myproj. Is there a standard way to do
this? I've looked into head/gcc/Makefile.in but it seem quite
cluttered and I don't really know where to begin since the gcc build
is quite complex.

Any suggestions? (Probably I can have my Makefile.in in myproj dir)
but then where should I tell gcc to compile them)



Thank you for the issue on C90, which I will adhere to.
Still, I cannot compile my files living on a new dir. So, exactly what
I did. Under gcc I created a subdir gsvt with files symbol-tables.c,
symbol-tables.h and symbol-tables-priv.h. My pass which requires these
files to build is with all other passes inside gcc and it is called
ipa-gsvt-pass.c. So, I have this in gcc/Makefile.in
In OBJS-common I added: ipa-gsvt-pass.o symbol-tables.o
Then I created a target for my pass and symbol-tables:
ipa-gsvt-pass.o : ipa-gsvt-pass.c ...
symbol-tables.o : gsvt/symbol-tables.c gsvt/symbol-tables.h
gsvt/symbol-tables-priv.h ../../../acocc/data_structures/trie/trie.o

Everything seems to compile perfectly but when linking I get:
i686-pc-linux-gnu-ar rc libbackend.a tree-chrec.o
tree-scalar-evolution.o tree-data-ref.o tree-cfg.o tree-dfa.o
tree-eh.o tree-ssa.o tree-optimize.o tree-gimple.o gimplify.o
tree-pretty-print.o tree-into-ssa.o ipa-gsvt-pass.o symbol-tables.o
tree-outof-ssa.o tree-ssa-ccp.o tree-vn.o tree-ssa-uncprop.o
tree-ssa-dce.o  tree-ssa-copy.o tree-nrv.o tree-ssa-copyrename.o
tree-ssa-pre.o tree-ssa-live.o tree-ssa-operands.o tree-ssa-alias.o
tree-ssa-phiopt.o tree-ssa-forwprop.o tree-nested.o tree-ssa-dse.o
tree-ssa-dom.o domwalk.o tree-tailcall.o gimple-low.o tree-iterator.o
tree-phinodes.o tree-ssanames.o tree-sra.o tree-complex.o
tree-vect-generic.o tree-ssa-loop.o tree-ssa-loop-niter.o
tree-ssa-loop-manip.o tree-ssa-threadupdate.o tree-vectorizer.o
tree-vect-analyze.o tree-vect-transform.o tree-ssa-loop-ivcanon.o
tree-ssa-propagate.o tree-ssa-address.o tree-ssa-math-opts.o
tree-ssa-loop-ivopts.o tree-if-conv.o tree-ssa-loop-unswitch.o alias.o
bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o
cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgloopanal.o
cfgloopmanip.o loop-init.o loop-unswitch.o loop-unroll.o cfgrtl.o
combine.o conflict.o convert.o coverage.o cse.o cselib.o dbxout.o
ddg.o tree-ssa-loop-ch.o loop-invariant.o tree-ssa-loop-im.o debug.o
df.o diagnostic.o dojump.o dominance.o loop-doloop.o dwarf2asm.o
dwarf2out.o emit-rtl.o except.o explow.o loop-iv.o expmed.o expr.o
final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o
global.o graph.o gtype-desc.o haifa-sched.o hooks.o ifcvt.o
insn-attrtab.o insn-emit.o insn-modes.o insn-extract.o insn-opinit.o
insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o
langhooks.o lcm.o lists.o local-alloc.o loop.o mode-switching.o
modulo-sched.o optabs.o options.o opts.o params.o postreload.o
postreload-gcse.o predict.o insn-preds.o pointer-set.o print-rtl.o
print-tree.o profile.o value-prof.o var-tracking.o real.o recog.o
reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o
reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o
sched-ebb.o sched-rgn.o sched-vis.o sdbout.o simplify-rtx.o sreal.o
stmt.o stor-layout.o stringpool.o targhooks.o timevar.o toplev.o
tracer.o tree.o tree-dump.o varasm.o varray.o vec.o version.o
vmsdbgout.o xcoffout.o alloc-pool.o et-forest.o cfghooks.o bt-load.o
pretty-print.o ggc-page.o web.o passes.o tree-profile.o rtlhooks.o
cfgexpand.o lambda-mat.o lambda-trans.o  lambda-code.o
tree-loop-linear.o tree-ssa-sink.o tree-vrp.o tree-stdarg.o
tree-cfgcleanup.o tree-ssa-reassoc.o tree-ssa-structalias.o
tree-object-size.o i386.o  host-linux.o tree-inline.o cgraph.o
cgraphunit.o tree-nomudflap.o ipa.o ipa-inline.o ipa-utils.o
ipa-reference.o ipa-pure-const.o ipa-type-escape.o ipa-prop.o ipa-cp.o
i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory

And in fact there is no symbol-tables.o but I saw it being compiled so
I wonder where it has gone to.


Any suggestions ??
Regards,

Paulo Matos


Regards,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:

On 06 March 2007 18:22, Paulo J. Matos wrote:


> i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory
>
> And in fact there is no symbol-tables.o but I saw it being compiled so
> I wonder where it has gone to.
>
>
> Any suggestions ??

  1.  Always pipe the build output to a file so you can review it after the
build and see what went wrong.



Yes, so? What help would that be right now?


  2.  Learn about the unix 'find' command.



I know about the find command! Why should I need it here? To do "find
. -name symbol-tables.o" ? I told you, there's no such file.


  3.  Don't use a subdirectory, none of the other passes do that,
subdirectories are for separate languages.  Think of it like this: a compile
taking place in a subdirectory of the gcc build dir can reference the core gcc
.o files built in the parent dir, but the core gcc build in the parent dir
can't reference files in a sub-dir.  (This isn't strictly true, I'm sure
there's a way to make it work, but all the existing build machinery works this
way round and it's probably easiest to keep to the same scheme).



So, any auxiliar files to the pass should be in the same directory as
the pass itself. Or do you advise me to have _all_ the code in the
pass file?

Cheers,

Paulo Matos



cheers,
  DaveK
--
Can't think of a witty .sigline today





--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:

  No, I advise that when adding a pass, regardless of whether the code can fit
in a single file or is large enough to need to use several separate files,
it's consistent to put all the files that implement the pass in the main 'gcc'
source directory.




OK, thank you.


cheers,
  DaveK
--
Can't think of a witty .sigline today





--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote:

On 07 March 2007 14:30, [EMAIL PROTECTED] wrote:

> Is it time to offer "second-strap" level of compilation? Ie allow C99 to
> bootstrap the creation of a basic GCC compiler, then allow a second compile
> using the basic GCC compiler to get the full compiler.
>
> Nick

  Effectively that's what bootstrapping already does, so IIUIC, as long as no
C99 creeps into the core C language compiler, it /should/ work to use C99 (and
indeed GCC language extensions, attributes etc. etc.) in e.g. the cp/
subdirectory or other places where the files only relate to other languages.



But if I add in my pass // args, or mixed code and variable
declarations for example, I get warnings, so it is not that clean.
Maybe only by removing pedantic, are you able to do that.

Right?

Cheers,

Paulo Matos


cheers,
  DaveK
--
Can't think of a witty .sigline today





--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/7/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:

On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
>
> > Is it time to offer "second-strap" level of compilation? Ie allow C99 to
> > bootstrap the creation of a basic GCC compiler, then allow a second compile
> > using the basic GCC compiler to get the full compiler.
> >
> > Nick
>
>   Effectively that's what bootstrapping already does, so IIUIC, as long as no
> C99 creeps into the core C language compiler, it /should/ work to use C99 (and
> indeed GCC language extensions, attributes etc. etc.) in e.g. the cp/
> subdirectory or other places where the files only relate to other languages.
>

But if I add in my pass // args, or mixed code and variable
declarations for example, I get warnings, so it is not that clean.
Maybe only by removing pedantic, are you able to do that.



Moreover, for some reason when using malloc, a lot of poisonous malloc
warning come up which are solved by using xmalloc instead, which is
another thing I cannot figure out. What is better in xmalloc than
malloc?


Right?

Cheers,

Paulo Matos

> cheers,
>   DaveK
> --
> Can't think of a witty .sigline today
>
>


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Accessing function code from CFG

[Paulo J. Matos]

On 3/2/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 03/02/07 10:12:

> In an IPA pass, for each CFG node, I have a tree decl member from
> which I can access the return type, name of the function, argument
> names and its types, but I can't seem to find a way to get the
> function code. I would guess it would be a basic block list but I
> don't know where I can get it.

You need to get at the function structure from the cgraph node with
DECL_STRUCT_FUNCTION (cgraph_node->decl).  Then you can use one of the
CFG accessors like basic_block_info_for_function().



For functions to which DECL_STRUCT_FUNCTION (cgraph_node->decl) != 0,
I'm always getting
VARRAY_ACTIVE_SIZE(basic_block_info_for_function(DECL_STRUCT_FUNCTION
(cgraph_node->decl))) == 0.

Is this normal? It seems there are no basic blocks set for the
functions. Probably my pass is being run before the bbs are created?

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/7/07, Paul Brook <[EMAIL PROTECTED]> wrote:

On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
> Is it time to offer "second-strap" level of compilation? Ie allow C99 to
> bootstrap the creation of a basic GCC compiler, then allow a second compile
> using the basic GCC compiler to get the full compiler.

Maybe, but I consider rejecting mixed code/declarations to be a feature :-)


Well, I'm curious to hear more about that... Why do you think that...
int i;
...
...
for(i = 0; i < n; i++) ..

is better than
for(int i = 0; i < ..) ... ???

I find the second much more compact and readable than the first.


C++ comments are handy for quick debugging hacks, but I'm not sure they add
any real value to production code.



Their value lies (at least for me) in things line
if (foo) // now I'll do...
{

}

and for example
struct foo {
int myint ; // this int is ...
double mydouble ; // this double is...
};

in a one line comments, using /* */ is just horrid! :)


Paul




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Accessing function code from CFG

[Paulo J. Matos]

On 3/7/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 03/07/07 10:36:

> Is this normal? It seems there are no basic blocks set for the
> functions. Probably my pass is being run before the bbs are created?

Looks like it.  Set a breakpoint in build_tree_cfg and your function.
If gdb stops in your function first, you found the problem.



Now, this is wierd, probably I'm just doing it wrong, gdb is not
finding any build_tree_cfg or my pass pass_gsvt, but it find, for
example xmalloc.
$ gdb gcc-bin/bin/gcc
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) break build_tree_cfg
Function "build_tree_cfg" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) break pass_gsvt
Function "pass_gsvt" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) break xmalloc
Breakpoint 1 at 0x415f30: file ../../gsvt/libiberty/xmalloc.c, line 145.

Same results if I use objdump -t gcc | grep 
finds xmalloc but no build_tree_cfg or pass_gsvt.

What am I missing?

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Accessing function code from CFG

[Paulo J. Matos]

On 3/7/07, Diego Novillo <[EMAIL PROTECTED]> wrote:

Paulo J. Matos wrote on 03/07/07 11:43:

> What am I missing?

You are debugging the wrong binary.  I'd suggest you browse through
http://gcc.gnu.org/wiki/DebuggingGCC

You need to debug one of cc1/cc1plus/jc1



Thank  you. It seems I've not found my error then. build_tree_cfg is
called 4 times before my pass. I guess it's one for each function I
have in my source file.

So, how come no bbs are created? Is there any other way to test where
the problem lies?


--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Accessing function code from CFG

[Paulo J. Matos]

On 3/7/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:

On 3/7/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Paulo J. Matos wrote on 03/07/07 11:43:
>
> > What am I missing?
>
> You are debugging the wrong binary.  I'd suggest you browse through
> http://gcc.gnu.org/wiki/DebuggingGCC
>
> You need to debug one of cc1/cc1plus/jc1
>

Thank  you. It seems I've not found my error then. build_tree_cfg is
called 4 times before my pass. I guess it's one for each function I
have in my source file.

So, how come no bbs are created? Is there any other way to test where
the problem lies?



As a side note, if I instead try to access BBs through FOR_EACH_BB_FN
I get the basic blocks I wanted. :)
struct function *fdecl = DECL_STRUCT_FUNCTION(node->decl);
basic_block bb;
FOR_EACH_BB_FN(bb, fdecl) {
   printf("For each bb!\n");
 }

This will print "For each bb!" a couple of times for each function.
Seems to be working this way around! :) heh!



--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Adding a new gcc dir

[Paulo J. Matos]

On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote:


  As explained: because it makes it impossible for users running old systems
with pre-C99 compilers to build gcc and thereby excludes them from the world
of free software, which is the opposite of what we're trying to achieve.



Well, I surely understand that and I find it nice. Still, I was
questioning Paul why he said: "I consider rejecting mixed
code/declarations to be a feature" because it seems that if he could
use mixed code/declarations, he wouldn't. I just asked why? Now, as I
said, I understand gcc restriction and in my gcc code I surely adhere
to it.



  The benefit of saving three keypresses is outweighed (for the FSF's goals)
by the disadvantage of excluding a whole category of potential
users/contributors.



I surely don't know FSF's goals but again I understand gcc code not
containing //, but my question was more directed to Paul view. :)


> in a one line comments, using /* */ is just horrid! :)

  That's a purely religious opinion!



Yes, it is. I'm religiously simplistic, best-language agnostic and god atheist!


  You might find it interesting to browse the gnu coding standards
(http://www.gnu.org/prep/standards/) and the additional standards specific to
gcc (http://gcc.gnu.org/codingconventions.html), since much of what we have
discussed is explained there along with the rationale that justifies the
decisions.



I'll look into it .


  Things won't stay like this forever, and at some point we'll undoubtedly
decide that it's no longer necessary to stay backwardly compatible all that
far back, and start using C99 features (and beyond that, we may at sometime
start using C++ in the compiler core).  It's a purely practical matter of
ensuring gcc is accessible to the greatest possible number of people.

cheers,
  DaveK
--
Can't think of a witty .sigline today







--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Libiberty functions

[Paulo J. Matos]

Hello all,

when using functions from libiberty, I'm for example using xstrdup and
xmalloc but free is not defined as free or xfree afail nor strlen so
how should I include things? Before system.h and then standard libs or
the other way around?

I am almost sure it should be the other way around but I would like
confirmation on this.

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Libiberty functions

[Paulo J. Matos]

Thank you all for the excellent suggestions, I'll be looking into all
of your references this afternoon. Regarding my initial question, I
understand I don't need free.
My real problem was if I needed to include standard libraries after
including system.h or if system.h would provide me free from stdlib
but I understand now that I need stdlib anyway. :)

Thank you.

On 3/8/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:

On 3/8/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Another convenient way of allocating a pool of memory is to use obstacks
> (See libiberty/obstack.c).

Though alloc-pool might be a better idea than obstack, see
alloc-pool.[ch].  As alloc-pool contains checking code while obstack
does not.

-- Pinski




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

MODIFY_EXPR lhs

[Paulo J. Matos]

Hello,

Why is it that a left hand side of a modify_expr usually had void_type
while other times it has integer, real or something else _type? One
pattern I'm detecting is that when the lhs is a user variable it has
void type, but when the lhs if a gcc generated variable, the modify
expr has the type of the variable. Is it like that?

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Static Chain Argument in call_expr

[Paulo J. Matos]

Hello,

in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the
static chain argument, or NULL. Can someone tell me or reference me to
what static chain argument is?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Static Chain Argument in call_expr

[Paulo J. Matos]

On 3/8/07, Duncan Sands <[EMAIL PROTECTED]> wrote:

> in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the
> static chain argument, or NULL. Can someone tell me or reference me to
> what static chain argument is?

It's for nested functions, eg

int parent (int n)
{
  int child (int m) { return m * n; }

  return child (2);
}

Notice how child using a variable of parent, namely
the parameter n.  This gets lowered to something like:

struct frame { int n; };

int child (struct frame *static_chain, int m) { return m * static_chain->n; }

int parent (int n)
{
  struct frame FRAME;
  FRAME.n = n;
  return child (&FRAME, 2);
}



Ah, nice, didn't know that was possible in C. Is that new in C99 or
it's a GCC extension?

Cheers,

Paulo Matos


Ciao,

Duncan.




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

On INTEGER_CST

[Paulo J. Matos]

Hello all,

INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH
fields (tree.def). Each has 32 bits.
1 - Should I use ints for these fields?
2 - If the INTEGER_CST is negative, is the negative part only in one
of the high or low fields, i.e. low is always unsigned and high is
always signed? If not, how do I know if the constant is signed or
unsigned?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

On NULL and 0

[Paulo J. Matos]

Hello,

When programming, due to my journeys through C++ recently, I've been
using 0 instead of NULL. Strangely gcc compilation doesn't warn me
about it. Is it ok to do this? (So far, I had no problems). Is there
anything I should be aware when using 0 instead of NULL in gcc code?

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: On NULL and 0

[Paulo J. Matos]

On 3/13/07, Dave Korn <[EMAIL PROTECTED]> wrote:

On 13 March 2007 13:52, Paulo J. Matos wrote:

> Hello,
>
> When programming, due to my journeys through C++ recently, I've been
> using 0 instead of NULL. Strangely gcc compilation doesn't warn me
> about it. Is it ok to do this? (So far, I had no problems). Is there
> anything I should be aware when using 0 instead of NULL in gcc code?

  Nope.  (This is really a gcc-help@ question, but anyway)  Zero is
completely acceptable for a null pointer constant in all circumstances
*except* when passing to a varargs function, which can go badly wrong on
platforms where the sizeof a pointer is larger than the sizeof an int.  See
the gnu coding standards, which mentions this.



Thank you, I only posted here because it was about standard coding in
gcc code. But should read the gnu coding standards indeed. Always
forget gcc is GNU. :)



cheers,
  DaveK
--
Can't think of a witty .sigline today





--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: On INTEGER_CST

[Paulo J. Matos]

On 13 Mar 2007 07:58:41 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

"Paulo J. Matos" <[EMAIL PROTECTED]> writes:

> INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH
> fields (tree.def). Each has 32 bits.

No, each has type HOST_WIDE_INT.  On a 64-bit host they will be 64
bits.

> 1 - Should I use ints for these fields?

I don't understand the question.



Which C type is HOST_WIDE_INT?


> 2 - If the INTEGER_CST is negative, is the negative part only in one
> of the high or low fields, i.e. low is always unsigned and high is
> always signed? If not, how do I know if the constant is signed or
> unsigned?

Negative numbers are sign extended through both the high and low
fields.  That said, you need to look at the type of the constant to
know whether you have a negative number or a very large positive
number.



Isn't the type of the constant always integer_type? How can I know if
it is negative or positive?


Ian



Thank you,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Referenced Vars in IPA pass

[Paulo J. Matos]

Hi all,

In #gcc, it was suggested to use referenced vars to get all the
referenced vars for a function. I added to my IPA pass props,
PROP_referenced_vars , used push_cfun and then
FOR_EACH_REFERENCED_VAR, however, it just segfaults in
tree-flow-inline.h:34 :
hti->slot = table->entries;

It was said gimple was lowered and referenced vars created before IPA
passes but I guess not due to the segfault. :(

Is there a way to get the referenced vars?

This was all due to the fact  that I wished to get a list of
referenced vars in my pass, so I was going through all the basic
blocks and statements, then found out that...
int x;
 {
 int y;
 {
 int z;
 ...
 }
 ...
}

just happens to have three statements, all VAR_DECL,x, y, z, without
any reference to the starting and ending blocks. As a side question,
how can I get hand of where the blocks start and finish? Don't really
know if it's useful but If I need it later, better I know how.

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Referenced Vars in IPA pass

[Paulo J. Matos]

On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:


> int x;
>  {
>  int y;
>  {
>  int z;
>  ...
>  }
>  ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks start and finish? Don't really
> know if it's useful but If I need it later, better I know how.

This is not available anymore after lowering to GIMPLE.  BIND_EXPRs
(representing lexical scope) are removed in gimple-low.c.



So, I guess I should not worry about nested blocks. But then again,
why do I get a segfault?


Paolo




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Referenced Vars in IPA pass

[Paulo J. Matos]

On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:


> int x;
>  {
>  int y;
>  {
>  int z;
>  ...
>  }
>  ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks start and finish? Don't really
> know if it's useful but If I need it later, better I know how.

This is not available anymore after lowering to GIMPLE.  BIND_EXPRs
(representing lexical scope) are removed in gimple-low.c.



Ah, by the way, I'm not using trunk, I'm using stable 4.1 code.


Paolo




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Referenced Vars in IPA pass

[Paulo J. Matos]

On 3/13/07, Jeffrey Law <[EMAIL PROTECTED]> wrote:

On Tue, 2007-03-13 at 18:09 +0100, Paolo Bonzini wrote:
> > int x;
> >  {
> >  int y;
> >  {
> >  int z;
> >  ...
> >  }
> >  ...
> > }
> >
> > just happens to have three statements, all VAR_DECL,x, y, z, without
> > any reference to the starting and ending blocks. As a side question,
> > how can I get hand of where the blocks start and finish? Don't really
> > know if it's useful but If I need it later, better I know how.
>
> This is not available anymore after lowering to GIMPLE.  BIND_EXPRs
> (representing lexical scope) are removed in gimple-low.c.
Correct.  FWIW, we originally kept that BIND_EXPRs and a variety of
other higher level constructs.  But they turned out to be a major
PITA to work with in the optimizers.  It was far cleaner to flatten
the IL.



OK, thank you.


Jeff





--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Referenced Vars in IPA pass

[Paulo J. Matos]

On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:

Uh, since when did 4.1 support IPA GIMPLE?




What do you mean by that?

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Referenced Vars in IPA pass

[Paulo J. Matos]

On 3/13/07, Richard Guenther <[EMAIL PROTECTED]> wrote:

On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> > On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > Uh, since when did 4.1 support IPA GIMPLE?
> > >
> > >
> >
> > What do you mean by that?
>
> I'm pretty sure there were a number of cgraph and other related
> changes necessary to make IPA work completely that were first in 4.2.
>
> I may be misremembering though, Jan?

No, you are right.  Paulo, you should be working off the trunk really.

Richard.



Argh, those are really bad news... :( My initial choice for stable 4.1
was that I didn't know _anything_ about gcc internals and since my
work is involved with my PhD research I didn't want to mess with gcc
internal problems (which may come up in trunk code) since problems
with my phd are enough. Now I'm really not knowing what to do. Should
I really work on trunk or 4.2 is better to stay off nasty problems?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

EH references

[Paulo J. Matos]

Hello all,

Is that any reference (paper, guide, whatever,) on how gcc is handling
exceptions in intermediate code? Is it based on a known (published)
method? Is it intuitive and explained somewhere?

I've looked at internal docs but it is not really explicit how it
works. I'm having a hard time understanding how RESX_PTR, FILTER_EXPR,
EH_FILTER_EXPR work together in gimple and how all of this is then
made to work in assembler.

References would be extremely valuable.

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Duplicate assembler function names in cgraph

[Paulo J. Matos]

Hello all,

I'm doing in my IPA pass:
for(node = cgraph_nodes; node; node = node->next) {
   reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
}

to get all the function names in the cgraph. I'm adding them to a list
and I'm assuming that two nodes do not have the same
DECL_ASSEMBLER_NAME but I'm wrong. In a C++ file I'm getting two
functions with name _ZN4listIiE6appendEPS0_, DECL_NAME = append.
Why is this? The code is at
http://pastebin.ca/442691

Is there a way to transverse the cgraph but never going through the
same twice? Or should I just ignore the node if the function name is
already registered?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Builtin functions?

[Paulo J. Matos]

Hello all,

I'm going through the bodies of all user-defined functions. I'm using
as user-defined function as one that:
DECL_BUILT_IN(node) == 0.

Problem is that for  a function (derived from a C++ file) whose output
from my pass is (output is self-explanatory, I think):
Registering cgraph node:
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
[operator<<]... SUCCESSFUL
Declared on 
/home/pmatos/gsvt-bin/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/ostream.tcc,
line 735
Decl Node Code is function_decl
Registering output void ...SUCCESSFUL
Arguments: __out : reference_type, __s : pointer_type

Well, this is definitely builtin but DECL_BUILT_IN == 0, which means
that when I do FOR_EACH_BB_FN, I'm getting a segmentation fault.

I wonder where my wrong assumption is. Any suggestions?

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Builtin functions?

[Paulo J. Matos]

On 4/16/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

On Mon, Apr 16, 2007 at 05:04:05PM +0100, Paulo J. Matos wrote:
> _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
> [operator<<]... SUCCESSFUL

> Well, this is definitely builtin but DECL_BUILT_IN == 0, which means
> that when I do FOR_EACH_BB_FN, I'm getting a segmentation fault.
>
> I wonder where my wrong assumption is. Any suggestions?

What do you mean, it's built in?  It comes from a source file, so
almost by definition it isn't.



Ok, sorry, didn't know that. Thought BUILT IN meant in this context,
not in the programmers source files. :)


--
Daniel Jacobowitz
CodeSourcery




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Builtin functions?

[Paulo J. Matos]

On 4/16/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:


First, it's not built in, because it's defined in a source file.
Builtin functions are those defined by the compiler.

Second, we should make FOR_EACH_BB_FN never crash on empty tree functions.
It seems really rude to do otherwise.
Just because we don't have a body for a function doesn't mean we
should crash.  Users shouldn't have to be checking random things like
DECL_SAVED_TREE to determine if FOR_EACH_BB_FN will work (this is not
to say that they should be able to pass any random crap to it, but it
should be detecting if the function has a body)



Is there a way to check if the function was or not defined by the
user, i.e., it comes from the users source file?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Duplicate assembler function names in cgraph

[Paulo J. Matos]

On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:

Hi,
> Hello all,
>
> I'm doing in my IPA pass:
> for(node = cgraph_nodes; node; node = node->next) {
>reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
> }
>
> to get all the function names in the cgraph. I'm adding them to a list
> and I'm assuming that two nodes do not have the same
> DECL_ASSEMBLER_NAME but I'm wrong. In a C++ file I'm getting two
> functions with name _ZN4listIiE6appendEPS0_, DECL_NAME = append.
> Why is this? The code is at
> http://pastebin.ca/442691

Callgraph is currently trying to avoid use of DECL_ASSEMBLER_NAME, the
motivation is that for C++, the DECL_ASSEMBLER_NAMEs are very long and
expensive and thus it is not good idea to compute them for symbols not
output to final assembly (DECL_ASSEMBLER_NAME triggers lazy construction
of the names).  So if you don't have good reason for using the names,
you should not do it.


My only reason to use DECL_ASSEMBLER_NAME is, when I'm transversing
cgraph_nodes, to have an ID for the nodes I've already 'analyzed'.



Cgraph rely on frontend that there are no duplicate FUNCTION_DECLs
representing the same function (with same assembler node), that seems to
be broken in your testcase.  Would be possible to have a small tewstcase
reproducing the problem?



Sure, however, I'm developing over 4.1.1, still you might still have
the error on current head, (I know 4.1.1 is quite old). What do you
mean by a test case? Do you want a short version of my IPA pass which
shows up the issue?

Cheers,

Paulo Matos


Honza
>
> Is there a way to transverse the cgraph but never going through the
> same twice? Or should I just ignore the node if the function name is
> already registered?
>
> Cheers,
> --
> Paulo Jorge Matos - pocm at soton.ac.uk
> http://www.personal.soton.ac.uk/pocm
> PhD Student @ ECS
> University of Southampton, UK




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Builtin functions?

[Paulo J. Matos]

On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:

>
> If you just want to scan every function you have around, the obvious
> way to do it is
>
> For each function
>  FOR_EACH_BB_FN (function).
>
> This is probably slightly slower than
>
> For each function
>  if cgraph_function_body_availability != NOT_AVAILABLE
>FOR_EACH_BB_FN (function)
>


Yes, it's working now, thank you!

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: EH references

[Paulo J. Matos]

Thank you for the references at Code Sourcery, regading SJLJ exception
handling I found the paper (which references it): "Exception Handling
in the Choices Operating System", is the reference for SJLJ EH?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Duplicate assembler function names in cgraph

[Paulo J. Matos]

On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:

>
> Sure, however, I'm developing over 4.1.1, still you might still have
> the error on current head, (I know 4.1.1 is quite old). What do you
> mean by a test case? Do you want a short version of my IPA pass which
> shows up the issue?
Either that or of you can just minimize the testcase (perhaps with
delta) so it can be inspected by hand, it is probably easiest for me ;)

Honza



It is working now, I'm ignoring duplicated entries in cgraph_nodes. I
wonder, that if I am to use gcc head, how can I do that?
What I initially did was to import gcc 4.1.1 sources into my own
repository and have my pass there also. If I am to use the svn head
with my pass, how do people usually manage this, since svn head is on
one repository and your pass in another, still the pass lives inside
the gcc directory tree. Is there a way to handle this situation?

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Duplicate assembler function names in cgraph

[Paulo J. Matos]

On 4/17/07, Mike Stump <[EMAIL PROTECTED]> wrote:

On Apr 17, 2007, at 3:11 AM, Paulo J. Matos wrote:
> I wonder, that if I am to use gcc head, how can I do that?

This isn't a trick question is it?  Anyway, it is answered by our web
site.  Briefly, you check out trunk and then you edit it.  patch is
one way to mass edit a source tree for example.

> What I initially did was to import gcc 4.1.1 sources into my own
> repository and have my pass there also. If I am to use the svn head
> with my pass, how do people usually manage this, since svn head is on
> one repository and your pass in another, still the pass lives inside
> the gcc directory tree. Is there a way to handle this situation?

svn/svk questions should go to those lists.  Briefly, you merge in
trunk into your branch:

svn merge base gcc/trunk .

Or, you can take svn diff mybranch-base mybranch and apply that as a
patch to a checkout of trunk.  These are source code management 101
style questions.  While we might be able to offer help if you get
stuck, better would be to punt you to the svn/svk docs and users lists.



I think I understood. I'll look into it. Thank you!
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

loop hoisting fails

[Paulo J. Matos]

Hi,

I am facing a problem with code hoisting from a loop in our backend.

This problem seems to be hinted at on:
-fbranch-target-load-optimize
Perform branch target register load optimization before prologue / 
epilogue threading. The use of target registers can typically be exposed 
only during reload, thus hoisting loads out of loops and doing 
inter-block scheduling needs a separate optimization pass.



However, the problem has nothing to do with this flag.
Our architecture doesn't allow something like:

store 0,(X+2) ; store 0 into mem of X+2

So we need to do
load Y,0 ; load Y with constant zero
store Y,(X+2)  ; store the 0 in Y into mem of X+2

If I compile a loop:
int vec[8];
int i = 0;
while(i++ < 8)
  vec[i] = 0;

I something like:

  load X,#vec
?L2:
  load Y,0
  store Y,(X+0)
  add X,1

The load Y,0 though should be out of the loop.
I know what the problem is... gcc during expand has:

For ?L2 bb:

(set (mem/s:QI (reg:QI 41)) (const_int 0))

This is only transformed after the reload into:

(set (reg:QI Y) (const_int 0))
(set (mem/s:QI X) (reg:QI Y))

And so there's no opportunity after reloading for hoistering it seems... 
so I though about splitting the insn into two during expand:


(set (reg:QI Y) (const_int 0))
(set (mem/s:QI X) (reg:QI Y))

But then this is combined by cse into:

(set (mem/s:QI (reg:QI 41)) (const_int 0))

and bammm, same problem. No loop hoisting. What's the best way to handle 
this? Any suggestions?


Cheers,

Paulo Matos

Re: loop hoisting fails

[Paulo J. Matos]

On 09/02/11 15:07, Ian Lance Taylor wrote:


You need to set TARGET_RTX_COSTS to indicate that this operation is
relatively expensive.  That should stop combine from generating it.



Thanks, I will give it a try. One of the things that are not as polished 
as it should is exactly the rtx costs. I am writing costs for optimize_size.


It is slightly confusing for me the way it works. I have added a debug 
printf in it so I can debug the costs and when they are called and I get 
a list like this:


== RTXCOST[pass]: outer_code rtx => cost rec/done==

And it starts with:
== RTXCOST[]: UnKnown (const_int 0 [0x0]) => 0 [done]==
== RTXCOST[]: set (plus:QI (reg:QI 18 [0])
(reg:QI 18 [0])) => 4 [rec]==
== RTXCOST[]: set (neg:QI (reg:QI 18 [0])) => 4 [rec]==
...
== RTXCOST[]: set (set (reg:QI 21)
(subreg:QI (reg:SI 14 virtual-stack-vars) 3)) => 4 [rec]==

The first one is the only one that is called with an unknown outer_code. 
All the other seems to have an outer_code set which should be the 
context in which it shows up but then you get things like the last line. 
outer_code is a set but the rtx itself is _also_ a set. How is this 
possible?


Now, what's the best way to write the costs? For example, what's the 
cost for a constant? If the rtx is a (const_int 0), and the outer is 
unknown I would guess the cost is 0 since there's no cost in using it. 
However, if the outer_code is set, then the cost depends on where I am 
putting the zero into. If the outer_code is plus, should the cost be 0? 
(since x + 0 = x and the operation will probably be discarded?)


Any tips on this?

Cheers,

Paulo Matos

Re: loop hoisting fails

[Paulo J. Matos]

On 09/02/11 15:57, Ian Lance Taylor wrote:

For your processor it sounds like you should make a constant more
expensive than a register for an outer code of SET.  You're right that
the cost should really depend on the destination of the set but
unfortunately I don't know if you will see that.

I agree that costs are unfortunately not very well documented and the
middle-end does not use them in the most effective manner.  It's still
normally the right mechanism to use to control what combine does.



Thanks for the help.
Is there any bug open or anyone working to improve handling of costs?

Re: loop hoisting fails

[Paulo J. Matos]

On 09/02/11 15:57, Ian Lance Taylor wrote:


For your processor it sounds like you should make a constant more
expensive than a register for an outer code of SET.  You're right that
the cost should really depend on the destination of the set but
unfortunately I don't know if you will see that.


Increasing the cost of constants slightly for outer code set actually 
works. It blocks cse from doing the transformation but then gcse comes 
and does the transformation without consulting costs. That makes the 
cost change pretty useless.


Also, saying that 0 with a set is slightly more expensive than a 
register is also a mistake since it depends on the destination of the 0. 
But then again I guess this is a gcc constraint which everyone has 
probably to live with.

Re: loop hoisting fails

[Paulo J. Matos]

On 10/02/11 16:04, Ian Lance Taylor wrote:


Bother.  I've encountered that problem before and I think I used a
sledgehammer (a local patch).  It's definitely a bug that gcse doesn't
consider costs.



At least I am happy that you confirm this. :) Have you reported a bug 
for this before?

Re: loop hoisting fails

[Paulo J. Matos]

On 10/02/11 17:59, Richard Henderson wrote:


If constants are never valid as the source of a store,


They are but it really depends to which registers they are going to. If 
the destination belongs to a certain class it is ok, for all the others 
it is not. It is tricky even to define costs when you are given:


rtx_costs of (const_int 0), outer_code SET.

This might be very, very cheap or very, very expensive for certain 
classes of registers.

Re: loop hoisting fails

[Paulo J. Matos]

On 10/02/11 16:04, Ian Lance Taylor wrote:

Bother.  I've encountered that problem before and I think I used a
sledgehammer (a local patch).  It's definitely a bug that gcse doesn't
consider costs.



I think I might try also patching my local gcc. I guess the trick is to 
check for the cost of the alternative before making the replacement in 
gcse, right? Is it possible to have an idea of how you did it?

Re: Reloading an auto-increment addresses

[Paulo J. Matos]

On 11/02/11 09:46, Mohamed Shafi wrote:


How can i overcome this failure?  Can some one suggest a solution?




Have you defined TARGET_LEGITIMATE_ADDRESS_P and also BASE_REG_CLASS 
correctly for your target?

Volatile memory is not general operand

[Paulo J. Matos]

Hi,

I just noticed something very surprising. There's a clause in 
general_operand (recog.c):


if (! volatile_ok && MEM_VOLATILE_P (op))
return 0;

Oh... so, a MEM_VOLATILE_P is _not_ a general operand? Why? This is also 
not referred to in the documentation of general operand so it kind of 
caught me by surprise.


Before gimplification I have: INT_PRIORITIESD.10391[iD.10456] ={v} 0;

This is converted to a couple of insn that combine tries to combine into:
(set (mem/s/v:QImode ...) (const_int 0))

I have a
(set (match_operand:QImode "nonimmediate_operand" "")
 (match_operand:QImode "general_operand" ""))

However, the insn doesn't match cause nonimmediate_operand returns false 
for (mem/s/v ...).


Why is this? And what can I do to match this set? I guess I can only 
create another pattern. I am just amazed that a volatile memory is not a 
general_operand.


Cheers,

PMatos

Re: Volatile memory is not general operand

[Paulo J. Matos]

On 11/02/11 12:03, Eric Botcazou wrote:

  if (! volatile_ok&&  MEM_VOLATILE_P (op))
  return 0;

.

It's more of the other way around: MEM_VOLATILE_P is a general operand unless
explicitly requested via init_recog_no_volatile.  Some passes, like combine,
don't track the volatileness of operands precisely, so they disable their
manipulation altogether to avoid generating wrong code.



But the piece of code I quoted above is in general_regs. A (mem/v ...) 
will never be a general_operand, will it?


Without that, the insn

(set (mem/s/v:QImode ...) (const_int 0))

is never matched by

(set (match_operand:QImode "nonimmediate_operand" "")
 (match_operand:QImode "general_operand" ""))

Re: Volatile memory is not general operand

[Paulo J. Matos]

On 11/02/11 13:56, Michael Matz wrote:


The piece of code you quoted also is conditional on volatile_ok.  Connect
that with what Eric said.



Thanks Michael, I guess I should sleep before asking anything else. Now 
I understand what Eric said.

Re: loop hoisting fails

[Paulo J. Matos]

On 11/02/11 19:41, Ian Lance Taylor wrote:


My case was somewhat different.  I think I just patched gcse_constant_p.




Thanks!

Using cc (question from avr)

[Paulo J. Matos]

Hi,

I am having some trouble really understanding the working of cc_status.
In order to understand it better I was looking at the code for avr under 
gcc 4.3.


My assumption is that set_zn, set_* means that an instructions _changes_ 
these flags. So an instruction that set_zn means that Z and N are 
modified but we are not sure to which values. I assume clobber means 
that an instruction changes some flags but we don't know which.


Now, the first thing that surprises me is clobber. Given a processor 
instruction description we know exactly which instructions set what. 
What's the need for clobber?


Check the following example from avr:

(define_insn "*strlenhi"
  [(set (match_operand:HI 0 "register_operand" "=e")
(unspec:HI [(mem:BLK (match_operand:HI 1 "register_operand" "%0"))
(const_int 0)
(match_operand:HI 2 "immediate_operand" "i")]
   UNSPEC_STRLEN))]
  ""
  "ld __tmp_reg__,%a0+ 



tst __tmp_reg__ 



brne .-6"
  [(set_attr "length" "3")
   (set_attr "cc" "clobber")])


From the instruction manual I have [1] ld changes none, tst changes Z,N 
and brne changes none so I would expect this instruction to have 
(set_attr "cc" "set_zn") instead of the clobber. Why is this?


[1]: http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf

Cheers,

Paulo Matos

mov arguments are still the same

[Paulo J. Matos]

Hi,

I have touched this subject before:
http://thread.gmane.org/gmane.comp.gcc.devel/116198/focus=116200

Now, at the time I didn't pursue this issue but now with 4.4.4 this 
keeps happening and I traced it to the cprop_hardreg replacing a 
register which makes the set insn having the same source and dest.


Here's insn 32 from pass 183:ce3

(insn 32 31 33 4 h.c:51 (set (reg:QI 1 AL)
(reg/f:QI 8 @H'fff9 [33])) 4 {*movqi} (expr_list:REG_DEAD 
(reg/f:QI 8 @H'fff9 [33])

(expr_list:REG_EQUAL (plus:QI (reg/f:QI 6 Y)
(const_int 1 [0x1]))
(nil


Now the same insn after the following pass 185:cprop_hardreg


insn 32: replaced reg 8 with 1

...

(insn 32 31 33 4 h.c:51 (set (reg:QI 1 AL)
(reg/f:QI 1 AL [33])) 4 {*movqi} (expr_list:REG_DEAD (reg/f:QI 
8 @H'fff9 [33])

(expr_list:REG_EQUAL (plus:QI (reg/f:QI 6 Y)
(const_int 1 [0x1]))
(nil


This stays as is until assembler generation, which is really annoying 
cause it generates an instruction (which is basically a nop) like:

...
mov AL,AL
...

Is this a known issue? I can't see how this is a problem with my backend 
but might as well be. Maybe cprop_regmove should check if it is making 
the src equal to dest and if it is remove the insn?


Any suggestions?

--
PMatos

avr compilation

[Paulo J. Matos]

Hi all,

I am looking at the avr backend in order to try to sort some things out 
on my own backend.


One of the tests I am doing is by compiling the following:
int x = 0x1010;
int y = 0x0101;

int add(void)
{
  return x+y;
}

It compiles to (in gcc-4.3.5_avr with -Os)
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r18,r24
adc r19,r25
mov r24,r18
mov r25,r19
/* epilogue start */
ret

I don't know much avr assembler so bear with me but I would expect this 
to be written:

add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r24,r18
adc r25,r19
/* epilogue start */
ret

By inverting the add arguments we save two mov instructions.

If it can be written like this any ideas on why GCC is avoiding it?

Cheers,

--
PMatos

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 10:08, WANG.Jiong wrote:

This may related with subreg regmove finding
Suggest specifiy -fdump-rtl-regmove to see what happen after this pass
Maybe avr need a target dependent regmove pass to handle this



It doesn't look like it's regmove, whose result looks pretty sane:
;; Pred edge  ENTRY [100.0%]  (fallthru)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)

(insn 5 2 6 2 add.c:5 (set (reg:HI 42)
(mem/c/i:HI (symbol_ref:HI ("y") [flags 0x2] 0x7f40954201e0 y>) [2 y+0 S2 A8])) 8 {*movhi} (nil))


(insn 6 5 7 2 add.c:5 (set (reg:HI 44 [ x ])
(mem/c/i:HI (symbol_ref:HI ("x") [flags 0x2] 0x7f4095420140 x>) [2 x+0 S2 A8])) 8 {*movhi} (nil))


(insn 7 6 25 2 add.c:5 (set (reg:HI 42)
(plus:HI (reg:HI 42)
(reg:HI 44 [ x ]))) 20 {*addhi3} (expr_list:REG_DEAD 
(reg:HI 44 [ x ])

(nil)))

(insn 25 7 26 2 add.c:7 (set (reg:QI 24 r24)
(subreg:QI (reg:HI 42) 0)) 4 {*movqi} (nil))

(insn 26 25 18 2 add.c:7 (set (reg:QI 25 r25 [+1 ])
(subreg:QI (reg:HI 42) 1)) 4 {*movqi} (expr_list:REG_DEAD 
(reg:HI 42)

(nil)))

(insn 18 26 0 2 add.c:7 (use (reg/i:HI 24 r24)) -1 (nil))
;; End of basic block 2 -> ( 1)


If psr 42 and 44 are allocated to the proper registers, i.e. 42 is 
allocated to the return registers insn 25/26 could be deleted, however, 
that's not what happens after register allocation:


;; Pred edge  ENTRY [100.0%]  (fallthru)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)

(insn 5 2 6 2 add.c:5 (set (reg:HI 18 r18 [42])
(mem/c/i:HI (symbol_ref:HI ("y") [flags 0x2] 0x7f40954201e0 y>) [2 y+0 S2 A8])) 8 {*movhi} (nil))


(insn 6 5 7 2 add.c:5 (set (reg:HI 24 r24 [orig:44 x ] [44])
(mem/c/i:HI (symbol_ref:HI ("x") [flags 0x2] 0x7f4095420140 x>) [2 x+0 S2 A8])) 8 {*movhi} (nil))


(insn 7 6 25 2 add.c:5 (set (reg:HI 18 r18 [42])
(plus:HI (reg:HI 18 r18 [42])
(reg:HI 24 r24 [orig:44 x ] [44]))) 20 {*addhi3} (nil))

(insn 25 7 26 2 add.c:7 (set (reg:QI 24 r24)
(reg:QI 18 r18 [42])) 4 {*movqi} (nil))

(insn 26 25 18 2 add.c:7 (set (reg:QI 25 r25 [+1 ])
(reg:QI 19 r19 [+1 ])) 4 {*movqi} (nil))

(insn 18 26 27 2 add.c:7 (use (reg/i:HI 24 r24)) -1 (nil))
;; End of basic block 2 -> ( 1)

So, I guess it's probably something else...



Best,
Jiong

On 03/18/2011 04:47 PM, Paulo J. Matos wrote:

Hi all,

I am looking at the avr backend in order to try to sort some things
out on my own backend.

One of the tests I am doing is by compiling the following:
int x = 0x1010;
int y = 0x0101;

int add(void)
{
return x+y;
}

It compiles to (in gcc-4.3.5_avr with -Os)
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r18,r24
adc r19,r25
mov r24,r18
mov r25,r19
/* epilogue start */
ret

I don't know much avr assembler so bear with me but I would expect
this to be written:
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r24,r18
adc r25,r19
/* epilogue start */
ret

By inverting the add arguments we save two mov instructions.

If it can be written like this any ideas on why GCC is avoiding it?

Cheers,

--
PMatos

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 12:10, David Brown wrote:

If you are digging through the AVR backend and find ways to improve code
sequences like this, the avr-gcc community would be very grateful.

There is an avr-gcc mailing list at
, which may be of
interest to you.



Thanks for your reply. Just subscribed to avr-gcc through gmane.
Georg-Johann Lay suggests correctly that -fno-split-wide-types helps. 
With this option the code is as I suggested.


I will try 4.5.2 to see if it works out of the box! :)

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 13:26, Georg-Johann Lay wrote:

note that the last moves are two QI moves, the add is HI.



Yes, correct, this seems to cause some confusion on gcc side then... humm!


Without splitting HI the moves will disappear, try -fno-split-wide-types.



It does work! It's enabled by -O1, maybe it should be disabled by -Os if 
it improves the code size consistently.




Try newer version of gcc, like 4.5.2



Thanks, I will. Hopefully it will do the optimisation out of the box 
without the need for the extra option.



Cheers,

--
PMatos

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 14:20, Ian Lance Taylor wrote:


-fsplit-wide-types is an improvement on most targets, in which ints and
pointers have the size UNITS_PER_WORD.  On AVR that appears not to be
the case, and it seems possible that AVR should set
flag_split_wide_types to 0 in TARGET_OPTION_OPTIMIZATION_TABLE.


That does explains why split-wide-types causes improvement on avr. Thanks.

Re: mov arguments are still the same

[Paulo J. Matos]

Let me revive this thread and ask for suggestions/tips on the issue below.

Cheers,

PMatos

On 16/03/11 18:19, Paulo J. Matos wrote:

Hi,

I have touched this subject before:
http://thread.gmane.org/gmane.comp.gcc.devel/116198/focus=116200

Now, at the time I didn't pursue this issue but now with 4.4.4 this
keeps happening and I traced it to the cprop_hardreg replacing a
register which makes the set insn having the same source and dest.

Here's insn 32 from pass 183:ce3

(insn 32 31 33 4 h.c:51 (set (reg:QI 1 AL)
(reg/f:QI 8 @H'fff9 [33])) 4 {*movqi} (expr_list:REG_DEAD (reg/f:QI 8
@H'fff9 [33])
(expr_list:REG_EQUAL (plus:QI (reg/f:QI 6 Y)
(const_int 1 [0x1]))
(nil


Now the same insn after the following pass 185:cprop_hardreg


insn 32: replaced reg 8 with 1

...

(insn 32 31 33 4 h.c:51 (set (reg:QI 1 AL)
(reg/f:QI 1 AL [33])) 4 {*movqi} (expr_list:REG_DEAD (reg/f:QI 8 @H'fff9
[33])
(expr_list:REG_EQUAL (plus:QI (reg/f:QI 6 Y)
(const_int 1 [0x1]))
(nil


This stays as is until assembler generation, which is really annoying
cause it generates an instruction (which is basically a nop) like:
...
mov AL,AL
...

Is this a known issue? I can't see how this is a problem with my backend
but might as well be. Maybe cprop_regmove should check if it is making
the src equal to dest and if it is remove the insn?

Any suggestions?

--
PMatos

Re: Supporting multiple pointer sizes in GCC

[Paulo J. Matos]

On 30/03/11 08:57, Claudiu Zissulescu wrote:

Hi,

I would try using the named address space for your issue (see
TARGET_ADDR_SPACE_POINTER_MODE). Please check the SPU target for an
implementation example.



Hummm, I haven't noticed this hook before. Could this be used to 
implement cases where function pointers have a different size than data 
pointers (as in harvard archs). It looks like it but can someone confirm?


Cheers,

--
PMatos

Truncating df to sf (and typo in code)

[Paulo J. Matos]

Hi,

I have been looking at the fp-bit code and noticed:
/* numeric parameters */
/* F_D_BITOFF is the number of bits offset between the MSB of the mantissa
   of a float and of a double. Assumes there are only two float types.
   (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS-float::NGARDS))
 */
#define F_D_BITOFF (52+8-(23+7))


I would guess the comment has a typo and should be
(double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS+float::NGARDS))
instead.

In my port I am having some trouble with the truncation from df to sf.
I wonder if there's any doc reference upon which the code was based to 
do the truncation. I can't really find anything and even though the code 
is not hard I am still missing something.


Cheers,

--
PMatos

Volatile memory move

[Paulo J. Matos]

Hi,

I am running into trouble with a volatile memory move on my port of 
GCC4.4.4. The code is:

int main(void)
{
  register volatile float sc = 1E35;

  if(sc < 1.5e35)
return 1;
  return 0;
}

The very first part of this code is being expanded as:

;; sc ={v} 1.000409184787596297531937521664e+35;

(insn 5 4 6 vol.c:3 (set (reg/f:QI 20)
(symbol_ref/u:QI ("*?LC0") [flags 0x2])) -1 (nil))

(insn 6 5 7 vol.c:3 (set (reg:QI 1 AL)
(mem/u/c/i:QI (plus:QI (reg/f:QI 20)
(const_int 1 [0x1])) [2 S1 A16])) -1 (nil))

(insn 7 6 8 vol.c:3 (set (reg:QI 0 AH)
(mem/u/c/i:QI (reg/f:QI 20) [2 S1 A16])) -1 (nil))

(insn 8 7 9 vol.c:3 (set (mem/v/c/i:QI (plus:QI (reg/f:QI 14 
virtual-stack-vars)

(const_int 1 [0x1])) [2 sc+1 S1 A16])
(reg:QI 1 AL)) -1 (nil))

(insn 9 8 0 vol.c:3 (set (subreg:QI (mem/v/c/i:HI (reg/f:QI 14 
virtual-stack-vars) [2 sc+0 S2 A16]) 0)

(reg:QI 0 AH)) -1 (nil))


Now, the problem with this comes with insn 9 that has a subreg:QI of a 
mem:HI it seems. The raw move we are trying to do is:

(set (mem/v/c/i:HI (reg/f:QI 14 virtual-stack-vars) [2 sc+0 S2 A16])
 (mem/u/c/i:HI (reg/f:QI 20) [2 S2 A16]))

To do this we need to go through two QImode registers AL and AH and I 
have as part of my port:
emit_move_insn(gen_rtx_REG(QImode, RAL), gen_lowpart(QImode, 
operands[1]));
emit_move_insn(gen_rtx_REG(QImode, RAH), gen_highpart(QImode, 
operands[1]));
emit_move_insn(gen_lowpart(QImode, operands[0]), 
gen_rtx_REG(QImode, RAL));
emit_move_insn(gen_highpart(QImode, operands[0]), 
gen_rtx_REG(QImode, RAH));



The problem here comes with gen_lowpart and gen_highpart applied to:
(mem/v/c/i:HI (reg/f:QI 14 virtual-stack-vars) [2 sc+0 S2 A16])

gen_lowpart generates: (mem/v/c/i:QI (plus:QI (reg/f:QI 14 
virtual-stack-vars)(const_int 1 [0x1]))


but gen_highpart generates:
(subreg:QI (mem/v/c/i:HI (reg/f:QI 14 virtual-stack-vars) [2 sc+0 S2 
A16]) 0)



Why is that? Any suggestion on solving this situation?

Cheers,

Paulo Matos

MULTILIB_EXTRA_OPTS and LIBGCC2_CFLAGS

[Paulo J. Matos]

Hi all,

I am quite confused about the difference between the above two options 
in Makefile fragments.


They both seem to be doing the same thing which is to set the options to 
build libgcc2 with.


The only thing that comes to mind is that LIBGCC2_CFLAGS only applies to 
the main library and MULTILIB_EXTRA_OPTS applies to all the 'specially' 
build libgcc2 that go into MULTILIB_DIRNAMES.


Anyone can confirm this?

Cheers,
--
Paulo Matos

Re: MULTILIB_EXTRA_OPTS and LIBGCC2_CFLAGS

[Paulo J. Matos]

On 17/06/11 15:22, Ian Lance Taylor wrote:

LIBGCC2_CFLAGS applies only to libgcc (all multilib versions of libgcc).

MULTILIB_EXTRA_OPTS applies to all target libraries (libstdc++, libjava,
libgo, etc.).



Thanks for clearing that up for me. Since I am focused on the C frontend 
only I actually forgot about other libraries which MULTILIB applies to.


Cheers,
--
PMatos

LIBGCC2_FLAGS not used by libgcc2 configure?

[Paulo J. Matos]

Hi,

There are some flags that are needed by the target to build libgcc2. I 
am keeping those in TARGET_LIBGCC2_FLAGS. However, compilation is failed 
even before the building begins because configure fails. While trying to 
compile test programs configure is using TARGET_LIBGCC2_FLAGS.


This seems odd to say the list.

Anything else that I need to set so that TARGET_LIBGCC2_FLAGS is also 
used by configure?


Cheers,

--
PMatos

Re: LIBGCC2_FLAGS not used by libgcc2 configure?

[Paulo J. Matos]

On 18/06/11 00:00, Ian Lance Taylor wrote:


You are saying that configure is using TARGET_LIBGCC2_FLAGS, but that
you want to set something so that it uses TARGET_LIBGCC2_FLAGS?  Are you
missing a "not" in there somewhere?  Or do I misunderstand?



Thanks for the reply Ian. I am using MULTILIBS. However, there's a flag 
that I want all the LIBGCC2 built with. That's a special flag for my 
backend -mas-mode. I added this to TARGET_LIBGCC2_FLAGS, however, 
libgcc/configure is not passing this flag to the configure programs and 
configure simply flags.


I noticed that it works if I do make CFLAGS_FOR_BUILD=-mas-mode but I 
wonder if there's a cleaner way (so that I don't need to pass flags 
through the command line.



Is it libgcc/configure that is failing?  If so it sounds like you want
to set MULTILIB_EXTRA_OPTS, per your earlier question.



Yes, it's libgcc/configure that's failing. So, you mean I should
MULTILIB_EXTRA_OPTS=-mas-mode in my t- makefile fragment?

--
PMatos

Re: LIBGCC2_FLAGS not used by libgcc2 configure?

[Paulo J. Matos]

On 20/06/11 13:08, Ian Lance Taylor wrote:

Yes, it's libgcc/configure that's failing. So, you mean I should
MULTILIB_EXTRA_OPTS=-mas-mode in my t- makefile fragment?


Yes.


I will give that a try.



Alternatively, you implied that your backend always needs this option.
In that case you could make it the default or you could add it to
DRIVER_SELF_SPECS.  Or did you just mean that you always need it for
libgcc2 but not for user code?



My backend as two 'compilation modes' (the generated code differs slightly).

I added a define into the command line by doing
make CFLAGS_FOR_BUILD="-DAS_MODE"

and then in my backend header:
#ifdef AS_MODE
#undef CC1_SPEC
#define CC1_SPEC "%{!mas-mode:-mas-mode}"
#endif

However, this is not working since gcc.c is not being compiled with the 
CFLAGS_FOR_BUILD, meaning it's not being passed -DAS_MODE in the command 
line and therefore no defining CC1_SPEC.


Which flag (like CFLAGS_FOR_BUILD) can I use that is passed in the 
command line to compile the driver?


Cheers,
--
Paulo Matos

Re: LIBGCC2_FLAGS not used by libgcc2 configure?

[Paulo J. Matos]

On 21/06/11 19:01, Ian Lance Taylor wrote:


CFLAGS.

CFLAGS_FOR_BUILD is for code compiled for the build system.  CFLAGS is
for code compiled for the host system.  CFLAGS_FOR_TARGET is for code
compiled for the target system.  The driver and the compiler as a whole
run on the host system.  The build system is used for tools which are
run while building the compiler, such as genrecog.

Ian



Thanks. That makes a lot of sense. It is now working beautifully! :)

__function_size builtin

[Paulo J. Matos]

Hello,

I have added a builtin __function_size that is supposed to receive a 
pointer to a function and return the size, in words, that the function 
takes.


We got it working until GCC4.5. In GCC4.5 became tricky for 2 reasons.

First, GCC 4.5 removes the function if the only reference to the 
function is through the builtin.


The way it currently works is that the builtin is converted into a 
label, through target_fold_builtin, and then after each function we 
output some code so that this label is has a value equal to the function 
size by subtracting two labels (current position and function label). 
This actually only works without assembler-linker (2 in 1).


However, since GCC4.5 if __function_size(swap) is the only reference to 
function swap, swap is removed and then there is no function in the 
assembler, and the calculation of the size fails.


How can I tell GCC to keep functions referenced by __function_size?

The second problem is the adoption of the GNU Binutils for assembling 
and linking. There is a backend for our target. However, the problem is 
that the function size, due to relaxation, is only available at link 
time. I know elf has a size attribute for symbols so I was thinking 
about using that, however, I am unsure on how to use GCC to get it 
working. Any suggestions?


My thought was to fold __function_size still to a special label (unique 
for each function) that would be then generates by as and set to the 
unrelaxed size of the function. Once the linker performs the required 
relaxation it also modifies the label value accordingly.


Cheers,

--
PMatos