protect label from being optimized

[Kunal Parmar]

Hi,

I am working on porting GCC to a new RISC architecture. The ISA does not 
have a "Jump and Link Register" instruction. So I am simulating one by 
replacing

 jal [reg]
by
 load ra, Lret
 jr reg
Lret:

in RTL.
But my return label is getting optimized away. Could you please tell me 
how to avoid this.


Also, is this the correct approach.

Thanks in advance,
Kunal

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

[Denys Vlasenko]

On Thursday 17 April 2008 05:26, Brian Dessent wrote:
> Denys Vlasenko wrote:
> 
> > Only in my case, $prefix contain neither as nor ld. gcc lives in
> 
> Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
> and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
> --with-{as,ld}.

It will remember the path?
What will happen when I install binutils-2.19
into /usr/app/binutils-2.19-x86_64-linux-uclibc sometime later?

I strongly prefer gcc to use my "public" x86_64-linux-uclibc-ld,
which is accessible by just searching PATH.

By searching PATH gcc doesn't even need to know how exactly it is done -
by adding /usr/app/binutils-2.19-x86_64-linux-uclibc/bin
to PATH or by creating /usr/bin/x86_64-linux-uclibc-ld symlink.
No ad-hoc, gcc-specific searching is needed, execvp already does
that searching in a "standard", well-known way.
This wheel is already invented.

Currently, gcc insists on knowing full path to executable.
It's a policy decision. It narrows down the options.
Policy decisions are best left to humans,
while programs should just provide capabilities.

> > it's much better for sanity that way.
> 
> I would argue that it's not, since simply using the same $prefix
> JustWorks(tm) without worrying about modifying PATH or any --with-foo.

Using the same $prefix requires one to remeber which versions
of binutils+gcc+whatever are installed into same $prefix,
and God knows how exactly they will stomp on each other's
toes (files) there.

IMO, of course.
--
vda

4.3.1 Status Report (2008-04-17)

[Jakub Jelinek]

Status
==

The GCC 4.3 branch is open for commits under normal release branch
rules.

GCC 4.3.1 is due around 2008-05-05.  As soon as the P1 bugs are
fixed and we have -mcld workaround for the x86 direction flag
issue, we'll release 4.3.1-rc1.  One of the 4 P1s has approved
patch and one has been failing also in 4.1/4.2, so IMHO we could release
4.3.1 even without it being fixed.  But the remaining two,
PR35758 and PR35773, are new C++ 4.3/4.4 regressions and is something
that really should be fixed before 4.3.1.  So I'd like to draw Jason's
and Mark's attention to these.


Quality Data


Priority   #   Change from Last Report
 ---   ---
P1 4   +  3
P296   +  3
P3 9   - 13
 ---   ---
Total109   -  7

There are no known regressions on the 4.3 branch against a previous
4.3.x release.

31 of the 109 serious regressions for 4.3 are not present on the 4.2
branch.  11 of the 109 serious regressions for 4.3 are fixed for 4.4.


Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-03/msg01081.html


The next report for the 4.3 branch will be sent by Mark.

Re: Moving statements from one BB to other BB.

[Sandeep Maram]

On Tue, Apr 15, 2008 at 11:40 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> On 4/15/08 1:34 PM, Zdenek Dvorak wrote:
>
> > Hi,
> >
> >
> > >
> > > >  > To clarify what Richard means, your assertion that "you have
> updated
> > > >  > SSA information" is false.
> > > >  > If you had updated the SSA information, the error would not occur
> :).
> > > >  >
> > > >  > How exactly are you updating the ssa information?
> > > >  >
> > > >  > The general way to update SSA for this case would be:
> > > >  >
> > > >  > For each statement you have moved:
> > > >  >   Call update_stmt (t);
> > > >  >
> > > >  > Then call update_ssa (TODO_update_ssa) (or instead use
> > > >  > rewrite_into_loop_closed_ssa if this is a loop pass).
> > > >  >
> > > >  > If you do not call update_stmt in this case, update_ssa won't
> actually
> > > >  > do anything.
> > > >
> > > >  actually, it will not do anything even if he calls update_stmt, as
> the
> > > >  statements that he is moving are already in ssa form, so update_stmt
> > > >  will not mark anything for renaming.
> > > >
> > > >
> > > You are partially right (and right where it matters, that it won't fix
> > > the problem)
> > > That said, update_stmt on ssa form statements will at least reset the
> > > vuse/vdef back to original variables for renaming.
> > >
> >
> > I don't think so; as long as you do not introduce new vops (which you
> > should not by just moving the statements), update_stmt is a no-op on
> > vops too (unless something has changed since the last time I needed
> > this),
> >
>
>  Right.  Moving statements in SSA form needs to introduce name->name
> mappings (eg, as is done during loop unrolling).
>

