question about pass management

[Prateek Saxena]

Hi, 
 
I have to run a pass which modifies the function types of all functions in a
a C file, by adding an extra parameter to each function. If this pass
runs like all other optimization passes, then this pass runs when each
function is being processed. So, for a prog like this:
 


int my_funct(int var, float hell)
{

  printf("%d",var);
}

int main()
{
  my_funct (4, 5.6);
}


if I modify the type of my_funct to take 3 args (int, int, float),
then the type checker ( which runs before my pass for "main" ) bombs
out saying that the call to "my_funct" has lesser than required
parameters. Where should I be running this pass? The way it looks is
that i need the pass manager to run my pass for all the functions,
instead of running all the passes for each function, and then
processing the next function. Is this possible to specify to the pass
manager?

Any help would be appreciated.

 

Thanks,

Prateek.

Re: -fprofile-generate and -fprofile-use

[Zdenek Dvorak]

Hello,

> >A more likely source of performance degradation is that loop unrolling
> >is enabled when profiling, and loop unrolling is almost always a bad
> >pessimization on 32 bits x86 targets.
> 
> To clarify, I was compiling with -funroll-loops and -fpeel-loops
> enabled in both cases.
> 
> The FDO slowdown in my case was caused by the presence of some loop
> invariant code that was getting removed from the loop by the loop
> optimizer pass in the non-FDO case.

you may try adding -fmove-loop-invariants flag, which enables new
invariant motion pass.

Zdenek

Re: doloop-opt deficiency

[Zdenek Dvorak]

Hello,

> Dale Johannesen wrote:
> > I think this is a simple pasto; this code was evidently copied from
> > the previous block:
> > 
> 
> I don't think that this was a simple pasto.  The code looks correct.
> We have the same code in tree-ssa-loop-niter.c around line 436, since
> we inherited this code from the rtl-level.

note the extra negation in loop-iv.c.  I think the fix is OK.

Zdenek

> > Index: loop-iv.c
> > ===
> > RCS file: /cvs/gcc/gcc/gcc/loop-iv.c,v
> > retrieving revision 2.35
> > diff -u -b -c -p -r2.35 loop-iv.c
> > cvs diff: conflicting specifications of output style
> > *** loop-iv.c   21 Jul 2005 07:24:07 -  2.35
> > --- loop-iv.c   29 Aug 2005 23:34:12 -
> > *** iv_number_of_iterations (struct loop *lo
> > *** 2417,2423 
> >   tmp0 = lowpart_subreg (mode, iv0.base, comp_mode);
> >   tmp1 = lowpart_subreg (mode, iv1.base, comp_mode);
> >   
> > ! bound = simplify_gen_binary (MINUS, mode, mode_mmin,
> >lowpart_subreg (mode, step, comp_mode));
> >   if (step_is_pow2)
> > {
> > --- 2417,2423 
> >   tmp0 = lowpart_subreg (mode, iv0.base, comp_mode);
> >   tmp1 = lowpart_subreg (mode, iv1.base, comp_mode);
> >   
> > ! bound = simplify_gen_binary (PLUS, mode, mode_mmin,
> >lowpart_subreg (mode, step, comp_mode));
> >   if (step_is_pow2)
> > {
> 
> 
> I don't think this fix is correct: 'bound' is used to test whether an
> overflow has occured, and in the following code that uses 'bound', it
> is expected to overflow for the example that you have provided:
> 
> /* If s is power of 2, we know that the loop is infinite if
>a % s <= b % s and a - s overflows.  */
> assumption = simplify_gen_relational (reverse_condition (cond),
>   SImode, mode,
>   bound, tmp0);
> 
> > 
> > 
> > The code as it was computed -2147483648-256 which overflows.
> 
> this is the right behavior.
> 
> > We noticed that the simple loop here
> 
> > extern int a[];
> > int foo(int w) {
> >   int n = w;
> >   while (n >= 512)
> > {
> > a[n] = 42;
> > n -= 256;
> > }
> >   }
> 
> > 
> > 
> > was being treated as ineligible for the doloop modification. 
> 
> The problem in this example is that the initial value of the induction
> variable is not known: it is a parameter 'w'.  Consequently we have
> not enough information to determine how many times it wraps, nor for
> estimating the number of iterations, if you're using the -fwrapv
> semantics.  
> 
> I'm not sure whether at rtl level we have this distinction of
> wrapping/non wrapping operations, but from the code that I've read,
> everything wraps (probably Roger Sayle knows more about the wrapping
> behavior that is expected at rtl level).  Having said this, we have to
> adjust the code at the tree level such that it catches this case
> (conditionally on signed iv and !fwrapv).
> 
> sebastian

Re: question about pass management

[Paolo Bonzini]

if I modify the type of my_funct to take 3 args (int, int, float),
then the type checker ( which runs before my pass for "main" ) bombs
out saying that the call to "my_funct" has lesser than required
parameters. Where should I be running this pass? The way it looks is
that i need the pass manager to run my pass for all the functions,
instead of running all the passes for each function, and then
processing the next function. Is this possible to specify to the pass
manager?


My guess is that you should run your pass as part of the 
inter-procedural analysis passes (IPA).  Maybe only if 
flag_unit_at_a_time is set.


Paolo

Re: doloop-opt deficiency

[Sebastian Pop]

Dale Johannesen wrote:
> No, look closer.  The version in loop-iv.c does a NEG of 'step' just
> before what's shown here.  The version in tree-ssa-loop-niter.c
> doesn't.  Reversing the operator does make them do the same thing.

Then, I think this is ok.  But you'll have to ask a middle-end
maintainer for checking this fix in.

Thanks,
Sebastian

RE: question about pass management

[Dave Korn]

Original Message
>From: Paolo Bonzini
>Sent: 31 August 2005 10:07

>> if I modify the type of my_funct to take 3 args (int, int, float),
>> then the type checker ( which runs before my pass for "main" ) bombs
>> out saying that the call to "my_funct" has lesser than required
>> parameters. Where should I be running this pass? The way it looks is
>> that i need the pass manager to run my pass for all the functions,
>> instead of running all the passes for each function, and then
>> processing the next function. Is this possible to specify to the pass
>> manager?
> 
> My guess is that you should run your pass as part of the
> inter-procedural analysis passes (IPA).  Maybe only if
> flag_unit_at_a_time is set.
> 
> Paolo


  My guess is that he should modify the relevant language frontend to add
the new parameter from the first moment it creates the trees for functions
and calls, rather than using an optimiser pass at all.  Would that
necessarily be any more difficult, overall?


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

mmx register moves through memory

[Vahur Sinijärv]

Hi !

I've found that latest GCC versions (past 4.0.0 and up to latest in CVS 
head) never use 'movd %genreg, %mmxreg' to load mmx registers and always 
insists doing it through memory eq.

'mov %genreg, (mem)'
'movd (mem), %mmxreg'

Older GCC versions do the same thing directly, without involving memory. 
These dummy uses of memory do not come out with with different 
optimization switches I've tried. After digging in GCC source code I 
found that:


gcc/config/i386/i386.c:
int ix86_secondary_memory_needed (enum reg_class class1, enum reg_class 
class2, enum machine_mode mode, int strict)

...

/* ??? This is a lie. We do have moves between mmx/general, and for 
mmx/sse2.

But by saying we need secondary memory we discourage the register allocator
from using the mmx registers unless needed. */

if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)) return true;
...

