Re: New SVN Wiki page

[Giovanni Bajo]

Mike Stump <[EMAIL PROTECTED]> wrote:

> Ok, question about the merge tool.  Does revision N mean all changes
> that predate N that apply, or just N-1 to N?

N-1 to N. You can specify a single commit and it will apply only that.

> So, let's say that 3, 4, 5, 6, 7 are available, can I merge 3 today,
> then 6, the next day, then 5, then all the rest (4 and 7) the next
> day?  If yes, this corresponds to a N-1 to N above.

Yes. The good thing is that it'll keep track of what you've merged, so the list
of available revisions will trim down as you go.

> Could you update the doc to reflect your answer.

Uhm, I'm not sure how to explain this without being too pedantic. Does this
sound clearer?

"""
To do partial merges or cherry-picking, you can pass -r/--revision to svnmerge
merge and name the single commit (or range of commits).
"""

Giovanni Bajo

A question about define_insn and force-reg

[Eric Fisher]

Hello, gcc

I think it's very interesting. I want to split a insn of loading SF
data through SI symbol, such as (set (reg:SF 5 $5) (mem/u/f:SF
(symbol_ref/u:SI ("*$LC0".
I want to it firstly load the address into a register, then load the
data through
the register. So I define the insn as follows,
  (define_insn "loadsf"
  [(set (match_operand:SF 0 "register_operand" "=r")
(mem:SF (match_operand:SI 1 "immediate_operand" "m")))]
  ""
  {
operands[1] = force_reg (SImode, operands[1]);
return md_output_move (operands[0], operands[1]);
  }
  [(set_attr "type" "load")
   (set_attr "mode" "SF")
   (set_attr "length"   "*")])

  But the gcc will come out such error,
  internal compiler error: in gen_reg_rtx,  at emit-rtl.c:819.

  Which is the codes as following at emit-rtl.c:819,
   /* Don't let anything called after initial flow analysis create new
 registers.  */
  if (no_new_pseudos)
abort ();

  Why can't I create a new register? So how should I do to implement it?

  Thanks for your help time after time.
  Eric.

Re: Question on Dwarf2 unwind info and optimized code

[Christophe LYON]

Daniel Jacobowitz wrote:

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 :-)



Well, anyway thanks for your response, it is sufficient for me.
FYI, I first asked on the dwarf-dedicated mailing-list and surprisingly 
got no reply at all!


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.


OK, thanks for clarifying the situation.

Christophe

Re: Question on Dwarf2 unwind info and optimized code

[Christophe LYON]

Jim Wilson wrote:

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.



That's what I thought, but wanted to be sure I was not missing something.

On occasions, I wonder whether it wouldn't make sense to generate
different infos in debug_frame and eh_frame: IIUC, GCC tries to
'compress' the debug frame info by generating few advance_loc
instructions (eg only 1 for the whole prologue), which makes sense in
the C++ EH stack unwinding context, but my cause problems in a debugger.

Thanks

Christophe.

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-24 18:59:44 -0700, Mike Stump wrote:
> 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.

The problem occurs very often with iTerm under Mac OS X.

Also, this sometimes happen with *any* terminal when the application
has added spaces for a redraw. Emacs and Mutt at least are affected
by this problem (even when one uses bce). Concerning Mutt, I know
that ncurses sometimes clears the end of a line with spaces instead
of the escape sequence because this is more efficient when there are
only a few characters left.

Well, some terminals can be configured to strip the trailing spaces,
but then, one gets the inverse problem, i.e. lines with "\[LF]"
instead of "\[whitespace][LF]".

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

Re: A question about define_insn and force-reg

[Paolo Bonzini]

  (define_insn "loadsf"
  [(set (match_operand:SF 0 "register_operand" "=r")
(mem:SF (match_operand:SI 1 "immediate_operand" "m")))]


This makes no sense, because the constraint means that the mem's operand 
is an immediate before reload (and you want it to be a register), and a 
mem after reload.  What you want is something like


  (mem:SF (match_operand:SI 1 "general_operand" "r")))]

which means "the address can be a general operand, but after reload we 
only accept registers here", or


  (mem:SF (match_operand:SI 1 "register_operand" "r")))]


  Why can't I create a new register? So how should I do to implement it?


You can create new registers only at special places.  GCC tries passing 
a SYMBOL_REF to gen_mov.  To convert it, use a define_expand.


Paolo

RE: backslash whitespace newline

[Dave Korn]

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.
> 
> Neil.


  I would like it to be retained in at least one case: CRLF line endings
should still work, specifically backslash-CR-LF should be usable to indicate
a continued line.  So how about having gcc accept

  ?

instead?

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

RE: A question about define_insn and force-reg

[Dave Korn]

Eric Fisher wrote:

> I think it's very interesting. I want to split a insn of loading SF
> data through SI symbol, such as (set (reg:SF 5 $5) (mem/u/f:SF
> (symbol_ref/u:SI ("*$LC0".
> I want to it firstly load the address into a register, then load the
> data through the register. So I define the insn as follows,
>   (define_insn "loadsf"
>   [(set (match_operand:SF 0 "register_operand" "=r")
> (mem:SF (match_operand:SI 1 "immediate_operand" "m")))]
>   ""
>   {
> operands[1] = force_reg (SImode, operands[1]);
> return md_output_move (operands[0], operands[1]);
>   }
>   [(set_attr "type"   "load")
>(set_attr "mode"   "SF")
>(set_attr "length" "*")])
> 
>   But the gcc will come out such error,
>   internal compiler error: in gen_reg_rtx,  at emit-rtl.c:819.
> 
>   Which is the codes as following at emit-rtl.c:819,
>/* Don't let anything called after initial flow analysis create new
>  registers.  */
>   if (no_new_pseudos)
> abort ();
> 
>   Why can't I create a new register? 

  Read about reload and no_new_pseudos in the docs for `movm'

http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html

>So how should I do to implement it?

  Generate it earlier:

http://gcc.gnu.org/onlinedocs/gccint/Expander-Definitions.html#Expander-Defi
nitions

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

Re: backslash whitespace newline

['Neil Booth']

Dave Korn wrote:-

> 
>   I would like it to be retained in at least one case: CRLF line endings
> should still work, specifically backslash-CR-LF should be usable to indicate
> a continued line.  So how about having gcc accept
> 
>   ?
> 
> instead?

This is entirely orthogonal; the two issues should not be confused.

Neil.

RE: backslash whitespace newline

[Dave Korn]

'Neil Booth' wrote:
> Dave Korn wrote:-
> 
>> 
>>   I would like it to be retained in at least one case: CRLF line endings
>> should still work, specifically backslash-CR-LF should be usable to
>> indicate a continued line.  So how about having gcc accept
>> 
>>   ?
>> 
>> instead?
> 
> This is entirely orthogonal; the two issues should not be confused.
> 
> Neil.



  So it is.  For a long time gcc accepted CRLF line ends everywhere *except*
after a continuation character; when it started working, I thought it was an
indirect consequence of the whitespace collapsing, but a quick browse
through cpplex.c/skip_escaped_newlines shows that it's only non-vertical
whitespace that gets collapsed, and that handle_newline specifically accepts
CR-LF (and LF-CR) as well as LF.

  Apologies for the noise; I certainly agree it's a violation of the
language spec to allow tabs and spaces after the backslash.


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

Re: GGC Questions

[Daniel Berlin]

On Tue, 2005-10-25 at 10:13 +0530, Ranjit Mathew wrote:
> 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,
> 

Some people do this, but it doesn't really help, and will cause problems
later if we ever change the type of GC we have.

Re: GGC Questions

[Andrew MacLeod]

On Tue, 2005-10-25 at 09:36 -0400, Daniel Berlin wrote:
> On Tue, 2005-10-25 at 10:13 +0530, Ranjit Mathew wrote:
> > 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,
> > 
> 
> Some people do this, but it doesn't really help, and will cause problems
> later if we ever change the type of GC we have.
> 

You need to do it if the structure is not managed by the garbage
collector, but is contained in a structure which is. The garbage
collector insists on being made aware of whats in the structure in this
case.

The operand cache is managed separately, and completely disposed of when
ssa is free'd.  It is included in other structures, such as
tree_ssa_name which *is* garbage collected. The skip tells the garbage
collector to ignore any memory pointer to by ssa_use_operand_t since it
isn't GC managed.

Andrew

Re: backslash whitespace newline

[Joe Buck]

On Mon, Oct 24, 2005 at 06:59:44PM -0700, Mike Stump wrote:
> 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.

Firefox.  Emacs.

Often when I cut and paste a program example from Firefox into Emacs, I
wind up with extra whitespace.

Question on proposed use of "svn switch"

[Richard Kenner]

I just finished reading the SVN manual. This was the 1.1 version, so I hope
there's nothing important in the newer versions.

Somebody at one point asked how to have a subdirectory of the repository
that wouldn't be touched so they could have something entirely different
in it.  I think "svn switch" was suggested, but I can't find that message.
I recall it being some URL like file:/dev/null, but when I read the manual,
I find that the operand of "svn switch" needs to be in the same repository
as the rest of the working directory, so I'm confused.

Here's what I need to do and I welcome suggestions: one of the working
directories I have is the FSF GCC repository (from HEAD), but the
gcc/ada subdirectory is the AdaCore repository.  For cvs, what I do in
gcc/CVS/Entries is delete the line for "ada" and then checkout the AdaCore
repository into there.  What's the way to do this in svn?

Re: Question on proposed use of "svn switch"

[Daniel Jacobowitz]

On Tue, Oct 25, 2005 at 01:05:46PM -0400, Richard Kenner wrote:
> I just finished reading the SVN manual. This was the 1.1 version, so I hope
> there's nothing important in the newer versions.
> 
> Somebody at one point asked how to have a subdirectory of the repository
> that wouldn't be touched so they could have something entirely different
> in it.  I think "svn switch" was suggested, but I can't find that message.
> I recall it being some URL like file:/dev/null, but when I read the manual,
> I find that the operand of "svn switch" needs to be in the same repository
> as the rest of the working directory, so I'm confused.

It was simpler than that: Dan created an empty directory in the GCC
repository to switch to.

Googling for "gcc svn switch" took me directly to the Wiki page, which
covers this; it's under setup:

  svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir libada

> Here's what I need to do and I welcome suggestions: one of the working
> directories I have is the FSF GCC repository (from HEAD), but the
> gcc/ada subdirectory is the AdaCore repository.  For cvs, what I do in
> gcc/CVS/Entries is delete the line for "ada" and then checkout the AdaCore
> repository into there.  What's the way to do this in svn?

I think you would need to do something a bit more complicated for this,
using svk.  Among other things, this should let you combine multiple
conceptual "repositories".  But I'll defer this one to our experts.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Question on proposed use of "svn switch"

[Richard Kenner]

 It was simpler than that: Dan created an empty directory in the GCC
 repository to switch to.

Ah!

 Googling for "gcc svn switch" took me directly to the Wiki page, which
 covers this; it's under setup:

I didn't Google, but searched the GCC list for "svn switch".  That's why
I didn't find it.

svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir libada

I bet that'd work.  svn would treat the directory as empty and cvs would
ignore the svn stuff.  I'll try it.  Thanks.

 I think you would need to do something a bit more complicated for
 this, using svk.  Among other things, this should let you combine
 multiple conceptual "repositories".  But I'll defer this one to our
 experts.

Note that the gcc/ada I want would be under cvs, not svn.

Re: Question on proposed use of "svn switch"

[Florian Weimer]

* Richard Kenner:

> Here's what I need to do and I welcome suggestions: one of the working
> directories I have is the FSF GCC repository (from HEAD), but the
> gcc/ada subdirectory is the AdaCore repository.  For cvs, what I do in
> gcc/CVS/Entries is delete the line for "ada" and then checkout the AdaCore
> repository into there.  What's the way to do this in svn?

Just apply the "svn switch" trick, and check out that single directory
from the AdaCore CVS tree?  (Assuming that AdaCore continues to use
CVS.)

If this results in unwanted output from "svn status", we probably
should set the svn:ignore property on the dummy directory
svn+ssh://gcc.gnu.org/svn/gcc/emptydir to "*".

Problem building svn on x86-64

[Richard Kenner]

I'm trying to build svn from sources on my x86-64 machine and get:

cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool --tag=CC 
--silent --mode=link gcc  -g -O2  -g -O2 -pthread  -DNEON_ZLIB   -rpath 
/usr/local/lib -o libsvn_subr-1.la  auth.lo cmdline.lo config.lo config_auth.lo 
config_file.lo config_win.lo ctype.lo date.lo error.lo hash.lo io.lo lock.lo 
md5.lo opt.lo path.lo pool.lo quoprint.lo sorts.lo stream.lo subst.lo 
svn_base64.lo svn_string.lo target.lo time.lo utf.lo utf_validate.lo 
validate.lo version.lo xml.lo 
/gcc/gcc/subversion-1.2.3/apr-util/libaprutil-0.la -lgdbm -ldb-4.2 -lexpat 
/gcc/gcc/subversion-1.2.3/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread 
-ldl 
/usr/lib/libgdbm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

The problem is that /usr/lib/libgdbm is a 32-bit file.  It should be using
/usr/lib64 and ld should know that.  But it looks like something is
short-circuiting stuff.  Does anybody know enough about svn build
procedures to know how to fix this?

Re: Question on proposed use of "svn switch"

[Daniel Jacobowitz]

On Tue, Oct 25, 2005 at 01:16:30PM -0400, Richard Kenner wrote:
>  I think you would need to do something a bit more complicated for
>  this, using svk.  Among other things, this should let you combine
>  multiple conceptual "repositories".  But I'll defer this one to our
>  experts.
> 
> Note that the gcc/ada I want would be under cvs, not svn.

In this case, you can probably just check it out.  Subversion ought to
ignore the contents.  You'll have to both svn up and cvs up, though.

You can get much slicker behavior if you use svn for both halves, but
obviously migrating internal trees isn't easy...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Question on Dwarf2 unwind info and optimized code

[Joern RENNECKE]

In http://gcc.gnu.org/ml/gcc/2005-10/msg00823.html, Jim Wilson wrote:

> 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.


It can't be easily implemented in target-specific code alone.  Sometimes 
there is code after the epilogue, so there would have to be

a mechanism to get the dwarf virtual machine back to the pre-epilogue state.

[gomp] C++ #pragma omp for and -fno-for-scope

[Jakub Jelinek]

Hi!

While looking at PR c++/24512, I have noticed that for
#pragma omp {,parallel }for loops we don't handle -fno-for-scope
and don't emit the default error messages that point people to
the problem otherwise.

So my question is, should we consider #pragma omp for and
#pragma omp parallel for a separate scope around the for loop for
this kind of purpose or not?  I think it would be better to be
consistent with -fno-openmp (i.e. if there is a declaration
in the for loop, move the DECL_EXPR right before the loop, either
into a separate sk_for scope if flag_new_for_scope > 0, or just into
the parent scope at that point) and create sk_omp scope for the
rest of the construct.

What do you think?

extern void bar (int);

void foo ()
{
#pragma omp for lastprivate (i)
  for (int i = 0; i < 10; i++)
bar (i);
  bar (i);
#pragma omp parallel for lastprivate (j)
  for (int j = 0; j < 10; j++)
bar (j);
  bar (j);
}

Jakub

Re: Problem building svn on x86-64

[H. J. Lu]

On Tue, Oct 25, 2005 at 01:43:28PM -0400, Richard Kenner wrote:
> I'm trying to build svn from sources on my x86-64 machine and get:
> 
> cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool 
> --tag=CC --silent --mode=link gcc  -g -O2  -g -O2 -pthread  -DNEON_ZLIB   
> -rpath /usr/local/lib -o libsvn_subr-1.la  auth.lo cmdline.lo config.lo 
> config_auth.lo config_file.lo config_win.lo ctype.lo date.lo error.lo hash.lo 
> io.lo lock.lo md5.lo opt.lo path.lo pool.lo quoprint.lo sorts.lo stream.lo 
> subst.lo svn_base64.lo svn_string.lo target.lo time.lo utf.lo utf_validate.lo 
> validate.lo version.lo xml.lo 
> /gcc/gcc/subversion-1.2.3/apr-util/libaprutil-0.la -lgdbm -ldb-4.2 -lexpat 
> /gcc/gcc/subversion-1.2.3/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread 
> -ldl 
> /usr/lib/libgdbm.so: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> 
> The problem is that /usr/lib/libgdbm is a 32-bit file.  It should be using
> /usr/lib64 and ld should know that.  But it looks like something is
> short-circuiting stuff.  Does anybody know enough about svn build
> procedures to know how to fix this?

Do you have the 64bit version of libgdbm.so under /usr/lib64?


H.J.

Re: Problem building svn on x86-64

[Richard Kenner]

 Do you have the 64bit version of libgdbm.so under /usr/lib64?

Yes.  The question is why it isn't getting used.

Re: Problem building svn on x86-64

[H. J. Lu]

On Tue, Oct 25, 2005 at 03:10:58PM -0400, Richard Kenner wrote:
>  Do you have the 64bit version of libgdbm.so under /usr/lib64?
> 
> Yes.  The question is why it isn't getting used.

Add --verbose to ld and post the ld command line as well as its output.


H.J.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 11:50:00AM -0700, Eric Christopher wrote:
> 
> On Oct 25, 2005, at 8:54 AM, Joe Buck wrote:
> >Often when I cut and paste a program example from Firefox into  
> >Emacs, I
> >wind up with extra whitespace.
> 
> I've got an elisp file that removes trailing whitespace if you'd like  
> it...

Not needed; the following sequence removes trailing whitespace in Emacs:

ESC-x picture-mode NL
CTL-c CTL-c

(picture-mode cleans up trailing whitespace on exit).

The problem, though, is the program behavior is affected by something that
is invisible (the trailing whitespace).

If it's an issue that different compilers handle this differently and that
the standard does not specify the behavior, the answer, I think, is to
warn when trailing whitespace affects the behavior of the program.
I think that the only case is when the last character is a \ but there
may be others.

Re: Problem building svn on x86-64

[Alexandre Oliva]

On Oct 25, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:

> cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool 
> --tag=CC --silent --mode=link gcc  -g -O2  -g -O2 -pthread  -DNEON_ZLIB   
> -rpath /usr/local/lib -o libsvn_subr-1.la  auth.lo cmdline.lo config.lo 
> config_auth.lo config_file.lo config_win.lo ctype.lo date.lo error.lo hash.lo 
> io.lo lock.lo md5.lo opt.lo path.lo pool.lo quoprint.lo sorts.lo stream.lo 
> subst.lo svn_base64.lo svn_string.lo target.lo time.lo utf.lo utf_validate.lo 
> validate.lo version.lo xml.lo 
> /gcc/gcc/subversion-1.2.3/apr-util/libaprutil-0.la -lgdbm -ldb-4.2 -lexpat 
> /gcc/gcc/subversion-1.2.3/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread 
> -ldl 
> /usr/lib/libgdbm.so: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status

> The problem is that /usr/lib/libgdbm is a 32-bit file.  It should be using
> /usr/lib64 and ld should know that.  But it looks like something is
> short-circuiting stuff.  Does anybody know enough about svn build
> procedures to know how to fix this?

Libtool searches /usr/lib instead of /usr/lib64 because the Debian
folks decided to not follow the AMD64 ABI, and libtool remained
neutral in this regard (i.e., broken for both Debian and ABI-compliant
distros).  Try adding -L/usr/lib64 or something along these lines to
LDFLAGS, so that libtool finds libs in the right place, and it should
work.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: Question on Dwarf2 unwind info and optimized code

[James E Wilson]

On Tue, 2005-10-25 at 11:34, Joern RENNECKE wrote:
> It can't be easily implemented in target-specific code alone.  Sometimes 
> there is code after the epilogue, so there would have to be
> a mechanism to get the dwarf virtual machine back to the pre-epilogue state.

There is.

I'm more conversant with IA-64 unwind info than dwarf2 unwind info at
the moment.  In IA-64 unwind info, we have operators label_state and
copy_state.  We just emit label_state before the epilogue, and then
copy_state after the epilogue.  The IA-64 port already does this via
hooks in final.c.  The code is there if you want to look at it.  The
IA-64 port is probably the only one emitting epilogue unwind info at the
moment.

There are equivalent features in dwarf unwind info.  Looks like they are
called DW_CFA_remember_state and DW_CFA_restore_state.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: [gomp] C++ #pragma omp for and -fno-for-scope

[Mike Stump]

On Oct 25, 2005, at 11:56 AM, Jakub Jelinek wrote:

While looking at PR c++/24512, I have noticed that for
#pragma omp {,parallel }for loops we don't handle -fno-for-scope


Issue a sorry and don't worry about it?  -fno-for-scope is for legacy  
code for people that can't be bothered to spend a few minutes  
updating their code.  I'd hope that the gomp code bases aren't that  
crusty.

Re: Question on Dwarf2 unwind info and optimized code

[James E Wilson]

On Tue, 2005-10-25 at 01:08, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame:

That is probably a reasonable solution if it can be implemented
cleanly.  There are already some differences.  debug_frame info can
contain unaligned data, but for eh_frame we try to avoid this, because
some targets which aren't native DWARF2 users may lack the necessary
relocs.  There are also already other differences.

The long term solution here is to get gdb to start using debug_frame
info exclusively, instead of disassembling prologues as it does now for
most targets.  Then, people will start caring more about the accuracy of
the debug_frame info than its size, and gcc will be fixed to emit full
debug_frame info, including for the epilogue.

Until then, if you want something fixed in the debug_frame info, you
will probably have to fix it yourself.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Question on Dwarf2 unwind info and optimized code

[Daniel Jacobowitz]

On Tue, Oct 25, 2005 at 12:44:42PM -0700, James E Wilson wrote:
> On Tue, 2005-10-25 at 01:08, Christophe LYON wrote:
> > On occasions, I wonder whether it wouldn't make sense to generate
> > different infos in debug_frame and eh_frame:
> 
> That is probably a reasonable solution if it can be implemented
> cleanly.  There are already some differences.  debug_frame info can
> contain unaligned data, but for eh_frame we try to avoid this, because
> some targets which aren't native DWARF2 users may lack the necessary
> relocs.  There are also already other differences.
> 
> The long term solution here is to get gdb to start using debug_frame
> info exclusively, instead of disassembling prologues as it does now for
> most targets.  Then, people will start caring more about the accuracy of
> the debug_frame info than its size, and gcc will be fixed to emit full
> debug_frame info, including for the epilogue.

It already does use .debug_frame exclusively, on most targets, if
.debug_frame is present.  i.e. if the dwarf2 information includes
incorrect information about the epilogue, gdb will fall down in the
epilogue.

The prologue analyzers are used strictly when no debug info is
available (or for a couple of thorny targets, MIPS in particular,
that's a TODO).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: backslash whitespace newline

[Mike Stump]

On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote:

Emacs in an xterm, from time to time.


Yeah, I knew about that one, cutting and pasting from any full screen  
program running in a terminal emulator tends to be wrong.  Tab  
characters are usually the first causalities, along with long  
lines.  :-(  I'd propose to encourage people submit bug reports  
against xterm/emacs/terminfo/termcap/curses if they care much about  
the issue.  I think it might be possible to improve the situation alot.


Doing this is a better solution, as then cutting and pasting would be  
fundamentally more reliable in that environment.


Thanks for the pointer.

Re: backslash whitespace newline

[Tom Tromey]

> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:

Joe> Not needed; the following sequence removes trailing whitespace in Emacs:
Joe> ESC-x picture-mode NL
Joe> CTL-c CTL-c
Joe> (picture-mode cleans up trailing whitespace on exit).

There's also the more direct M-x delete-trailing-whitespace

Tom

Re: backslash whitespace newline

[Daniel Jacobowitz]

On Tue, Oct 25, 2005 at 12:53:23PM -0700, Mike Stump wrote:
> On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote:
> >Emacs in an xterm, from time to time.
> 
> Yeah, I knew about that one, cutting and pasting from any full screen  
> program running in a terminal emulator tends to be wrong.  Tab  
> characters are usually the first causalities, along with long  
> lines.  :-(  I'd propose to encourage people submit bug reports  
> against xterm/emacs/terminfo/termcap/curses if they care much about  
> the issue.  I think it might be possible to improve the situation alot.

In fact, it really isn't (or at least it's defeated everyone who
tried); I spent some time talking with the ncurses maintainer about
this earlier in the month.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

c compiler VMS 8.2

[[EMAIL PROTECTED]]

Hello,

We just bought a HP Integrity Itanium server and are running VMS 8.2.
Does a Gnu C-compiler exist ?

Best regards,

Sincerely,

Rudy Campe
Annabel Textiles
Belgium - Europe
[EMAIL PROTECTED]

Re: New SVN Wiki page

[Mike Stump]

On Oct 25, 2005, at 12:50 AM, Giovanni Bajo wrote:
Uhm, I'm not sure how to explain this without being too pedantic.  
Does this

sound clearer?


This tool tracks each individual change (fine-grained) and will never  
reapply an already applied change.


I think that is a high level answer, and completely answers the  
question to people that have the question, while doing as little as  
possible to confuse someone that doesn't even have the question.   
Anyone doing merges should have the question and understand the answer.


Or, you can say it merges in N-1 to N, when one requests a merge of  
N.  A totally different way of expressing the same thing, and conveys  
the same information.


Sound reasonable?

Re: c compiler VMS 8.2

[Steven Bosscher]

On Tuesday 25 October 2005 22:19, [EMAIL PROTECTED] wrote:
> Hello,
>
> We just bought a HP Integrity Itanium server and are running VMS 8.2.
> Does a Gnu C-compiler exist ?

So, you're saying you can find this mailing list, but not the compiler
that is being discussed here?

Gr.
Steven

SVN 1.3?

[Richard Kenner]

The Wiki mentiones it, but not where to get it.  Google searches don't
see to find the tar file for it.

Re: backslash whitespace newline

[Florian Weimer]

* Mike Stump:

> On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote:
>> Emacs in an xterm, from time to time.
>
> Yeah, I knew about that one, cutting and pasting from any full screen  
> program running in a terminal emulator tends to be wrong.  Tab  
> characters are usually the first causalities, along with long  
> lines.  :-(  I'd propose to encourage people submit bug reports  
> against xterm/emacs/terminfo/termcap/curses if they care much about  
> the issue.  I think it might be possible to improve the situation alot.

There's a mitigating factor: If you past it into another Emacs in an
xterm of the same width, all lines are wrapped.  This provides a
strong incentive to remove at least some of the trailing whitespace.

Re: SVN 1.3?

[Daniel Berlin]

On Tue, 2005-10-25 at 16:39 -0400, Richard Kenner wrote:
> The Wiki mentiones it, but not where to get it.  Google searches don't
> see to find the tar file for it.

I will email the list when the release candidate is released.

Re: SVN 1.3?

[Giovanni Bajo]

Richard Kenner <[EMAIL PROTECTED]> wrote:

> The Wiki mentiones it, but not where to get it.  Google searches don't
> see to find the tar file for it.

I'll add a note to the wiki about this. Subversion 1.3 RC1 should be out
real soon now, you can use (and test) that one. The idea is that if the GCC
community finds serious bugs in RC1, those bugs could get fixed before 1.3
final is out.

I believe you could try pulling it from the 1.3 branch on its repository.
Otherwise, use 1.2 for now and wait for 1.3 RC1 in the next couple of days.

The wiki also mention that you will see a disk usage improvement by using
1.3 RC1. This is also not true *right now* but will be true after Daniel
converts the CVS repository to SVN for good this weekend.
-- 
Giovanni Bajo

Re: backslash whitespace newline

[Andreas Schwab]

Joe Buck <[EMAIL PROTECTED]> writes:

> On Tue, Oct 25, 2005 at 11:50:00AM -0700, Eric Christopher wrote:
>> 
>> On Oct 25, 2005, at 8:54 AM, Joe Buck wrote:
>> >Often when I cut and paste a program example from Firefox into  
>> >Emacs, I
>> >wind up with extra whitespace.
>> 
>> I've got an elisp file that removes trailing whitespace if you'd like  
>> it...
>
> Not needed; the following sequence removes trailing whitespace in Emacs:
>
> ESC-x picture-mode NL
> CTL-c CTL-c
>
> (picture-mode cleans up trailing whitespace on exit).

There's also delete-trailing-whitespace (since Emacs 21).

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-25 12:12:31 -0700, Joe Buck wrote:
> Not needed; the following sequence removes trailing whitespace in Emacs:
> 
> ESC-x picture-mode NL
> CTL-c CTL-c
> 
> (picture-mode cleans up trailing whitespace on exit).

What about M-x delete-trailing-whitespace?

Anyway by removing trailing whitespace, one assumes that it is not
significant. So, let the compiler regard it as not significant.

> The problem, though, is the program behavior is affected by
> something that is invisible (the trailing whitespace).

Yes.

> If it's an issue that different compilers handle this differently and that
> the standard does not specify the behavior, the answer, I think, is to
> warn when trailing whitespace affects the behavior of the program.

I agree.

> I think that the only case is when the last character is a \ but there
> may be others.

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

Re: [gomp] C++ #pragma omp for and -fno-for-scope

[Richard Henderson]

On Tue, Oct 25, 2005 at 02:56:54PM -0400, Jakub Jelinek wrote:
> So my question is, should we consider #pragma omp for and
> #pragma omp parallel for a separate scope around the for loop for
> this kind of purpose or not?  I think it would be better to be
> consistent with -fno-openmp (i.e. if there is a declaration
> in the for loop, move the DECL_EXPR right before the loop, either
> into a separate sk_for scope if flag_new_for_scope > 0, or just into
> the parent scope at that point) and create sk_omp scope for the
> rest of the construct.
> 
> What do you think?

I think that's too much work to cater to pre-ISO C++.  If you like,
print a warning message when the decl is present and -fno-for-scope
has been used.  Something like

  "-fno-for-scope ignored with #pragma omp for"


r~

Re: GGC Questions

[Mike Stump]

On Oct 24, 2005, at 9:43 PM, Ranjit Mathew wrote:

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


Doesn't really help on time.


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


No, doesn't reduce the size, nor the load time.  We can only know  
that it doesn't matter for PCH.



3. some other reason?


Andrew hit it one of the reasons on the head.  That, or, one doesn't  
want to go to the trouble of marking all the data-structures.



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


Yes, this is _why_ one can mark them as skip.


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.


I don't believe it is necessary.


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.


Set a breakpoint on creation, and one of use, either, the data  
matches, or it doesn't.  If it doesn't set a watch point on the  
changed data, and rerun.  Careful to enable the breakpoint only after  
creation, as watch doesn't like unmapped mempory (on darwin anyway).   
You can also tell GC to never collect, and thus `know' if that is the  
issue.  Also, you can breakpoint the walker/freer and check if the  
address that can't be freed is.  Doing an up from that point tells  
you the context it was in when freed.  At times, collect isn't  
allowed, and it might be one of those times.  Breaking on freer is  
easier to understand than breaking on a watch point.  ggc_free might  
be called on data that isn't totally free, just comment out the  
ggc_free call to fix.

Re: c compiler VMS 8.2

[Mike Stump]

On Oct 25, 2005, at 1:31 PM, Steven Bosscher wrote:

So, you're saying you can find this mailing list, but not the compiler
that is being discussed here?


No, he is asking if it really does work, which isn't as obvious.  :-)

After that, he might be asking for a pointer to a binary to bootstrap  
with.


Anyway, these questions are more suitable for gcc-help.

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-25 16:01:43 -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 25, 2005 at 12:53:23PM -0700, Mike Stump wrote:
> > Yeah, I knew about that one, cutting and pasting from any full screen  
> > program running in a terminal emulator tends to be wrong.  Tab  
> > characters are usually the first causalities, along with long  
> > lines.  :-(  I'd propose to encourage people submit bug reports  
> > against xterm/emacs/terminfo/termcap/curses if they care much about  
> > the issue.  I think it might be possible to improve the situation alot.
> 
> In fact, it really isn't (or at least it's defeated everyone who
> tried); I spent some time talking with the ncurses maintainer about
> this earlier in the month.

This can be improved a bit. The fact that ncurses clears the end of
a line with spaces instead of an escape sequence when there are a
few columns left is 100% ncurses fault, and easy to fix IMHO (just
remove the optimization).

-- 
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

[Daniel Jacobowitz]

On Tue, Oct 25, 2005 at 11:16:23PM +0200, Vincent Lefevre wrote:
> On 2005-10-25 16:01:43 -0400, Daniel Jacobowitz wrote:
> > On Tue, Oct 25, 2005 at 12:53:23PM -0700, Mike Stump wrote:
> > > Yeah, I knew about that one, cutting and pasting from any full screen  
> > > program running in a terminal emulator tends to be wrong.  Tab  
> > > characters are usually the first causalities, along with long  
> > > lines.  :-(  I'd propose to encourage people submit bug reports  
> > > against xterm/emacs/terminfo/termcap/curses if they care much about  
> > > the issue.  I think it might be possible to improve the situation alot.
> > 
> > In fact, it really isn't (or at least it's defeated everyone who
> > tried); I spent some time talking with the ncurses maintainer about
> > this earlier in the month.
> 
> This can be improved a bit. The fact that ncurses clears the end of
> a line with spaces instead of an escape sequence when there are a
> few columns left is 100% ncurses fault, and easy to fix IMHO (just
> remove the optimization).

I invite you to talk to Thomas about that one; he may well agree.  That
doesn't affect the general case.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: backslash whitespace newline

[Eric Christopher]

On Oct 24, 2005, at 3:52 PM, 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.


I filed bugzilla 24531 about this.

Haven't heard Joseph weigh in on this issue, but here are the options  
that I see:


a) We enable the conditional warning for line continuation in a  
comment at all times

(just as we do for normal lines)

b) Change the preprocessor to remove the behavior and disable the  
continuation

if we have a \ followed by a space

c) Do nothing.

Option c will leave us with the current behavior that I don't believe  
I've heard

anyone want to keep (other than it's the current documented behavior).

I'll work up a patch for b since that's what Apple would like the  
most. I believe that

option a is needed at least.

This is, as Mr. Buck has noted, a regression from 2.95.

-eric

Re: backslash whitespace newline

[Andrew Pinski]

> 
>  > OK, so it must be this, then
> 
>  Installed.
> 
> That works.  Thanks.
> 

Re: backslash whitespace newline

[Andrew Pinski]

> 
> 
> On Oct 24, 2005, at 3:52 PM, 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.
> 
> I filed bugzilla 24531 about this.

Note this is documented behavior and I don't think we should change it at
all since it is one more thing to break old gcc code like stuff in Linux kernel.

We have people already complaining about removing extensions.  Why should we 
change
this implementionation defined documented behavior.

-- Pinski

Re: Question on Dwarf2 unwind info and optimized code

[Richard Henderson]

On Tue, Oct 25, 2005 at 10:08:59AM +0200, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame: IIUC, GCC tries to
> 'compress' the debug frame info by generating few advance_loc
> instructions (eg only 1 for the whole prologue), which makes sense in
> the C++ EH stack unwinding context, but my cause problems in a debugger.

No it doesn't.  Look closer at the optimization.  It compresses
the advances only when the original register is still unmodified.


r~

Re: Question on Dwarf2 unwind info and optimized code

[Richard Henderson]

On Tue, Oct 25, 2005 at 10:08:59AM +0200, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame

And we do this.


r~

Re: backslash whitespace newline

[Andrew Pinski]

> 
> > 
> >  > OK, so it must be this, then
> > 
> >  Installed.
> > 
> > That works.  Thanks.
> > 

Ignore this, this was a typo.

-- Pinski

Re: c compiler VMS 8.2

[Robert Dewar]

[EMAIL PROTECTED] wrote:

Hello,

We just bought a HP Integrity Itanium server and are running VMS 8.2.
Does a Gnu C-compiler exist ?


Note that AdaCore is currently busy doing a GNAT Pro port for this
target (funded by HP), we have to get a C compiler working as part
of this effort.

Re: GCC-generated code and i386 condition codes behavior

[Richard Henderson]

On Mon, Oct 24, 2005 at 03:39:53PM -0500, Bryan Ford wrote:
> 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?

No.


r~

Re: backslash whitespace newline

[Eric Christopher]

Oh, one more thing.  This seems like the normal problem of not  
reading the docs

if something does not work the way you want it to work.


So?

The only thing we can do is point it out that it is documented  
behavior and

then move on to the next issue.  Also why are we discussing this when
there are more important bugs to fix currently as this behavior has  
been documented

for a long time, at least 4 years.


Your important and my important are two different things.

-eric

Re: backslash whitespace newline

[Andrew Pinski]

> 
> > 
> > 
> > On Oct 24, 2005, at 3:52 PM, 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.
> > 
> > I filed bugzilla 24531 about this.
> 
> Note this is documented behavior and I don't think we should change it at
> all since it is one more thing to break old gcc code like stuff in Linux 
> kernel.
> 
> We have people already complaining about removing extensions.  Why should we 
> change
> this implementionation defined documented behavior.

Oh, one more thing.  This seems like the normal problem of not reading the docs
if something does not work the way you want it to work.

The only thing we can do is point it out that it is documented behavior and
then move on to the next issue.  Also why are we discussing this when
there are more important bugs to fix currently as this behavior has been 
documented
for a long time, at least 4 years.

-- Pinski

Re: backslash whitespace newline

[Phil Edwards]

On Mon, Oct 24, 2005 at 10:07:33PM -0400, DJ Delorie wrote:
> 
> > 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.

Yes, to this day, even using their latest command shells.  Curse them.


-- 
"It won't be any more frightening than the time
 I climbed up an elevator shaft with my teeth."
- Sunny Baudelaire

Re: backslash whitespace newline

[Andrew Pinski]

> 
> >
> > Oh, one more thing.  This seems like the normal problem of not  
> > reading the docs
> > if something does not work the way you want it to work.
> 
> So?
> 
> > The only thing we can do is point it out that it is documented  
> > behavior and
> > then move on to the next issue.  Also why are we discussing this when
> > there are more important bugs to fix currently as this behavior has  
> > been documented
> > for a long time, at least 4 years.
> 
> Your important and my important are two different things.

But this is the FSF GCC mailing list so the important here should
be regressions.  Hint  hint.  If people don't want FSF releases
any more say so please, otherwise we get into this fights about
what is really important.

This is not a regression really.


-- Pinski

Re: backslash whitespace newline

[Eric Christopher]

This is not a regression really.



It is a regression against 2.95.

-eric

gcc-3.4-20051025 is now available

[gccadmin]

Snapshot gcc-3.4-20051025 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051025/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20051025 

You'll find:

gcc-3.4-20051025.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20051025.tar.bz2 C front end and core compiler

gcc-ada-3.4-20051025.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20051025.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20051025.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20051025.tar.bz2 Java front end and runtime

gcc-objc-3.4-20051025.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20051025.tar.bz2The GCC testsuite

Diffs from 3.4-20051018 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 03:14:27PM -0700, Eric Christopher wrote:
> This is, as Mr. Buck has noted, a regression from 2.95.

No, it is not (and I did not say that); it is a behavior change, which I
vaguely recall was requested.

Still, many of us have to get code past multiple compilers, so the
warning would be useful.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 03:45:36PM -0700, Eric Christopher wrote:
> >
> >This is not a regression really.
> >
> 
> It is a regression against 2.95.

As I said, no it is not.  A behavior change is only a regression when
the first behavior is correct and the second is not.

In this case, there is no defined behavior.

ISO/IEC 14882:2003

[Turner, Keith S]

The man page information for the gcc  c++98 option says that the
compiler will be compliant with "The 1998 ISO C++ standard plus
amendments." Are the amendments referring to the changes to the C++
standard that is now "ISO/IEC 14882:2003". I need to know if "ISO/IEC
14882:2003" is supported by gcc 4.0.2.

Thank you for your help.

Keith Turner
Lockheed Martin Aeronautics - Fort Worth
817-763-3570

Re: backslash whitespace newline

[Eric Christopher]

As I said, no it is not.  A behavior change is only a regression when
the first behavior is correct and the second is not.



Fair enough. :)

-eric

Re: backslash whitespace newline

[Stan Shebs]

Andrew Pinski wrote:

Oh, one more thing.  This seems like the normal problem of not  
reading the docs

if something does not work the way you want it to work.


So?


The only thing we can do is point it out that it is documented  
behavior and

then move on to the next issue.  Also why are we discussing this when
there are more important bugs to fix currently as this behavior has  
been documented

for a long time, at least 4 years.


Your important and my important are two different things.



But this is the FSF GCC mailing list so the important here should
be regressions.  Hint  hint.  If people don't want FSF releases
any more say so please, otherwise we get into this fights about
what is really important.


I think you've managed to get everything backwards. We have potential
customers (dunno if I'm allowed to name them, so I won't) who can't
use GCC because of its current behavior. We can fix Apple GCC in a
minute to make them happy, but of course then we'll have to tell them
"don't use FSF GCC, you'll lose". So we're offering to make FSF GCC
work for these users also, and asking for input on the idea. As
always, it's the community's choice as to whether this is a desirable
feature for FSF GCC, and that's part of the discussion, but at least
don't p*ss on us for making the offer in the first place!

Stan

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 04:05:55PM -0700, Stan Shebs wrote:
> I think you've managed to get everything backwards. We have potential
> customers (dunno if I'm allowed to name them, so I won't) who can't
> use GCC because of its current behavior.

I had thought that a numer of users had requested the current
behavior back in the egcs days, though I can't track down the brain cell I
stored that info in; also, I'm having a hard time picturing source code that

 a) exhibits different behavior because of this bug, and
 b) is maintainable (remember, the behavior depends on the presence
of characters that are completely invisible to many tools).