Yes, calling update_stmt for evry transfer and then calling update_ssa
later, didn't work. From the discussions, I understood that I have to
change the SSA names in the statements to be transfered, to the
corresponding SSA names in the destination block. Can you please tell
me , whether there are any functions that manipulate the SSA names ?

Thanks,
Sandeep.

>
>  Diego.
>

Re: Moving statements from one BB to other BB.

[Sandeep Maram]

On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
>  > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>  >  > To clarify what Richard means, your assertion that "you have updated
>  >  >  SSA information" is false.
>  >  >  If you had updated the SSA information, the error would not occur :).
>  >  >
>  >  >  How exactly are you updating the ssa information?
>  >
>  >  I am calling update_ssa (TODO_update_ssa), after all the statements
>  >  are transferred.
>  >
>  >
>  >  >
>  >  >  The general way to update SSA for this case would be:
>  >  >
>  >  >  For each statement you have moved:
>  >  >   Call update_stmt (t);
>  >  >
>  >  >  Then call update_ssa (TODO_update_ssa) (or instead use
>  >  >  rewrite_into_loop_closed_ssa if this is a loop pass).
>  >  >
>  >  >  If you do not call update_stmt in this case, update_ssa won't actually
>  >  >  do anything.
>  >  >
>  >  >  Diego, the bsi iterators do not update the statements for you though
>  >  >  it is not clear if this is a bug or not.
>  >  >
>  >  >  The bsi iterators call update_modified_stmts, which says:
>  >  >
>  >  >  /* Mark statement T as modified, and update it.  */
>  >  >  static inline void
>  >  >  update_modified_stmts (tree t)
>  >  >
>  >  >  However, this only calls update_stmt_if_modified (IE it does not mark
>  >  >  the statement as modified and update it, as it claims to).
>  >  >
>  >  >  Sandeep, it should also suffice to call mark_stmt_modified *before*
>  >  >  moving the statements (since the above routine should then update
>  >  >  them).
>  >  >
>  >
>  >  Thanks. I will use update_stmt, update_ssa now.
>
>  You need to do more than that - you appearantly are moving uses of
>  SSA names to a place where its definition is not available like if you do
>
>   b_1 = 1;
>   a_1 = b_1 + 1;
>
>  and transform this to
>
>   a_1 = b_1 + 1;
>   b_1 = 1;
>
>  which obviously cannot work.  So "updating" SSA form won't help you
>  and renaming the symbols will only make the verifier happy and leave
>  you with wrong code.
>
>  So you need to investigate what exactly you are doing wrong with
>  your stmt movement.

I am considering two consequent fusible loops. These loops have a
single header and a single latch.  I want to move the statements in
the header of the second loop to the header of the first loop. This
function will be called only after certain constraints are met. That
is legality test is performed before fusing these loops.

I think I am transfering all the statements inside the loop correctly.
But I am doing some mistake with the "iterator variable".

Thanks,
Sandeep.

>
>  Richard.
>

Re: Moving statements from one BB to other BB.

[Richard Guenther]