If I comment out that "if" line, mmx register assignments from general 
registers will work.
So, my question is: Should this requirement of using secondary memory to 
move MMX registers between general regs be relaxed ?
I do not see the point why you should discourage the register allocator 
from using mmx registers, move through memory is clearly inefficent and 
enlarges resulting code (if the function containing moves is inlined in 
several places, even more so).
What would be the correct code for MMX part of 
ix86_secondary_memory_needed() function.


Regards,
Vahur

Re: mmx register moves through memory

[Prakash Punnoor]

Hi,

Vahur Sinijärv schrieb:
> I've found that latest GCC versions (past 4.0.0 and up to latest in CVS
> head) never use 'movd %genreg, %mmxreg' to load mmx registers and always
> insists doing it through memory eq.
> 'mov %genreg, (mem)'
> 'movd (mem), %mmxreg'

I haven't read entirely through your mail, but I have reported above issue
already and it seems to be fixed in cvs:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23630

Cheers,

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V



signature.asc
Description: OpenPGP digital signature

GCC-3.4.5 status report

[Gabriel Dos Reis]

Hi,

  Despite a number of bug fixing patches applied to gcc-3_4-branch
(special thanks to Richard Sandiford), the total count of bugs open
against GCC-3.4.5 only has increased from 115 (last report) to 117
(this morning).  That reflects a continual flux of incoming PRs for
GCC-3.4.x and bugs present in 3.4.5, 4.0.x and 4.1.x fixed in the
last two branches but not in 3.4.x.  As ever, the C++ front-end is the
winner of the usual contest.

bootstrap: 2
  18532 libgcc.mk isn't parallel build safe for multilib
  22213 quoting of dir-variable in mklibgcc.in

c: 4
  16676 ICE with nested functions and -g1, blocks glibc
  20239 ICE on empty preprocessed input
  21536 C99 array of variable length use causes segmentation fault
  22061 internal compiler error: in find_function_data, at function.c:317

c++: 50
  11224 warning "value computed is not used" no longer emitted
  13377 unexpected behavior of namespace usage directive
  14500 most specialized function template vs. non-template function
  14950 always_inline does not mix with templates and -O0
  16021 Tests for container swap specialisations FAIL in debug mode
  16030 stdcall function decoration vs LTHUNK alias in multiple inheritanc
  16042 ICE with array assignment
  16276 G++ generates local references to linkonce sections
  16405 Temporary aggregate copy not elided
  16572 Wrong filename/line number were reported by g++ in inlining's warning 
messages
  17248 __always_inline__ throws "unimplemented" in -O0 mode
  17332 Missed inline opportunity
  17609 spurious error message after using keyword
  17655 ICE with using a C99 initializer in an if-condition
  17972 const/pure functions result in bad asm
  18273 Fail to generate debug info for member function.
  18368 C++ error message regression
  18445 ice during overload resolution in template instantiation
  18462 Segfault on declaration of large array member
  18466 int ::i; accepted
  18512 ICE on invalid usage of template base class
  18514 Alternate "asm" name ignored for redeclared builtin function imported 
