Lots of soft-fp warnings

[Rask Ingemann Lambertsen]

   Soft-fp spews lots of warnings of this sort:

/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c: In function 
'__floatuntitf':
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c:40: warning: 
comparison of unsigned expression < 0 is always false
In file included from ../.././gcc/extendsftf2.c:2:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/extendsftf2.c:37: warning: no 
previous prototype for '__extendsftf2'
In file included from ../.././gcc/extenddftf2.c:2:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/extenddftf2.c:37: warning: no 
previous prototype for '__extenddftf2'
In file included from ../.././gcc/extendxftf2.c:2:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/extendxftf2.c:36: warning: no 
previous prototype for '__extendxftf2'
In file included from ../.././gcc/trunctfsf2.c:2:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/trunctfsf2.c:37: warning: no 
previous prototype for '__trunctfsf2'
In file included from ../.././gcc/trunctfdf2.c:2:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/trunctfdf2.c:37: warning: no 
previous prototype for '__trunctfdf2'
In file included from ../.././gcc/trunctfxf2.c:2:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/trunctfxf2.c:36: warning: no 
previous prototype for '__trunctfxf2'

-- 
Rask Ingemann Lambertsen

get complete type

[allozano]

I need get the param type. For example

void f (std::string){...}

with Macros TYPE_NAME, TYPE_DECL,... i find the param is "string" but  I 
need "std::string" for code generator.


I dont find the fields or macros in the files tree.h and cp/cp-tree.h 
and don find information in google.


Thanks and sorry for my english

Re: Lots of soft-fp warnings

[Joseph S. Myers]

On Mon, 2 Jul 2007, Rask Ingemann Lambertsen wrote:

>Soft-fp spews lots of warnings of this sort:
> 
> /n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c: In function 
> '__floatuntitf':
> /n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c:40: warning: 
> comparison of unsigned expression < 0 is always false

This is not a useful warning for this sort of code with heavy use of 
macros that may take signed or unsigned types.

> In file included from ../.././gcc/extendsftf2.c:2:
> /n/12/rask/src/all/libgcc/../gcc/config/soft-fp/extendsftf2.c:37: warning: no 
> previous prototype for '__extendsftf2'

Get declarations added to glibc and then import the updated version if you 
wish.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Turning a scope block into not-quite-a nested function?

[KJKHyperion]

Let's say I have a function that looks like this:

void a()
{
   int n = x();

   __try
   {
   y();
   }
   __finally
   {
   z(n);
   w();
   }
}

... assuming a hypothetical extension to C syntax that turns a __try {
... } __finally { ... } into the proper TRY_FINALLY_EXPR (maybe just a
matter of adapting the equivalent ObjectiveC keyword...?). As per
Unwind ABI, it gets compiled to something like this:

void a()
{
   int n = x();

   y();
   z(n);
   w();

cleanup:
   z(n);
   w();
   Unwind_Resume(...);
}

But I need it to compile to something quite different:

void __a_cleanup(<>)
{
   z(<>.n);
   w();
}

void a()
{
   int n = x();
   y();
   __a_cleanup(<>);
}

This is not a cosmetic matter: I'm developing a new exception handling
scheme for GCC, compatible with native Windows exceptions (henceforth:
SEH), where unwinding doesn't lower the stack at each frame unwound
relying on cleanup code to call Unwind_Resume, but instead calls all
cleanup code in a loop, from a stack frame *above* where the exception
was thrown.

Specifically, the frame that catches an exception is tasked with
unwinding the stack from the throwing frame up to itself, calling the
standard function RtlUnwind, and after RtlUnwind is done, it's
supposed to longjmp to the landing pad on its own. It is an
unescapeable fact that __finally { ... } blocks need to be callable
out-of-band, with the "right" frame pointer but the "wrong" stack
pointer (the call stack is, approximately, ,
RtlDispatchException, , RtlUnwind, ).