Perhaps you could explain (without violating the customer's
confidentiality) how it is that this is an important problem?

> minute to make them happy, but of course then we'll have to tell them
> "don't use FSF GCC, you'll lose". So we're offering to make FSF GCC
> work for these users also, and asking for input on the idea. As
> always, it's the community's choice as to whether this is a desirable
> feature for FSF GCC, and that's part of the discussion, but at least
> don't p*ss on us for making the offer in the first place!

I think that there was only pissing because this feature that many
considered useful was labeled a regression and a bug.

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:

We have people already complaining about removing extensions.  Why  
should we change

this implementionation defined documented behavior.


I'm not convinced that "extension" is a proper term for this  
behavior.  It is more like an incompatibility with the rest of the  
world's compilers.  The reason for change is to conform to a de-facto  
standard, and thus ease the migration of future gcc customers to our  
compiler.


These hypothetical customers coming from MS, EDG-based, or  
CodeWarrior compilers might have code that looks like:


// A poorly formatted comment \\
int x = 0;
int y = 1;
...

Note I'm not trying to defend code that looks like this.  But the  
fact is that if you've got a million lines of code that's been  
compiling with a non-gcc compiler for a decade, silly things like  
this tend to add an extra hurdle to porting to gcc.


I don't claim that gcc's behavior is better or worse than everyone  
else's.  I only claim that gcc is unique in this regard, and that  
isn't a good thing if you're trying to be friendly to customers  
wanting to adopt your product.