into namespace std
  18545 ICE when returning undefined type
  18625 triple error message for invalid typedef
  18738 typename not allowed with non-dependent qualified name
  19004 ICE in uses_template_parms at cp/pt.c:4860
  19043 -fpermissive gives bad loop initializations
  19063 ICE on invalid template parameter
  19395 invalid scope qualifier allowed in typedef
  19396 Invalid template in typedef accepted
  19397 ICE with invalid typedef
  19441 Bad error message with invalid destructor declaration
  19628 g++ no longer accepts __builtin_constant_p in constant-expressions
  19710 ice on invalid one line C++ code
  19734 Another ICE on invalid destructor call
  19762 ICE in invalid explicit instantiation of a destructor
  19764 ICE on explicit instantiation of a non-template destructor
  19982 The left side of the "=" operator must be an lvalue.
  20152 ICE compiling krusader-1.5.1 with latest CVS gcc
  20153 ICE when C++ template function contains anonymous union
  20383 #line directive breaks try-catch statement
  20427 ()' not default initialized
  20552 ICE in write_type, at cp/mangle.c:1579
  20905 confuses unrelated type name with instance name
  21784 Using vs builtin names
  22215 g++ -O2 generates Undefined Global for statically defined function
  22233 ICE with wrong number of template parameters
  22545 ICE with pointer to class member & user defined conversion operator
  23162 internal compiler error: in c_expand_expr, at c-common.c:4138
  23287 Explicitly invoking destructor of template class

debug: 4
  16035 internal compiler error: in gen_subprogram_die, at dwarf2out.c:10798
  17076 ICE on variable size array initialization in debug mode in C++
  20253 Macro debug info broken due to lexer change
  21932 -O3 -fno-unit-at-a-time causes ICE

fortran: 4
  18913 seg. fault with -finit-local-zero option on complex array of dimension 1
  20774 Debug information in .o (from FORTRAN) points to temporary file under 
certain circumstances
  23460 g77 unable to locate fortran INCLUDE files when preprocessed
  23573 internal compiler error: in gen_subprogram_die

libf2c: 1
  17725 g77 libs installed in wrong directory

libobjc: 1
  11572 GNU libobjc no longer compiled on Darwin

libstdc++: 1
  11953 _REENTRANT defined when compiling non-threaded code.

middle-end: 4
  18956 'bus error' at runtime while passing a special struct to a C++ member 
function
  19183 ICE with -fPIC
  19371 Missing uninitialized warning with dead code (pure/const functions)
  22177 error: in assign_stack_temp_for_type, at function.c:655

other: 5
  15378 -Werror should provide notification of why gcc is exiting
  17594 GCC does not error about unknown options which starts with a valid 
option
  20731 contrib/gcc_update hard code -r gcc-3_4-branch
  22511 cc1plus: error: unrecognized command line option "-Wno-pointer-sign"
  23253 copyright year still at 2004

preprocessor: 2
  15307 Preprocessor ICE on invalid in

Re: mmx register moves through memory

[Vahur Sinijärv]

Hi,

No, the problem I wrote about is not fixed. I used GCC from CVS head
30.08.2005.
I think you found a different bug, you seem to have many unneccessary
uses of secondary memory between moves from MMX reg to MMX reg. The code
I wrote about (in i386.c) allows direct moves between MMX regs, but
prevents moves directly from general registers to MMX registers, so this
cannot be the case.

Regards,
Vahur

Prakash Punnoor wrote:


Hi,

Vahur Sinijärv schrieb:
 


I've found that latest GCC versions (past 4.0.0 and up to latest in CVS
head) never use 'movd %genreg, %mmxreg' to load mmx registers and always
insists doing it through memory eq.
'mov %genreg, (mem)'
'movd (mem), %mmxreg'
   



I haven't read entirely through your mail, but I have reported above issue
already and it seems to be fixed in cvs:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23630

Cheers,

 

Re: mmx register moves through memory

[Richard Guenther]

On 8/31/05, Vahur Sinijärv <[EMAIL PROTECTED]> wrote> Hi,
> 
> No, the problem I wrote about is not fixed. I used GCC from CVS head
> 30.08.2005.
> I think you found a different bug, you seem to have many unneccessary
> uses of secondary memory between moves from MMX reg to MMX reg. The code
> I wrote about (in i386.c) allows direct moves between MMX regs, but
> prevents moves directly from general registers to MMX registers, so this
> cannot be the case.

Please provide a testcase and report a bug with the
gcc.gnu.org/bugzilla interface.

Thanks,
Richard.

RE: question about pass management

[Daniel Berlin]