I have considered a couple of options, but none appear especially
appealing to me. One is to make __a_cleanup a full-blown nested
function; I have looked into nested functions, but their
implementation seems very complex and ad-hoc, hard to adapt to a
different (and simpler) task. The other option, which seemed quite
straightforward to me at first, was to have a builtin function to call
a function with a saved frame pointer; it turns out, though, that GCC
still addresses relative to stack pointer even without FPO - on x86, I
see that the outgoing arguments area is addressed at fixed positive
offsets from ESP - unlike Visual C++ where all the compiler does to
implement __finally blocks is to juggle EBP around.

So there we are. Any suggestions?

Re: Turning a scope block into not-quite-a nested function?

[Paolo Bonzini]

So there we are. Any suggestions?


If I understand correctly, nested functions *are* what you want and 
there is code to do exactly what you want in the implementation of OpenMP.


However, I am not into that code enough to give you any further hint.

Paolo

Re: Turning a scope block into not-quite-a nested function?

[KJKHyperion]

On 7/2/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:

> So there we are. Any suggestions?
If I understand correctly, nested functions *are* what you want and
there is code to do exactly what you want in the implementation of OpenMP.


k, cool. Will look into it (mostly, though, I was *hoping* I wouldn't
have to mess with nested functions!)

Is it still true that message-lenght == 72 for C++?

[Paolo Carlini]

Hi,

I'm looking into a library issue and noticed that these lines:

  -fmessage-length=n
  Try to format error messages so that they fit on lines of 
about n characters.  The
  default is 72 characters for g++ and 0 for the rest of the 
front ends supported by
  GCC.  If n is zero, then no line-wrapping will be done; each 
error message will

  appear on a single line.

apparently aren't up to date anymore for C++: I'm seeing the same 
behavior I see for message-length == 0.

Indeed:

   void
   pp_cxx_pretty_printer_init (cxx_pretty_printer *pp)
   {
 ...
 pp_set_line_maximum_length (pp, 0);
 ...

Is that intended? I suppose so, then likely we should adjust the docs?

Thanks,
Paolo.

no_new_pseudos

[Kenneth Zadeck]

I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos.  All of the sets can just go away, as well
as the tests of it that occur in passes that only run before reload.

For those few passes that can run both before and after reload, the test
would be replaced with a test of reload_completed.

I believe that the original purpose of this was to protect certain
datastructures that had to be resized manually when pseudos were added. 
However, all of these are gone, and have been replaced with structures
inside of df that are automatically resized.

Does anyone think this is a bad idea?  A grep for no_new_pseudos bears
out that nothing is really going on here anymore. 


Kenny

Re: no_new_pseudos

[Richard Kenner]

> I believe that the original purpose of this was to protect certain
> datastructures that had to be resized manually when pseudos were added. 

Correct.

> Does anyone think this is a bad idea?  A grep for no_new_pseudos bears
> out that nothing is really going on here anymore. 

Seems like a real improvement to me.

Re: no_new_pseudos

[Richard Earnshaw]

On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
> I do not remember if it was stevenb or bonzini that observed that
> because of changes that came with the dataflow branch it is now trivial
> to get rid of no_new_pseudos.  All of the sets can just go away, as well
> as the tests of it that occur in passes that only run before reload.
> 
> For those few passes that can run both before and after reload, the test
> would be replaced with a test of reload_completed.
> 
> I believe that the original purpose of this was to protect certain
> datastructures that had to be resized manually when pseudos were added. 
> However, all of these are gone, and have been replaced with structures
> inside of df that are automatically resized.
> 
> Does anyone think this is a bad idea?  A grep for no_new_pseudos bears
> out that nothing is really going on here anymore. 

There are 199 uses of it in the backends; compared to 32 in the front
end.

So it is quite heavily used by MD code.

R.
-- 
Richard Earnshaw Email: [EMAIL PROTECTED]
ARM Ltd  Phone: +44 1223 400569 (Direct + VoiceMail)
110 Fulbourn RoadSwitchboard: +44 1223 400400
Cherry HintonFax: +44 1223 400410
Cambridge CB1 9NJWeb: http://www.arm.com/
UK

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

Re: no_new_pseudos

[Richard Kenner]

> There are 199 uses of it in the backends; compared to 32 in the front
> end.
> 
> So it is quite heavily used by MD code.

That distinction shouldn't matter unless some of the MD code uses it instead
of reload_completed, which is (unfortunately) a real possibility.

So I fear those will have to be checked.

Re: no_new_pseudos

[Paolo Bonzini]

Kenneth Zadeck wrote:

I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos.


For the record, this was Steven's observation.  And Kenner confirming 
that this was the original purpose of no_new_pseudos is very 
encouraging, since he's an integral part of the history of GCC's RTL 
passes. :-)