On Thu, Apr 17, 2008 at 1:35 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther
>  <[EMAIL PROTECTED]> wrote:
>  >
>  > On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
>  >  > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> 
> wrote:
>  >  >  > To clarify what Richard means, your assertion that "you have updated
>  >  >  >  SSA information" is false.
>  >  >  >  If you had updated the SSA information, the error would not occur 
> :).
>  >  >  >
>  >  >  >  How exactly are you updating the ssa information?
>  >  >
>  >  >  I am calling update_ssa (TODO_update_ssa), after all the statements
>  >  >  are transferred.
>  >  >
>  >  >
>  >  >  >
>  >  >  >  The general way to update SSA for this case would be:
>  >  >  >
>  >  >  >  For each statement you have moved:
>  >  >  >   Call update_stmt (t);
>  >  >  >
>  >  >  >  Then call update_ssa (TODO_update_ssa) (or instead use
>  >  >  >  rewrite_into_loop_closed_ssa if this is a loop pass).
>  >  >  >
>  >  >  >  If you do not call update_stmt in this case, update_ssa won't 
> actually
>  >  >  >  do anything.
>  >  >  >
>  >  >  >  Diego, the bsi iterators do not update the statements for you though
>  >  >  >  it is not clear if this is a bug or not.
>  >  >  >
>  >  >  >  The bsi iterators call update_modified_stmts, which says:
>  >  >  >
>  >  >  >  /* Mark statement T as modified, and update it.  */
>  >  >  >  static inline void
>  >  >  >  update_modified_stmts (tree t)
>  >  >  >
>  >  >  >  However, this only calls update_stmt_if_modified (IE it does not 
> mark
>  >  >  >  the statement as modified and update it, as it claims to).
>  >  >  >
>  >  >  >  Sandeep, it should also suffice to call mark_stmt_modified *before*
>  >  >  >  moving the statements (since the above routine should then update
>  >  >  >  them).
>  >  >  >
>  >  >
>  >  >  Thanks. I will use update_stmt, update_ssa now.
>  >
>  >  You need to do more than that - you appearantly are moving uses of
>  >  SSA names to a place where its definition is not available like if you do
>  >
>  >   b_1 = 1;
>  >   a_1 = b_1 + 1;
>  >
>  >  and transform this to
>  >
>  >   a_1 = b_1 + 1;
>  >   b_1 = 1;
>  >
>  >  which obviously cannot work.  So "updating" SSA form won't help you
>  >  and renaming the symbols will only make the verifier happy and leave
>  >  you with wrong code.
>  >
>  >  So you need to investigate what exactly you are doing wrong with
>  >  your stmt movement.
>
>  I am considering two consequent fusible loops. These loops have a
>  single header and a single latch.  I want to move the statements in
>  the header of the second loop to the header of the first loop. This
>  function will be called only after certain constraints are met. That
>  is legality test is performed before fusing these loops.
>
>  I think I am transfering all the statements inside the loop correctly.
>  But I am doing some mistake with the "iterator variable".

Well, we cannot do mind-reading here to figure out what exactly you
do wrong.  Please have a look at the tree-dumps before and after
your transformation (-fdump-tree-all-vops), this should obviously
explain what is going wrong.  I suppose you simply forgot about
PHI nodes.

Richard.

Re: Moving statements from one BB to other BB.

[Sandeep Maram]