-Howard

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:
> 
> > We have people already complaining about removing extensions.  Why  
> > should we change
> > this implementionation defined documented behavior.
> 
> I'm not convinced that "extension" is a proper term for this  
> behavior.  It is more like an incompatibility with the rest of the  
> world's compilers.  The reason for change is to conform to a de-facto  
> standard, and thus ease the migration of future gcc customers to our  
> compiler.
> 
> These hypothetical customers coming from MS, EDG-based, or  
> CodeWarrior compilers might have code that looks like:
> 
> // A poorly formatted comment \\
> int x = 0;
> int y = 1;
> ...

But this is not an extension at all.  This is an implementation defined
behavior which is different than what an extension would do.

People depending on this is not the correct thing do any ways as
there could be another compiler besides which GCC which does this.

Please read what implemenation defined means, this is what you
are talking about.

Also Note there is a much older PR about this, PR 8270: 
http://gcc.gnu.org/PR8270.

-- Pinski

Re: backslash whitespace newline

[Ian Lance Taylor]

Joe Buck <[EMAIL PROTECTED]> writes:

> I had thought that a numer of users had requested the current
> behavior back in the egcs days, though I can't track down the brain cell I
> stored that info in;

For the record, the current behaviour was implemented here:
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00430.html

Ian

Re: backslash whitespace newline

