Re: template class

[eric]

Dear Mr. Bjarne Stroustrup:

  Thanks your suggestion, I follow it but it show fatal error:Array.cpp:
no such file
so
I add #include "Array.cpp" in my main program, pg52.cpp
then
it can compile
but
when I run it, it response
Segmentation fault

again it's g++ 4.5.2.  What may cause wrong?

hope to see your suggestion/advice again, and thanks a lot in advance,
Eric
-

On Fri, 2011-06-10 at 22:18 -0400, bs wrote:
> On 6/10/2011 9:43 PM, eric wrote:
> > Dear Bjarne Stroustrup:
> >
> >I copied a piece of codes from book(C++ primer 3rd Ed) chapter 2 about
> > page 52.
> > but it failed to be compiled under my g++ 4.5.2
> > here is the program
> 
> That book is an antique, but I think that the problem may simply be that 
> you can't separately compile pg52.cpp and Array.cpp. Try 
> #include in Array.h .
> 
> > ---
> >
> > eric@eric-laptop:~/CppPrimer3$ g++ Array.cpp pg52.cpp
> > /tmp/ccE9MPMg.o: In function `main':
> > pg52.cpp:(.text+0x23): undefined reference to `Array::Array(int)'
> > pg52.cpp:(.text+0x37): undefined reference to
> > `Array::Array(int)'
> > pg52.cpp:(.text+0x4b): undefined reference to `Array::Array(int)'
> > collect2: ld returned 1 exit status
> > --
> > #include
> > #include "Array.h"
> >
> >
> >
> > int main() {
> >const int array_size = 4;
> >
> >// elemType becomes int
> >Array  ia(array_size);
> >
> >// elemType becomes double
> >Array  da(array_size);
> >
> >// elemType becomes char
> >Array  ca(array_size);
> >
> > int ix;
> >
> > for ( ix = 0; ix<  array_size; ++ix ) {
> >   ia[ix] = ix;
> >   da[ix] = ix * 1.75;
> >   ca[ix] = ix + 'a';
> >  }
> >
> >  for ( ix = 0; ix<  array_size; ++ix )
> >std::cout<<  "[ "<<  ix<<  " ]   ia: "<<  ia[ix]
> > <<  "\tca: "<<  ca[ix]
> > <<  "\tda: "<<  da[ix]<<  std::endl;
> >
> >   return 0;
> > }
> > ---
> > // Array.cpp
> >
> > #include "Array.h"
> >
> > /*
> > Array::Array(elemType *iarray, int iarray_size)
> > {
> >ia = iarray;
> >_size = iarray_size;
> > }
> > */
> >
> > template  Array::Array(const Array  &rhs )
> > {
> >ia = rhs;
> > }
> >
> > template  Array::Array(const int size )
> > {
> >_size = size;
> > }
> >
> >
> > --
> > #ifndef Array_H
> > #define Array_H
> >
> >
> > template<  class elemType>
> > class Array {
> > public:
> >// parameterize element type
> >explicit Array( int size = DefaultArraySize );
> >Array( elemType *array, int array_size );
> >Array( const Array&rhs );
> >
> >virtual ~Array() { delete [] ia; }
> >
> >bool operator==( const Array&  ) const;
> >bool operator!=( const Array&  ) const;
> >
> >Array&  operator=( const Array&  );
> >int size() const { return _size; }
> >
> >/* virtual */ elemType&  operator[](int index){ return ia[index]; }
> >/*
> >    virtual void sort();
> >
> >virtual elemType min() const;
> >virtual elemType max() const; */
> >/* virtual */ int  find( const elemType&value ) const;
> >
> > protected:
> > static const int DefaultArraySize = 12;
> >
> > int _size;
> > elemType *ia;
> > };
> >
> > #endif
> > ---
> > I asked mailing list in gcc, but so far I did not get any useful
> > response.  I know the book's author Stanley B. Lippman or Josee Lajoie
> > ever work with you.  And I tried to reach Stanley B. Lippman, I can not
> > find his email addreess.  I emailed Josee Lajoie but again never get any
> > message from her (for 2 or 3 days).
> > hope to get your help on this problem.
> > Thanks your efforts a lot in advance
> > Eric
> >
> >
> 

Re: [Bulk] Re: your (or Stroustrup) chapter.12.3.cpp (and 12.7.2.cpp)can not compile on my ubuntu/linux10.03

[eric]

On Sun, 2010-10-31 at 21:48 -0700, C.W. Holeman II wrote:
> You might try:
> 
> http://groups.google.com/group/ppp-public?pli=1
> 
> --
> C.W.Holeman II | cw...@julianlocals.com |  http://JulianLocals.com/cwhii
>  To only a fraction of the  human  race does God  give the  privilege of
>  earning one's bread doing what one would have  gladly pursued free, for
>  passion. I am very thankful. The Mythical Man-Month Epilogue/F.P.Brooks
> 
> 
> 

dear Holeman:

  I follow your advice read that mailing list (or newsgroup) article,
and download fltk-1.3.x-r7769
re autoconf
   ./configure
   make
   sudo make install


  then recompile

e...@eric-laptop:~/BStrou/usingC++4/code/Chapter12$ g++ -Wno-deprecated
chapter.12.7.2.cpp   -lfltk 
In file included from chapter.12.7.2.cpp:7:
Simple_window.h:17: error: reference to ‘Window’ is ambiguous
/usr/include/X11/X.h:96: error: candidates are: typedef XID Window
Window.h:26: error: class Graph_lib::Window
Simple_window.h:17: error: reference to ‘Window’ is ambiguous
/usr/include/X11/X.h:96: error: candidates are: typedef XID Window
Window.h:26: error: class Graph_lib::Window
e...@eric-laptop:~/BStrou/usingC++4/code/Chapter12$ 

--
should I also post this to X.org and gcc 's mailing list?
-
this is code of chapter.12.7.2.cpp(same as that newgroup's Drill.cpp)
again my compiler is not MS visual c++, it is gnu gcc 4.4.3 on linux
plz help

//--

int main ()
try
{ 
Point tl(100,100); // top-left corner of our window

Simple_window win(tl,600,400,"Canvas");
// screen coordinate tl for top-left corner
// window size(600*400)
// title: Canvas
win.wait_for_button(); // Display!
} 
catch(exception& e) {
// some error reporting
return 1;
}
catch(...) {
// some more error reporting
return 2;
}

//--
-

Re: GNAT, SJLJ and zero-cost exception handling

[Eric Botcazou]

> I'd like to know how I should go about building GCC such that I can choose
> between SJLJ and ZCX at compile time, using --rts=sjlj.

$srcdir/configure --enable-languages=ada --disable-libada
make [bootstrap]
make -C gcc gnatlib-sjlj
make install
in the $prefix/lib/gcc/$target/$version directory:
 - create 'sjlj' subdir
 - move 'adainclude' and 'adalib' subdirs to 'sjlj' subdir
rm gcc/stamp-gnatlib*
make -C gcc gnatlib-shared gnattools
make install

You need GCC 3.x or GCC 4.2 for GNAT SJLJ exceptions to work.

> From [2] it looks like this is a configure-time option only.

[2] describes GCC SJLJ, which is not the same as GNAT SJLJ.

-- 
Eric Botcazou

Re: GNAT, SJLJ and zero-cost exception handling

[Eric Botcazou]

> Do you mean that it does not work with GCC 4.1.1?

Yes, it doesn't work in the 4.1.x series.

> > [2] describes GCC SJLJ, which is not the same as GNAT SJLJ.
>
> How different?

The latter is a "primitive" form of SJLJ, the former is more structured.

> I was somehow suspecting that gnat1 supports both ZCX and SJLJ, looks in
> system.ads, and decides what kind of assembly code it needs to emit based on
> that.  Am I correct? 

Yes, you are.

> In that case, I need just one compiler and two libgnats, right?

Right.

-- 
Eric Botcazou

Re: Adding support for demangling MSVC symbols to libiberty

[Eric Christopher]

Has this been considered in the past, but rejected for some reason?


Don't see why it would. Could be useful.


Should I have posted this to a different GCC list? :P


This is fine.

-eric

Re: GNAT, SJLJ and zero-cost exception handling

[Eric Botcazou]

> I can confirm that gnat gcc 4.1.1 does *not* correctly handle SJLJ
> exceptions, at least on MinGW where SJLJ is currently the only viable EH
> mechanism.

The 2 SJLJ mechanisms should be available there, so you could try to use 
GCC SJLJ instead of GNAT SJLJ (set ZCX_By_Default to True in system.ads).

> Eric, how difficult would it be to backport a fix from 4.2 to 4.1?

Too invasive I'd think.

-- 
Eric Botcazou

stability of libgomp and libssp

[Eric Christopher]

We're thinking of including these libraries in the next version of OS  
X on the system so that 4.2 will work out of the box when either a) it  
is released, or b) leopard is released, whichever happens last. Since  
we need to keep abis stable, I was wondering if anyone planned on  
changing abi or if we can depend on all changes not breaking the abi  
of these libraries?


Thoughts? Comments? Plans? Assurances?

-eric

Re: stability of libgomp and libssp

[Eric Christopher]

On Oct 19, 2006, at 2:50 PM, Diego Novillo wrote:


Eric Christopher wrote on 10/19/06 17:33:


I was wondering if anyone planned on changing abi or if we can depend
on all changes not breaking the abi of these libraries?
There is nothing planned in that area, but I wouldn't want to  
guarantee ABI stability.  Mostly as a result of bug fixing.  Since  
this will
be the first official release, I expect several bugs that may  
introduce

ABI problems.



OK.

Unless you can use some kind of versioning, I don't see a good way  
to address this.


And as discussed on irc symbol versioning won't quite solve the  
problem anyhow. :)


thanks.

-eric

Re: GMP test

[Eric Christopher]

On Oct 23, 2006, at 4:15 PM, Paolo Bonzini wrote:




if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi

but I think that the whole test now belongs in the GCC  
subdirectory, not in the toplevel (it was anyway a hack for the  
sake of disabling Fortran).
Moving it is not really a good thing anyways as you are able to  
configure
and then do a "make -j3" and it is hard to figure out why the build  
fail

because you don't have the correct version of GMP/MPRF.


Maintainability first.  If something fails with parallel make, and  
is reproducible with plain "make" (i.e. doesn't screw up the build  
directory), I don't see a reason not to move it.  You'd do "make"  
anyway to check if a dependency is missing, wouldn't you?


Really, all I care about is having it depend on the languages enabled.  
It's driving me crazy at the moment on a non-fortran build.


-eric

Re: GMP test

[Eric Christopher]

Maintainability first.  If something fails with parallel make, and  
is reproducible with plain "make" (i.e. doesn't screw up the build  
directory), I don't see a reason not to move it.  You'd do "make"  
anyway to check if a dependency is missing, wouldn't you?


Really, all I care about is having it depend on the languages  
enabled. It's driving me crazy at the moment on a non-fortran build.




As was pointed out, gmp/mpfr are now used in the default code path.  
This is causing systems with multiple sets of libraries installed, or  
optional libraries installed in odd paths (/opt/local) to start  
overriding others.


Right now, for example there are two sets of libiconv found on my  
system. Configure finds one set in /usr/lib, but the -L added for gmp  
when I set it to /opt/local finds gnu libiconv  off in /opt/local  
which really isn't the desired result. Of course, I can work around  
this using --with-libiconv-prefix, but my configure line is starting  
to look a bit long...


At some point the configury should agree on how to find optional  
libraries. I don't mind picking either the system or the ones in .../ 
some-prefix, but it should be consistent in how it looks for libraries  
and headers.


Thoughts?

-eric

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

[Eric Botcazou]

> Lots of people seem to test release branches -- probably more than mainline
> -- and I would hope that using the fix from this PR is by far the strongest 
> contender.

Definitely.  People report bugs against released versions and expect fixes for 
these versions, not for versions that will be released one year from now.

> I think we'd be doing ourselves a favour by going with what we 
> expect to be the final fix and getting as much testing of it as possible.
> After all, it's not difficult to test & apply a patch to a branch at the
> same time as mainline, or to revert it in the same way.

Exactly my position. :-)

> Also, having patches on mainline and not a release branch can cause
> quite a bit of confusion.  Witness what happend with PR 28243, where I
> fixed something on mainline, but it was not directly approved for a
> release branch.  Then Eric B. worked around the same problem on the
> release branch and forward-ported the work-around to mainline, where
> it wasn't really needed.

I'd have said: "fixed a subcase" but the picture is globally correct.
Btw, what about backporting your fix?  Or is it too late now?

> I just don't think it's as obvious a call as your question above makes out.
> There are downsides to this approach too, especially when no one person
> is in overall charge of repository (mainline and branch).

Right.  And, in my opinion, these downsides are easily underestimated.

-- 
Eric Botcazou

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

[Eric Botcazou]

> Finally before I finish the retrospective part of this e-mail, I'll
> point out this isn't a sudden recent unilateral policy decision, but
> purely a crystallization of the prescribed GCC work-flow outlined in
> contributing.html that has been refined over many years.

I disagree.  I've been working on GCC for almost 5 years and you're the only 
maintainer who has ever requested me to wait before backporting a fix for a 
regression on a release branch.  That may be hard to believe, but I honestly 
think that I'm not rewriting history here.

> As a reviewer I have more comfort and faith in patches that have had more
> testing than those that haven't.  Given that different branches have
> differing stability/certainty requirements, it makes sense that its easier 
> to get a patch approached for mainline and/or 4.3, than it is for 4.1,
> 4.0 or 3.4.

In my opinion, it is (almost) always possible to make a judgment a priori.

> The obvious question is what can be done to learn from and prevent
> repeating the problems of the past.  I'd suggest that absolutely no-one
> could have forseen that the PR28690 would have adversely affected
> MIPS/libgcj.

Well, REG_POINTER is a tricky business as HP-UX maintainers can tell you.
However, we don't have to hold ourselves to an unrealistic standard; there 
will always be unexpected interactions, that's OK I'd think.

> I'm not sure that applying it immediately to the release branches would
> improve things.  Likewise, for David's current fix, we know it'll affect
> primary platforms that haven't been tested, we just don't know how.

So why not give the patch more exposure by putting it on the active release 
branch sooner than later?

> I think one source of the problem is that standards the that I hold
> myself to, may potentially be unrealistic for many contributors.

Definitely.  I'd say that the patches you review are not your babies, only 
those you write are. :-)

-- 
Eric Botcazou

Re: Abt RTL expression - Optimization

[Eric Botcazou]

> since p is a global variable, it can be used in other functions. Any
> other causes?

The first thing to do is to post a reproducer.  As Ian said, your code doesn't 
even compile...

-- 
Eric Botcazou

Re: compiling very large functions.

[Eric Botcazou]

> AFAIK not one of the tree optimizers disables itself, but perhaps we
> should. The obvious candidates would be the ones that require
> recomputation of alias analysis, and the ones that don't update SSA
> info on the fly (i.e. require update_ssa, which is a horrible compile
> time hog).

Tree alias analysis can partially disable itself though:

  /* If the program has too many call-clobbered variables and/or function
 calls, create .GLOBAL_VAR and use it to model call-clobbering
 semantics at call sites.  This reduces the number of virtual operands
 considerably, improving compile times at the expense of lost
 aliasing precision.  */
  maybe_create_global_var (ai);

We have found this to be quite helpful on gigantic elaboration procedures 
generated for Ada packages instantiating gazillions of generics.  We have 
actually lowered the threshold locally.

-- 
Eric Botcazou

Re: compiling very large functions.

[Eric Botcazou]

> > Tree alias analysis can partially disable itself though:
>
> No, it can't.  Tree alias representation can :)

I presume you're thinking of the pass that performs the analysis, while I was 
more thinking of the global machinery; my understanding is that the machinery 
will not be able to disambiguate memory accesses it would have been able to, 
if the limit were not reached.

> it is also not really partially disabling. It's really fully disabling
> in 99% of

Partially because it only affects call-clobbered variables IIUC.

-- 
Eric Botcazou

Re: build failure, GMP not available

[Eric Christopher]

I ended up including both your preference and mine.  Hopefully one or
other other (or both) end up being useful to users.



Thanks, this will help with some of the questions I received  
internally today.


-eric

Re: Problem with listing i686-apple-darwin as a Primary Platform

[Eric Christopher]

  Right now after patches by the Apple folks causes you to need a  
newer

dwarfutils which don't exist outside of Apple so the community of Free
Source and GCC is not helped by making Darwin a primary platform.
Maybe we should list a specific version of darwin which changes the
confusion of which darwin (Mac OS X) version is supposed to be able to
compile right out of the box.  Right now on the PowerPC side, Darwin
before 8 (so Panther and before) are broken bootstrapping the mainline
and is also broken on the 4.2 branch.


We're in stage1, breakages happen - see the current fun with gmp/mpfr as
well as c99 inlining. File a bug or bring a problem up for discussion.

As far as 4.2 this is the first I've heard of it. What's the problem?

-eric

Re: Problem with listing i686-apple-darwin as a Primary Platform

[Eric Christopher]

On Nov 6, 2006, at 8:59 PM, Andrew Pinski wrote:


On Mon, 2006-11-06 at 20:57 -0800, Eric Christopher wrote:

As far as 4.2 this is the first I've heard of it. What's the problem?


Well you need a new cctools which does not exist for 10.2.



While I'm sure you could be less specific, would you be more specific in
this case?

And, no offense, but 10.2 is quite old, I'm not sure that Apple is even
supporting it these days, but I'll leave that to the people that know
better. Perhaps odcctools would work for you?

-eric

Re: Problem with listing i686-apple-darwin as a Primary Platform

[Eric Christopher]

Except this is a different issue as the patch is for Darwin.
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00168.html


Geoff appears to have given a workaround for the problem and has
promised to inquire further about more up to date solutions. Another
solution, of course, is to revert the default back to stabs. Or use
Shantonu's workaround. Personally I agree with Daniel's complaint
on the issue and we may need to temporarily revert that single patch
until a newer dwarf-utilities can be distributed.



This is also one reason why I suggested a specific version of Darwin
that is required.


That may not be a bad idea.

Oh and 10.0, 10.1, 10.2 compiling with GCC are all broken (so is  
10.3).


