Re: A question on alias analysis

[Nathan Sidwell]

shreyas krishnan wrote:

Hi ,
  I am overwhelmed with the jargon and world of alias analysis and
different kinds of it. I was wondering if some one can help me with
this simple question.  Is deciding if a pointer is pointing to what
segment (heap/otherwise) a simpler problem than exactly deciding the
points to set?


No.

nathan

--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: A question on alias analysis

[Daniel Berlin]

On Mon, 2005-10-24 at 04:50 +, shreyas krishnan wrote:
> Hi ,
>   I am overwhelmed with the jargon and world of alias analysis and
> different kinds of it. I was wondering if some one can help me with
> this simple question.  Is deciding if a pointer is pointing to what
> segment (heap/otherwise) a simpler problem than exactly deciding the
> points to set?

No, since deciding what segments it points to is equivalent to deciding
what it points to.

All you'd really be doing in an analyzer to solve this would be simply
replacing things that added the explicit variables to the points-to
sets, which things that added segmentof(variable) to the points-to set.

I.E. Knowing the type of memory a variable points to (stack, heap) is a
side-effect of knowing what the variable points to.

--Dan

Re: @true in makefiles

[Rafael Espíndola]

> The cases you have to look at are the ones with move-if-change.  You
> have to make sure that if the file does not change, none of the
> dependencies are considered to have changed.
>
> For example in
>
> multilib.h: s-mlib; @true
> s-mlib: $(srcdir)/genmultilib Makefile
>   ...
>   $(SHELL) $(srcdir)/../move-if-change tmp-mlib.h multilib.h
>   $(STAMP) s-mlib
>
> we need the property that if multilib.h changes, everything that
> depends upon it gets rebuilt.  If genmultilib or Makefile changes, we
> must try rebuilding multilib.h.  However, if multilib.h does not then
> change, then things that depend upon multilib.h should not get rebuilt
> for that reason.
>
> The @true is necessary so that make checks whether the timestamp of
> multilib.h changed before deciding that it will rebuild things that
> depend upon multilib.h.
>
> Can you restate your plan based on that, showing examples which use
> move-if-change?  Thanks.
Unfortunately no :(
but I think that I can document that :)

I will make a small example and add a comment to Makefile.in
describing the use of stamps with mkconfig.sh and move-if-change.

One small improvement would be to create the dependencies on s-gtype
automatically. At least the Make-lang.in s wouldn't need to know about
the stamps. Maybe I can implement this.

> Ian

Thank you very much,
Rafael

Re: adding a new register type to i386.h, and add spill/fill support

[Tyler Anderson]

I've gotten much further. I've added the new register
type to just about everywhere I can think of.

Then I was getting a cannot find a spill register
error.

Any thoughts?
Tyler


--- Ian Lance Taylor  wrote:

> Tyler Anderson <[EMAIL PROTECTED]> writes:
> 
> > I've already added the new type to i386.h,
> however, I
> > think I'm missing something in the #define
> > REG_CLASS_CONTENTS section. Could anyone point me
> to
> > more documentation about what each bit means? We
> need
> > to add a new register type, and extend the # of
> > existing registers. Extending the # of a register
> > seems easy, but it's unclear to me if it has been
> done
> > right since I don't know what each bit set in the
> > REG_CLASS_CONTENTS define is.
> 
> Well, there is documentation in the internals
> manual, of course.
> 
> Each bit in each entry in REG_CLASS_CONTENTS
> corresponds to a
> particular register.  Which register it means is
> target specific, but
> you can figure it out based on, e.g.,
> REGISTER_NAMES.  For example,
> for the i386, bit 0 is ax, bit 1 is dx, etc.
> 
> Ian
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Profiling+nested functions+dynamic linking on IA-64/Linux

[Eric Botcazou]

Hi,

As the title may hint at, the combination doesn't work because:
  1. the static chain register is r15 and
  2. mcount is called from the prologue and
  3. r15 is correctly preserved in glibc/sysdeps/ia64/_mcount.S but
  4. r15 is clobbered in the PLT:

5.3.6 Procedure Linkage Table

2. The relocation index for the function being called must be placed into
GR 15 so that the dynamic linker can identify the target of the call.
This value is an index into the portion of the dynamic relocation table
addressed by the DT_JMPREL dynamic section entry. The designated
relocation entry will have type R_IA_64_IPLTMSB or R_IA_64_IPLTLSB,
and its offset will specify the local function descriptor entry referenced
by the call.

Would that be fixable purely on the compiler side without too much kludgery?
My understanding is that the way _mcount_ret_helper is written in glibc (in 
particular the 'alloc' line) is quite annoying.  Or is that a lost cause and 
should profiling require static linking in presence of nested functions?

Thanks in advance.

-- 
Eric Botcazou

Diego Novillo and Daniel Berlin appointed alias analysis maintainers

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo and Daniel Berlin as alias analysis maintainers --
both Tree-SSA and RTL middle-end.

Please join me in congratulating Diego and Daniel on their new
role.  Diego and Daniel, please update your listings in the MAINTAINERS
file.

Happy hacking!
David

Re: A couple more subversion notes

[Gerald Pfeifer]

On Thu, 20 Oct 2005, Richard Guenther wrote:
> If it is at all possible we should probably try to keep read-only CVS 
> working (and up-to-date) for HEAD and release-branches.

That would be great.  It would allow me to continue my nightly bootstraps
on some guest account without interruption.

On Fri, 21 Oct 2005, Paolo Bonzini wrote:
> I don't promise anything on the timing, but I can do this.  I already 
> have a very similar arch-to-cvs script which I attach.

Cool, thanks!

Gerald

GGC Questions

[Ranjit Mathew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

  I have a few queries on GGC, the GCC garbage collector,
and usage of GTY markers in GCC sources. I would be grateful
if someone could take some time out to answer these.

First off, several fields are marked "skip", though the
documents seem to strongly discourage this. For example,
see ssa_use_operand_t in tree.h.

Second, some of the tree nodes ending in variable-length
arrays do not seem to have the appropriate GTY "length"
attributes. For example, see struct tree_string's "str"
field in tree.h.

I guess these are done on purpose, but I can't make out
exactly why. :-/

Lastly, on the gcjx-branch, a simple patch to
get_output_file_with_visibility() makes it recognise
".hh" and ".cc" C++ source files with GTY markers.
My question is, is this sufficient? Do people foresee
any problems with this?

Thanks,
Ranjit.

- --
Ranjit Mathew   Email: rmathew AT gmail DOT com

Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDXQiAYb1hx2wRS48RAqwlAJ984LDJosi5L5IGaU3sg9sGzm5mYwCeKfly
zE3y0CWFnWOGQwoTd7p3M7Y=
=EJQC
-END PGP SIGNATURE-

Question on Dwarf2 unwind info and optimized code

[Christophe LYON]

Hi all,

I have been look at the Dwarf2 frame info generated by GCC, and how it 
works.
From what I can see, only the register saves are recorded, and not the 
restores. Why?


I guess it may loose GDB if one sets a breakpoint inside a function 
epilogue, right?




I am currently working on the debug_frame info emission in our C/C++ 
compiler (based on Open64) and I have recently come across optimized 
code which I don't know how to handle.


Consider the following function:

foo() {
PROLOGUE

if (COND1) {
SAVE_REG r1 to stack (r1 is callee save)
compute...
bar1()
RESTORE r1
}
else if (COND2) {
bar2()
}

EPILOGUE
}

Suppose that the generated code looks like:
foo:
PROLOGUE
COND1
if true goto LABEL1

COND2
if true goto LABEL2

epilogue_label:
EPILOGUE

LABEL1:
SAVE register r1 to stack
compute
goto CALL_BAR1

LABEL2:
CALL bar2
goto epilogue_label

CALL_BAR1:
CALL bar1
RESTORE r1
goto epilogue_label

My question is:
what debug_frame info should I generate around epilogue, LABEL1, LABEL2, 
and CALL_BAR1 ?

Should I repeat all the info of the prologue before LABEL1 and LABEL2?
for CALL_BAR1, should I also add the save of register r1 ?

It's also unclear to me if I can/should use the 
remember_state/restore_state dwarf operators.

Indeed, what is the rule?

Use remember_state after the prologue, and use restore state at LABEL1 
and LABEL2?
But as states are defined as a stack, it means I would restore twice the 
same thing...


Any help/suggestion highly appreciated!

Thanks,

Christophe.

Re: Question on Dwarf2 unwind info and optimized code

[Daniel Jacobowitz]

On Mon, Oct 24, 2005 at 06:27:55PM +0200, Christophe LYON wrote:
> 
> Hi all,
> 
> I have been look at the Dwarf2 frame info generated by GCC, and how it 
> works.
> From what I can see, only the register saves are recorded, and not the 
> restores. Why?

IIUC, because (A) it's much harder, and (B) it's rarely necessary.

> I guess it may loose GDB if one sets a breakpoint inside a function 
> epilogue, right?

Yes, occasionally this happens.

> I am currently working on the debug_frame info emission in our C/C++ 
> compiler (based on Open64) and I have recently come across optimized 
> code which I don't know how to handle.

Reposting this question to increasingly unrelated lists is not likely
to help you find an answer :-)