On Thu, Apr 17, 2008 at 5:20 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 17, 2008 at 1:35 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
>  >
>  > On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther
>  >  <[EMAIL PROTECTED]> wrote:
>  >  >
>  >  > On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> 
> wrote:
>  >  >  > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> 
> wrote:
>  >  >  >  > To clarify what Richard means, your assertion that "you have 
> updated
>  >  >  >  >  SSA information" is false.
>  >  >  >  >  If you had updated the SSA information, the error would not 
> occur :).
>  >  >  >  >
>  >  >  >  >  How exactly are you updating the ssa information?
>  >  >  >
>  >  >  >  I am calling update_ssa (TODO_update_ssa), after all the statements
>  >  >  >  are transferred.
>  >  >  >
>  >  >  >
>  >  >  >  >
>  >  >  >  >  The general way to update SSA for this case would be:
>  >  >  >  >
>  >  >  >  >  For each statement you have moved:
>  >  >  >  >   Call update_stmt (t);
>  >  >  >  >
>  >  >  >  >  Then call update_ssa (TODO_update_ssa) (or instead use
>  >  >  >  >  rewrite_into_loop_closed_ssa if this is a loop pass).
>  >  >  >  >
>  >  >  >  >  If you do not call update_stmt in this case, update_ssa won't 
> actually
>  >  >  >  >  do anything.
>  >  >  >  >
>  >  >  >  >  Diego, the bsi iterators do not update the statements for you 
> though
>  >  >  >  >  it is not clear if this is a bug or not.
>  >  >  >  >
>  >  >  >  >  The bsi iterators call update_modified_stmts, which says:
>  >  >  >  >
>  >  >  >  >  /* Mark statement T as modified, and update it.  */
>  >  >  >  >  static inline void
>  >  >  >  >  update_modified_stmts (tree t)
>  >  >  >  >
>  >  >  >  >  However, this only calls update_stmt_if_modified (IE it does not 
> mark
>  >  >  >  >  the statement as modified and update it, as it claims to).
>  >  >  >  >
>  >  >  >  >  Sandeep, it should also suffice to call mark_stmt_modified 
> *before*
>  >  >  >  >  moving the statements (since the above routine should then update
>  >  >  >  >  them).
>  >  >  >  >
>  >  >  >
>  >  >  >  Thanks. I will use update_stmt, update_ssa now.
>  >  >
>  >  >  You need to do more than that - you appearantly are moving uses of
>  >  >  SSA names to a place where its definition is not available like if you 
> do
>  >  >
>  >  >   b_1 = 1;
>  >  >   a_1 = b_1 + 1;
>  >  >
>  >  >  and transform this to
>  >  >
>  >  >   a_1 = b_1 + 1;
>  >  >   b_1 = 1;
>  >  >
>  >  >  which obviously cannot work.  So "updating" SSA form won't help you
>  >  >  and renaming the symbols will only make the verifier happy and leave
>  >  >  you with wrong code.
>  >  >
>  >  >  So you need to investigate what exactly you are doing wrong with
>  >  >  your stmt movement.
>  >
>  >  I am considering two consequent fusible loops. These loops have a
>  >  single header and a single latch.  I want to move the statements in
>  >  the header of the second loop to the header of the first loop. This
>  >  function will be called only after certain constraints are met. That
>  >  is legality test is performed before fusing these loops.
>  >
>  >  I think I am transfering all the statements inside the loop correctly.
>  >  But I am doing some mistake with the "iterator variable".
>
>  Well, we cannot do mind-reading here to figure out what exactly you
>  do wrong.  Please have a look at the tree-dumps before and after
>  your transformation (-fdump-tree-all-vops), this should obviously
>  explain what is going wrong.  I suppose you simply forgot about
>  PHI nodes.

Thank you.

Regards,
Sandeep.
>
>  Richard.
>

Uncessary long long produced in tree-ssa?

[Bingfeng Mei]

Hello,
I noticed in some cases GCC 4.3.0 produces unnecessary long long data
type in tree ssa form. It results in inefficient 64-bit arithmetic in
our porting. 

Original C code

void main(int *a, int *b, int *c, int j){
  int i;
  for(i = 0; i <= 4; i++){
int tx = j  + i;
a[i] = b[tx] + c[i];
  }
}  

.final_cleanup

;; Function main (main)

main (a, b, c, j)
{
  long unsigned int D.1759;
  long long unsigned int ivtmp.19;

:
  ivtmp.19 = 0;

:
  D.1759 = (long unsigned int) ivtmp.19 * 4;
  MEM[base: a, index: D.1759] = MEM[base: c, index: D.1759] + MEM[base:
b + (long unsigned int) j * 4, index: D.1759];
  ivtmp.19 = ivtmp.19 + 1;
  if (ivtmp.19 != 5)
goto ;
  else
goto ;

:
  return;

}

Is it necessary to use "long long unsigned" ivtmp.19 here?  It would
require 64-bit addition in the loop. 


Cheers,
Bingfeng Mei
Broadcom UK 

Re: Some questions about writing a front end

[Ian Lance Taylor]

Tim Josling <[EMAIL PROTECTED]> writes:

> 2. Most-Gimplified front-end: Allied to Q1, which front ends have been
> most thoroughly converted to GIMPLE?

They've all been converted to generate GENERIC, or they wouldn't work.


> 3. LANG_HOOKS: There has been some discussion about LANG_HOOKS being
> removed in the future. From memory this was in the context of the
> "optimization in the linker (LTI)" projects. Is there a replacement I
> should use now, or is there anything I should do to prepare for the
> replacement?

There is no replacement.  The idea is to extend GENERIC/GIMPLE
sufficiently that lang hooks are not needed.


> 4. What does Gimple cover: What is the scope of GIMPLE? Most of the
> discussion is about procedural code. Does it also cover variable
> definition, function prototype definition etc.

GIMPLE is about procedural code.  Variable definitions are done using
essentially the same data structures, though.


> 5. What is deprecated: Is there any time-effective way to identify
> constructs, header files, macros, variable and functions that are
> "deprecated".

