GCC 4.3.4 Released

[Richard Guenther]

The GNU Compiler Collection version 4.3.4 has been released.

GCC 4.3.4 is a bug-fix release containing fixes for regressions and
serious bugs in GCC 4.3.3.  This release is available from the
FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments about
this release.  Instead, use the resources available from 
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: [lambda] Segmentation fault in simple lambda program

[Adam Butcher]

Adam Butcher wrote:
>John Freeman wrote:
>>
>> I just inspected my code again.  The call to layout_class_type at the
>> beginning of finish_lambda_function_body at semantics.c:5241 was
>> intended to recalculate offsets to members in the case of default captures.
>>
>> Here is the complete order of the pertinent function calls (file
>> location has nothing to do with call order; I supply them to help the
>> reader to follow):
>>
>> finish_struct @ parser.c:6985
>>
>> cp_parser_lambda_body @ parser.c:6992
>> --> finish_lambda_function_body @ parser.c:7380
>> > layout_class_type @ semantics.c:5241
>>
>> finish_struct_1 @  I don't see this added yet.  I've checked out
>> revision 150396.
>>
>I think Jason's waiting for the formality of copyright assignment to be 
>finalized.   I attached my patches against the
>latest lambda branch head in the following mail if you want to try them out:
>  http://gcc.gnu.org/ml/gcc/2009-08/msg00058.html
>
I see you've committed the fix.  Great.  Much better to do the relayout in 
semantics.c where the previous layout stuff
was than in the parser.  I take you're point on it potentially being overkill 
but at least it means that user programs
that copy can work.

I guess this thread is done with now that the fix has been committed.  I should 
start another to discuss polymorphic
lambda experimentation and implicit template parameters.  BTW I have got the 
latter working now -- to a certain (read
limited and buggy) extent.

The 'implicit template parameter via auto' addition is literally a quick hack 
for me to investigate what functionally
needs to occur to achieve it -- the implementation is not pleasant by any means 
as yet.

I've attached my two diffs made against the latest lambda head.  First is 
explicit polymorphic lambda support via the
additional template parameter syntax, second is the very hacky 
'for-discovery-purposes-only' prototype for typename
inference.  The examples below demonstrate the supported syntaxes.

  1.  []  (T const& t, U u) { return t + u; }
  2.  [] (auto const& t, auto u) { return t + u; }
  3.  []  (T const& t, auto u) { return t + u; }

Currently for auto typename inference, cv-qualifiers (and other bits like 
attributes) are lost but I'll come to that
when I rewrite it all in light of what I have found out.  Just thought I'd 
share this functional-approximation to a
solution.  As a result of the aforementioned bug, although 1. and 3. produce 
effectively the same code, 2. ends up
being equivalent to:

  []  (__AutoT1& t, __AutoT2 u) { 
return t + u; }

rather than the expected:

  []  (__AutoT1 const& t, __AutoT2 u) 
{ return t + u; }

There's a number of things I'm not sure about regarding location of the 
implementation (parser.c, semantics.c, decl.c
etc).

One thing I'm worried about is that I'm using make_tree_vec() with a length one 
greater than that of the previous
vector in order to grow the template parameter list whilst parsing function 
arguments.  This seems inefficient and
ugly.  Not least as there seems to be no way to ditch the old tree-vec.  I can 
ggc_free it but that won't do any
housekeeping of the tree counts and sizes.  It looks like tree-vecs are only 
supposed to be alloc'd into the pool
(zone?) and never removed.  In this case, incrementally adding additional 
parameters, you get allocs like:

  [--tree-vec-1--]
  [--tree-vec-1--] [-+-tree-vec-2-+-]
  [--tree-vec-1--] [-+-tree-vec-2-+-] [-++-tree-vec-3-++-]

And all you want is the last one.  I appreciate that its probably done this way 
to avoiding full fragmentation
management but I'd expect this sort of thing may happen often (or maybe it 
shouldn't!).  Off the top of my head, one
solution would be to add tree_vec_resize() which would realloc the memory and 
update the counts/sizes iff the tree-vec
were the last in the list.  The fallback behaviour if it weren't the last would 
be to do the previous manual
make_tree_vec() behaviour.  Something like:

   [--tv1--]