I'd probably suggest at least 10.3.9 myself. I'm not sure since 10.3.x  
predates

my employment at apple, or what the current policy is regarding it.

-eric

Re: Problem with listing i686-apple-darwin as a Primary Platform

[Eric Christopher]

On Nov 7, 2006, at 5:24 AM, David Edelsohn wrote:


Eric Christopher writes:


Eric> We're in stage1, breakages happen - see the current fun with  
gmp/mpfr as
Eric> well as c99 inlining. File a bug or bring a problem up for  
discussion.


Yes, breakage happens in Stage 1, but the goal should be no
breakage.  Breakage is by no means inevitable.  As a consideration to
other developers, breakage should be fixed or reverted as soon as  
possible
to allow other work to proceed.  Other developers and other breakage  
is
not a valid excuse, IMHO -- problems cause by others is not a free  
pass.




Well, yes, did you see anything in what I wrote that argued differently?

-eric

Re: Problem with listing i686-apple-darwin as a Primary Platform

[Eric Christopher]

Eric> Well, yes, did you see anything in what I wrote that argued  
differently?


Yes, what I quoted, the comparison with gmp/mpfr and c99 inlining.
Those other problems are irrelevant.



I disagree, they were other examples of breakages.

-eric

Re: [m32c-elf] losing track of register lifetime in combine?

[Eric Botcazou]

> Combine (rightfully) knows that i becomes the constant 0xf and
> replaces the two constant shifts with it.  However, it doesn't update
> the life information.  So, we have a basic block (#3 below) which has
> register 28 live, but being assigned (i.e. it's really dead).  GCC
> notices this later, and dies.

See PR rtl-optimization/29329 for a variant.

> Ideas?

The combiner already knows how to update liveness information in some cases 
(lost REG_NOTEs) so I think that we probably need to extend this mechanism.

-- 
Eric Botcazou

Re: [m32c-elf] losing track of register lifetime in combine?

[Eric Botcazou]

> The problem is presumably arising from the REG_EQUAL notes.  Where are
> those being generated?  Why does this case not arise for other targets?

If the problem stems from REG_NOTEs, then it may again be a duplicate of PR 
rtl-optimization/25514.

-- 
Eric Botcazou

Re: bootstrap on powerpc fails

[Eric Botcazou]

> But note this is with RTL checking enabled (--enable-checking=rtl).

Can anyone refresh my memory: why is RTL checking disabled on the mainline?

-- 
Eric Botcazou

Re: bootstrap on powerpc fails

[Eric Christopher]

On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote:


Kaveh R GHAZI writes:


Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html

Kaveh> Perhaps we could take a second look at this decision?  The  
average system
Kaveh> has increased in speed many times since then.  (Although  
sometimes I feel
Kaveh> like bootstrapping time has increased at an even greater pace  
than chip

Kaveh> improvements over the years. :-)

I object.


Any reason other than the obvious "bootstrap already takes too long"?  
Andrew's suggestion seemed reasonable too.


-eric

Re: bootstrap on powerpc fails

[Eric Christopher]

On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote:


Kaveh R GHAZI writes:


Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html

Kaveh> Perhaps we could take a second look at this decision?  The  
average system
Kaveh> has increased in speed many times since then.  (Although  
sometimes I feel
Kaveh> like bootstrapping time has increased at an even greater pace  
than chip

Kaveh> improvements over the years. :-)

I object.


Any reason other than the obvious "I don't want bootstrap time to  
increase"?


-eric

Re: bootstrap on powerpc fails

[Eric Botcazou]

> Because it takes a LONG time.

Figures?  Tree checking is not cheap with GCC 4.x either.

-- 
Eric Botcazou

Re: bootstrap on powerpc fails

[Eric Botcazou]

> I can sympathize with that, I have a slightly different problem.  Right
> now there are some java test that time-out 10x on solaris2.10.  I run four
> passes of the testsuite with different options each time, so that 40
> timeouts.  (This is without any extra RTL checking turned on.)  At 5
> minutes each it adds up fast!
> http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00294.html

This happened at some point during 4.1 development too.  It turned out to be a 
code generation bug that was butchering the PTHREAD_* initializer macros.

-- 
Eric Botcazou

Re: bootstrap on powerpc fails

[Eric Botcazou]

> Figures?  Tree checking is not cheap with GCC 4.x either.

Here are mine (Athlon64 2.4 GHz, 1 GB, c,c++,objc,obj-c++,java,fortran,ada):

gcc version 4.3.0 20061103 (experimental)

assert,runtime (aka release):   115 min
assert,runtime,misc:176 min
assert,runtime,misc,gc: 186 min
assert,runtime,misc,gc,tree:203 min
assert,runtime,misc,gc,tree,rtl,rtlflag 266 min

So I was wrong, tree checking is still relatively cheap; misc and rtl are not.

-- 
Eric Botcazou

Re: Do not use autoconf 2.60 yet

[Eric Christopher]

You appear to have regenerated configure, on both mainline and 4.2  
branch,

with autoconf 2.60.  Could you please regenerate it with 2.59 in both
places?


Sure, I'll have to dig it up somewhere. It appears to be the default  
on FC6, I'll use that.


-eric

Re: Do not use autoconf 2.60 yet

[Eric Christopher]

On Nov 14, 2006, at 11:32 AM, Eric Christopher wrote:



You appear to have regenerated configure, on both mainline and 4.2  
branch,

with autoconf 2.60.  Could you please regenerate it with 2.59 in both
places?


Sure, I'll have to dig it up somewhere. It appears to be the default  
on FC6, I'll use that.


Done, sorry about that.

-eric

Re: libffi on Macintel?

[Eric Christopher]

On Nov 15, 2006, at 8:59 PM, Jack Howarth wrote:


Mike,
   The problem is that the Geoff rejected the configure.in patch
that removes libgcj from noconfigdirs...

http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00642.html

...as being too invasive for gcc 4.2. If you manually
apply that, it should build java fine with --disable-multilib
on Intel Darwin. Why don't you try to get that patch into
gcc trunk now that gcc 4.2 has branched?



Yup. You should just be able to commit it now.

-eric

RE: [avr-gcc-list] AVR byte swap optimization

[Eric Weddington]

You could always equate the macro to some inline assembly like what is done
for a number of avr-libc macros.

Eric Weddington 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Shaun Jackman
> Sent: Friday, November 17, 2006 4:31 PM
> To: avr-gcc-list@nongnu.org; gcc@gcc.gnu.org
> Subject: [avr-gcc-list] AVR byte swap optimization
> 
> The following macro expands to some rather frightful code on the AVR:
> 
> #define BSWAP_16(x) \
>  x) >> 8) & 0xff) | (((x) & 0xff) << 8))
> 
> uint16_t bswap_16(uint16_t x)
> {
>0: 9c 01   movwr18, r24
>2: 89 2f   mov r24, r25
>4: 99 27   eor r25, r25
>6: 32 2f   mov r19, r18
>8: 22 27   eor r18, r18
>   return BSWAP_16(x);
> }
>a: 82 2b   or  r24, r18
>c: 93 2b   or  r25, r19
>e: 08 95   ret
> 
> Ideally, this macro would expand to three mov instructions and a ret.
> Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
> with -O2.
> 
> I won't bother to show bswap_32 here, which produces a real disaster!
> Think 47 instructions, for what should be 6.
> 
> Cheers,
> Shaun
> 
> $ avr-gcc --version |head -1
> avr-gcc (GCC) 4.1.0
> 
> 
> ___
> AVR-GCC-list mailing list
> AVR-GCC-list@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> 

RE: [avr-gcc-list] Re: AVR byte swap optimization

[Eric Weddington]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Paul Brook
> Sent: Saturday, November 18, 2006 9:46 AM
> To: gcc@gcc.gnu.org; Shaun Jackman
> Cc: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] Re: AVR byte swap optimization
> 
> > Ideally, this macro would expand to three mov instructions 
> and a ret.
> > Is there anything I can do to help GCC along here? I'm 
> using GCC 4.1.0
> > with -O2.
> >
> > I won't bother to show bswap_32 here, which produces a real 
> disaster!
> > Think 47 instructions, for what should be 6.
> 
> Use gcc head, __builtin_bswap and make sure the AVR backend 
> implements the 
> bswap rtl patterns.

There's the problem. You can't just glibly say "make sure the AVR backend
implements the bswap rtl patterns". There are precious few volunteers who
are familiar enough with gcc internals and the avr port in particular to go
do just that. AFAIK, there is no bswap rtl pattern in the avr port, at least
there doesn't seem to be in 4.1.1.

 
> Future versions of gcc may also be able to recognise these 
> idioms without 
> using the builtin, but AFAIK that's not been implemented yet.

Plus there is a long lead time between when it is implemented on HEAD, then
branched, released from a branch, and then when it shows up in binary
distributions.

Eric Weddington