Not really.  We try not to leave deprecated stuff around for too long.


> 6. Tuples: I am a bit confused about tuples. Tuples seem to be really
> just structs by another name, unless I have missed the point. The idea
> is not a bad one - I went through the same process in the Lisp code in
> the front end where initially I stored everything in arrays and later
> switched to structs/tuples. In lisp this provided the advantages of
> run-time type-checking and the ability to use mnemonic names. 
>
> The first email about tuples that I can find seems to assume a
> reasonable amount of background on the part of the reader:
> http://www.mailinglistarchive.com/gcc@gcc.gnu.org/msg01669.html
>
> Some clarification about what the tuples project is trying to do, and in
> particular how I should position for the advent of tuples would be very
> useful. I have read the material in the Wiki and from the GCC summit.

Tuples is a reworking of the internal data structures.  They shouldn't
matter for a frontend, as they are generated during the gimplification
process.


> 7. Should I target GENERIC, High Gimple or Low Gimple? Would I miss
> optimizations if I went straight to a Gimple representation? Is one
> interface more likely to change radically in the future? The assumption
> here is that the front end will be using an entirely different
> representation so there is no question of using one of these in the
> Front End. It is just a question of which format to convert into.

You should normally target GENERIC, and pass it to the gimplifier.
That's the defined interface.  Really GENERIC and GIMPLE are not so
different--you can essentially generate GIMPLE if you like, but you
should still pass it to the gimplifier.

Ian

Re: protect label from being optimized

[Ian Lance Taylor]

Kunal Parmar <[EMAIL PROTECTED]> writes:

> I am working on porting GCC to a new RISC architecture. The ISA does
> not have a "Jump and Link Register" instruction. So I am simulating
> one by replacing
>  jal [reg]
> by
>  load ra, Lret
>  jr reg
> Lret:
>
> in RTL.
> But my return label is getting optimized away. Could you please tell
> me how to avoid this.

Make sure the load label instruction is using a LABEL_REF.  Look at
sh.md for various examples.

Ian

Re: Uncessary long long produced in tree-ssa?

[Ian Lance Taylor]

"Bingfeng Mei" <[EMAIL PROTECTED]> writes:

> I noticed in some cases GCC 4.3.0 produces unnecessary long long data
> type in tree ssa form. It results in inefficient 64-bit arithmetic in
> our porting. 

You neglected to mention the target.  I assume that pointers are
64-bits.  Otherwise this behaviour is inexplicable.  With 64-bit
pointers, you need 64-bit arithmetic.  gcc thinks it is being clever
by using an induction variable of the right type, rather than sign
extending the variable in the middle of the loop.  That may be the
wrong choice for your target.  In general gcc is not well optimized
for cases where pointers are larger than the ordinary register size.

If pointers are not 64-bits, then I have no idea what is going on.

Ian

Re: Some questions about writing a front end

[Tom Tromey]

> "Tim" == Tim Josling <[EMAIL PROTECTED]> writes:

Tim> 1. Sample front-end: Given treelang no longer exists and "is not a good
Tim> example anyway" what would be the best front end to use as a model and
Tim> to plagiarize code?

Tim> What I don't know is how up-to-date the various front ends are and how
Tim> good an example they are.

I'm not familiar with all the front ends.  But, I'd say don't copy gcj
(it doesn't do anything very bad AFAIK, but it is also not very
well-organized) or the C family (those are the oldest and most
tree-enmeshed FEs).

When I was writing my front end I just did a lot of grepping through
all the FEs to augment what I learned from reading tree.def and tree.h
(and cgraph.c and varpool.c and ... bleah).  That isn't awesome, but
it isn't terrible either.  Now I wish I'd taken notes and updated
tree.def with the odd things I discovered.  GCC would benefit if you
did that...

Tim> 2. Most-Gimplified front-end: Allied to Q1, which front ends have
Tim> been most thoroughly converted to GIMPLE?
[...]

IMO: don't worry much about gimple, lang hooks, or tuples.  Instead,
just make trees, following GENERIC.  Though, since I don't think
GENERIC is extremely well-defined, that means reading tree.def and the
like.  Going this route will give you one view of procedural code,
types, declarations, etc.

Tim> 5. What is deprecated: Is there any time-effective way to identify
Tim> constructs, header files, macros, variable and functions that are
Tim> "deprecated".