tv1 = tree_vec_resize (tv1, TREE_VEC_LENGTH (tv1) + 1);

   [-+-tv1-+-]

tv1 = tree_vec_resize (tv1, TREE_VEC_LENGTH (tv1) + 1);

   [-++-tv1-++-]

tv2 = make_tree_vec (n)

   [-++-tv1-++-] [--tv2--]

tv1 = tree_vec_resize (tv1, TREE_VEC_LENGTH (tv1) + 1);

   [-++-tv1-++-] [--tv2--] [-+++-tv1-+++-]
   ^   ^
   | no longer |
   | referenced|

This seems to work optimally in the case of incremental addition to the last 
tree-vec -- you are left with the minimum
tree-vecs necessary to avoid full fragmentation handling, and it degrades to 
supports the effect of the manual method
of calling make_tree_vec (old_size + n).

Maybe a doubling size on realloc and starting at, say, 4 elements could make 
realloc'ing more efficient -- but it
would require different 'end' and length handling for tree-vec which may 
pervade the code-base (though the macro
front-ends may be able to hide this).

Maybe I've misunderstood tree-vecs and the garbage collection mechanics 
completely and its simply not a

Re: support new-style profiling in the Linux kernel for ARM

[Uwe Kleine-König]

Hello,

I'm going to make use of the new ABI for profiling in gcc 4.4 on ARM.

The patch posted on the linux-arm-kernel ML


http://news.gmane.org/find-root.php?group=gmane.linux.ports.arm.kernel&article=63642

seems to work, but I'd like to have an OK from the gcc people that
globbering ip is OK.

The patch is similar to the glibc patch at

http://sourceware.org/ml/libc-ports/2008-04/msg9.html

.  There ip is globbered, too.

It would be great if someone could have a look and review my change.

Best regards and thanks in advance
Uwe

-- 
Pengutronix e.K.  | Uwe Kleine-König|
Industrial Linux Solutions| http://www.pengutronix.de/  |

Re: [lambda] Segmentation fault in simple lambda program

[John Freeman]

On Thu, Aug 6, 2009 at 6:27 AM, Adam Butcher > wrote:


   I take you're point on [finish_struct_1] potentially being overkill
   but at least it means that user programs
   that copy can work.


Right.  I only added that comment so that other developers who come 
along and want to optimize it won't fall into the same trap I did.



   I've attached my two diffs made against the latest lambda head.
First is explicit polymorphic lambda support via the
   additional template parameter syntax, second is the very hacky
   'for-discovery-purposes-only' prototype for typename
   inference.


I was hesitant to add the first patch alone, but now that you've got the 
second, I'm eager to take another look. 



   Currently for auto typename inference, cv-qualifiers (and other bits
   like attributes) are lost

   One thing I'm worried about is that I'm using make_tree_vec() with a
   length one greater than that of the previous
   vector in order to grow the template parameter list whilst parsing
   function arguments.


I'll be sure to look at these issues.


   There's a number of things I'm not sure about regarding location of
   the implementation (parser.c, semantics.c, decl.c
   etc).


The general guideline I followed was to put as much non-parsing logic 
into semantics.c as possible, and call into it from parser.c when 
needed.  I'm not sure what needs to go into decl.c either.



I will try to take this opportunity of renewed interest in the lambdas 
branch to look at dependent type support and name mangling.  When I say 
dependent type support, I mean using lambdas that capture or declare 
variables of dependent type from a surrounding template context.  Many 
people won't be able to effectively use lambdas until these features are 
added.


- John

Re: Preparing to merge ARM/hard_vfp_branch to trunk

[Joseph S. Myers]

On Wed, 5 Aug 2009, Richard Earnshaw wrote:

> I think we are now in the position where we can merge the arm hard-vfp
> ABI code into trunk.  There are no known issues with the compiler code
> and just one outstanding issue relating to tests and dealing with
> compiler variants (multilibs and other options).  That issue shouldn't
> prevent merging.

I've remembered two outstanding issues from 
:

* The pcs attribute needs documentation and testcases.

* The attribute warning using %qs should now use %qE.

-- 
Joseph S. Myers
jos...@codesourcery.com