[Gabriel Dos Reis]

Andrew Pinski <[EMAIL PROTECTED]> writes:

| Please read what implemenation defined means, this is what you
| are talking about.

Andrew --

Before taking your time to insult people; please do spend a little
bit of that time on your homework on their background.

-- Gaby

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 07:41:11PM -0400, Howard Hinnant wrote:
> I'm not convinced that "extension" is a proper term for this  
> behavior.  It is more like an incompatibility with the rest of the  
> world's compilers.  The reason for change is to conform to a de-facto  
> standard, and thus ease the migration of future gcc customers to our  
> compiler.
> 
> These hypothetical customers coming from MS, EDG-based, or  
> CodeWarrior compilers might have code that looks like:
> 
> // A poorly formatted comment \\
> int x = 0;
> int y = 1;
> ...

Howard,

Have you tested the sequence above with various compilers?  I just
have.  The behavior depends on whether there is whitespace after the
\\ or not.  If there is none, then EDG-based compilers will comment
out the declaration of x.  If there is whitespace, gcc 3.x comments
it out and the others don't.  I personally like the fact that gcc's
behavior does not depend on invisible characters; on the other hand,
there's a good argument that this behavior is ordinarily not desirable
and should be warned about, except to continue strings.

I have difficulty believing that it is desirable for production code
to contain surprises like this.

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:

But this is not an extension at all.  This is an implementation  
defined

behavior which is different than what an extension would do.

People depending on this is not the correct thing do any ways as
there could be another compiler besides which GCC which does this.


  I'm not disagreeing with anything you're saying.  My only  
point is that it might be in gcc's best interest to have the same  
implementation defined behavior as MS, EDG-based compilers and  
CodeWarrior when that is a reasonable choice (and probably others, I  
know my list of compilers is incomplete).


-Howard

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:
> 
> > But this is not an extension at all.  This is an implementation  
> > defined
> > behavior which is different than what an extension would do.
> >
> > People depending on this is not the correct thing do any ways as
> > there could be another compiler besides which GCC which does this.
> 
>   I'm not disagreeing with anything you're saying.  My only  
> point is that it might be in gcc's best interest to have the same  
> implementation defined behavior as MS, EDG-based compilers and  
> CodeWarrior when that is a reasonable choice (and probably others, I  
> know my list of compilers is incomplete).

Why not get other compilers to change to what GCC does?  Why does GCC
have to follow what other compilers do, maybe other compilers 
would be in the best interest of following what GCC does.

Why not instead get the standard changed and then GCC will just follow
then (and really should only follow at that point)?

(and Yes I know you wrote the MW C++ library and part of the C++
standards comittee).


-- Pinski

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 25, 2005, at 8:11 PM, Joe Buck wrote:


// A poorly formatted comment \\
int x = 0;
int y = 1;
...



Howard,

Have you tested the sequence above with various compilers?


I only know of the results on gcc 4.x, MS, EDG-based, and Freescale  
CodeWarrior.



I just
have.  The behavior depends on whether there is whitespace after the
\\ or not.  If there is none, then EDG-based compilers will comment
out the declaration of x.  If there is whitespace, gcc 3.x comments
it out and the others don't.


Right, that's exactly the issue.