Like Ian said, things that are truly deprecated tend to be removed.
Sometimes this deletion is accompanied by a poisoning in system.h, at
least in cases where a merge might potentially do the wrong thing.

A couple useful rules of thumb.  First, don't add your own tree codes.
You won't need them, at least not from what I understand of your
overall design.  Second, don't add new lang hooks, either.

Tom

list::merge and GLIBCXX_DEBUG

[David Greene]

I hit something in GLIBCXX_DEBUG mode the other day and I
want to ask about it.

Do list iterators remain valid after splice and merge operations?

The code is below.  Is this a valid program?  If not, what assumptions
am I violating?

  -Dave

#include 
#include 

int main(void)
{
  std::list list1;
  std::list list2;

  for(int i = 0; i < 10; ++i) {
list1.push_back(i);
list2.push_back(10-i);
  }

  list1.sort();
  list2.sort();

  std::list::iterator node_of_interest = list2.begin();

  // Ok, preserves iterator and updates iterator owner in
  // GLIBCXX_DEBUG mode
  list1.splice(list1.begin(), list2, node_of_interest);
  // Ok, preserves iterator and updates iterator owner in
  // GLIBCXX_DEBUG mode
  list2.splice(list2.begin(), list1, node_of_interest);

  // Oops, does not appear to update iterator owner in GLIBCXX_DEBUG
  // mode
  list1.merge(list2, std::less());

  // Triggers GLIBCXX_DEBUG error: "attempt to splice an iterator from
  // a different container."  Is node_of_interest still a valid
  // iterator according to the standard?
  list2.splice(list2.begin(), list1, node_of_interest);

  std::cout << "list1:\n";
  for(std::list::iterator i = list1.begin();
  i != list1.end();
  ++i) {
std::cout << *i << "\n";
  }

  std::cout << "list2:\n";
  for(std::list::iterator i = list2.begin();
  i != list2.end();
  ++i) {
std::cout << *i << "\n";
  }

  return 0;
}

gcc-4.3-20080417 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 134414

You'll find:

gcc-4.3-20080417.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080417.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080417.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080417.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080417.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080417.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080417.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080417.tar.bz2The GCC testsuite

Diffs from 4.3-20080410 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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: protect label from being optimized

[Kunal Parmar]

Hi,

>> I am working on porting GCC to a new RISC architecture. The ISA does
>> not have a "Jump and Link Register" instruction. So I am simulating
>> one by replacing
>>  jal [reg]
>> by
>>  load ra, Lret
>>  jr reg
>> Lret:
>>
>> in RTL.
>> But my return label is getting optimized away. Could you please tell
>> me how to avoid this.
>
>Make sure the load label instruction is using a LABEL_REF.  Look at
> sh.md for various examples.

Is this correct :
   ret_label = gen_label_rtx ();
   emit_move_insn (gen_rtx_REG (HImode, 7),
   gen_rtx_LABEL_REF (VOIDmode, 
ret_label));

   emit_call_insn (gen_brc_call_simulate (addr, args_size));
   emit_label (ret_label);

Cheers,
Kunal

Re: RFC: named address space support

[Ben Elliston]

Hi Joseph

> > .. the embedded C proposal as of 2008-01-18 is at stage 90.92.  This
> > suggests that it's very close to being incorporated into the standard.
> > Have I understood that correctly?
> 
> No.  All it means is that TR 18037 is being revised, not anything to do 
> with the standard.  This is a TR Type 2, not an IS, and remains a TR Type 
> 2, not an IS.  [snip]

Thanks for the run-down on the standards process; very helpful!

> A TR Type 2 may be considered as indicating "if you want a feature to
> do this, it may be a good idea to do it this way and so gain
> implementation experience for future standardization".  As such, I
> think it is reasonable 
> to continue to add features from such TRs to GCC, provided we
> understand that they are experimental and may be changed incompatibly
> in future to accord with future TR versions or changes in the course
> of inclusion in the IS; that unlike actual language standards, we will
> not try to provide 
> options to support different versions of a TR in the same compiler
> version.  (The same applies to informative annexes in an IS, which may
> have the same sort of content as a Type 2 TR, such as Annex G in C99.)