GCC 3.3.6 source bugs (can't compile it with gcc 4.1.2)

[Dmitry Samersoff]

1. fixincl script uses $SHELL variable and assume it points to sh 
derived shell, therefor it doesn't work with tcsh.


Have to be changed to explicit /bin/sh

2. Conflict type declaration in com.c

shine:gcc-3.3.6#diff -u ./gcc/f/com.c_orig ./gcc/f/com.c
--- ./gcc/f/com.c_orig  2009-08-06 17:52:05.111996368 +0400
+++ ./gcc/f/com.c   2009-08-06 17:52:24.331939097 +0400
@@ -11075,7 +11075,7 @@
   return decl;
 }

-ffeinfoBasictype
+ffeinfoKindtype
 ffecom_gfrt_basictype (ffecomGfrt gfrt)
 {
   assert (gfrt < FFECOM_gfrt);



--
Dmitry Samersoff
d...@samersoff.net, http://devnull.samersoff.net
* There will come soft rains ...

Re: GCC 3.3.6 source bugs (can't compile it with gcc 4.1.2)

[Diego Novillo]

On Thu, Aug 6, 2009 at 10:20, Dmitry Samersoff wrote:

> shine:gcc-3.3.6#diff -u ./gcc/f/com.c_orig ./gcc/f/com.c

The 3.x series are no longer maintained.  You will need to maintain
your own repository for these changes.

Contributions to GCC are always welcome, please refer to
http://gcc.gnu.org/contribute.html for guidelines.


Thanks.  Diego.

Re: Preparing to merge ARM/hard_vfp_branch to trunk

[Richard Earnshaw]

On Wed, 2009-08-05 at 14:20 +0100, Richard Earnshaw wrote:
> I think we are now in the position where we can merge the arm hard-vfp
> ABI code into trunk.  There are no known issues with the compiler code
> and just one outstanding issue relating to tests and dealing with
> compiler variants (multilibs and other options).  That issue shouldn't
> prevent merging.
> 
> All the patches to non-arm code bar one have already received approval
> for mainline integration.  The outstanding issue is a change to the
> SPARC back-end to account for a change to the LIBCALL_VALUE macro.
> 
> I believe that I could legitimately approve that patch myself (it's
> pretty trivial and I didn't author it), but I'd prefer to get approval
> from one of the SPARC maintainers.  Here's your chance:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html
> 
> Once that issue is taken care of, I don't think there are any further
> obstacles to completing the merge and propose to do that sometime over
> the next week.
> 
> Comments/objections please?
> 
> R.

I've now completed the merge.  A couple of late issues that Joseph has
just reminded me of will now be fixed on the trunk.

R.

Notes toward re-implementing EH in gimple

[Richard Henderson]

I've also been thinking a good deal about a grand EH reorg; I'll try
to post something for you to comment on later today.


Here ya go.  Thoughts?


r~
New constructs:

  { exc_ptr, filter } = EH_LANDING_PAD;

Placeholder for the landing-pad rtl.  Has 2 outputs
for both the exception pointer and the filter.

  EH_DISPATCH (filter);

Placeholder for the switch statement that we'll
generate to jump between the alternatives for 
different catches.

  ERT_NOP

A new type of exception region that merely implies
a different landing pad to the containing region.
Inserting one of these below the "current" region
is how we'll split critical edges, instead of copying
regions.

  exc_ptr and filter members in each eh_region

The code within each region will use these decls.
When falling through from an inner region to an
outer region, these variables must be initialized.
These replace the EXC_PTR_EXPR and FILTER_EXPR
constructs that we currently use.

  RESX (exc_ptr, filter);

Of course we have this now, but we also store the
region number in the statement directly, instead
of via add_stmt_to_eh_region.  Which leads to special
cases all over.  There does not seem to be a real
point to this.  Also, we need to propagate ext_ptr
and filter up to the next level, if we're not calling
_Unwind_Resume.

Examples:

  Catch with nested cleanup:

struct S { ~S(); };
void bar();
int x, y;
void foo()
{
  try {
S s;
bar();
  } catch (int) {
x++;
  } catch (float) {
y++;
  }
}

  Compiles to (before eh_dispatch/resx expansion)

EH Region Tree:
  3 catch int -> post-land = BB8
  4 catch float -> post-land = BB9
  2 try -> { e2, f2 }, land = BB6, post-land = BB7
1 cleanup -> { e1, f1 }, land = BB4, post-land = BB5
  5 must_not_throw

BB1:
  bar();[EH 1]
  # succ 2 4(eh)
BB2:
  S::~S(&s);[EH 2]
  # succ 3
BB3:
  return;
  # succ exit
BB4:
  { e1, f1 } = EH_LANDING_PAD;  [EH 1]
  # succ 5
BB5:
  S::~S(&s);[EH 5]
  RESX (e1, f1);
  # succ 6(eh)
BB6:
  { e2, f2 } = EH_LANDING_PAD;  [EH 2]
  # succ 7
BB7:
  EH_DISPATCH (f2); [EH 2]
  # succ 8(ab) 9(ab) 10(ab)
BB8:
  __cxa_begin_catch (e2);
  x++;
  __cxa_end_catch (e2);
  # succ 3
BB9:
  __cxa_begin_catch (e2);
  y++;
  __cxa_end_catch (e2);
  # succ 3
BB10:
  RESX (e2, f2);[EH 2]

  After inlining, we have a new pass that expands both RESX and EH_DISPATCH:

BB5:
  e2 = e1;
  f2 = f1;
  # succ 7

BB7:
  switch (f2)
{
case 1:  goto BB8;
case 2:  goto BB9;
default: goto BB10
}
  # succ 8 9 10

BB10:
  _Unwind_Resume (e2);

  There are a couple of advantages that ought to be clear immediately.
  First, no more silliness that tree_empty_eh_handler_p has to clean up.
  Second, everything can be properly put into SSA form.
  Third, we're not too late to easily generate switch statements.  See

  /* ??? It is mighty inconvenient to call back into the
 switch statement generation code in expand_end_case.
 Rapid prototyping sez a sequence of ifs.  */

  which has been in except.c for nearly 10 years.

  Critical edge splitting:

struct S { ~S() throw(); };
void bar();
void foo()
{
  S s1;
  bar();
  bar();
  S s0;
  bar();
}

  Compiles to:

EH Region Tree:
1 cleanup -> { e1, f1 }, land = BB7, post-land = BB8
  2 cleanup -> { e2, f2 }, land = BB5, post-land = BB6

BB0:
  bar();[EH 1]
  # succ 1 7(eh)
BB1:
  bar();[EH 1]
  # succ 2 7(eh)
BB2:
  bar();[EH 2]
  # succ 3 5(eh)
BB3:
  S::~S(&s0);
  S::~S(&s1);
  # succ 4
BB4:
  return;
BB5:
  { e2, f2 } = EH_LANDING_PAD;
  # succ 6
BB6:
  S::~S(&s0);
  RESX (e2, f2);
  # succ 7(eh)
BB7:
  { e1, f1 } = EH_LANDING_PAD;
  # succ 8
BB8:
  S::~S(&s1);
  RESX (e1, f1)

  Expand RESX and we get

BB6:
  S::~S(&s0);
  e1 = e2;
  f1 = f2;
  # succ 8

BB8:
  S::~S(&s1);

Re: Notes toward re-implementing EH in gimple

[Diego Novillo]

On Thu, Aug 6, 2009 at 15:35, Richard Henderson wrote:
>> I've also been thinking a good deal about a grand EH reorg; I'll try
>> to post something for you to comment on later today.
>
> Here ya go.  Thoughts?

Y'all are going to make the LTO streamer cry.

Re: Notes toward re-implementing EH in gimple

[Jan Hubicka]

> New constructs:
> 
>   { exc_ptr, filter } = EH_LANDING_PAD;
> 
>   Placeholder for the landing-pad rtl.  Has 2 outputs
>   for both the exception pointer and the filter.

Hmm, EH_LANDING_PAD will still need to be somewhat special (as moving it
across eh edge or something will change behaviour) but it indeed seems
uite sane representation of fact that the EH/filter is really set by
runtime...
> 
>   EH_DISPATCH (filter);
> 
>   Placeholder for the switch statement that we'll
>   generate to jump between the alternatives for 
>   different catches.

Similarly here, it seemed to me that normal switch would suffice.
> 
>   ERT_NOP
> 
>   A new type of exception region that merely implies
>   a different landing pad to the containing region.
>   Inserting one of these below the "current" region
>   is how we'll split critical edges, instead of copying
>   regions.

I am not sure how this will work.
When you have throwing statement inside several catch...try regions with
different types caught, you will have multiple EH edges from that
statement.  It seems that all those edges are neccesary since runtime
can really deliver control flow to any of the try..catch handlers.

We might want to redirect edge that does not correspond to the innermost
try...catch that is where we need to copy nontrivial chain of EH regions
for specific redirection.  You intend to represent this by ERT_NOP?
>   After inlining, we have a new pass that expands both RESX and EH_DISPATCH:
> 
>   BB5:
> e2 = e1;
> f2 = f1;
> # succ 7
> 
>   BB7:
> switch (f2)
>   {
>   case 1:  goto BB8;
>   case 2:  goto BB9;
>   default: goto BB10
>   }
> # succ 8 9 10
> 
>   BB10:
> _Unwind_Resume (e2);

Seems sane.  Removing fully optimized out cleanups still benefits from
RESX not being lowered to _Unwind_Resume, but the lowering can happen
somewhere at later half of the optimization queue, it is not probably
going to bring that much new optimization oppurtunities.
> 
>   There are a couple of advantages that ought to be clear immediately.
>   First, no more silliness that tree_empty_eh_handler_p has to clean up.
>   Second, everything can be properly put into SSA form.
>   Third, we're not too late to easily generate switch statements.  See
> 
>   /* ??? It is mighty inconvenient to call back into the
>  switch statement generation code in expand_end_case.
>  Rapid prototyping sez a sequence of ifs.  */
> 
>   which has been in except.c for nearly 10 years.

Yep, I also found this comment entertaining ;)
> 
>   We decide we want to split edge BB1->BB7, so we modify:
> 
>   EH Region Tree:
>   1 cleanup -> { e1, f1 }, land = BB7, post-land = BB8
> 2 cleanup -> { e2, f2 }, land = BB5, post-land = BB6
> 3 nop -> { e1, f1 }, land = BB9, post-land = BB8
> 
>   BB1:
> bar();[EH 3]
> # succ 2 9(eh)
> 
>   BB9:
> { e1, f1 } = EH_LANDING_PAD;
> # succ 8
> 
>   Which, if I'm not mistaken, duplicates far less code than you
>   do at present to split these edges.

Hmm, if I understand right, edge rediretion now involve creation of new
BB.  I don't think it is very lucky solution.  With current
implementation EH redirection behave same way as redirection of normal
edges.

We don't duplicate code, just pieces of EH tree and when we end up
redirecting things back, we cleanup.  So passes don't need to care EH
edges specially and also critical edge splitting is fully undone by
cfg+eh cleanup when nothing is inserted over the split paths.
>   EH optimization:
> 
>   This pass would remove shadowed exception handlers and other
>   unreachable code.  It's supposed to be currently handled in

Yes, current way of handling via unreachable code don't work as
originally was designed to, so I hoped to move this code away too.
We will need to propagate lists of types into every resx and propagate
where the resx can be reached, but it don't seem that difficult to do.

>   (As an aside, the dead handler elimination we attempt in
>   reachable_next_level doesn't work because the C++ front end
>   tells us that __cxa_end_catch can throw, which is only true
>   when the thrown object has a destructor that can throw.  With
>   a single extra check in the front end, we can set the NOTHROW
>   bit on that __cxa_end_catch call and re-enable this.)

Hmm, we probably should fix this...
But still there is problem that originally we didn't have RESX->outer
region edges as we do now, so regions that has types completely shadowed
by inner regions we will still have it reachable from the RESX of inner
regions (that no longer have the type info)

I will need to look into this tomorrow.  Thanks for writting this up!
Honza

c-c++-common testsuite

[Manuel López-Ibáñez]

Often I want to test the exactly same testcase in C and C++, so I find
myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be
possible to have a shared testsuite dir that is run for both C and C++
languages? (possibly with different default configurations, like
adding -Wc++-compat to the commandline for C runs).

Cheers,

Manuel.

Re: c-c++-common testsuite

[Joseph S. Myers]

On Fri, 7 Aug 2009, Manuel López-Ibáñez wrote:

> Often I want to test the exactly same testcase in C and C++, so I find
> myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be
> possible to have a shared testsuite dir that is run for both C and C++
> languages? (possibly with different default configurations, like
> adding -Wc++-compat to the commandline for C runs).

You'd need to have two .exp files (one in a gcc.something directory and 
one in a g++.something directory) that look somewhere other than 
$srcdir/$subdir to find the test source files.  $srcdir in the .exp files 
should refer to the gcc/testsuite directory so you should be able to write 
the .exp files to look in $srcdir/c-c++-common (say) to find the source 
files to use in the tests.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Notes toward re-implementing EH in gimple

[Richard Henderson]

On 08/06/2009 01:44 PM, Jan Hubicka wrote:

Hmm, EH_LANDING_PAD will still need to be somewhat special (as moving it
across eh edge or something will change behaviour) but it indeed seems
uite sane representation of fact that the EH/filter is really set by
runtime...


Yes, EH_LANDING_PAD is still somewhat special in that it cannot be
moved *at all*.  Specifically, it must be the first statement in the
block whose label is recorded in the EH Region Table.

But that's not a very onerous special case.


Similarly here, it seemed to me that normal switch would suffice.


A normal switch only suffices after inlining, when we've collected
the complete set of types which can be caught within the function.
Until then, we must make do with a place holder.


   ERT_NOP

A new type of exception region that merely implies
a different landing pad to the containing region.
Inserting one of these below the "current" region
is how we'll split critical edges, instead of copying
regions.


I am not sure how this will work.
When you have throwing statement inside several catch...try regions with
different types caught, you will have multiple EH edges from that
statement.  It seems that all those edges are neccesary since runtime
can really deliver control flow to any of the try..catch handlers.

We might want to redirect edge that does not correspond to the innermost
try...catch that is where we need to copy nontrivial chain of EH regions
for specific redirection.  You intend to represent this by ERT_NOP?


You're misunderstanding how the edges are to be drawn.

Under the current scheme, before rtl's finish_eh_generation runs,
we do have edges that go direct from a call to each of the possible
handlers and cleanups.

Under this proposed scheme, we model how the runtime actually
works, right from the beginning.  There is only *one* EH edge for
any one statement that can throw, and that edge is to the landing
pad.  From the landing pad, the filter value de-multiplexes this
one edge to select the proper handler/cleanup.

It seems extremely unlikely to me that we actually want to put fixup
code before handler X, as opposed to merely on any EH edge, simply
because the CFG won't be drawn that way.

We *can* put anything we want into the landing pad block (after the
actual EH_LANDING_PAD statement).  We can even duplicate the
EH_DISPATCH stmt (nee SWITCH stmt) and so split edges to individual
handlers if we really needed to go that far.


Seems sane.  Removing fully optimized out cleanups still benefits from
RESX not being lowered to _Unwind_Resume, but the lowering can happen
somewhere at later half of the optimization queue, it is not probably
going to bring that much new optimization oppurtunities.


I'd been imagining lowering RESX/EH_DISPATCH here:

  p = &all_passes;
+ NEXT_PASS (pass_lower_eh_dispatch);
  NEXT_PASS (pass_all_optimizations);

so that it happens immediately after inlining even without -O1.


   There are a couple of advantages that ought to be clear immediately.
   First, no more silliness that tree_empty_eh_handler_p has to clean up.
   Second, everything can be properly put into SSA form.
   Third, we're not too late to easily generate switch statements.  See

   /* ??? It is mighty inconvenient to call back into the
  switch statement generation code in expand_end_case.
  Rapid prototyping sez a sequence of ifs.  */

   which has been in except.c for nearly 10 years.


Yep, I also found this comment entertaining ;)

   We decide we want to split edge BB1->BB7, so we modify:

EH Region Tree:
1 cleanup ->  { e1, f1 }, land = BB7, post-land = BB8
  2 cleanup ->  { e2, f2 }, land = BB5, post-land = BB6
  3 nop ->  { e1, f1 }, land = BB9, post-land = BB8

BB1:
  bar();[EH 3]
  # succ 2 9(eh)

BB9:
  { e1, f1 } = EH_LANDING_PAD;
  # succ 8

   Which, if I'm not mistaken, duplicates far less code than you
   do at present to split these edges.


Hmm, if I understand right, edge rediretion now involve creation of new
BB.  I don't think it is very lucky solution.  With current
implementation EH redirection behave same way as redirection of normal
edges.


Pardon?  Edge splitting always involves creation of a new block.
The only thing that's different here is that the new block isn't
empty -- it must include the EH_LANDING_PAD statement.

What did you think you are doing in the current implementation?
It's the same, except the expansion of the landing pad is hidden
in the rtl code, triggered by the label being in the EH tables.

I almost wish the EH_LANDING_PAD could be hidden within the PHIs,
so that it couldn't be separated from the beginning of the block.

Actually, it occurs to me that we *could* do something really
really special here.  Suppose we make SSA notice EH landing pad
labels, and go off to the EH table to find the statement.  In
that w

gcc-4.5-20090806 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 150546