I think that, as a first step, we should remove setting no_new_pseudos 
to 1 until just before reload.  This will effectively turn 
no_new_pseudos into a synonym for "reload_in_progress || reload_completed".


Paolo

Re: no_new_pseudos

[Kenneth Zadeck]

Richard Kenner wrote:
>> There are 199 uses of it in the backends; compared to 32 in the front
>> end.
>>
>> So it is quite heavily used by MD code.
>> 
>
> That distinction shouldn't matter unless some of the MD code uses it instead
> of reload_completed, which is (unfortunately) a real possibility.
>
> So I fear those will have to be checked.
>   
there are a few in the back ends that will require some thought.  most
are trivial. 

There appears to be an idiom, (or at least a chunk of code that has been
heavily copied) where *_output_mi_thunk sets reload_completed and
no_new_pseudos at the top and clears them at the bottom. 

This appears to be the majority of the not trivial places to change and
an explanation by a trained professional would be helpful and greatly
appreciated.

Kenny

Re: get complete type

[Mike Stump]

On Jul 2, 2007, at 2:48 AM, allozano wrote:

I need get the param type. For example

void f (std::string){...}

with Macros TYPE_NAME, TYPE_DECL,... i find the param is "string"  
but  I need "std::string"


Look for CONTEXT in *.h.

Re: no_new_pseudos

[Ian Lance Taylor]

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

> There appears to be an idiom, (or at least a chunk of code that has been
> heavily copied) where *_output_mi_thunk sets reload_completed and
> no_new_pseudos at the top and clears them at the bottom. 
> 
> This appears to be the majority of the not trivial places to change and
> an explanation by a trained professional would be helpful and greatly
> appreciated.

Several of the output_mi_thunk routines essentially run a
mini-compilation of a small function.  They generate a series of
insns, then call final().  Setting reload_completed directs the move
expanders to make the right decisions in this limited case.  If you
remove no_new_pseudos elsewhere in the compiler, you can remove the
setting and clearing of no_new_pseudos from *_output_mi_thunk without
fear.

Ian

Re: no_new_pseudos

[Jan Hubicka]

> Kenneth Zadeck wrote:
> >I do not remember if it was stevenb or bonzini that observed that
> >because of changes that came with the dataflow branch it is now trivial
> >to get rid of no_new_pseudos.
> 
> For the record, this was Steven's observation.  And Kenner confirming 
> that this was the original purpose of no_new_pseudos is very 
> encouraging, since he's an integral part of the history of GCC's RTL 
> passes. :-)
> 
> I think that, as a first step, we should remove setting no_new_pseudos 
> to 1 until just before reload.  This will effectively turn 
> no_new_pseudos into a synonym for "reload_in_progress || reload_completed".

Just for a record, I pushed no_new_pseudo until the reload pass on
rtlopt patch some time ago and it did work at least on i386 (I am not
sure why this change was never merged, perhaps it was just forgotten
or dependent on other changes, it is a while).

The no-new-pseudos was mostly useful when we was still updating dataflow
incrementally and had things set in a way that they didn't allowed
resizing, but those limitations was removed.

Honza
> 
> Paolo