I personally like the fact that gcc's
behavior does not depend on invisible characters; on the other hand,
there's a good argument that this behavior is ordinarily not desirable
and should be warned about, except to continue strings.

I have difficulty believing that it is desirable for production code
to contain surprises like this.


Personally I'd fire a programmer that depended on the presence of  
whitespace after a '\'.  It is implementation defined behavior, and  
invisible in the source at that (in most editors).  I've seen code  
broken both by gcc's behavior, and by other compiler's behavior by  
depending on what happens when whitespace is included after a '\'.


And it is not my assertion that gcc's behavior is better or worse  
than other compilers.  Only that gcc's behavior is unique in the  
industry (I actually haven't tried all other modern compilers) and  
that uniqueness in this way is not an asset to gcc.


-Howard

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 08:22:15PM -0400, Howard Hinnant wrote:
> And it is not my assertion that gcc's behavior is better or worse  
> than other compilers.  Only that gcc's behavior is unique in the  
> industry (I actually haven't tried all other modern compilers) and  
> that uniqueness in this way is not an asset to gcc.

gcc is "unique in the industry" in any number of ways, as is every
other compiler -- in that each of them will have some kind of behavior
that is perhaps odd, but might have been accidentally exploited by
a programmer who just whacks away at code and accepts anything that
happens to compile.

I'm still waiting for an explanation as to why this is an important
issue, other than that someone has a customer who says that it is.
Why is it important to the customer?  Why wouldn't a one-line sed
script that eliminates the issue altogether suffice?

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 25, 2005, at 8:22 PM, Andrew Pinski wrote:


Why not get other compilers to change to what GCC does?  Why does GCC
have to follow what other compilers do, maybe other compilers
would be in the best interest of following what GCC does.

Why not instead get the standard changed and then GCC will just follow
then (and really should only follow at that point)?


 I'm just a pragmatic I guess.

It is only a suggestion.  And a tiny suggestion at that.  Imho, it  
would be in gcc's best interest.  I respect the fact that you feel  
otherwise.


-Howard

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 08:22:12PM -0400, Andrew Pinski wrote:
> Why not get other compilers to change to what GCC does?  Why does GCC
> have to follow what other compilers do, maybe other compilers 
> would be in the best interest of following what GCC does.

The problem, I think, is that the behavior of both GCC *and* the
other compilers does not serve the users.

The reason is that there simply isn't any reason why a user would
use a backslash to continue a C++ comment on purpose, and plenty of
reason why she might do it by accident.

There appear to be five relevant cases; the backslash-newline (or
whitespace/backslash/newline) can be in

1) a C++ comment
2) a C comment
3) a string literal
4) a preprocessor directive
5) somewhere else.

For cases 2 and 5, the behavior doesn't matter.  For case 3, the
continuation is unlikely to be accidental, and the user is, I think,
less likely to leave a stray slash in case 4.

But case 1 is the nasty one, as users think they can put anything
in a comment.  A backslash at the end is likely to be an accident,
since just starting the next line with a // is easy enough.

So, I think that a trailing backslash at the end of a C++ comment
(followed or not by whitespace) should be warned about.  I think
Apple's customers would want this warning too, since many of them
will also be interested in compiling for other systems, and there
is a lot of gcc 3.x out there.  Best to use warnings to get rid
of the problematic code.

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-25 17:28:14 -0400, Daniel Jacobowitz wrote:
> I invite you to talk to Thomas about that one; he may well agree.
> That doesn't affect the general case.

I've just seen that it was fixed two years ago. From the ncurses
changelog:

20030719
+ use clr_eol in preference to blanks for bce terminals, so select and
  paste will have fewer trailing blanks, e.g., when using xterm
  (request by Vincent Lefevre).

Indeed I haven't had any problem with Mutt in an xterm for quite a
while, IIRC.

However, there are many problems with Mutt in an iTerm under Mac OS X:
I don't even always get newline characters. So, here, copy-paste of
C code with continuation lines would definitively lead to incorrect
behavior, whatever gcc does.

-- 
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

[Mike Stump]

On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
I don't think we should change it at all since it is one more thing  
to break old gcc code like stuff in Linux kernel.


To get concrete, how many times does \ SP SP * NL occur in old/ 
current linux kernels?

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 4:25 PM, Joe Buck wrote:

I'm having a hard time picturing source code that

 a) exhibits different behavior because of this bug, and
 b) is maintainable (remember, the behavior depends on the presence
of characters that are completely invisible to many tools).

Perhaps you could explain (without violating the customer's
confidentiality) how it is that this is an important problem?


Existing ASCII line art in documentation embedded in the source code  
as C++ style comments.

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 4:44 PM, Andrew Pinski wrote:

People depending on this is not the correct thing do any ways as
there could be another compiler besides which GCC which does this.


Let's enumerate them, what other compilers do this besides gcc?

REMINDER: CVS Server going readonly tomorrow

[Daniel Berlin]

At 12:00PM EST tomorrow, GCC CVS, excluding wwwdocs, will become
readonly.

I will announce when the new SVN repository is ready.

I will make the final commit to the cvs repository noting it has moved.
in the toplevel dir of *both* /cvs/gcc and /cvs/gcc/gcc

In the meanwhile, 1.3.0rc1 of SVN will become available at sometime in
the next hour or so at:

http://lolut.utbm.info/pub/subversion-1.3.0-rc1/

Please remember that if you break the bootstrap before it goes readonly,
people will be annoyed with you :)

I also will remove the old test repository at /svn/gcc when i start the
conversion, so do not be surprised when it disappears.

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 4:44 PM, Andrew Pinski wrote:
> > People depending on this is not the correct thing do any ways as
> > there could be another compiler besides which GCC which does this.
> 
> Let's enumerate them, what other compilers do this besides gcc?

Does that really matter?

-- Pinski

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
I personally like the fact that gcc's behavior does not depend on  
invisible characters


All other things being equal, this is a nice design goal.  I like it  
too.  Should we break peoples otherwise portable code to have an  
implementation defined behavior that no one else has?

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 4:25 PM, Joe Buck wrote:
> > I'm having a hard time picturing source code that
> >
> >  a) exhibits different behavior because of this bug, and
> >  b) is maintainable (remember, the behavior depends on the presence
> > of characters that are completely invisible to many tools).
> >
> > Perhaps you could explain (without violating the customer's
> > confidentiality) how it is that this is an important problem?
> 
> Existing ASCII line art in documentation embedded in the source code  
> as C++ style comments.

In fact the removal of the warning for comment cases was that exact case
so ...

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00603.html


http://gcc.gnu.org/ml/gcc/2002-11/msg00267.html

-- Pinski

Re: backslash whitespace newline

[David Daney]

Mike Stump wrote:

On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:

I don't think we should change it at all since it is one more thing  
to break old gcc code like stuff in Linux kernel.



To get concrete, how many times does \ SP SP * NL occur in old/ current 
linux kernels?




$ egrep -r '\\ +$' *

On my 2.6.14-rc2 tree reports no hits in any source files.

David Daney

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
> > I don't think we should change it at all since it is one more thing  
> > to break old gcc code like stuff in Linux kernel.
> 
> To get concrete, how many times does \ SP SP * NL occur in old/ 
> current linux kernels?

I was just showing where this could show up.

In fact currently there is a testcase in GCC which tests this.

Hint, hint it was not an accident that this was done.

-- Pinski

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
> > I personally like the fact that gcc's behavior does not depend on  
> > invisible characters
> 
> All other things being equal, this is a nice design goal.  I like it  
> too.  Should we break peoples otherwise portable code to have an  
> implementation defined behavior that no one else has?

but it is not portable code.  That is my point.  Instead of all
this discussion, I went and found all the times this behavior
was mentioned and found it was mentioned each year since it
was added.  I was only mentioned twice last year.