On Wed, 2005-08-31 at 10:50 +0100, Dave Korn wrote:
> Original Message
> >From: Paolo Bonzini
> >Sent: 31 August 2005 10:07
> 
> >> if I modify the type of my_funct to take 3 args (int, int, float),
> >> then the type checker ( which runs before my pass for "main" ) bombs
> >> out saying that the call to "my_funct" has lesser than required
> >> parameters. Where should I be running this pass? The way it looks is
> >> that i need the pass manager to run my pass for all the functions,
> >> instead of running all the passes for each function, and then
> >> processing the next function. Is this possible to specify to the pass
> >> manager?
> > 
> > My guess is that you should run your pass as part of the
> > inter-procedural analysis passes (IPA).  Maybe only if
> > flag_unit_at_a_time is set.
> > 
> > Paolo
> 
> 
>   My guess is that he should modify the relevant language frontend to add
> the new parameter from the first moment it creates the trees for functions
> and calls, rather than using an optimiser pass at all.  Would that
> necessarily be any more difficult, overall?

He's going to have to do that for all the frontends then, if he wants to
handle all the languages gcc supports.

This is something that the IPA level optimizers should be able to do
already without any pain, since it doesn't actually modify the
callgraph.


> 
> 
> cheers,
>   DaveK

Re: GCC-3.4.5 status report

[Richard Earnshaw]

On Wed, 2005-08-31 at 12:42, Gabriel Dos Reis wrote:
> rtl-optimization: 20
>   17810   internal compiler error: in verify_local_live_at_start for 
> arm-rtems, arm-linux

This is a dup of 15342.  I'm just testing a back-port of the fix to the
3.4 branch.

R.

Improved aliasing branch todo list

[Daniel Berlin]

I've put the current todo list (at least, my todo list) for the
improved-aliasing branch up on the wiki.


http://gcc.gnu.org/wiki/Improved%20Aliasing%20Todo%20List

Re: -fprofile-generate and -fprofile-use

[Peter Steinmetz]

>you may try adding -fmove-loop-invariants flag, which enables new
>invariant motion pass.

That cleaned up both my simplified test case, and the code it
originated from.  It also cleaned up a few other cases where I
was noticing worse performance with FDO enabled.  Thanks!!

Perhaps this option should be enabled by default when doing FDO
to replace the loop invariant motions done by the recently
disabled loop optimize pass.

Pete

Re: GCC-3.4.5 status report

[Volker Reichelt]

Just to let you know (to avoid duplicate work):

There are several C++ bugs assigned to Mark which he already
fixed on mainline and the 4.0 branch. Since he's busy with 4.0/4.1
regressions, I'll try to backport (at least some of) the patches
back to the 3.4 branch. (He agreed to that plan in private mail.)

Regards,
Volker

Re: mmx register moves through memory

[Richard Henderson]

On Wed, Aug 31, 2005 at 02:23:03PM +0300, Vahur Sinijärv wrote:
> So, my question is: Should this requirement of using secondary memory to 
> move MMX registers between general regs be relaxed ?

No.

> I do not see the point why you should discourage the register allocator 
> from using mmx registers, move through memory is clearly inefficent and 
> enlarges resulting code (if the function containing moves is inlined in 
> several places, even more so).

First, what you think is "clearly inefficient" is at least two cycles
faster, at least for AMD (Intel hasn't published anything as useful as
instruction latencies since early PentiumPro).  I'm not sure what sort
of pipeline bypasses are or are not responsible, but *all* cross function
unit moves are discouraged.

Second, proper use of MMX requires proper placement of emms instructions.
Allowing the register allocator to use MMX registers at will breaks that.


r~

Re: mmx register moves through memory

[Vahur Sinijärv]

I filed a bug #23660:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23660

Regards,
Vahur

Richard Guenther wrote:


On 8/31/05, Vahur Sinijärv <[EMAIL PROTECTED]> wrote> Hi,
 


No, the problem I wrote about is not fixed. I used GCC from CVS head
30.08.2005.
I think you found a different bug, you seem to have many unneccessary
uses of secondary memory between moves from MMX reg to MMX reg. The code
I wrote about (in i386.c) allows direct moves between MMX regs, but
prevents moves directly from general registers to MMX registers, so this
cannot be the case.
   



Please provide a testcase and report a bug with the
gcc.gnu.org/bugzilla interface.

Thanks,
Richard.
 

Re: GCC testsuite timeout question (gcc.c-torture/compile/20001226-1.c)

[Steve Ellcey]

> > By hand, I can compile the test in about 3 1/2 minutes on the machine in
> > question (the machine may have been busier when the failure occured and thus
> > taken longer). 
> 
> I think it's a real regression (memory consumption/speed) of the compiler, it 
> is timing out on all the slow SPARC machines I have (it is OK with 4.0.x).
> IIRC I observed the same regression between 3.2.x and 3.3.x on even slower 
> machines, but 3.4.x fixed it.
> 
> -- 
> Eric Botcazou

Yes, I think you are right.  I can see a substantial slowdown in
compilation times on IA64 HP-UX at -O2 (though it doesn't time out
there).

gcc 4.0.0 - 81 seconds
gcc 3.4.1 - 38 seconds
gcc 3.4.0 - 37 seconds
gcc 3.3.5 - 89 seconds
gcc 3.3.1 - 91 seconds

3.3 is slow, 3.4 is faster, 4.0.0 seems slow agin, I don't have 4.0.*
hanging around to test.

Looking at a timing report based on the 4.0.0 compiler it looks like
half the compile time is spent in the phase "dominance frontiers".

I will investigate some more.