This (in addition to Mark's comments) sounds perfectly acceptable to me.
We want the implementation to be standards compliant; if the standard
one day changes the details, we will have to change to be compliant.
Until then, the support should have a big neon sign over it that says
"experimental".

Cheers, Ben

[tuples] New requirement for new patches

[Diego Novillo]

Please notice that the wiki page for tuples has new rules for patches. 
From now on, every patch needs to have been tested with a C-only bootstrap.



Thanks.  Diego.

[tuples] Branch status and merge scenarios

[Diego Novillo]

The tuples branch was scheduled to merge last during stage 1 (21/Apr).
At this point, it will be impossible for the branch to be ready for that
date.  The current status is (http://gcc.gnu.org/wiki/tuples):

- The C front end is bootstrapping.  The failure rate in the testsuites
  is in the 2-4% range.

- We are close (~3 weeks) to having the C++ and Fortran FEs
  bootstrapping.

- A good number of passes have been converted (55%) or are in the
  process of being converted (70%).  The conversion process is usually
  a matter of 1-2 days.  The passes that I expect may be problematic
  are PRE and FRE, but not overly so.

- Two big items left to convert are mudflap and OpenMP (which Aldy is
  finishing up).

- We continuously test the branch on ppc, x86 and x86_64.  Backend
  conversion is usually a matter of a few hours.

The biggest constraints we have for tuples is that we absolutely must go
last in the merging order.  Going first would be convenient for us, but
it would mess everyone up (particularly things like the openmp3 branch).

Although it's not crucial for tuples to go in GCC 4.4, we would prefer
not to carry all this baggage around for LTO.

At the rate that we are currently progressing, I estimate that it will
take us around 5-7 more weeks to finish all the conversion.

So, I see a couple different scenarios that we may want to consider:

1- Push back and tell us to come back at the next stage 1.  This is
   certainly the easiest for everyone else, and will create a few
   challenges for us on the LTO branch.

2- Once bootstrap is working for the major languages and targets, merge
   and finish fixing remaining passes during stage 2.  Pass conversion
   is highly mechanical, so I don't consider it risky for stage 2
   stabilization.  We will be at this point in the 5-7 weeks I mentioned
   earlier.

Merge metrics: the branch has one main goal: strict API and data
structure separation between GENERIC and GIMPLE.  We achieved this at
the statement level, though operands are still represented as trees.
The new API is reportedly cleaner and we think this will make things
easier for LTO and pass writing in general.

A secondary goal was to provide a more space-efficient data structure
for representing statements.  The idea is to provide a better foundation
for GIMPLE streaming in LTO.  I don't think we will see huge savings in
terms of memory utilization (the projections were in the high single
digit), because statements are not actually a big part of the IL
(symbols, pools and debug info are pretty big).  We still need to do
measurements here, but they are a bit hard to perform now.

I am content if the memory utilization remains the same and I will be
very surprised if it goes up (modulo bugs or implementation
boneheadedness, which should be easy to fix).

A third risk that we need to analyze are the delays that other branches
will present (they need to be converted too).

Does any one see other risks and/or scenarios we could consider for the 
branch?



Thanks.  Diego.

Re: [tuples] New requirement for new patches

[Tim Josling]

> - The C front end is bootstrapping.  The failure rate in the
testsuites is in the 2-4% range.

I've been trying to do a C-only bootstrap of the tuples branch for a
couple of days  on "Linux tim-gcc 2.6.20-15-generic #2 SMP Sun Apr 15
06:17:24 UTC 2007 x86_64 GNU/Linux" and I get

/../libdecnumber
-I/home2/gcc-gimple-tuples-branch/gcc/gcc/../libdecnumber/bid
-I../libdecnumber  /home2/gcc-gimple-tuples-branch/gcc/gcc/tree-optimize.c -o 
tree-optimize.o
/home2/gcc-gimple-tuples-branch/gcc/gcc/tree-data-ref.c: In function
'compute_all_dependences':
/home2/gcc-gimple-tuples-branch/gcc/gcc/tree-data-ref.c:3930: internal
compiler error: in avail_expr_eq, at tree-ssa-dom.c:2482
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [tree-data-ref.o] Error 1
make[3]: *** Waiting for unfinished jobs

Also this one is looping at the time the other one crashes. From ps aux|
grep cc1:

tim   4500 71.9  1.6  82840 67128 pts/0RN+  11:08
3:02 /home2/gcc-gimple-tuples-branch/objdir/./prev-gcc/cc1 -quiet -I.
-I. -I/home2/gcc-gimple-tuples-branch/gcc/gcc
-I/home2/gcc-gimple-tuples-branch/gcc/gcc/.
-I/home2/gcc-gimple-tuples-branch/gcc/gcc/../include
-I/home2/gcc-gimple-tuples-branch/gcc/gcc/../libcpp/include
-I/usr/local/include
-I/home2/gcc-gimple-tuples-branch/gcc/gcc/../libdecnumber
-I/home2/gcc-gimple-tuples-branch/gcc/gcc/../libdecnumber/bid
-I../libdecnumber
-iprefix 
/home2/gcc-gimple-tuples-branch/objdir/prev-gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/
 -isystem /home2/gcc-gimple-tuples-branch/objdir/./prev-gcc/include -isystem 
/home2/gcc-gimple-tuples-branch/objdir/./prev-gcc/include-fixed -DIN_GCC 
-DHAVE_CONFIG_H insn-attrtab.c -quiet -dumpbase insn-attrtab.c -mtune=generic 
-auxbase-strip insn-attrtab.o -g -O2 -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-Wno-return-type -Wno-format -Wno-missing-format-attribute -o /tmp/ccHig7nY.s

Tim Josling

On Thu, 2008-04-17 at 17:19 -0700, Diego Novillo wrote:
> Please notice that the wiki page for tuples has new rules for patches. 
>  From now on, every patch needs to have been tested with a C-only bootstrap.
> 
> 
> Thanks.  Diego.

Re: Gomp cell,...

[Sebastian Pop]

On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>  Huh???  Spu support is in gcc 4.3.0.
>

Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
Cell?  Is there an efficient port of libGOMP for Cell?  I assume that
the linux port could be used for Cell, but how good is this for Cell?
In particular you're going to be able to use only the PPU, with the
current linux port of libGOMP on Cell, isn't it?

Sebastian

Re: Gomp cell,...

[Andrew Pinski]

On Thu, Apr 17, 2008 at 8:25 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>  >  Huh???  Spu support is in gcc 4.3.0.
>  >
>
>  Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
>  Cell?  Is there an efficient port of libGOMP for Cell?  I assume that
>  the linux port could be used for Cell, but how good is this for Cell?
>  In particular you're going to be able to use only the PPU, with the
>  current linux port of libGOMP on Cell, isn't it?

Correct.  I was just trying to correct the idea that spu support was
not committed to the FSF GCC.  Considering I am a maintainer of it
too, I don't want people to get the wrong thought there.

Thanks,
Andrew Pinski

Re: Gomp cell,...

[Sebastian Pop]

On Thu, Apr 17, 2008 at 10:36 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>  Correct.  I was just trying to correct the idea that spu support was
>  not committed to the FSF GCC.  Considering I am a maintainer of it
>  too, I don't want people to get the wrong thought there.
>

Ok, I got an email from Ogier (as he's also a student at University of
Strasbourg where I've been for quite some time, etc...) who asked for
directions on how to implement an efficient OpenMP support for Cell.

The main difficulty is the outlining to SPUs code, that has to be
generated by another backend.  Do you have ideas on how that should be
implemented?

Ogier proposed to dump the outlined gimple to a file (i.e. LTO could
do that) and then read this back in the SPU compiler.  Does this
approach sound right?

Thanks,
Sebastian

Re: protect label from being optimized

[Ian Lance Taylor]

Kunal Parmar <[EMAIL PROTECTED]> writes:

> Is this correct :
>ret_label = gen_label_rtx ();
>emit_move_insn (gen_rtx_REG (HImode, 7),
>gen_rtx_LABEL_REF (VOIDmode,
> ret_label));
>emit_call_insn (gen_brc_call_simulate (addr, args_size));
>emit_label (ret_label);

It looks plausible.

Ian

Re: Gomp cell,...

[Andrew Pinski]

On Thu, Apr 17, 2008 at 8:47 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
>  Ogier proposed to dump the outlined gimple to a file (i.e. LTO could
>  do that) and then read this back in the SPU compiler.  Does this
>  approach sound right?

Yes, this was my idea also which is why I was waiting for LTO to be finished.

Thanks,
Andrew Pinski