> It's also unclear to me if I can/should use the 
> remember_state/restore_state dwarf operators.
> Indeed, what is the rule?

There's no rule, just documentation of how they work - if you can run
through the CFI stack machine and get the right results, you could use
them.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Profiling+nested functions+dynamic linking on IA-64/Linux

[Richard Henderson]

On Mon, Oct 24, 2005 at 05:37:06PM +0200, Eric Botcazou wrote:
> Would that be fixable purely on the compiler side without too much kludgery?

Yes.  Instead of a direct call, load the fptr for _mcount and do an
indirect call.  That'll avoid the dynamic linker.  You can conditionalize
this on cfun->static_chain_decl to avoid the extra work when nested
functions aren't involved.

Also, technically fptrs (and thus dynamic linking) isn't used when either
TARGET_NO_PIC or TARGET_AUTO_PIC are set.  Of course, I wouldn't expect
nested functions to be used here either, but...


r~

Re: adding a new register type to i386.h, and add spill/fill support

[Ian Lance Taylor]

Tyler Anderson <[EMAIL PROTECTED]> writes:

> I've gotten much further. I've added the new register
> type to just about everywhere I can think of.
> 
> Then I was getting a cannot find a spill register
> error.

Could be any number of things.  It's not trivial to do what you are
trying to do.  You are going to have to learn how gcc works
internally.  If you have specific questions we can try to answer them.
But a general question like this is impossible to answer.

(If you can find a gcc developer willing to put in the time, you could
send your patches and have them look them over.  I don't have the time
myself.)

Good luck.

Ian

Re: Diego Novillo and Daniel Berlin appointed alias analysis maintainers

[Diego Novillo]

On Monday 24 October 2005 11:41, David Edelsohn wrote:

> Diego and Daniel, please update your listings in the MAINTAINERS file.
>
Done.  Thanks.

Re: GGC Questions

[Mike Stump]

On Oct 24, 2005, at 9:14 AM, Ranjit Mathew wrote:

  I have a few queries on GGC, the GCC garbage collector,
and usage of GTY markers in GCC sources. I would be grateful
if someone could take some time out to answer these.

First off, several fields are marked "skip", though the
documents seem to strongly discourage this. For example,
see ssa_use_operand_t in tree.h.


Was this a question?  :-)  Skipping is anti-social and decreases the  
flexibility of the software, that said, one can skip any field that  
doesn't need to be walked without any technical problems, as that  
field doesn't need to be walked.


So this devolves into, which fields don't need to be walked.  Any  
field that is not live during PCH writing it safe to skip.  The  
liveness of any particular field is deeply related to the algorithm  
that uses the field, and in general, unrelated to PCH, save for  
timing issues.  For example, if during parsing a field it set  
(DECL_SIZE for example), and later read by, say the optimizers (they  
can run post PCH loading), then that field is live.  If it is set  
during optimization, but that type of optimization _never_ runs  
before the PCH is written out (basic block info was at one time an  
example of this type of thing), then that it an example of the type  
of thing that is technical safe to skip.