You'll find:

gcc-4.5-20090806.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090806.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090806.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090806.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090806.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090806.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090806.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090806.tar.bz2The GCC testsuite

Diffs from 4.5-20090730 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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: c-c++-common testsuite

[Janis Johnson]

On Fri, 2009-08-07 at 00:06 +0200, Manuel López-Ibáñez wrote:
> Often I want to test the exactly same testcase in C and C++, so I find
> myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be
> possible to have a shared testsuite dir that is run for both C and C++
> languages? (possibly with different default configurations, like
> adding -Wc++-compat to the commandline for C runs).

I've been thinking about that lately, it would be useful for several
kinds of functionality.  We'd want effective targets for the language
for using different options and for providing different error/warning
checks for each language.  I haven't looked into how to handle it with
DejaGnu, maybe something like gcc.shared and a [symbolic] link to it
called g++.shared; do links work with Subversion?

Janis

Re: c-c++-common testsuite

[Joseph S. Myers]

On Thu, 6 Aug 2009, Janis Johnson wrote:

> I've been thinking about that lately, it would be useful for several
> kinds of functionality.  We'd want effective targets for the language
> for using different options and for providing different error/warning
> checks for each language.  I haven't looked into how to handle it with
> DejaGnu, maybe something like gcc.shared and a [symbolic] link to it
> called g++.shared; do links work with Subversion?