Wow!

[Uros Bizjak]

Hello!

It is worth noticing that latest changes to gcc brought more than 75% 
speed-up on Polyhedron aermod.f90 benchmark [1]. I can confirm this on 
32bit nocona, and double-checked on 64bit core2:


gcc -O3 -funroll-loops -ftree-vectorize -ffast-math:

(GCC) 4.3.0 20070622 : 0m33.530s
(GCC) 4.3.0 20070702 : 0m11.805s

[1]: 
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html


Uros.

Re: Wow!

[Daniel Berlin]

I'm curious if it was the pre/fre changes.  can you try -fno-tree-pre
and -fno-tree-fre and see if it slows down again?

On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:

Hello!

It is worth noticing that latest changes to gcc brought more than 75%
speed-up on Polyhedron aermod.f90 benchmark [1]. I can confirm this on
32bit nocona, and double-checked on 64bit core2:

gcc -O3 -funroll-loops -ftree-vectorize -ffast-math:

(GCC) 4.3.0 20070622 : 0m33.530s
(GCC) 4.3.0 20070702 : 0m11.805s

[1]:
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html

Uros.

[GSoC: DDG export][RFC] Current status

[Alexander Monakov]

Hello,

The attached patch implements (partially) the first part of proposed
work: exporting and verification of data dependence information.

The implementation follows the outline presented in my initial message
on the project, here: http://gcc.gnu.org/ml/gcc/2007-03/msg00900.html
.  Data references and data dependency relations obtained via
compute_dependencies_for_loop are copied into containing struct (which
is a member of struct function).  This containing struct is marked
GTY((skip)), because its lifetime and lifetime of its components is
known (from the moment of export until destruction late in the RTL
pipeline).  However, I need to preserve trees that are referenced in
the exported datarefs (to be able to bind MEMs to datarefs later), so
I need to put them into a GC-visible array.  For now that array is
global.  Can it be done better?

MEMs are bound to datarefs by means of saving original trees for MEMs
during expand.  This is a large part of the attached patch with
changes to emit-rtl.[ch], which adds new field to struct mem_attrs
(mem_orig_expr), initializes it and propagates through various RTL
transformations.  Notice that it has stricter hashing  (as compared to
orig_expr part of the same struct), so it will reduce sharing of
mem_attrs (and also increase size of the struct, obviously).  Can it
be a problem?  Please also note that this patch is a part of aliasing
information exporting patch by Dmitry Melnik, which available now in
alias-export branch.

After original tree is found, a corresponding dataref is looked up in
exported info.  I guess I will need here hashtabs for fast lookup
(also for searching ddrs for pairs of datarefs), am I right?

The only place that required patching so far wrt. exporting was
iv-opts pass (we need to rewrite TARGET_MEM_REFs to their respective
TMR_ORIGINALs, because that's what MEM_ORIG_EXPR will provide binding
to later).  However, the issue of basic block duplication is not
addressed yet in this patch, I will be looking into it shortly.

The verification routines walk all loops and memory references in
function, and provide counters of references with/without relevant
exported dataref, and also count number of exported ddrs.  They are
run after every pass, both GIMPLE and RTL.  On GIMLPE, verifier looks
into REFERENCE_CLASS_P trees being LHSs and RHSs of MODIFY_STMTs (as
compute_dependencies_for_loop does), on RTL simply all MEMs are
visited.  However, I just noticed that 'optimized' dump may contain
D.2108 = (short unsigned int) shortsum + (short unsigned int)
MEM[symbol: data_ch, index: (unsigned int) i];
which is not verifier expects.

The verifier also frequently breaks on passes that create unreachable
basic blocks (because dominator analysis called from flow_loops_find
asserts there are none).  For now I just place
delete_unreachable_blocks in such passes, is that ok?

I'm proceeding with testing on small examples (tree-vectorizer
testsuite provides plenty :) ).

Thanks in advance for comments