Steve Ellcey
[EMAIL PROTECTED]

Running ranlib after installation - okay or not?

[Gerald Pfeifer]

We currently perform the following sequence of commands as part of the 
installation (-m 444 being the default on current FreeBSD systems).

  install -m 444 ./libgcc.a 
/prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/
  ranlib 
/prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/libgcc.a

This works fine when running as root, but when doing an installation as
user, installation fails:
 
  ranlib: unable to copy file 
'/prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/libgcc.a'
 reason: Permission denied
  gmake[2]: *** [install] Error 1


I believe installing libraries with permissions 444 ought to be okay,
as is for ranlib to refuse working on files which are not writeable.

Does anyone disagree (and if not, have suggestions how to address this
in GCC)?

Gerald

Re: Running ranlib after installation - okay or not?

[Ian Lance Taylor]

Gerald Pfeifer <[EMAIL PROTECTED]> writes:

> We currently perform the following sequence of commands as part of the 
> installation (-m 444 being the default on current FreeBSD systems).
> 
>   install -m 444 ./libgcc.a 
> /prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/
>   ranlib 
> /prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/libgcc.a
> 
> This works fine when running as root, but when doing an installation as
> user, installation fails:
>  
>   ranlib: unable to copy file 
> '/prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/libgcc.a'
>  reason: Permission denied
>   gmake[2]: *** [install] Error 1
> 
> 
> I believe installing libraries with permissions 444 ought to be okay,
> as is for ranlib to refuse working on files which are not writeable.
> 
> Does anyone disagree (and if not, have suggestions how to address this
> in GCC)?

ranlib is basically never required on a modern system.  It is really
only needed if the archive is built with the S option to ar.

So I think the best way to address this is to not run ranlib.

Ian

Re: Running ranlib after installation - okay or not?

[Shantonu Sen]

ranlib is required on Darwin after changing the timestamp of the  
archive.


Shantonu

On Aug 31, 2005, at 11:02 AM, Ian Lance Taylor wrote:


Gerald Pfeifer <[EMAIL PROTECTED]> writes:

We currently perform the following sequence of commands as part of  
the

installation (-m 444 being the default on current FreeBSD systems).

  install -m 444 ./libgcc.a /prefix/lib/gcc/i386-portbld- 
freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/
  ranlib /prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386- 
portbld-freebsd5.4/3.4.5/libgcc.a


This works fine when running as root, but when doing an  
installation as

user, installation fails:

  ranlib: unable to copy file '/prefix/lib/gcc/i386-portbld- 
freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/libgcc.a'  
reason: Permission denied

  gmake[2]: *** [install] Error 1


I believe installing libraries with permissions 444 ought to be okay,
as is for ranlib to refuse working on files which are not writeable.

Does anyone disagree (and if not, have suggestions how to address  
this

in GCC)?


ranlib is basically never required on a modern system.  It is really
only needed if the archive is built with the S option to ar.

So I think the best way to address this is to not run ranlib.

Ian

Re: Running ranlib after installation - okay or not?

[Andrew Pinski]

On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote:


Gerald Pfeifer <[EMAIL PROTECTED]> writes:


Does anyone disagree (and if not, have suggestions how to address this
in GCC)?


ranlib is basically never required on a modern system.  It is really
only needed if the archive is built with the S option to ar.

So I think the best way to address this is to not run ranlib.


If you consider Darwin "modern", then that statement is not correct
as moving/copying an archive on darwin, requires ranlib to be run.

-- Pinski

Re: GCC-3.4.5 status report

[Gabriel Dos Reis]

Volker Reichelt <[EMAIL PROTECTED]> writes:

| Just to let you know (to avoid duplicate work):
| 
| There are several C++ bugs assigned to Mark which he already
| fixed on mainline and the 4.0 branch. Since he's busy with 4.0/4.1
| regressions, I'll try to backport (at least some of) the patches
| back to the 3.4 branch. (He agreed to that plan in private mail.)

Thank you very much for the notice and the offer.  
I'll concentrate my effort on different areas.

-- Gaby

Re: Running ranlib after installation - okay or not?

[Joe Buck]

On Wed, Aug 31, 2005 at 02:15:46PM -0400, Andrew Pinski wrote:
> 
> On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote:
> 
> >Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> >
> >>Does anyone disagree (and if not, have suggestions how to address this
> >>in GCC)?
> >
> >ranlib is basically never required on a modern system.  It is really
> >only needed if the archive is built with the S option to ar.
> >
> >So I think the best way to address this is to not run ranlib.
> 
> If you consider Darwin "modern", then that statement is not correct
> as moving/copying an archive on darwin, requires ranlib to be run.

I suppose RANLIB could point to a script that checks for a readonly
archive, and if found, make it writable, run ranlib, then restore the
mode.  It's a kludge, true, but it might get the job done.

Re: GCC testsuite timeout question (gcc.c-torture/compile/20001226-1.c)

[Eric Botcazou]