Now, why avoid skipping, say in the last case.  The answer is, if  
people want to `improve' the compiler by running that sort of  
optimization sooner, then the variable is live.  Bad things will  
happen til they track down the field, and arrange for it to be walked.



Second, some of the tree nodes ending in variable-length
arrays do not seem to have the appropriate GTY "length"
attributes. For example, see struct tree_string's "str"
field in tree.h.


Can be a form of skip.  In general, only pointers need to be walked,  
data char [1] is just data and is handled by the size of the object  
as I recall.  If you walk the PCH writer, you can watch exactly how  
it does this done if you are curious.



Lastly, on the gcjx-branch, a simple patch to
get_output_file_with_visibility() makes it recognise
".hh" and ".cc" C++ source files with GTY markers.
My question is, is this sufficient? Do people foresee
any problems with this?


When tested, it either works, or it doesn't.  I'd rather it be tested  
and known to work, then say it looks Ok, and have it turn out to be  
incomplete.  For example, the parser knows about a subset of C, if  
those files deviate from this subset too far, they can simply fail to  
work.  Usually these failures are of a compile time nature, so it is  
safe to try it out by building the compiler.  Better of course to  
actually test that the right thing happens.

New SVN Wiki page

[Giovanni Bajo]

Hello,

I have rehauled http://gcc.gnu.org/wiki/SvnHelp. I'm almost done with it
(should be ready tomorrow), but only a few things are missing now. I believe
I have integrated all the issues raised during the past week in the mailing
list. Also, I have added new information (especially for branch
maintaieners), and reorganized information so that they are hopefully easier
to find.

Let me know if I have missed something. Feel free to fix typos and rephrase
my bad English, but I'd like to know if you plan on adding something
substantial, so to find the best place to put it and not to duplicate
information.

Thanks,
-- 
Giovanni Bajo

Re: New SVN Wiki page

[Paolo Carlini]

Giovanni Bajo wrote:


Hello,

I have rehauled http://gcc.gnu.org/wiki/SvnHelp.


I had a look earlier today and liked a lot! Thanks!

Paolo.

Re: Profiling+nested functions+dynamic linking on IA-64/Linux

[Eric Botcazou]

> Yes.  Instead of a direct call, load the fptr for _mcount and do an
> indirect call.  That'll avoid the dynamic linker.  You can conditionalize
> this on cfun->static_chain_decl to avoid the extra work when nested
> functions aren't involved.

Ah! yes, of course, writing the stub by hand.  This completely escaped me.

> Also, technically fptrs (and thus dynamic linking) isn't used when either
> TARGET_NO_PIC or TARGET_AUTO_PIC are set.  Of course, I wouldn't expect
> nested functions to be used here either, but...

I don't expect Ada to be used in that cases either, but who knows. ;-)

Thanks for your decisive help.

-- 
Eric Botcazou

GCC-generated code and i386 condition codes behavior

[Bryan Ford]

I have a question about GCC's handling of the condition codes (specifically 
the CF, ZF, NF, OF, PF bits in bits in EFLAGS) on the i386 that will 
hopefully be trivial to anyone familiar with the implementation of the i386 
target.  My impression is that GCC generally treats the i386 condition codes 
as a single pseudo-register, which some instructions change (e.g., ADD) and 
others don't (e.g., MOV).  But some i386 instructions change only some 
condition code bits while leaving other bits unchanged (e.g., INC/DEC, which 
leave CF unchanged).

My question: does GCC-generated code ever actually depend on this aspect of 
the x86 architecture - i.e., on instructions that architecturally change some 
but not all condition codes _not_ changing those bits that they're not 
supposed to change?  In other words, if the i386 architecture were suddenly 
to be modified so that all instructions that traditionally affect only some 
of the condition code bits suddenly instead affect _all_ condition code 
flags, would GCC-generated code care at all?  Would the i386 backend have to 
be changed?  My impression is the answer is no, but I'm not deeply familiar 
with the i386 backend enough to be sure.

Thanks very much!
Bryan

docs for setting up new target library

[Janis Johnson]

The end of http://gcc.gnu.org/onlinedocs/gccint/Top-Level.html#Top-Level
has a link to a separate manual that is supposed to explain how the
top level build works, including building target libraries.  Here's the
corresponding text in sourcebuild.texi:

  The build system in the top level directory, including how recursion
  into subdirectories works and how building runtime libraries for
  multilibs is handled, is documented in a separate manual, included
  with GNU Binutils.  @xref{Top, , GNU configure and build system,
  configure, The GNU configure and build system}, for details.

The link is to http://gcc.gnu.org/onlinedocs/configure/index.html#Top,
which does not exist: "The requested URL /onlinedocs/configure/index.html
was not found on this server."

Where is it?  Will it help me figure out how to set up a new target
library for GCC?

Janis

backslash whitespace newline

[Howard Hinnant]

I've been reviewing the age-old issue of interpreting  
* as the end-of-line indicator as is the current  
practice with gcc.  For those not familiar with this issue, gcc takes  
advantage of C99's 5.1.1.2p1b1 "implementation-defined manner" to  
convert multibyte end-of-line indicators to newline characters.  gcc  
considers zero or more whitespace characters preceding a more  
traditional CR and/or LF as the end-of-line indicator.  This behavior  
can cause differences in some code compared to compilers which do not  
strip trailing whitespace off of lines.  For example:


// comment \
int x;
int y;

Pretend there's one or more spaces or tabs after the '\'.  gcc will  
interpret this as:


A:

// comment int x;
int y;

while other compilers (Microsoft, EDG-based, CodeWarrior to name a  
few) interpret it as:


B:

// comment
int x;
int y;

And depending on what you're trying to do, either A or B is the  
"correct" answer.  I've seen code broken either way (by assuming A  
and having the compiler do B and vice-versa).


This issue has recently been discussed on the C standards reflector,  
and though I was not privy to that discussion, my understanding is  
that the likely resolution from this standards body will be that a  
compiler implementing either A or B is conforming.


That being said, gcc to the best of knowledge, is the only modern  
compiler to implement end-of-line whitespace stripping (yes I'm aware  
of older compilers and dealing with punch cards). So on the basis of  
conforming to a de-facto standard alone, I propose that gcc abandon  
end-of-line whitespace stripping, or at least strip 2 or more  
whitespace characters down to 1 space instead of to 0 spaces during  
translation phase 1.


I realize that this change could break some existing code.  But I am  
also aware of existing code wishing to port to gcc which is broken by  
gcc's current behavior.  If we want gcc to "gain market share", does  
it not make sense to "welcome" new comers when possible by adopting  
what is otherwise industry-wide practice?


Thanks,
Howard

Re: backslash whitespace newline

[Neil Booth]

Howard Hinnant wrote:-

> I've been reviewing the age-old issue of interpreting  
> * as the end-of-line indicator as is the current  
> practice with gcc.

FWIW I support abandoning this behaviour too.

Neil.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 07:52:36AM +0900, Neil Booth wrote:
> Howard Hinnant wrote:-
> 
> > I've been reviewing the age-old issue of interpreting  
> > * as the end-of-line indicator as is the current  
> > practice with gcc.
> 
> FWIW I support abandoning this behaviour too.

It would probably be a good idea to warn about code where this will
make a difference, since the older gcc versions will be around for a long
time.

Re: docs for setting up new target library

[Ian Lance Taylor]

Janis Johnson <[EMAIL PROTECTED]> writes:

> The end of http://gcc.gnu.org/onlinedocs/gccint/Top-Level.html#Top-Level
> has a link to a separate manual that is supposed to explain how the
> top level build works, including building target libraries.  Here's the
> corresponding text in sourcebuild.texi:
> 
>   The build system in the top level directory, including how recursion
>   into subdirectories works and how building runtime libraries for
>   multilibs is handled, is documented in a separate manual, included
>   with GNU Binutils.  @xref{Top, , GNU configure and build system,
>   configure, The GNU configure and build system}, for details.
> 
> The link is to http://gcc.gnu.org/onlinedocs/configure/index.html#Top,
> which does not exist: "The requested URL /onlinedocs/configure/index.html
> was not found on this server."
> 
> Where is it?  Will it help me figure out how to set up a new target
> library for GCC?

That document can be found in src/etc/configure.texi in a binutils
distribution, or it can be found here:
http://www.airs.com/ian/configure/

It is generally out of date.  You probably already know the
information that it covers.

Ian

Re: Question on Dwarf2 unwind info and optimized code

[Jim Wilson]

Christophe LYON wrote:
I have been look at the Dwarf2 frame info generated by GCC, and how it 
works.
 From what I can see, only the register saves are recorded, and not the 
restores. Why?


The frame info is primarily used for C++ EH stack unwinding.  Since you 
can't throw a C++ exception in an epilogue, epilogue frame info isn't 
needed for this, and was never implemented for most targets.  Which is a 
shame.


There is a PR for this, PR 18749, for the x86-64 target.  The lack of 
epilogue unwind info shows up if you run the libunwind testsuite. 
Otherwise, it is really hard to find an example where the missing unwind 
info is a problem.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Passing an argument

[shreyas krishnan]

Hi,
I need to do the following. I want to at run time run a data
correction pass  on some of my integer arrays. As the data needs
correctioin often, it needs to be done just before the use of such an
array.
I am trying to do this in gcc by inserting a function
(convert(int *))  just before such a use. But then I need extract the
argument from the assignment and pass it to this function. Can anyone
give me pointers to how I can pass an argument after extracting it
from a assignment statement. I successfully extracted the operand but
have difficulty passing it as an argument. i would appreciate any
suggestions/help/pointers to similar code

thanks
Shrey


ps: If anyone would want  to see what I am doing, here it is,



get_stmt_operands(stmt)
 FOR_EACH_SSA_OPERAND(op,stmt,iter,SSA_OP_USE)
  {
 tree id =get_identifier("convert")
 tree
t_list=build_function_type_list(void_type_node,TREE_TYPE(op))
 tree decl=build_decl(FUNCTION_DECL,id,t_list);
  call=build_function_call_expr(decl,op)
   gimplify_to_stmt_list(&call)
   bsi_insert_before(iter,call,BSI_SAME_STMT)
 }

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-25 07:52:36 +0900, Neil Booth wrote:
> Howard Hinnant wrote:-
> > I've been reviewing the age-old issue of interpreting  
> > * as the end-of-line indicator as is the current  
> > practice with gcc.
> 
> FWIW I support abandoning this behaviour too.

But then, copy-paste would no longer always work since spaces are
sometimes added at the end of some lines (depending on the terminal
and the context).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 02:52:31AM +0200, Vincent Lefevre wrote:
> On 2005-10-25 07:52:36 +0900, Neil Booth wrote:
> > Howard Hinnant wrote:-
> > > I've been reviewing the age-old issue of interpreting  
> > > * as the end-of-line indicator as is the current  
> > > practice with gcc.
> > 
> > FWIW I support abandoning this behaviour too.
> 
> But then, copy-paste would no longer always work since spaces are
> sometimes added at the end of some lines (depending on the terminal
> and the context).

I believe that this is why gcc got this behavior in the first place, so
that files that visually look the same are handled the same.

gcc 2.95.3 does not have it; the oldest 3.x version I can locate around
here, gcc 3.0.3, does.

That is,

// this is a comment \  
and so is this.

where there are two spaces after the slash, is all one comment for gcc
3.x, and is a syntax error for 2.95.3.

Re: backslash whitespace newline

[Mike Stump]

On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote:

But then, copy-paste would no longer always work since spaces are
sometimes added at the end of some lines (depending on the terminal
and the context).


Please name such systems.  We can then know to not use them, and can  
document in the manual they are broken if we wish.

Re: backslash whitespace newline

[DJ Delorie]

> Please name such systems.  We can then know to not use them, and can  
> document in the manual they are broken if we wish.

IIRC the Windows cut-n-paste cuts a rectangle, not as-printed.

Also, beware of the \r\n line endings, where \r is considered
"whitespace" if it's not auto-converted.

Re: GGC Questions

[Ranjit Mathew]

On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> >
> > First off, several fields are marked "skip", though the
> > documents seem to strongly discourage this. For example,
> > see ssa_use_operand_t in tree.h.
>
> Was this a question?  :-)  Skipping is anti-social and decreases the
> flexibility of the software, that said, one can skip any field that
> doesn't need to be walked without any technical problems, as that
> field doesn't need to be walked.

Thanks. Though I didn't frame the question properly (sorry),
I wanted to know why we would want some fields of some
nodes to be skipped. Is it because:

1. we want to reduce time spent in the GC,

2. we know it doesn't matter for PCH, so we do it to
reduce the size of the PCH and its loading time,

3. some other reason?

The problem is that I see the documentation indicate
that this shouldn't be done but I see it being used with
abandon in the actual sources. Hence the query.

Your answer seems to indicate that is something
like #2 because PCH runs before any of these
fields is of any use.


> > Second, some of the tree nodes ending in variable-length
> > arrays do not seem to have the appropriate GTY "length"
> > attributes. For example, see struct tree_string's "str"
> > field in tree.h.
>
> Can be a form of skip.  In general, only pointers need to be walked,
> data char [1] is just data and is handled by the size of the object
> as I recall.  If you walk the PCH writer, you can watch exactly how
> it does this done if you are curious.

That array ("str") in "tree_string" is of variable length and
its length is indicated by the "length" field. So technically
at least it should be marked with a GTY((length(...)))
marker.


> > Lastly, on the gcjx-branch, a simple patch to
> > get_output_file_with_visibility() makes it recognise
> > ".hh" and ".cc" C++ source files with GTY markers.
> > My question is, is this sufficient? Do people foresee
> > any problems with this?
>
> When tested, it either works, or it doesn't.  I'd rather it be tested
> and known to work, then say it looks Ok, and have it turn out to be
> incomplete.  For example, the parser knows about a subset of C, if
> those files deviate from this subset too far, they can simply fail to
> work.  Usually these failures are of a compile time nature, so it is
> safe to try it out by building the compiler.  Better of course to
> actually test that the right thing happens.

Well, the current compiler crashes building
"java/lang/Character.java" where in the debugger I see the
Tree-SSA operands processing code "going bonkers". So
I am trying to figure out if this is because something was
yanked from under its feet by the GC or because there
is some bug in the relevant Tree-SSA code from the time
of the merge or because somehow the GCJX front-end
is not creating the trees properly or something else.

Not being familiar with GGC or Tree-SSA, tracking this
problem has been really frustrating for me. :-(

Thanks,
Ranjit.

--
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

GCC 4.0.2 i686-pc-linux-gnu Debian testing/unstable

[Dominic Crutchley]

Successfully built and installed GCC 4.0.2  on i686-pc-linux-gnu Debian 
Testing/Unstable


# config.guess
   i686-pc-linux-gnu

# gcc -v
   Using built-in specs.
   Target: i686-pc-linux-gnu
   Configured with: ../gcc/configure --enable-threads --with-cpu=i686
   Thread model: posix
   gcc version 4.0.2

# /etc/issue
  Debian GNU/Linux testing/unstable \n \l

# Uname --a
   Linux randomServer 2.4.26-20050108-djpc #1 SMP Sat Jan 8 18:51:45 GMT 
2005 i686 GNU/Linux


# libc6 version
2.3.5-6 

Re: backslash whitespace newline

[Florian Weimer]

* Mike Stump:

> On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote:
>> But then, copy-paste would no longer always work since spaces are
>> sometimes added at the end of some lines (depending on the terminal
>> and the context).
>
> Please name such systems.  We can then know to not use them, and can  
> document in the manual they are broken if we wish.

Emacs in an xterm, from time to time.  I don't know if this is fixed
in Emacs 22, though.