--
Alexander Monakov
diff -puN trunk/gcc/cfgexpand.c export-ddg/gcc/cfgexpand.c
--- trunk/gcc/cfgexpand.c   2007-06-22 20:19:52.0 +0400
+++ export-ddg/gcc/cfgexpand.c  2007-06-29 17:34:20.0 +0400
@@ -1988,6 +1988,7 @@ tree_expand_cfg (void)
   /* Tag the blocks with a depth number so that change_scope can find
  the common parent easily.  */
   set_block_levels (DECL_INITIAL (cfun->decl), 0);
+  delete_unreachable_blocks ();
   return 0;
 }
 
@@ -2004,7 +2005,7 @@ struct tree_opt_pass pass_expand =
   PROP_gimple_leh | PROP_cfg,   /* properties_required */
   PROP_rtl, /* properties_provided */
   PROP_trees,  /* properties_destroyed */
-  0,/* todo_flags_start */
-  TODO_dump_func,   /* todo_flags_finish */
+  TODO_no_verify_trees, /* todo_flags_start */
+  TODO_dump_func|TODO_no_verify_trees, /* todo_flags_finish */
   'r'  /* letter */
 };
diff -puN trunk/gcc/common.opt export-ddg/gcc/common.opt
--- trunk/gcc/common.opt2007-06-29 19:31:47.0 +0400
+++ export-ddg/gcc/common.opt   2007-07-02 17:54:00.0 +0400
@@ -462,6 +462,10 @@ fexpensive-optimizations
 Common Report Var(flag_expensive_optimizations) Optimization
 Perform a number of minor, expensive optimizations
 
+fexport-ddg
+Common Report Var(flag_export_ddg) Init(1)
+Gather and export data relation information
+
 ffast-math
 Common
 