> Yes, I think you are right.  I can see a substantial slowdown in
> compilation times on IA64 HP-UX at -O2 (though it doesn't time out
> there).
>
> gcc 4.0.0 - 81 seconds
> gcc 3.4.1 - 38 seconds
> gcc 3.4.0 - 37 seconds
> gcc 3.3.5 - 89 seconds
> gcc 3.3.1 - 91 seconds
>
> 3.3 is slow, 3.4 is faster, 4.0.0 seems slow agin, I don't have 4.0.*
> hanging around to test.

Thanks for the figures.

More generally, I think 3.4.x is overall faster than 3.3.x because someone 
really competent (Jan Hubicka) sat down a few weeks before the release and 
produced a series of patches only aimed at cutting down the memory 
consumption and speeding up the compiler.  So that's definitely doable, 
albeit certainly hard.

-- 
Eric Botcazou

Re: mmx register moves through memory

[Vahur Sinijärv]

Richard Henderson wrote:

I do not see the point why you should discourage the register allocator 
from using mmx registers, move through memory is clearly inefficent and 
enlarges resulting code (if the function containing moves is inlined in 
several places, even more so).
   



First, what you think is "clearly inefficient" is at least two cycles
faster, at least for AMD (Intel hasn't published anything as useful as
instruction latencies since early PentiumPro).  I'm not sure what sort
of pipeline bypasses are or are not responsible, but *all* cross function
unit moves are discouraged.

 

I see, i did a speed test with GCC 4.1.0 and 3.4.4 on my athlon-xp and 
you are right. Direct moves between genregs and MMX are still useful 
when optimizing for size. GCC could do a bit more sophisticated guesses 
whether to use secondary memory for such moves or not, right now it just 
disables them all.



Second, proper use of MMX requires proper placement of emms instructions.
Allowing the register allocator to use MMX registers at will breaks that.


r~
 

That is true, but would register allocator choose MMX regs for anything 
else than MMX ops ?


Regards,
Vahur

Re: Running ranlib after installation - okay or not?

[Ian Lance Taylor]

Andrew Pinski <[EMAIL PROTECTED]> writes:

> On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote:
> 
> > Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> >
> >> Does anyone disagree (and if not, have suggestions how to address this
> >> in GCC)?
> >
> > ranlib is basically never required on a modern system.  It is really
> > only needed if the archive is built with the S option to ar.
> >
> > So I think the best way to address this is to not run ranlib.
> 
> If you consider Darwin "modern", then that statement is not correct
> as moving/copying an archive on darwin, requires ranlib to be run.

Gah.  I keep forgetting about that.  Sorry.

Ian

Re: GCC-3.4.5 status report

[Gerald Pfeifer]

Installed.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.514
diff -u -3 -p -r1.514 index.html
--- index.html  24 Aug 2005 19:04:13 -  1.514
+++ index.html  31 Aug 2005 19:24:26 -
@@ -40,7 +40,7 @@ mission statement.
   GCC 3.4.4 (released 2005-05-18)
 
   Branch status:
-  http://gcc.gnu.org/ml/gcc/2005-08/msg00080.html";>2005-08-02
+  http://gcc.gnu.org/ml/gcc/2005-08/msg00926.html";>2005-08-31
   (open for regression and documentation fixes only).
 
 

Re: Running ranlib after installation - okay or not?

[Ian Lance Taylor]

Ian Lance Taylor  writes:

> Andrew Pinski <[EMAIL PROTECTED]> writes:
> 
> > On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote:
> > 
> > > Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> > >
> > >> Does anyone disagree (and if not, have suggestions how to address this
> > >> in GCC)?
> > >
> > > ranlib is basically never required on a modern system.  It is really
> > > only needed if the archive is built with the S option to ar.
> > >
> > > So I think the best way to address this is to not run ranlib.
> > 
> > If you consider Darwin "modern", then that statement is not correct
> > as moving/copying an archive on darwin, requires ranlib to be run.
> 
> Gah.  I keep forgetting about that.  Sorry.

Still, all this really means is that we should be host specific when
deciding whether or not to run ranlib.

In fact we are already host specific as to what flags we use.  On
Darwin we use -c, which we do not use on any other system.  Maybe we
should remove AC_PROG_RANLIB from configure.ac, and add something to
config.host instead.

Except that probably this has to get into libtool somehow or
something.  Hmmm.

Ian

[gfortran] Change language name from "f95" to "fortran"

[FX Coudert]

Attached patch changes the name of the language in --enable-languages 
from "f95" to "fortran", and in a few other places. There are still lots 
of places which are refered to as f95 (such as f951 ;-), but they are 
all internal uses.


I'm not very familiar with the mechanism of language names, so I might 
have forgotten some changes. Built and regtested on i686-linux. Comments?


FX
2005-08-31  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

* configure.in: Recognize f95 in the --enable-languages option,
and substitute it for fortran, issuing a warning.
* configure: Regenerate.

2005-08-31  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

* Make-lang.in: Change targets prefixes from f95 to fortran.
* config-lang.in: Change language name to "fortran".
* lang.opt: Change language name to "fortran".
* options.c: Change CL_F95 to CL_Fortran.

Index: configure.in
===
RCS file: /cvsroot/gcc/gcc/configure.in,v
retrieving revision 1.363
diff -u -3 -p -r1.363 configure.in
--- configure.in12 Aug 2005 14:18:41 -  1.363
+++ configure.in31 Aug 2005 19:28:22 -
@@ -506,15 +506,15 @@ case "${target}" in
 unsupported_languages="$unsupported_languages java"
 case "${target}" in
   *-*-aout)