Here are the links to the previous discussion for other people's
benifit:
http://gcc.gnu.org/ml/gcc/2003-11/msg00105.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01685.html
http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00117.html
http://gcc.gnu.org/ml/gcc/2000-05/msg01032.html
http://gcc.gnu.org/ml/gcc/2001-03/msg00130.html
http://gcc.gnu.org/ml/gcc/2001-10/msg00012.html
http://gcc.gnu.org/ml/gcc/2002-02/msg01181.html
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00543.html
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg01118.html
http://gcc.gnu.org/ml/gcc/2002-11/msg00267.html
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00603.html

-- Pinski

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:

1) a C++ comment



But case 1 is the nasty one, as users think they can put anything
in a comment.  A backslash at the end is likely to be an accident,
since just starting the next line with a // is easy enough.


Be interesting to see the results of a grep on a large software  
base.  Does anyone have ready access to, say a linux distro handy?   
Of all the hits I know about, none of them were an accident.

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 6:45 PM, Andrew Pinski wrote:

Does that really matter?


gcc is free to ignore users, existing code, porting problems from  
other platforms and other C implementations, if we so choose.  I'm  
not used to writing such factors off wholesale.  I tend to think a  
balance is better weighing all the different factors.  On one hand,  
we have ascii line art in documentation, on the other hand, we have  
this esthetic beauty.  Existing, otherwise portable code against,  
confusing a user that is trying to do cut and paste programming on  
terminal emulators running curses packages that break cut-n-paste  
that can be themselves fixed, to fix not just gcc cut-n-paste  
programming, but all cut-n-pasting they might do.


Absent users, absent porting otherwise portable code, absent other  
implementations, I'd stick with the esthetics.

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 25, 2005, at 6:45 PM, Andrew Pinski wrote:
> > Does that really matter?
> 
> gcc is free to ignore users, existing code, porting problems from  
> other platforms and other C implementations, if we so choose.  I'm  
> not used to writing such factors off wholesale.  I tend to think a  
> balance is better weighing all the different factors.  On one hand,  
> we have ascii line art in documentation, on the other hand, we have  
> this esthetic beauty.  Existing, otherwise portable code against,  
> confusing a user that is trying to do cut and paste programming on  
> terminal emulators running curses packages that break cut-n-paste  
> that can be themselves fixed, to fix not just gcc cut-n-paste  
> programming, but all cut-n-pasting they might do.
> 
> Absent users, absent porting otherwise portable code, absent other  
> implementations, I'd stick with the esthetics.
> 

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 6:43 PM, Andrew Pinski wrote:
In fact the removal of the warning for comment cases was that exact  
case

so ...

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00603.html


Curious, the backslash2.c testcase is now:

/* Test warnings for backslash-space-newline.
   Source: Neil Booth. 6 Dec 2000.  */

foo \
bar
/* { dg-warning "separated by space" "" { target *-*-* } 8 } */

/* foo \
   bar */
/* { dg-bogus "separated by space" "" { target *-*-* } 12 } */

;-)

These are the cases that are uninteresting to us.

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 6:46 PM, Andrew Pinski wrote:

Hint, hint it was not an accident that this was done.


I am not unaware of the history.  What we are addressing is, if this  
was a mistake.

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 6:50 PM, Andrew Pinski wrote:

but it is not portable code.  That is my point.


I'm sorry, what word/phrase do you mean for code that compiles and  
runs on a plethora of actual C++ implementations?  Pretend I used  
that word/phrase instead.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 06:45:55PM -0700, Mike Stump wrote:
> On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
> >I personally like the fact that gcc's behavior does not depend on  
> >invisible characters
> 
> All other things being equal, this is a nice design goal.  I like it  
> too.  Should we break peoples otherwise portable code to have an  
> implementation defined behavior that no one else has?

Code that depends on invisible whitespace to function correctly is
already broken.  At some point, someone will do the equivalent of
delete-trailing-whitespace and break it.

And the code is easily cleaned up.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 07:07:08PM -0700, Mike Stump wrote:
> gcc is free to ignore users, existing code, porting problems from  
> other platforms and other C implementations, if we so choose.

You still have not demonstrated that this is a real problem.  If someone
is having a real problem, then we can offer them a simple sed script to
fix it.

Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?  Wow.  Write them a script to put a vertical
bar character at the ends of the comment lines or something.

Re: backslash whitespace newline

[Joe Buck]

On Tue, Oct 25, 2005 at 06:51:45PM -0700, Mike Stump wrote:
> On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
> >1) a C++ comment
> 
> >But case 1 is the nasty one, as users think they can put anything
> >in a comment.  A backslash at the end is likely to be an accident,
> >since just starting the next line with a // is easy enough.
> 
> Be interesting to see the results of a grep on a large software  
> base.  Does anyone have ready access to, say a linux distro handy?   
> Of all the hits I know about, none of them were an accident.

You're forgetting something: GNU/Linux distros are built with gcc,
and everyone is now using 3.x.  So there can't be buildable programs
that depend on behavior gcc doesn't support.  There can't be any
currently maintained programs for Linux or BSD that do.

Only users that have never used gcc 3.x could be depending on non-gcc
behavior.  Apple is free to do whatever, but please don't claim
that you're doing it for "portability" if you encourage your users
to write code that breaks with gcc 3.x shipped by folks other than
Apple.

Re: backslash whitespace newline

[Shantonu Sen]

You're forgetting something: GNU/Linux distros are built with  
thousands of lines of patches to support new/different gcc behavior.  
Thousands were added for the 2->3 transition, and thousands more for  
3->4. Please don't claim that all upstream programs in all  
distributions support gcc 3.4.4 and 4.0.2 without modification, and  
thus gcc is the standard by which portability is defined.


Shantonu

On Oct 25, 2005, at 9:33 PM, Joe Buck wrote:


On Tue, Oct 25, 2005 at 06:51:45PM -0700, Mike Stump wrote:

On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:

1) a C++ comment



But case 1 is the nasty one, as users think they can put anything
in a comment.  A backslash at the end is likely to be an accident,
since just starting the next line with a // is easy enough.


Be interesting to see the results of a grep on a large software
base.  Does anyone have ready access to, say a linux distro handy?
Of all the hits I know about, none of them were an accident.


You're forgetting something: GNU/Linux distros are built with gcc,
and everyone is now using 3.x.  So there can't be buildable programs
that depend on behavior gcc doesn't support.  There can't be any
currently maintained programs for Linux or BSD that do.

Only users that have never used gcc 3.x could be depending on non-gcc
behavior.  Apple is free to do whatever, but please don't claim
that you're doing it for "portability" if you encourage your users
to write code that breaks with gcc 3.x shipped by folks other than
Apple.

Re: GGC Questions

[Ranjit Mathew]

On 10/26/05, Mike Stump <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> I don't believe it is necessary.

Just to confirm that I understand you properly, it is not
necessary because that variable-length array merely
contains chars, not pointers that the GC might need
to follow. The size of the chunk would anyway be
stored in the metadata for that chunk, so the
GTY((length)) marker can't be for that.


> > 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.
>
> Set a breakpoint on creation, and one of use, either, the data
> matches, or it doesn't.  If it doesn't set a watch point on the
> changed data, and rerun.  Careful to enable the breakpoint only after
> creation, as watch doesn't like unmapped mempory (on darwin anyway).
> You can also tell GC to never collect, and thus `know' if that is the
> issue.  Also, you can breakpoint the walker/freer and check if the
> address that can't be freed is.  Doing an up from that point tells
> you the context it was in when freed.  At times, collect isn't
> allowed, and it might be one of those times.  Breaking on freer is
> easier to understand than breaking on a watch point.  ggc_free might
> be called on data that isn't totally free, just comment out the
> ggc_free call to fix.

Thanks a lot for your suggestions. I effected modify_stmt()
for the statement and called get_stmt_operands() from
within the debugger and followed the whole thing to find
out that the USEs are indeed calculated correctly. I also
disabled GC (by setting ggc-min-heapsize very high)
and found that the problem still persists.

I have a theory that the problem occurs because GCJX
is sharing the ADDR_EXPR for the Jv_ThrowBadArrayIndex
method across the CALL_EXPRs that call this method
(unlike GCJ on mainline), but I unfortunately ran out of
time before I could test this.

Thanks,
Ranjit.

--
Ranjit Mathew  Email: rmathew AT gmail DOT com

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