Whether or not links work with Subversion, they don't in my experience 
work well with "diff" (it likes to dereference them when comparing two 
trees, so showing diffs to the same files more than once) and I wouldn't 
recommend relying on storage of links or other special sorts of files in a 
particular version control system, so possibly constraining future 
conversions to other systems.  It's quite possible links are also 
problematic on some supported build systems.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc git's performance problem Fwd: git gc expanding packed data?

[Hin-Tak Leung]

I asked the git people, and here is the answer - maybe somebody can
fix the gcc git repositry?

-- Forwarded message --
From: Nicolas Pitre 
Date: Wed, Aug 5, 2009 at 11:39 PM
Subject: Re: git gc expanding packed data?
To: Hin-Tak Leung 
Cc: g...@vger.kernel.org


On Tue, 4 Aug 2009, Hin-Tak Leung wrote:

> I cloned gcc's git about a week ago to work on some problems I have
> with gcc on minor platforms, just plain 'git clone
> git://gcc.gnu.org/git/gcc.git gcc' .and ran gcc fetch about daily, and
> 'git rebase origin' from time to time. I don't have local changes,
> just following and monitoring what's going on in gcc. So after a week,
> I thought I'd do a git gc . Then it goes very bizarre.
>
> Before I start 'git gc', .The whole of .git was about 700MB and
> git/objects/pack was a bit under 600MB, with a few other directories
> under .git/objects at 10's of K's and a few 3-4K's, and the
> checkout was, well, the size of gcc source code. But after I started
> git gc, the message stays in the 'counting objects' at about 900,000
> for a long time, while a lot of directories under .git/objects/ gets a
> bit large, and .git blows up to at least 7GB with a lot of small files
> under .git/objects/*/, before seeing as I will run out of disk space,
> I kill the whole lot and ran git clone again, since I don't have any
> local change and there is nothing to lose.
>
> I am running git version 1.6.2.5 (fedora 11). Is there any reason why
> 'git gc' does that?

There is probably a reason, although a bad one for sure.

Well... OK.

It appears that the git installation serving clone requests for
git://gcc.gnu.org/git/gcc.git generates lots of unreferenced objects. I
just cloned it and the pack I was sent contains 1383356 objects (can be
determined with 'git show-index < .git/objects/pack/*.idx | wc -l').
However, there are only 978501 actually referenced objects in that
cloned repository ( 'git rev-list --all --objects | wc -l').  That makes
for 404855 useless objects in the cloned repository.

Now git has a safety mechanism to _not_ delete unreferenced objects
right away when running 'git gc'.  By default unreferenced objects are
kept around for a period of 2 weeks.  This is to make it easy for you to
recover accidentally deleted branches or commits, or to avoid a race
where a just-created object in the process of being but not yet
referenced could be deleted by a 'git gc' process running in parallel.

So to give that grace period to packed but unreferenced objects, the
repack process pushes those unreferenced objects out of the pack into
their loose form so they can be aged and eventually pruned.  Objects
becoming unreferenced are usually not that many though.  Having 404855
unreferenced objects is quite a lot, and being sent those objects in the
first place via a clone is stupid and a complete waste of network
bandwidth.

Anyone has an idea of the git version running on gcc.gnu.org?  It is
certainly buggy and needs fixing.

Anyway... To solve your problem, you simply need to run 'git gc' with
the --prune=now argument to disable that grace period and get rid of
those unreferenced objects right away (safe only if no other git
activities are taking place at the same time which should be easy to
ensure on a workstation).  The resulting .git/objects directory size
will shrink to about 441 MB.  If the gcc.gnu.org git server was doing
its job properly, the size of the clone transfer would also be
significantly smaller, meaning around 414 MB instead of the current 600+
MB.

And BTW, using 'git gc --aggressive' with a later git version (or
'git repack -a -f -d --window=250 --depth=250') gives me a .git/objects
directory size of 310 MB, meaning that the actual repository with all
the trunk history is _smaller_ than the actual source checkout.  If that
repository was properly repacked on the server, the clone data transfer
would be 283 MB.  This is less than half the current clone transfer
size.


Nicolas

Re: c-c++-common testsuite

[Dave Korn]

Joseph S. Myers wrote:
> On Thu, 6 Aug 2009, Janis Johnson wrote:
> 
>> I've been thinking about that lately, it would be useful for several
>> kinds of functionality.  We'd want effective targets for the language
>> for using different options and for providing different error/warning
>> checks for each language.  I haven't looked into how to handle it with
>> DejaGnu, maybe something like gcc.shared and a [symbolic] link to it
>> called g++.shared; do links work with Subversion?
> 
> Whether or not links work with Subversion, they don't in my experience 
> work well with "diff" (it likes to dereference them when comparing two 
> trees, so showing diffs to the same files more than once) and I wouldn't 
> recommend relying on storage of links or other special sorts of files in a 
> particular version control system, so possibly constraining future 
> conversions to other systems.  It's quite possible links are also 
> problematic on some supported build systems.

  I think MinGW would end up copying all the files into the linked tree.

  Possibly we could modify the algorithm that enumerates directories matching
"$tool.*" to look for (e.g.) "*$tool.*" and then name directories like 
"c.c++.dg"?

cheers,
  DaveK

Projects

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey

I have been lingering around the gcc mailing lists for sometime and
done a little work with a basic front-end, and working on doing decent
documentation into the gcc-internals manual.

But i would also like to get a little more involved, i got the gcc
copy-approval at the same time as i had to push my work into automake.

But i was wondering what work is there being done on:
http://gcc.gnu.org/wiki/Graphite/Parallelization

That is something i was always wanting to work on, but i was going to
make an external translator program to open-mp pragma's but this is
much better system.

Or would be great to know some good places to start, even what areas
need cleanup, just the projects list and regressions etc all seem to
be quite old and not sure which are still relevant!

I would like to do this for a while, but i was ultimately thinking of
doing a haskell implementation or python implementation maybe not too
sure haven't thought about it too much yet got my own work to finish
first.

Thanks

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

iEYEARECAAYFAkp7jtcACgkQAhcOgIaQQ2EaFwCfRdd7bT4BqgzEIcAIq+bvWWOJ
PHEAnikkh1pi4YGdTKfrmWOuywy70uL6
=Xwti
-END PGP SIGNATURE-