-   unsupported_languages="$unsupported_languages f95"
+   unsupported_languages="$unsupported_languages fortran"
noconfigdirs="$noconfigdirs target-libffi target-boehm-gc";;
   *-*-elf)
-   unsupported_languages="$unsupported_languages f95"
+   unsupported_languages="$unsupported_languages fortran"
noconfigdirs="$noconfigdirs target-boehm-gc";;
   *-*-linux*)
noconfigdirs="$noconfigdirs target-newlib target-libgloss";;
   *)
-   unsupported_languages="$unsupported_languages f95"
+   unsupported_languages="$unsupported_languages fortran"
noconfigdirs="$noconfigdirs ${libgcj} target-newlib target-libgloss";;
 esac
 ;;
@@ -665,7 +665,7 @@ case "${target}" in
 ;;
   mmix-*-*)
 noconfigdirs="$noconfigdirs target-libffi target-boehm-gc gdb libgloss"
-unsupported_languages="$unsupported_languages f95 java"
+unsupported_languages="$unsupported_languages fortran java"
 ;;
   mn10200-*-*)
 noconfigdirs="$noconfigdirs ${libgcj}"
@@ -1142,6 +1142,15 @@ if test -d ${srcdir}/gcc; then
 fi
   fi
   enable_languages=`echo "${enable_languages}" | sed -e 's/[[  ,]][[   
,]]*/,/g' -e 's/,$//'`
+
+  # 'f95' is the old name for the 'fortran' language. We issue a warning
+  # and make the substitution.
+  case ,${enable_languages}, in
+*,f95,*)
+  echo configure.in: warning: 'f95' as language name is deprecated, use 
'fortran' instead 1>&2
+  enable_languages=`echo "${enable_languages}" | sed -e 's/f95/fortran/g'`
+  ;;
+  esac
 
   # First scan to see if an enabled language requires some other language.
   # We assume that a given config-lang.in will list all the language
Index: gcc/fortran/Make-lang.in
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/Make-lang.in,v
retrieving revision 1.20
diff -u -3 -p -r1.20 Make-lang.in
--- gcc/fortran/Make-lang.in13 Jul 2005 13:33:31 -  1.20
+++ gcc/fortran/Make-lang.in31 Aug 2005 19:28:24 -
@@ -82,7 +82,7 @@ F95_LIBS = $(GMPLIBS) $(LIBS)
 
 #
 # Define the names for selecting gfortran in LANGUAGES.
-F95 f95: f951$(exeext)
+FORTRAN fortran: f951$(exeext)
 
 # Tell GNU make to ignore files by these names if they exist.
 .PHONY: F95 f95
@@ -118,31 +118,31 @@ gt-fortran-trans-intrinsic.h: s-
 #
 # Build hooks:
 
-f95.all.build: gfortran$(exeext)
-f95.all.cross: gfortran-cross$(exeext)
+fortran.all.build: gfortran$(exeext)
+fortran.all.cross: gfortran-cross$(exeext)
 
-f95.start.encap: gfortran$(exeext)
-f95.rest.encap:
+fortran.start.encap: gfortran$(exeext)
+fortran.rest.encap:
 
-f95.srcinfo: doc/gfortran.info
+fortran.srcinfo: doc/gfortran.info
-cp -p $^ $(srcdir)/fortran
 
-f95.tags: force
+fortran.tags: force
cd $(srcdir)/fortran; etags -o TAGS.sub *.c *.h; \
etags --include TAGS.sub --include ../TAGS.sub
 
-f95.info: doc/gfortran.info
+fortran.info: doc/gfortran.info
 dvi:: doc/gfortran.dvi
 html:: $(htmldir)/gfortran/index.html
 
 F95_MANFILES = doc/gfortran.1
 
-f95.man: $(F95_MANFILES)
+fortran.man: $(F95_MANFILES)
 
-f95.srcman: $(F95_MANFILES)
+fortran.srcman: $(F95_MANFILES)
-cp -p $^ $(srcdir)/doc
 
-f95.srcextra:
+fortran.srcextra:
 
 check-f95 : check-gfortran
 lang_checks += check-gfortran
@@ -182,11 +182,11 @@ gfortran.pod: $(GFORTRAN_TEXI)
 # f951 is installed elsewhere as part of $(COMPILERS).
 
 # Nothing to do here.
-f95.install-normal:
+fortran.install-normal:
 
 # Install the driver program as $(target)-gfortran
 # and also as either gfortran (if native) or $(tooldir)/bin/gfortran.
-f95.install-com

Re: Running ranlib after installation - okay or not?

[Gerald Pfeifer]

On Wed, 31 Aug 2005, Ian Lance Taylor wrote:
 ranlib is basically never required on a modern system.  It is really
 only needed if the archive is built with the S option to ar.