RE: [avr-gcc-list] Re: AVR byte swap optimization

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, November 19, 2006 3:55 AM
> To: Eric Weddington
> Cc: Paul Brook; gcc@gcc.gnu.org; Shaun Jackman; 
> avr-gcc-list@nongnu.org
> Subject: Re: [avr-gcc-list] Re: AVR byte swap optimization
> 
> On 11/19/06, Eric Weddington <[EMAIL PROTECTED]> wrote:
> > > Use gcc head, __builtin_bswap and make sure the AVR backend
> > > implements the
> > > bswap rtl patterns.
> >
> > There's the problem. You can't just glibly say "make sure 
> the AVR backend
> > implements the bswap rtl patterns". There are precious few 
> volunteers who
> > are familiar enough with gcc internals and the avr port in 
> particular to go
> > do just that. AFAIK, there is no bswap rtl pattern in the 
> avr port, at least
> > there doesn't seem to be in 4.1.1.
> 
> Why is that a problem?
> Do you have a different solution in mind?

> 
> > > Future versions of gcc may also be able to recognise these
> > > idioms without
> > > using the builtin, but AFAIK that's not been implemented yet.
> >
> > Plus there is a long lead time between when it is 
> implemented on HEAD, then
> > branched, released from a branch, and then when it shows up 
> in binary
> > distributions.
> 
> That happens with all improvements that are implemented between
> releases, so I don't see your point.

The original message went to the avr-gcc-list mailing list. I wasn't aware
that it also went to the gcc mailing list. There are different sets of
assumptions based on the audience.

A lot depends on where the OP is coming from, in wanting help:
Does the OP want a pre-built toolchain?
Does the OP build the toolchain from source?
Is the OP familiar with even patching the toolchain?

There are a number of people on the avr-gcc-list that when they say they
want help, they want the final, pre-built toolchain from a distributor to
fix their problem. They don't want to build the toolchain from source, or
they don't even know how to. Yes there are also people who can and will
build the toolchain from source but they are a small minority.

The point that I was making was to the original OP: yes, it would be great
to get it fixed, permanently. Historically there has never been enough
volunteers with the knowledge, capability, and the time on the avr port.

The audience on the gcc list is a completely different sort with different
assumptions. My apologies for annoying the people on the gcc list.

And yes I do have a different solution in mind:
Shaun, could you open a GCC bug report on this issue? Rask, could you then
post your implementation to that GCC bug report as a patch? Steven and Paul,
could you eyeball Rask's implementation and see if it is reasonable
impelementation? Rask, do you have FSF paperwork in place? If not, then
could somebody else, with FSF assignments in place, create a patch?

After all, you guys have a process to follow, right? ;-)

Eric Weddington

Re: AVR byte swap optimization

[Eric Christopher]

   It isn't only on the AVR that bswap_32() is nontrivial to get  
right.
These two versions would rule on the i386 if GCC would be just a  
little bit

smarter:



I prefer the single instruction bswap that we now generate for  
__builtin_bswap[32,64] myself...


-eric

Re: Configure test hangs on powerpc64-linux

[Eric Botcazou]

> It never returns from ppc64_elf_gc_mark_hook (spins looking things up
> in a hash table, I don't have the matching source handy).  I expect
> this is fixed in later binutils, but has anyone else seen this happen?
> Is there some way we can avoid an infinite loop in configure for this
> case?

The test needs to check that --gc-sections works, so indirectly invoking 
ppc64_elf_gc_mark_hook seems to be unavoidable.  You could try to tweak the 
contents of the sections if you understand why ppc64_elf_gc_mark_hook loops.

-- 
Eric Botcazou

Re: [PATCH] Canonical types (1/3)

[Eric Botcazou]

> This patch introduces canonical types into GCC, which allow us to
> compare two types very efficiently and results in an overall
> compile-time performance improvement.

Please avoid cross-posting, patches should go to gcc-patches@ only.

-- 
Eric Botcazou

Re: libffi compilation failure on Solaris 10?

[Eric Botcazou]

> This bug, documented in the installation instructions:
> [...]
> apparently can also be triggered by libffi on Solaris 10.  See
> http://www.mail-archive.com/g-wrap-dev@nongnu.org/msg00045.html and
> http://mail.python.org/pipermail/python-bugs-list/2006-July/034400.html
> for build logs.

I'm a bit skeptical, Kaveh and I have been building libffi on SPARC/Solaris 10 
for a couple of years without a hitch (3.4.x, 4.x) with the Sun tools.  Of 
course it all depends on the version of the Sun assembler or...

> Anybody knows what are the affected releases in this case, whether it is
> an assembler or linker bug, and whether there is a workaround?

... if the user is trying to link objects files assembled by the GNU assembler 
using the Sun linker.

-- 
Eric Botcazou

Re: Invoking static library automatically

[Eric Botcazou]

> I have built a static runtime library and i want the linker to access
> it automatically without having to pass it explicitly.

Wrong list, this one is for GCC development, not development with GCC.

Try [EMAIL PROTECTED] instead.

-- 
Eric Botcazou

Re: Richard Guenther appointed middle-end maintainer

[Eric Botcazou]

> Yes, congratulations Richard!

Auf Deutsch, bitte! :-)

-- 
Eric Botcazou

Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

[Eric Christopher]

to see if that eliminates the problems. Also I
assume Bradley remembered to install the build
before running make check. I see lots of libgomp
failures I believe those could be due to that.
Also, Bradley, did you remember to patch the
prune.exp scripts in the testsuite? You will
get a huge number of false failures due to
linker warnings at -m64 with -g if you don't.


Actually FWIW I agree, the fortran exp (and therefore libgomp) files  
don't

handle DYLD_LIBRARY_PATH at all, unlike the way that the C and C++
files do.

FWIW I'm running the tests right now, and I agree with Jack,
other than the failures with isfinite for long double and a couple
of other things darwin is remarkably clean in this situation.

-eric

Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

[Eric Christopher]

make -k -j 8 check >& check.log ; make mail-report-with-warnings.log

I got results that appear not much different from the powerpc-apple- 
darwin8.8.0 (i.e., 32-bit) results:


http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00267.html

i.e., these results don't show a particular fortran problem.



Oh good. I'd realized I'd used an older checkout earlier and was  
having to rerun them. Glad everything seems ok.


-eric

Re: bogon in a gcc-testresults post (sparc-sun-solaris2.8)

[Eric Botcazou]

> The report in
>
> http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00459.html
>
> claims to be from the 4_2_branch at
>
> Mon Dec 11 08:40:27 UTC 2006 (revision 119731)
>
> That's wrong; it's actually from
>
> Sun Dec 10 08:39:43 UTC 2006 (revision 119704)
>
> but the run took more than 24 hours and the cron job re-synced.  And
> that's without building Java.

Thanks for letting us know.

> The test wasn't using -j, and it's only a 400 MHz Sparc.  Seems I need
> to fix that.  Running the tests twice (for 32 and 64 bits) seems to take
> ages.

Right, this seems to be noticeably slower with 4.2, especially libstdc++.

-- 
Eric Botcazou

Re: libffi compilation failure on Solaris 10?

[Eric Botcazou]

> ...which seems to be the case. Even when configure is told to use gld,
> somewhere down the line, gcc eventually decides that it should use
> /usr/ccs/bin/ld instead.

You need to rebuild the whole compiler if you want to switch from the Sun 
tools to GNU binutils, i.e --with-gnu-ld should be passed to the configure 
line of GCC itself and the compiler entirely rebuilt.

-- 
Eric Botcazou

Re: [infrastructure] what about gmp and mpfr on multilibbed builds?

[Eric Botcazou]

> So, my question is this: Do I need to have libgmp and libmpfr
> available as both 32 and 64 bit variants?

No if you use only one compiler (i.e. the multilibbed 32-bit compiler).

-- 
Eric Botcazou

Re: [libgfortran, 4.2] Syntax error in array constructor

[Eric Botcazou]

> Any ideas what is going wrong here?

libgfortran/selected_int_kind.inc has very likely been corrupted, which would 
mean that your Fortran compiler is non-functional.  It should contain

  integer, parameter :: c = 3
  type (real_info), parameter :: real_infos(c) = (/ &
real_info (4, precision(0.0_4), range(0.0_4)), &
real_info (8, precision(0.0_8), range(0.0_8)), &
real_info (10, precision(0.0_10), range(0.0_10)) /)

or something along these lines.

-- 
Eric Botcazou

Re: [libgfortran, 4.2] Syntax error in array constructor

[Eric Botcazou]

> but again I got into troubles

libgfortran/selected_real_kind.inc is also generated.

-- 
Eric Botcazou

Re: [infrastructure] what about gmp and mpfr on multilibbed builds?

[Eric Botcazou]

> So, again, if I have a 32 bit compiler multilibbed enabled, then only
> 32 bit variants of gmp and mpfr libraries requires that gmp and/or
> mpfr routines are not used by the multilibbed libraries at all.
> Correct?

Correct, they are only used by the compiler itself.

> If gcc development would eventually make use of gmp and/or mpfr in the
> multilibbed libraries, that would require both 32 bit and 64 bit
> variants installed. If so, I wonder if the header files support
> multilibbed, 32 bit and 64 bit, install and use... in other words, I
> suppose gmp and mpfr should be multilibbed :)

Yes, that works, at least on x86-64/Linux.

-- 
Eric Botcazou

Re: building gcc4-4.3.0-20061223 on OSX 10.3 failed

[Eric Christopher]

On Dec 23, 2006, at 10:28 AM, Dominique Dhumieres wrote:


Building gcc4-4.3.0-20061223 on OSX 10.3 failed with:

...
gcc   -g -fkeep-inline-functions -no-cpp-precomp - 
DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC   -W -Wall -Wwrite-strings  
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute  
-fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/ 
genconstants \
build/genconstants.o build/rtl.o build/read-rtl.o build/ggc- 
none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/ 
print-rtl.o build/errors.o ../build-powerpc-apple-darwin7/libiberty/ 
libiberty.a

ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_integer_nonzerop
_integer_zerop


This was seen on a few platforms. I think it's due to zdenek's patch.

-eric

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bernd Schmidt on 12/30/2006 3:24 AM:
> Paul Eggert wrote:
>> That's great, but GCC has had many other hands stirring the pot.
>> I daresay a careful scan would come up with many other examples of
>> undefined behavior due to signed integer overflow.  (No doubt
>> you'll be appalled by them as well, but there they are.)
> 
> That's handwaving, not evidence.  Sorry, I'm unconvinced.

Here's an example from the intprops module of gnulib.  At least we have
identified the undefined behavior, but this set of macros is used in
production code (various coreutils, m4, ...) to check for overflow in
command line argument overflow.
http://cvs.savannah.gnu.org/viewcvs/gnulib/lib/intprops.h?rev=1.7&root=gnulib&view=auto

/* True if the arithmetic type T is an integer type.  bool counts as
   an integer.  */
#define TYPE_IS_INTEGER(t) ((t) 1.5 == 1)

/* True if negative values of the signed integer type T use two's
   complement, ones' complement, or signed magnitude representation,
   respectively.  Much GNU code assumes two's complement, but some
   people like to be portable to all possible C hosts.  */
#define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1)
#define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0)
#define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 < (t) -1)

/* True if the arithmetic type T is signed.  */
#define TYPE_SIGNED(t) (! ((t) 0 < (t) -1))

/* The maximum and minimum values for the integer type T.  These
   macros have undefined behavior if T is signed and has padding bits.
   If this is a problem for you, please let us know how to fix it for
   your host.  */
#define TYPE_MINIMUM(t) \
  ((t) (! TYPE_SIGNED (t) \
? (t) 0 \
: TYPE_SIGNED_MAGNITUDE (t) \
? ~ (t) 0 \
: ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
#define TYPE_MAXIMUM(t) \
  ((t) (! TYPE_SIGNED (t) \
? (t) -1 \
: ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1


I would really like to see gcc be able to warn when it is exploiting
optimization opportunities based on undefined wrap semantics, so that code
can easily be made robust against overflow without having to rely on
tedious code audits.  In my opinion, the expectation of sane overflow
semantics is just too pervasive in existing code to be able to audit
without compiler assistance.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFlnlT84KuGfSFAYARArTEAJ0XZHGg4ry9VCqNjYReplvfnOcWFwCdGeiq
eZeELW6hXlMZ9jXA7MeS3UI=
=+umQ
-END PGP SIGNATURE-

Re: Do we want non-bootstrapping "make" back?

[Eric Botcazou]

> Once upon a time, the --disable-bootstrap configure option wasn't
> necessary.  "make" built gcc, and "make bootstrap" bootstrapped it.
>
> Is this behavior useful?  Should we have it back again?

Is this a genuine question or some subtle attempt at mimicing Paul Eggert's 
cleverness to spark your own gigantic thread? :-)  Certainly, doing a mere 
build with "make" and a complete bootstrap with "make bootstrap" was rather 
reasonable, but you and other build machinery wizards convinced us that this 
would be a pain to support with toplevel bootstrap.  So what has changed?

-- 
Eric Botcazou

Re: Do we want non-bootstrapping "make" back?

[Eric Botcazou]

> Not much.  I'm convinced it would be feasible, but definitely not easy,
> so I wanted to see how much interest there was - seems like some, but
> not a lot.

Would this comprise retrofitting the support into the 4.2 branch?

-- 
Eric Botcazou

Re: Do we want non-bootstrapping "make" back?

[Eric Botcazou]

> I have no intention of touching the build system for the release
> branch, in any case.

So, assuming we go back to the old behaviour, 4.2.x would be the only series 
for which 'make' performs a complete bootstrap?  Seems a little odd.  I think 
we need a clear cut here: either automatic bootstrap is a good feature and 
we're done, or it (after all) isn't and no series of compilers should be 
released with it.

-- 
Eric Botcazou

Re: Build snapshots according to a more regular schedule

[Eric Botcazou]

> I'd like to see it closed, too, all Linux/BSD vendors I know of are either
> still using 3.x or have switched to 4.1 already.

Yes, 4.1.x seems to have been selected by various vendors as the codebase for 
their first GCC4-based release.

-- 
Eric Botcazou

Re: Mis-handled ColdFire submission?

[Eric Botcazou]

> I know Andrew replied privately, but I hope he doesn't mind me raising
> the issue on-list.  I just wanted to guage the general feeling as to
> whether I'd screwed up, and whether I should have submitted the patches
> in a different way.

The only problem I personally have is that you apparently successively replied 
to the previous post, which means that all the patches are tied to a single 
gigantic thread in my mailer. :-(

-- 
Eric Botcazou

Re: bug management: WAITING bugs that have timed out

[Eric Botcazou]

> > Saddest is that is that in a batch of various related bug closings, the
> > blanket comment "M68k/ColdFire is not a primary platform - CLOSED".
>
> That should not happen, they should only get their target milestone
> bumped.  I cannot remember having seen any case of a bug being _closed_
> just because the platform is not a primary one.

Neither can I.

-- 
Eric Botcazou

Re: fat binaries for FSF gcc on Darwin?

[Eric Christopher]

On Jan 13, 2007, at 6:13 AM, Jack Howarth wrote:


   I noticed that Apple's gcc compiler in MacOS X 10.4
creates fat binaries in /usr/lib rather than using a
ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin
gcc developers ever intend to replicate the use of fat
binaries for FSF gcc (in gcc 4.3 perhaps) or will
we always use separate subdirectories for 32-bit and
64-bit shared libraries?


All of that is done by a script that calls configure and post-processes
the resultant builds with the exception of libgcc which is built fat
in either place.

-eric

Re: debugging capabilities on AIX ?

[Eric Botcazou]

>   The reaction varies with developer. AIX continues to use
> xcoff/stabs.  The feedback of AIX users to IBM sales representatives and
> executives will determine the response.

FYI Sun has switched to DWARF-2 by default in Studio 11.  Just to put a bit of 
pressure on you. :-)

-- 
Eric Botcazou

Re: fat binaries for FSF gcc on Darwin?

[Eric Christopher]

On Jan 13, 2007, at 8:28 AM, Jack Howarth wrote:


Eric,
   So will FSF gcc on Darwin maintain the current 64-bit subdirectory
or will it eventually migrate to using fat binaries as Apple gcc does?


Current is likely.

-eric

Re: Preventing warnings

[Eric Botcazou]

> Since GNU Ada already has a pragma Warnings On/Off, if more than
> one front-end define it may be it's worth having a flag
> going through  the backend to suppress backend warnings too.

There is already TREE_NO_WARNING and the Ada compiler sets it on entities 
subject to pragma Warnings (entity, Off).  The problem of suppressing 
warnings for a whole given portion of code is of course more complex.

-- 
Eric Botcazou

Re: incorrect symlink on Darwin

[Eric Christopher]

On Jan 17, 2007, at 5:19 PM, Jack Howarth wrote:


 I noticed today that gcc 4.2 branch seems to create a bogus symlink
on Darwin PPC. A symlink for libgcc_s_x86_64.1.dylib is created that
points at libgcc_s.1.dylib. However libgcc_s.1.dylib is not a quad
binary...

file libgcc_s.1.dylib
libgcc_s.1.dylib: Mach-O fat file with 2 architectures
libgcc_s.1.dylib (for architecture ppc):Mach-O dynamically  
linked shared library ppc
libgcc_s.1.dylib (for architecture ppc64):  Mach-O 64-bit  
dynamically linked shared library ppc64


Is anyone else seeing this?


Yes, this is expected. If you somehow manage to build enough trees so  
that you can then lipo and get all four architectures together (ok,  
this only takes 2 trees), then the symlink will be correct.


-eric

Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

[Eric Botcazou]

> There's a later ;) simley in the mail and maybe you missed one after
> the second paragraph.  (certainly you did)

Then I guess the question is: what is the scope of a smiley?  Does it 
retroactively cover all the preceding sentences, including the subject?

-- 
Eric Botcazou

Re: Interesting build failure on trunk

[Eric Botcazou]

> libcpp/files.c:1238 seems to be a call to memcpy.  I don't see
> anyplace a floating point exception might come from.  I've certainly
> never seen anything like that.

Division by zero somewhere?

-- 
Eric Botcazou

Re: Interesting build failure on trunk

[Eric Botcazou]

> make STAGE1_CFLAGS="-O"
> BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE"
> profiledbootstrap

Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.

-- 
Eric Botcazou

Re: Interesting build failure on trunk

[Eric Botcazou]

> And I am still getting floating point exception even with a bare make. Any
> way to debug this?

Not easily unless you already know the innards of the compiler, I'm afraid.

-- 
Eric Botcazou

Re: gcc-4.1.2 RC1 build problem

[Eric Botcazou]

> however during 'make install' on the following architectures
>
>  alphaev56-dec-osf4.0f
>  alphaev68-dec-osf5.1b
>  sparc-sun-solaris2.8
>  i386-pc-solaris2.10
>  i386-pc-solaris2.9
>
> I ran into the following problem
>
> echo 'SYSTEM_HEADER_DIR="'"`echo /usr/include | sed -e :a -e
> "s,[^/]*/\.\.\/,," -e ta`"'"' \
>
> > /home/kate/gcc-4.1.2-20070128/alpha-OSF1-V4/lib/gcc/alpha
> >ev56-
>
> dec-osf4.0f/4.1.2/install-tools/mkheaders.conf
> /bin/sh: : cannot execute
> /bin/sh: /]*/../,, -e ta: not found
> sed: Function s,[ cannot be parsed.

That should not happen on Solaris if you set CONFIG_SHELL=/bin/ksh as 
recommended in http://gcc.gnu.org/install/specific.html#x-x-solaris2

-- 
Eric Botcazou

Re: How to get rid of attribute(mode(word))?

[Eric Christopher]

One target is to identify more places where we can get rid of  
_Unwind_Word.
Other places exist where we definitely need a data type like  
_Unwind_Word
representing a general purpose register.  So we have to find a way  
to define

_Unwind_Word without using the mode(word) attribute.


So, I might be missing something but I'm uncertain as to why you'd  
want to do this.


-eric

Re: How to get rid of attribute(mode(word))?

[Eric Christopher]

There was a long discussion about this a couple of months ago.  The
summary was that __attribute__ ((mode (word))) was considered harmful.
It's safe enough when you use it within a program, but when you start
to use in a data structure shared by different codes you run into ABI
problems.  A typical example is the eh_return_filter_mode target hook,
which was introduced (without documentation!) because Darwin needs to
access the same exception handling information with two different
values of word_mode.


I'm not sure I want to know why it seemed like a good idea for darwin  
to do this,

but it seems to be used for all of rs6000 as well. Whee.

Anyhow, I can see how it would be bad. Not sure how to handle it  
without breaking

how abi stuff is handled for darwin.

-eric

Re: Bug in value-prof.c:visit_hist

[Eric Botcazou]

> This patch bootstraps and passes make check on x86_64.

Please do not cross-post.  Patches should go to gcc-patches@ only.

-- 
Eric Botcazou

Re: GCC 4.1.2 RC2

[Eric Botcazou]

> 1.  g++.dg/debug/debug9.C fails as described in PR 30649.  I believe this
> is simply a mistaken testcase checkin.  If confirmed by someone, no big
> deal I can remove it.

Looks bogus to me like the 2 other testcases.

> 3.  gcc.c-torture/execute/20061101-1.c is a new failure at -O2 and at more
> opt levels with -fpic/-fPIC, but that testcase is from November so it's
> probably not a regression.

This is a real failure at -O2, caused by a bad iteraction between the old loop 
optimizer and the insn cost settings in the SPARC back-end.  But it's not a 
regression in the 4.x series.  Of course it will be gone in 4.2 and later.
I wrote a patch for the back-end at some point, but the problem is really in 
the old loop optimizer.  I think we can simply mark it as XFAIL on SPARC.

> I don't know whether any of these are important enough to hold up the
> release, most appear not.

The -fpic/-fPIC failures are a little annoying but other platforms probably 
have similar glitches, so we can live with them (I personally don't test
with -fpic/-fPIC so I have only the above 2 failures in my logs).

Results on other versions of Solaris are on par with those on Solaris 10.

-- 
Eric Botcazou

Re: GCC 4.1.2 RC2

[Eric Botcazou]

> Therefore, if the Java folks have daylight savings time patches that
> they would like to check in, please do so before Monday evening,
> California time.  If these work out, we'll leave them in for 4.1.2;
> otherwise, we'll back them out.  We will not do an RC4 simply to correct
> problems in these patches: the choices will be only to keep the patches
> checked in or to take them out entirely.

What about the patch for PR other/27843 then?

-- 
Eric Botcazou

Re: what is difference between gcc-ada and GNAT????

[Eric Botcazou]

> Furthermore, I am not really sure that the FSF testing
> infrastructure is setup to deal with tests of hundreds
> of thousands of lines of code.

Right, this is not the "spirit" of the GCC regression testsuite.
We instead strive to distill reduced testcases from these monsters.

-- 
Eric Botcazou

Re: GCC 4.2.0 Status Report (2007-02-19)

[Eric Botcazou]

> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).

Much more than in 3.x?

-- 
Eric Botcazou

Re: ancient history (was re: reduce dwarf debug size)

[Eric Botcazou]

> I could say much more (there are interesting stories about the
> behind-the-scenes politics) but it's off-topic.

Please think about writing a book telling the whole story when the dust will 
have settled. :-)

-- 
Eric Botcazou

Re: Massive SPEC failures on trunk

[Eric Botcazou]

> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
> CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
> Regression introduced somewhere between revision 122487 and 122478.

I observe a massive compilation time regression for bootstrap on x86-64 here, 
in particular libjava now appears to take *ages* to build:

revision 115944:
real255m53.382s
user230m40.934s
sys 13m20.426s

revision 116697:
real257m18.998s
user231m43.912s
sys 13m31.991s

revision 121500:
real257m50.984s
user230m46.276s
sys 12m19.737s

revision 121686:
real251m52.693s
user234m39.234s
sys 12m8.914s

revision 122521:
real687m3.830s
user374m37.001s
sys 19m26.378s

[EMAIL PROTECTED]:~/build/gcc/native> gcc/xgcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc/configure x86_64-suse-linux 
--prefix=/home/eric/install/gcc 
--with-as=/home/eric/build/binutils-2_17-branch/native/gas/as-new 
--with-ld=/home/eric/build/binutils-2_17-branch/native/ld/ld-new 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-__cxa_atexit 
--enable-checking=assert,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070304 (experimental)

I'm a bit puzzled by the real/user ratio, the box was supposed to be idle...

-- 
Eric Botcazou

Re: Massive SPEC failures on trunk

[Eric Botcazou]

> I observe a massive compilation time regression for bootstrap on x86-64
> here, in particular libjava now appears to take *ages* to build:

I cannot reproduce today at the same revision:

real275m23.314s
user242m28.724s
sys 12m18.249s

Something went awry with kpowersave yesterday... sorry for the noise.

-- 
Eric Botcazou

Re: Signed overflow patches OK for 4.2?

[Eric Botcazou]

> Then it should also be disabled by default also in 4.1.3 and should
> have been disabled in 4.1.2 which was only released last month so
> there is no reason why it has to be disabled in 4.2.0 if everyone is
> using 4.1 anyways.

VRP has become more aggressive in 4.2.x than in 4.1.x though.

-- 
Eric Botcazou

Re: Apple's Objective-C 2.0 extensions

[Eric Christopher]

Hi Michael,


Two questions about Apple's Objective-C 2.0 work:

1) Does anyone know when the syntax extensions will be available &  
working

in the gcc compiler?

2) Will their garbage collection & accelerated message dispatch  
mechanisms

also be supported?


Fairborz is working on them, I imagine that it won't be until they're  
done in Leopard, but I'll let him give more information.


-eric

Strange Behavior

[Eric Lemings]

Greetings,

While writing a generic C++ algoririthm for base64 encoding, I came
across
some very strange behavior.  If you take the following program
(admittedly
verbose for debugging purposes) and test it on some data, say the logo
image
from www.google.com, you may notice (depending on your platform) that
the
byte at offset 0230 (octal) is either read in with an incorrect value or
is
skipped entirely.

template < class InputItor, class OutputItor >
OutputItor
encode (InputItor first, InputItor last,
OutputItor out) {

  static const char s [] =
  "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
  "abcdefghijklmnopqrstuvwxyz"
  "0123456789+/";

  while (first != last) {
unsigned char uc0 = *first++;
int i0 = (uc0>>2) & 0x3f;
char c0 = s [i0];
*out++ = c0;

unsigned char uc1 = (first == last? 0: *first++);
int i1 = ((uc0<<4) + (uc1>>4)) & 0x3f;
char c1 = s [i1];
*out++ = c1;

bool eof = (first == last);
unsigned char uc2 = (eof? 0: *first++);
int i2 = ((uc1<<2) + (uc2>>6)) & 0x3f;
char c2 = (eof? '=': s [i2]);
*out++ = c2;

int i3 = uc2 & 0x3f;
char c3 = (first == last? '=': s [i3]);
*out++ = c3;
  }

  return out;
}

#include 
#include 
#include 
#include 
#include 
using namespace std;

extern int
main () {
  ifstream in ("logo.gif", ios_base::binary);

  istream_iterator< char > first (in);
  istream_iterator< char > last;
  string s;
  encode (first, last, back_inserter (s));

  cout << s;

  return 0;
}

You can boil the while loop down to it's basic read operations and still
see the same results.

  while (first != last) {
unsigned char uc0 = *first++;
unsigned char uc1 = (first == last? 0: *first++);
unsigned char uc2 = (first == last? 0: *first++);
}

Just for sake of sanity, I wrote a quick version of the algorithm in C.
Naturally, this program behaves as it should.

#include 
#include 

extern int
main (int argc, char* argv []) {

  FILE* in = fopen ("logo.gif", "rb");
  if (in == NULL) {
perror (argv[0]);
exit (EXIT_FAILURE);
  }

  const char s [] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz"
"0123456789+/";

  while (!feof (in)) {
unsigned char uc0 = fgetc (in);
int i0 = (uc0>>2) & 0x3f;
char c0 = s [i0];
putc (c0, stdout);

unsigned char uc1 = (feof (in)? 0: fgetc (in));
int i1 = ((uc0<<4) + (uc1>>4)) & 0x3f;
char c1 = s [i1];
putc (c1, stdout);

int eof = feof (in);
unsigned char uc2 = (eof? 0: fgetc (in));
int i2 = ((uc1<<2) + (uc2>>6)) & 0x3f;
char c2 = (eof? '=': s [i2]);
putc (c2, stdout);

int i3 = uc2 & 0x3f;
char c3 = (feof (in)? '=': s [i3]);
putc (c3, stdout);
  }

  fclose (in);

  return 0;
}

If anyone can shed some light on the strange behavior in the C++
program,
I would appreciate it very much.

Thanks,
Eric.

RE: Question for removing trailing whitespaces (not vertical tab) from source

[Eric Weddington]

 

> -Original Message-
> From: Dave Korn [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 13, 2007 9:59 AM
> To: 'Daniel Jacobowitz'
> Cc: 'Andrew Haley'; 'Kai Tietz'; gcc@gcc.gnu.org
> Subject: RE: Question for removing trailing whitespaces (not 
> vertical tab) from source
> 
> On 13 March 2007 15:12, Daniel Jacobowitz wrote:
> 
> > Personally I think that regardless of your indentation preferences,
> > using anything besides eight column tab stops for \t is 
> silly; that's
> > what "cat" is going to use.
> 
>   Well, I always *used* to think of a tab stop as being 
> unequivocally and
> universally equal to 8 columns too, but that was a long time 
> ago and since
> then bitmapped displays and WYSIWYG editors have come into being ... 

At the risk of extending this out further, can someone explain to me why 
using TABs is preferrable, as they are interpreted, while spaces are
unambiguous?

Not everyone uses emacs, vi, , or even GNU/Linux...

Eric

Re: core changes for mep port

[Eric Christopher]

This and the register changes come close to multi-arch gcc.  Is that a
direction we want to go?  Historically we have not tried to support


Personally I'd love to see us go this way if it doesn't inconvenience  
us too much.

From what I remember of the MeP port it was pretty clean and wouldn't
be an inconvenience.

-eric

Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?

[Eric Christopher]

Thanks for the answer, but I understand very little of it.


The above can be read as:

If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
is true, otherwise, TARGET_C99_FUNCTIONS is false.


So far so good.

we are targeting means that flag:


-mmacosx-version-min=version
The earliest version of MacOS X that this executable will
run on is version.
Typical values of version include 10.1, 10.2, and 10.3.9.

The default for this option is to make choices that seem
to be most useful.


Is this under the user control and how?


Yup. You can set it on the command line. A lot of people I've noticed  
set it to
10.3.9 for the latest panther update. 10.4 would mean tiger and  
above, and

10.5 will be leopard and above.




though, the exact default for this flag is changing (has change, is
going to change).


I noticed that!


The idea, I believe, is that the default will be the system that you  
are currently

on.




For example, if you tell it,


How could I? I would be interested by 10.3.9 (possibly 10.4.9).


gcc -mmacosx-version-min=10.3.9 ...




This is a part I cannot decipher.


Don't worry about that :) Basically it's depending things based on other
command line options by default. If, however, you always set it then you
should be fine there. I wouldn't set it for developing gcc, just using
gcc to develop some other application.

-eric

Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?

[Eric Christopher]

On Mar 17, 2007, at 4:15 PM, Dominique Dhumieres wrote:


Eric,

Thanks for the explanations.


The idea, I believe, is that the default will be the system that you
are currently on.


It would be nice, but it is not the way it seems to work (at least  
for gcc,

for g++ and gfortran it may, but I am not sure).  For instance
I have a version of 4.3.0 on 10.4. Without -mmacosx-version-min=10.4


The new method will be that the default will be the system that you are
currently on. It's not the default now.

-eric

Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?

[Eric Christopher]

On Mar 17, 2007, at 4:31 PM, Dominique Dhumieres wrote:

The new method will be that the default will be the system that  
you are

currently on. It's not the default now.


How new is new? As far as I can tell, it did not work for the
20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and
friends which do not pass for the 20070316 snapshot, it is
far from obvious that it is working. Is there a direct way
to check it?


It's not yet checked in :)

-eric

Re: gcc 4.2.0 RC1 darwin warnings...

[Eric Christopher]

../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:7597: warning:  
string length '575' is greater than the length '509' ISO C89  
compilers are required to support


Are these expected?


Yup.

-eric

Bitfield conversion bug in 4.2?

[Eric Lemings]

Hi,

The following code compiles fine in GCC 4.1.

enum E { e };
struct S {
  E v:5;
};
S s;
int main() { if (!s.v) return 0; }

In 4.2 (20070307), it gives the following error:

test.cpp: In function 'int main()':
test02.cpp:6: error: could not convert 's.S::v' to 'bool'
test02.cpp:6: error: in arguument to unary !

Is this a bug or new behavior?  If the latter, what is this attributed
to?

Thanks,
Eric.

Re: [Martin Michlmayr <[EMAIL PROTECTED]>] Documenting GCC 4.2 changes

[Eric Botcazou]

> 2006-02-07  Eric Botcazou  <[EMAIL PROTECTED]>
> config/sol26.h (CPP_SUBTARGET_SPEC): Accept -pthread.
> doc/invoke.texi (SPARC options): Document -pthread.

It's only an alias for the existing -pthreads, not worth mentioning IMO.

-- 
Eric Botcazou

Re: [Martin Michlmayr <[EMAIL PROTECTED]>] Documenting GCC 4.2 changes

[Eric Botcazou]

> So why is it there?  Compatibility with some other compiler?

To work around some laziness in libgomp. :-)  Other platforms only have 
-pthread it seems.

-- 
Eric Botcazou

Request for Bugzilla-only permissions

[Eric Weddington]

Hi,

Currently, and in the past I have been involved in the open source AVR
toolchain, mostly with other tools such as avr-libc
<http://savannah.nongnu.org/projects/avr-libc>, and in building a popular
distribution of the tools which include GNU Binutils and GCC. I have been
keeping track of AVR-specific bugs (and bugs that may remotely affect the
AVR port) with a list on the avr-libc project site on Savannah:
<http://www.nongnu.org/avr-libc/bugs.html>

My goal is to get more involved in Binutils, GCC, and possibly GDB, for the
AVR port, to help where I can. My FSF paperwork is in process on my
company's side but it may take a while. In the meantime I would like to
request Bugzilla-only permissions so I can at least help categorize the AVR
specific bugs.

All I am interested in is to be able to mark these bugs whether they have
been confirmed, or fixed, set the Keywords list, set the Known-to-work and
Known-to-fail lists, and in general just categorizing the latest state of
AVR bugs. Part of the reason for my request is some frustration in how long
it can take for other developers with permissions to come by and set these
fields after comments have been made on the bugs. Instead of being
frustrated, I'd much rather be able to help where I can. Besides, it will be
much easier to keep track of the state of the AVR port if these bugs are
better categorized as new information comes in. Also to that end, I'm trying
to do more to confirm the AVR bugs in my list.

Please note that I am *only* interested in bugs that affect, or may affect,
the AVR port at this time. I have no desire to mess around with bugs that
involve other areas.

Thanks for your time,
Eric Weddington 

Re: libstdc++.dylib linking problem on Darwin

[Eric Christopher]

That said, though, there's something weird going on in your build that
should probably be tracked down.  It didn't happen to me last time I
built...


Here's a patch that fixes it though it doesn't fix the testsuite  
results yet and is likely not quite what Daniel will want...


Dan?

The basic idea is that the darwin code uses slibdir to set the install  
name of the library - including full path. Yes, this is dumb, but it's  
the way that darwin does things at the moment. :(


We're getting slibdir set to null which makes the install name believe  
that it's rooted at / instead of $(slibdir)/.


-eric


Index: Makefile.in
===
--- Makefile.in (revision 123700)
+++ Makefile.in (working copy)
@@ -99,7 +99,7 @@ all: all-multi
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
$(MAKE) install DESTDIR=$(gcc_objdir) \
- slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)
+ slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR)
 
 .PHONY: all-multi
 all-multi:
@@ -820,4 +820,3 @@ include $(srcdir)/empty.mk $(wildcard *.
 #
 #   Remove use of $(gcc_srcdir).  Source files referenced using $(gcc_srcdir)
 #   should move into the libgcc directory.
-

Re: libstdc++.dylib linking problem on Darwin

[Eric Christopher]

I didn't just pull this out of a hat, you know :-)  Where do you think
it's going to install the library if you do that?


Yeah, I know. I said it wasn't a good patch, but I was on my way out  
of the office for the evening and wanted to get Doug something and  
have you look at the code too :)


-eric

Re: libstdc++.dylib linking problem on Darwin

[Eric Christopher]

On Apr 12, 2007, at 10:17 PM, Daniel Berlin wrote:

On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]>  
wrote:

I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.



The FSF libstdc++ is, I believe,
binary incompatible with the system one, and since system libraries
use the system one there is no way to guarantee that you're using the
right one for your code.

Okay, so uh, how do you propose to do a full bootstrap and test if you
can't test the built libstdc++?
In particular, since the testsuite sets the dyld library path, won't
this cause the system libs to try to use the libstdc++ you just built,
which is incompatible?
(This is mildly rhetorical, since this is indeed what happens, at
least as of 9A377a).


Yeah, it was less of a problem until we shipped a linker that uses  
libstdc++.

I'm looking into it when I get a chance.

-eric

RE: GCC 4.2.0 Status Report (2007-04-15)

[Eric Weddington]

 

> -Original Message-
> From: Mark Mitchell [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, April 15, 2007 4:51 PM
> To: GCC
> Subject: GCC 4.2.0 Status Report (2007-04-15)
> 
> However, I would consider asking the SC for permission to institute a
> rule that would prevent contributors responsible for P1 bugs (in the
> only possible bright-line sense: that the bug appeared as a result of
> their patch) from checking in changes on mainline until the P1 bug was
> resolved.  This would provide an individual incentive for 
> each of us to
> clean up our own mess.  I'm certain that someone will raise 
> the "latent
> bug" issue, but that's not the common case.  And, we can always decide
> to make an exception if necessary.  Of course, if we do this, I'd be
> happy to recuse myself as necessary, in order to avoid any 
> appearance of
> favoritism towards CodeSourcery personnel.
> 
> What do people think of that suggestion?

Instead of creating a new rule to try to convince people to get things done,
why not use your role of release manager and just not allow a release of 4.2
or 4.3 until the quality is deemed sufficient. If it takes longer to do a
release then so be it. Politely point out what is left to get done. The
status reports are a helpful reminder of the state of the branch.

Eric Weddington

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Kenneth Hoste [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 3:23 AM
> To: gcc@gcc.gnu.org
> Subject: GCC -On optimization passes: flag and doc issues

> - finline-functions is enabled at -Os, but isn't listed so

And it seems to have some issues:

Comments #4 and #6.

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 2:52 PM
> To: Eric Weddington
> Cc: Kenneth Hoste; gcc@gcc.gnu.org
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:
> > > - finline-functions is enabled at -Os, but isn't listed so
> >
> > And it seems to have some issues:
> > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528>
> > Comments #4 and #6.
> 
> The only real issue here is a wrong expectation: That a certain
> combination of flags magically does the best thing for every target.
> The -Ox options are "tuned" from time to time to get the best mix of
> results of a certain set of targets. 

Well this begs the question of why, when there are so many different
targets, are there are only 4 optimization flags (1,2,3,s), especially when
they only get tuned to certain targets? I know, "patches are welcome". ;-)

> That does not mean it does the
> best thing for all other targets. 

Bug #31528, comment #5:

"Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs?  I might give it a try to see whether I
can find a more optimal set of parameters."

This was in response to your comment in #4. Do you have any concrete
suggestions?

> Then, folks who like to complain
> come along and report silly bugs like this, 

Wow. Perhaps there is someone else here on the list who might point us in
the right direction, that doesn't think this is a silly bug, or that perhaps
thinks that we might be serious about getting this fixed for the AVR.

There is concerted effort to get the AVR port in shape wrt. fixing
outstanding bugs, updating the backend, regular regression testing, etc. One
of our goals is to propose the AVR to the "secondary platform" status,
hopefully in the next six months. The AVR is a popular GCC target, with
distros on FreeBSD, Linux, Windows, Mac OS X, it can build for Solaris, and
there have been at least 51,560 downloads in the last 2 months of the
Windows distro alone:
<http://sourceforge.net/project/stats/detail.php?group_id=68108&ugn=winavr&t
ype=prdownload&mode=60day&package_id=0>


> when perhaps they should
> also notice that the efficiency of GCC for -Os has increased
> tremendously in the past few years...

That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but they do care when there is a
compiled code size regression of even 1%. Yes, part of it is the
responsibility of the port, but there are other target-independent portions
that affect this too. It would be nice if GCC could try to take all users
into consideration.

Eric Weddington

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 2:52 PM
> To: Eric Weddington
> Cc: Kenneth Hoste; gcc@gcc.gnu.org
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:
> > > - finline-functions is enabled at -Os, but isn't listed so
> >
> > And it seems to have some issues:
> > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528>
> > Comments #4 and #6.
> 
> The only real issue here is a wrong expectation: That a certain
> combination of flags magically does the best thing for every target.
> The -Ox options are "tuned" from time to time to get the best mix of
> results of a certain set of targets. 

Well this begs the question of why, when there are so many different
targets, are there are only 4 optimization flags (1,2,3,s), especially when
they only get tuned to certain targets? I know, "patches are welcome". ;-)

> That does not mean it does the
> best thing for all other targets. 

Bug #31528, comment #5:

"Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs?  I might give it a try to see whether I
can find a more optimal set of parameters."

This was in response to your comment in #4. Do you have any concrete
suggestions?

> Then, folks who like to complain
> come along and report silly bugs like this, 

Wow. Perhaps there is someone else here on the list who might point us in
the right direction, that doesn't think this is a silly bug, or that perhaps
thinks that we might be serious about getting this fixed for the AVR.

There is concerted effort to get the AVR port in shape wrt. fixing
outstanding bugs, updating the backend, regular regression testing, etc. One
of our goals is to propose the AVR to the "secondary platform" status,
hopefully in the next six months. The AVR is a popular GCC target, with
distros on FreeBSD, Linux, Windows, Mac OS X, it can build for Solaris, and
there have been at least 51,560 downloads in the last 2 months of the
Windows distro alone:
<http://sourceforge.net/project/stats/detail.php?group_id=68108&ugn=winavr&t
ype=prdownload&mode=60day&package_id=0>


> when perhaps they should
> also notice that the efficiency of GCC for -Os has increased
> tremendously in the past few years...

That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but they do care when there is a
compiled code size regression of even 1%. Yes, part of it is the
responsibility of the port, but there are other target-independent portions
that affect this too. It would be nice if GCC could try to take all users
into consideration.

Eric Weddington

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 4:20 PM
> To: Eric Weddington
> Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch'; 
> 'Anatoly Sokolov'
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> Eric Weddington <[EMAIL PROTECTED]> writes:
> 
> > "Also, as you mention the target code has a chance to tune 
> this ..., can you
> > give me a hint about
> > where to look for these knobs?  I might give it a try to 
> see whether I
> > can find a more optimal set of parameters."
> > 
> > This was in response to your comment in #4. Do you have any concrete
> > suggestions?
> 
> Define OPTIMIZATION_OPTIONS in the CPU.h file.  See the internal
> documentation, and examples in many backends.

Thanks for your help. We'll look into it. 
 
> If the code size increases for AVR, when using -Os, when comparing an
> older release to mainline or 4.2 branch, you should report that as a
> regression in bugzilla.  Thanks.

Will change the bug report to reflect that.

Eric

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Mike Stump [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 4:28 PM
> To: Eric Weddington
> Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch'; 
> 'Anatoly Sokolov'
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
> > Well this begs the question of why, when there are so many  
> > different targets, are there are only 4 optimization flags  
> > (1,2,3,s), especially when they only get tuned to certain targets?
> 
> If you count again, you'll see there are more than 4 optimization  
> flags.  There are merely four in the set {-O0, -O1, -O2, -O3, - 
> Os}.  :-)  There are only 4 in the big-O set, as the poor 
> users can't  
> handle more.

Oh? I wonder how that decision was reached... 

> If you want to tune your target, well, patches welcome.

That's exactly what we're trying to do, sarcasm aside.

 
> > "Also, as you mention the target code has a chance to tune  
> > this ..., can you give me a hint about where to look for 
> these knobs?
> 
> See override_options (aka OVERRIDE_OPTIONS) in 
> config/i386/i386.c for  
> example.  See the documentation where this is described.  If you  
> wonder around some more port files, you can find all sorts of cost  
> things and tuning things, they might give you some addition ideas.

Thanks for the suggestion, it's very much appreciated. We'll look into it.

 
> If you set up a regression tester that checks nightly for code size  
> regressions on your platform and send hate mail whenever one 
> of these  
> events happens, you would be one step closer to having no  
> regressions.  

Thanks for the suggestion. I'll see what I can do to implement it.

> If you maintain your port, and ask others that do the  
> codesize tests (CSiBE), to also test your platform (if they don't  
> already), they might be willing to do that.

Well, there's part of the problem. Somehow, I don't think that CSiBE
testsuite was designed for an 8-bit micro. It will be difficult to do a real
comparison. But it's definitely a start if we can tune things from the
backend.

Eric

Re: GCC -On optimization passes: flag and doc issues

[Eric Christopher]

increase code size?  I feel I must be missing something really  
obvious... is
it just that the other optimisations that become possible on inline  
code

usually compensate?


That or the savings from not having to save/restore registers, set up  
the frame, etc as well.


-eric