diff -puN trunk/gcc/emit-rtl.c export-ddg/gcc/emit-rtl.c
--- trunk/gcc/emit-rtl.c2007-07-02 14:55:16.0 +0400
+++ export-ddg/gcc/emit-rtl.c   2007-07-02 17:53:53.0 +0400
@@ -177,8 +177,8 @@ static int const_double_htab_eq (const v
 static rtx lookup_const_double (rtx);
 static hashval_t mem_attrs_htab_hash (const void *);
 static int mem_attrs_htab_eq (const void *, const void *);
-static mem_attrs *get_mem_attrs (HOST_WIDE_INT, tree, rtx, rt

Re: Wow!

[Uros Bizjak]

Daniel Berlin wrote:

I'm curious if it was the pre/fre changes.  can you try -fno-tree-pre
and -fno-tree-fre and see if it slows down again?

Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;)

BTW: I was looking if this speedup was due to yet uncommitted patch for 
PR 32457 [1], but fortunatelly, it was not the case. However,  it would 
be nice, if the patch [2] for [1] would be committed to SVN to fix 32bit 
compilation.



[1]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[2]: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01941.html

Uros.

Fwd: sub-optimal code for packed boolean arrays in Ada -- bug or inherent limitation

[Alinabi]

-- Forwarded message --
From: Alinabi <[EMAIL PROTECTED]>
Date: Jul 2, 3:34 pm
Subject: sub-optimal code for packed boolean arrays in Ada -- bug or
inherent limitation
To: comp.lang.ada


Hello, everyone.

I am writing a chess program in Ada, using bitboards for position
representation. Bitboards are just 64 bit integers in which each bit
represents a predicate about a square of the board. For example, you
would have a bitboard called WhitePawns, which has a one for every
square that contains a white pawn, and zero for every other square. In
Ada, there are two possible implementations of a bitboard: using
Unsigned_64, which would closely mirror the way things are done in C,
and using packed arrays of booleans. The C-like version, using
Unsigned_64, leads to some rather obfuscated code, so I decided to
investigate the efficiency of the code that gnat generates for some
basic operations on packed arrays, which I implemented in the
following package:

package Test is

type Index_T is new Integer range 0..63;

type Bitboard_T is private;

procedure Set   (B : in out Bitboard_T; I : in Index_T);
procedure Clear (B : in out Bitboard_T; I : in Index_T);
procedure Clear (B : in out Bitboard_T);
procedure Flip  (B : in out Bitboard_T; I : in Index_T);
function  Is_Set(B : in Bitboard_T; I : in Index_T)
return Boolean ;

private

type Bitboard_T is array(Index_T) of Boolean;
pragma Pack(Bitboard_T);

pragma Inline_Always(Set, Clear, Flip, Is_Set);

end Test;

package body Test is

pragma Optimize(Time);

procedure Set(B : in out Bitboard_T; I : in Index_T) is
begin
B(I) := True;
end;

procedure Clear(B : in out Bitboard_T; I : in Index_T) is
begin
B(I) := False;
end;

procedure Clear(B : in out Bitboard_T) is
begin
B:= B xor B;
end;

procedure Flip(B : in out Bitboard_T; I : in Index_T) is
begin
B(i) := not B(i);
end;

function Is_Set(B : in Bitboard_T; I : in Index_T)
return Boolean is
begin
return B(I);
end;

end Test;

When compiled with
gnatmake -g -gnatp -gnatn -march=opteron -O3 -fdump-tree-optimized
test.adb
using the ada compiler in gcc 4.1.2, the code generated is generally
optimal, or close to optimal. For example, the code generated for Set
is

procedure Set(B : in out Bitboard_T; I : in Index_T) is
   0:   89 f1 mov   %esi,%ecx
begin
B(I) := True;
   2:   b8 01 00 00 00 mov$0x1,%eax
   7:   48 d3 e0   shl  %cl,%rax
   a:   48 09 f8or   %rdi,%rax
end;
   d:   c3  retq

The only notable exception is procedure Flip, which becomes

procedure Flip(B : in out Bitboard_T; I : in Index_T) is
  30:   89 f1   mov%esi,%ecx
begin
B(i) := not B(i);
  32:   48 c7 c0 fe ff ff ffmov$0xfffe,%rax
  39:   48 d3 c0   rol%cl,%rax
  3c:   48 21 f8   and   %rdi,%rax
  3f:   48 d3 efshr%cl,%rdi
  42:   83 f7 01   xor$0x1,%edi
  45:   83 e7 01  and$0x1,%edi
  48:   48 d3 e7  shl %cl,%rdi
  4b:   48 09 f8   or  %rdi,%rax
end;
  4e:   c3 retq

instead of the shorter

mov  %esi,  %ecx
mov  0x1,   %rax
shl%cl,%rax
xor% rax, %rdx
retq

I don't know much (if anything) about compiler internals, so I was
wondering if I should file a bug report. Is there some good
theoretical justification for all those extraneous shifts and
rotations? I would think that if the compiler can figure out the best
way to set or clear a bit in a register using shift and logical ops,
than it should also be able to negate it efficiently.

Re: no_new_pseudos

[Alexandre Oliva]

On Jul  2, 2007, Richard Earnshaw <[EMAIL PROTECTED]> wrote:

> On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
>> I do not remember if it was stevenb or bonzini that observed that
>> because of changes that came with the dataflow branch it is now trivial
>> to get rid of no_new_pseudos.  All of the sets can just go away, as well
>> as the tests of it that occur in passes that only run before reload.
>> 
>> For those few passes that can run both before and after reload, the test
>> would be replaced with a test of reload_completed.
>> 
>> I believe that the original purpose of this was to protect certain
>> datastructures that had to be resized manually when pseudos were added. 
>> However, all of these are gone, and have been replaced with structures
>> inside of df that are automatically resized.
>> 
>> Does anyone think this is a bad idea?  A grep for no_new_pseudos bears
>> out that nothing is really going on here anymore. 

> There are 199 uses of it in the backends; compared to 32 in the front
> end.

> So it is quite heavily used by MD code.

I recall having used it a number of times in expanders that shouldn't
create new pseudos during reload.  These could easily be turned into
(reload_in_progress || reload_completed).  Maybe we could turn
no_new_pseudos into a macro that expands to this?

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

Re: Fwd: sub-optimal code for packed boolean arrays in Ada -- bug or inherent limitation

[Robert Dewar]

Alinabi wrote:


Subject: sub-optimal code for packed boolean arrays in Ada -- bug or
inherent limitation


Certainly not a bug, the code generated is correct, it is just not
optimal. Surely it could be fixed if someone had the energy to do so.
I see no particular gain in filing a bug report, it is unlikely this
will cause someone else to jump into action to improve the code in this
case.

The most effective way to get something done here would be for you
to investigate how this could be improved, the relevant unit in the
compiler is exp_pakd.adb. Feel free to ask if you have questions
on the internals of this unit.


pragma Inline_Always(Set, Clear, Flip, Is_Set);


pragma Inline is usually a better choice when using gcc, Inline_ALways
is there primarily for non-gcc targets, and its use with gcc is
deprecated.


I don't know much (if anything) about compiler internals, so I was
wondering if I should file a bug report. Is there some good
theoretical justification for all those extraneous shifts and
rotations?


No, there is no theoretical justification, just a case of non-optimal
code.


I would think that if the compiler can figure out the best
way to set or clear a bit in a register using shift and logical ops,
than it should also be able to negate it efficiently.


Most certainly it could, it just does not happen to optimize this
particular case.

gcc-4.1-20070702 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20070702.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070702.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070702.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070702.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070702.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070702.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070702.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070702.tar.bz2The GCC testsuite

Diffs from 4.1-20070625 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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.

FYI: today's regressions in libstdc++

[Paolo Carlini]

Hi,

just an heads-up: today 27_io/basic_stringbuf/setbuf/char/4.cc (and the 
wchar_t counterpart) started failing at compile-time at least on x86 and 
x86_64: at -O2 the compiler eats all the available memory.

You can see the issue reported here, for example:

   http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00073.html

and I'm consistently seeing here too, of course. I also checked that the 
problem doesn't show up at -O0.


Paolo.

MPFR 2.3.0 Release Candidate

[Vincent Lefevre]

The release of MPFR 2.3.0 is imminent. Please help to make this
release as good as possible by downloading and testing this
release candidate:

http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.gz
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.zip

The MD5's:
4e9e2649ba1176206b58f7ea8543d3dd  mpfr-2.3.0-rc1.tar.bz2
9f9f34ff79270f8ac85d5452b2a39d03  mpfr-2.3.0-rc1.tar.gz
10e923edb46acf4ff37163ce9daf68ff  mpfr-2.3.0-rc1.zip

Changes from versions 2.2.* to version 2.3.0:
- The mpfr.info file is now installed in the share subdirectory
  (as required by the Filesystem Hierarchy Standard); see output
  of "./configure --help".
- The shared library is now enabled by default. If the MPFR build
  fails on your platform, try the --disable-shared configure option
  to disable the shared library.
- New functions mpfr_j0, mpfr_j1, mpfr_jn, mpfr_y0, mpfr_y1, mpfr_yn,
  mpfr_lgamma, mpfr_remainder, mpfr_remquo, mpfr_fms.
- Functions mpfr_sin, mpfr_cos and mpfr_sin_cos improved (argument
  reduction).
- More detailed MPFR manual.
- Bug fixes.

Please send success and failure reports to <[EMAIL PROTECTED]>.

If no problems are found, MPFR 2.3.0 should be released in 2 or 3 weeks.

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Wow!

[Daniel Berlin]

On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:

Daniel Berlin wrote:
> I'm curious if it was the pre/fre changes.  can you try -fno-tree-pre
> and -fno-tree-fre and see if it slows down again?
Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;)

Thanks.
(You really should thank richard guenther and steven bosscher, who
continually beat me up till i finished it :P)