>>> If you consider Darwin "modern", then that statement is not correct
>>> as moving/copying an archive on darwin, requires ranlib to be run.
> Still, all this really means is that we should be host specific when
> deciding whether or not to run ranlib.
> 
> In fact we are already host specific as to what flags we use.  On
> Darwin we use -c, which we do not use on any other system.  Maybe we
> should remove AC_PROG_RANLIB from configure.ac, and add something to
> config.host instead.
> 
> Except that probably this has to get into libtool somehow or
> something.  Hmmm.

Ouch, now you got me scared.  I already started testing a patch to remove 
the ranlib invocations that are part of the installation, but I'm afraid 
that level of configury work described above execeed what I feel confident 
hacking.

Is anyone else going to give it a try, or should it just file a Bugzilla?

Gerald

Re: -fprofile-generate and -fprofile-use

[girish vaitheeswaran]

I do not see this flag in gcc3.4.4. 


perflab2% gcc -o conftest -O3 -march=pentium4
-fmove-loop-invariants conftest.c
cc1: error: unrecognized command line option
"-fmove-loop-invariants"

Am I missing something?

-girish

--- Zdenek Dvorak <[EMAIL PROTECTED]>
wrote:

> Hello,
> 
> > >A more likely source of performance degradation
> is that loop unrolling
> > >is enabled when profiling, and loop unrolling is
> almost always a bad
> > >pessimization on 32 bits x86 targets.
> > 
> > To clarify, I was compiling with -funroll-loops
> and -fpeel-loops
> > enabled in both cases.
> > 
> > The FDO slowdown in my case was caused by the
> presence of some loop
> > invariant code that was getting removed from the
> loop by the loop
> > optimizer pass in the non-FDO case.
> 
> you may try adding -fmove-loop-invariants flag,
> which enables new
> invariant motion pass.
> 
> Zdenek
> 

Re: -fprofile-generate and -fprofile-use

[Eric Christopher]

On Aug 31, 2005, at 3:40 PM, girish vaitheeswaran wrote:


I do not see this flag in gcc3.4.4.


Am I missing something?





you may try adding -fmove-loop-invariants flag,
which enables new
invariant motion pass.


The "new invariant motion pass".

-eric

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

[John David Anglin]

> Used full distribution + make bootstrap. Used egcs-2.91.57 and 
> binutils-2.11.2 to compile gcc.

If you are interested in much improved C++ support, upgrade binutils to
2.16 or later and rebuild GCC with the new binutils.  This provides
one-only support under HP-UX 10.20.  You also need the latest (last)
HP linker patch for 10.20.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gerald Pfeifer wrote:
|>
|>Except that probably this has to get into libtool somehow or
|>something.  Hmmm.
|
|
| Ouch, now you got me scared.  I already started testing a patch to remove
| the ranlib invocations that are part of the installation, but I'm afraid
| that level of configury work described above execeed what I feel confident
| hacking.
|
| Is anyone else going to give it a try, or should it just file a Bugzilla?

Hi,
The problem is that libtool tries to run ranlib after install and that
ranlib can fail if the library is not writable? Note that on darwin running
ranlib on a 444 lib works and changes permissions to 644, remind me to file
a bug.

I would suggest continuing to run ranlib after install, but not failing if
it does not work. You need to look for the variable old_postinstall_cmds in
libtool.m4 and ltmain.m4sh (ltconfig and ltmain.sh in gcc??) and change
either how it is set or how it is run.

Another alternative would be to set RANLIB=: before configure if your system
does not need to ranlib anything.

Hope this helps,
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxZyhriDAg3OZTLPAQIpWgP9Fm5SHXP2X8CnpH7AAMkbSIcviisART3h
r9D4sXo4xLB253Yw8hxPsO1I6lQBTSUGV6cpK9C6eZEzb20u5YlqILe8x1jM/DDN
njjYOeY3Z9u7BQ0azKB8kE9FLzquDlpJ1hzJoBeKYYomFwilt5xXI+e74SPsskGf
I2naJmvC+yA=
=qEgR
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter O'Gorman wrote:
| The problem is that libtool tries to run ranlib after install and that
| ranlib can fail if the library is not writable?

[crosspost - beware - for context see
]

When I look more closely at this, I see in libtool.m4:
old_postinstall_cmds='chmod 644 $oldlib'

and a little later:
old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"

Should that be:
old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
??

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxaND7iDAg3OZTLPAQIenwQAw+FtzccBDNnixZdjK8gdI0Zaxu3xpX0D
9jPOkhPZaGMshTHF77W7h2ZxLmqmNwvWTlGjHCnwZXBuY3nW2Lms+ow0AZ9V+eP3
ADFRfvmlnkmkxl/pDiLKYPyCfJucuae1mAF8DMmWHN6gS3AknP0n4imybOp3GULd
FbSpIRKclJ0=
=COg3
-END PGP SIGNATURE-

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

[frankj]

On Wed, 31 Aug 2005, John David Anglin wrote:

Used full distribution + make bootstrap. Used egcs-2.91.57 and binutils-2.11.2 
to compile gcc.


If you are interested in much improved C++ support, upgrade binutils to
2.16 or later and rebuild GCC with the new binutils.  This provides
one-only support under HP-UX 10.20.  You also need the latest (last)
HP linker patch for 10.20.


Thanks!  Do you know if this includes pthreads support in C++?

-Frank.