Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Jakub Jelinek]

On Mon, May 16, 2005 at 05:26:36PM -0700, Mark Mitchell wrote:
> 2005-05-16  Mark Mitchell  <[EMAIL PROTECTED]>
> 
>   * gcc.dg/compat/generate-random.c (config.h): Do not include.
>   (limits.h): Include unconditionally.
>   (stdlib.h): Likewise.
>   * gcc.dg/compat/generate-random_r.c (config.h): Do not include.
>   (limits.h): Include unconditionally.
>   (stdlib.h): Likewise.
>   * gcc.dg/compat/struct-layout-1.exp: Do not link with libiberty.
>   * gcc.dg/compat/struct-layout-1_generate.c (config.h): Do not include.
>   (limits.h): Include unconditionally.
>   (stdlib.h): Likewise. 
>   (hashtab.h): Do not include.
>   (getopt.h): Likewise.
>   (stddef.h): Include.
>   (hashval_t): Define.
>   (struct entry): Add "next" field.
>   (HASH_SIZE): New macro.
>   (hash_table): New variable.
>   (switchfiles): Do not use xmalloc.
>   (mix): New macro.
>   (iterative_hash): New function.
>   (hasht): Remove.
>   (e_exists): New function.
>   (e_insert): Likewise.
>   (output): Use, instead of libiberty hashtable functions.
>   (main): Do not use getopt.  Do not call htab_create.

Thanks.

> + static hashval_t
> + iterative_hash (const void *k_in /* the key */,
> + register size_t  length /* the length of the key */,
> + register hashval_t initval /* the previous hash, or
> +   an arbitrary value */)
> + {
> +   register const unsigned char *k = (const unsigned char *)k_in;
> +   register hashval_t a,b,c,len;
> + 
> +   /* Set up the internal state */
> +   len = length;
> +   a = b = 0x9e3779b9;  /* the golden ratio; an arbitrary value */
> +   c = initval;   /* the previous hash value */
> + 
> +   /* handle most of the key */
> + #ifndef WORDS_BIGENDIAN
> +   /* On a little-endian machine, if the data is 4-byte aligned we can hash
> +  by word for better speed.  This gives nondeterministic results on
> +  big-endian machines.  */

WORDS_BIGENDIAN is not being defined in the headers that are included.
I think best would be just to kill this hunk and unconditionally do it the
slower way.

> +   if (sizeof (hashval_t) == 4 && (((size_t)k)&3) == 0)
> + while (len >= 12)/* aligned */
> +   {
> + a += *(hashval_t *)(k+0);
> + b += *(hashval_t *)(k+4);
> + c += *(hashval_t *)(k+8);
> + mix(a,b,c);
> + k += 12; len -= 12;
> +   }
> +   else /* unaligned */
> + #endif
> + while (len >= 12)
> +   {
> + a += (k[0] +((hashval_t)k[1]<<8) +((hashval_t)k[2]<<16) 
> +((hashval_t)k[3]<<24));
> + b += (k[4] +((hashval_t)k[5]<<8) +((hashval_t)k[6]<<16) 
> +((hashval_t)k[7]<<24));
> + c += (k[8] +((hashval_t)k[9]<<8) 
> +((hashval_t)k[10]<<16)+((hashval_t)k[11]<<24));
> + mix(a,b,c);
> + k += 12; len -= 12;
> +   }

Jakub

Re: GCC 4.1: Buildable on GHz machines only?

[Ralf Corsepius]

On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
> On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> > On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > > > Oh, and how helpful of you to post that patch to gcc-patches@ too...
> > > > NOT!
> > >
> > > Ah, I see you did post it to gcc-patches@, but not to fortran@, which
> > > is a requirement for gfortran patches -- and the reason why nobody
> > > has noticed the patch.
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02287.html
> > >
> > > The patch is OK too.
> >
> > Steven, please try to be politer to someone who is trying to help.
> 
> How is it helpful to not follow the rules when posting patches
Quite simple:

* I wasn't aware about this fortran specific patch posting policy. I
never have sent any gcc patch to any other list but gcc-patches for
approval before, so I also had not done so this time.

* How could I know that the responsible maintainers aren't listening to
bugzilla and gcc-patches, but are listening to a fortran specific list,
I even didn't know about until your posting?

>  and
> make exaggerated claims that something does not work?

I don't see where I exaggerated.

The fact that nobody before has hit these obvious issues, to me are
"just leaks" in GCC's QA/testing procedures/procedures, which ought to
be closed. If I weren't interested in seeing these closed, I would not
complain/file PRs on the and would not contribute/try to contribute
patches.

> > This kind of tone will only discourage contributors.
> 
> My tone was no different than Ralf's toward me.

Well, I admit I had been sarcastic/fatalistic in replying to Steven,
primarily, because I am pretty much frustrated about GCC's mainstream
developer's position/attitude on embedded targets.
Steven's answers perfectly queue-in into a long history of incidents
which had lead me to my understanding of "GCC mainstream developers'
attitude" on "embedded targets", which I already had described in former
postings.

Ralf

Re: GCC 4.1: Buildable on GHz machines only?

[Richard Earnshaw]

On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:

> No, I just don't build gfortran as a cross.  There are many reasons
> why this is a bad idea anyway.

Such as?

Re: GCC 4.1: Buildable on GHz machines only?

[Jonathan Wakely]

On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:

> * I wasn't aware about this fortran specific patch posting policy. I
> never have sent any gcc patch to any other list but gcc-patches for
> approval before, so I also had not done so this time.
> 
> * How could I know that the responsible maintainers aren't listening to
> bugzilla and gcc-patches, but are listening to a fortran specific list,
> I even didn't know about until your posting?

For future reference, where patches should be sent is explained here:
http://gcc.gnu.org/lists.html

jon

Re: GCC 4.1: Buildable on GHz machines only?

[Karel Gardas]

On Tue, 17 May 2005, Ralf Corsepius wrote:
This kind of tone will only discourage contributors.
My tone was no different than Ralf's toward me.
Well, I admit I had been sarcastic/fatalistic in replying to Steven,
primarily, because I am pretty much frustrated about GCC's mainstream
developer's position/attitude on embedded targets.
Steven's answers perfectly queue-in into a long history of incidents
which had lead me to my understanding of "GCC mainstream developers'
attitude" on "embedded targets", which I already had described in former
postings.
Ralf,
frustration will not help anybody nor GCC itself. Please look into GCC 3.4 
and GCC 4.0 release criteria documents:

http://gcc.gnu.org/gcc-3.4/criteria.html
http://gcc.gnu.org/gcc-4.0/criteria.html
you see that 4.0 added "embedded" platforms like arm-none-elf and 
mips-none-elf to the primary platforms list. That's IMHO just a sign that 
SC takes embedded developers seriously. Anyway, if you are not satisfied 
with this list, what about to suggest to SC to add some other more real 
embedded platform to this list to at least fix some of the most obvious 
problems? What platform would you suggest? I think that if you take the
discussion into this direction then we can see very good fruits comming 
from it, at least for some future GCC releases.

Thanks and I appreciate your hard work on rtems/gcc platform!
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Kiutaltunk egy "Eurorest" hotelcsekket

[Eurorest Információs Iroda]

Bravó ! Kiutaltunk Neked egy két fő részére, 14 ingyenes éjszakára 
szóló Eurorest hotelcsekket.

Ha korábban nem vettél részt az akcióinkban, akkor biztosan nem 
hitted eddig, hogy 1 üzenetért, amit az ismerőseidnek küldtél, egy olyan
hotelcsekk tulajdonosa lehetsz, amely 2 személy részére 14 ingyenes
éjszakát garantál a Magyarországon, Horvátországban, Szlovéniában,
Olaszországban, Franciaországban, Spanyolországban, Portugáliában,
Bulgáriában, Romániában, Németországban, Svájcban, Ausztriában,
Lengyelországban, Csehországban vagy Szlovákiában található
1000 hotel egyikében.
 
Most mégis bátran gratulálhatsz magadnak, az intuíciódnak, mert a jelenleg
folyó "Vakáció. 14 éjszaka ingyen" nemzetközi akció keretében kiutaltunk
Neked egy Eurorest hotelcsekket, és egy éved van arra, hogy felhasználd
a 14 ingyenes éjszakádat egy, az Eurorest rendszerhez csatlakozott,
általad szabadon kiválasztott szálláshelyen.

Az akciós csomag tartalma: 
1. Nemzetközi Eurorest hotelcsekk - 1 db.
2. Az Eurorest rendszer szabályzata - 1 db.

+---
| Az azonosítód(ID): Z5LPZ-SP4VX
+---
   Feltétlenül jegyezd meg az azonosítód, mivel szükség lesz rá a
   számodra kiutalt csekk átvételéhez - ne keverd a kiutalt csekk 
   alább megadott számával!

A kiutalt csekk sor./sz.: TT241393951
2005-05-17 12:02:42 napján maradt meg 36596 kiállítható csekk.

Látogass el most az alábbi oldalra:
http://www.eurorest.net/?lng=hu&uid=Z5LPZ-SP4VX 
ahol ki kell töltened a megrendelő űrlapot, megadva többek
között a címet, ahova a csekket küldjük, de előtte olvasd el az
alábbi instrukciót, hogy megismerd csekktulajdonos jogait és 
kötelezettségeit.

Az űrlap kitöltése előtt feltétlenül meg kell ismerkedned:
1. Az Eurorest Rendszer Szabályzatával - 
http://www.eurorest.net/?id=06&lng=hu&uid=Z5LPZ-SP4VX
2. Az "Info Eurorest" Hotelkatalógussal - 
http://www.eurorest.net/?id=03&lng=hu&uid=Z5LPZ-SP4VX
3. Az Eurorest Hotelcsekk Definíciójával - 
http://www.eurorest.net/?id=01&lng=hu&uid=Z5LPZ-SP4VX

Ennyi az egész. Kellemes pihenést kívánunk, abban a reményben, hogy 
további örömteli meglepetésben lesz részed!

Az Eurorest Információs Iroda Tanácsadói

P.S. Ha szeretnéd megtudni miért kapod a 14 ingyenes éjszakára 
szóló csekket és meg akarod ismerni az akció kulisszatitkait, vagy 
esetleg továbbra sem hiszed, hogy ez igaz lehet látogass el a 
"Hogyan lehetséges ez?" oldalra:
http://www.eurorest.net/?id=04&lng=hu&uid=Z5LPZ-SP4VX

Re: GCC 4.1: Buildable on GHz machines only?

[Steven Bosscher]

On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:

> On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> 
> > No, I just don't build gfortran as a cross.  There are many reasons
> > why this is a bad idea anyway.
> 
> Such as?

For one thing, libgfortran requires c99 support, which is not in
newlib iiuc.

Gr.
Steven

Re: GCC 4.1: Buildable on GHz machines only?

[Richard Earnshaw]

On Tue, 2005-05-17 at 11:16, Steven Bosscher wrote:
> On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> > 
> > > No, I just don't build gfortran as a cross.  There are many reasons
> > > why this is a bad idea anyway.
> > 
> > Such as?
> 
> For one thing, libgfortran requires c99 support, which is not in
> newlib iiuc.

Well, technically, that's a target/deeply-embedded problem.  That
doesn't mean that it shouldn't be possible to say cross-compile fortran
for Linux targets.

R.

Re: GCC 4.1: Buildable on GHz machines only?

[Ralf Corsepius]

On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> > 
> > > No, I just don't build gfortran as a cross.  There are many reasons
> > > why this is a bad idea anyway.
> > 
> > Such as?
> 
> For one thing, libgfortran requires c99 support, which is not in
> newlib iiuc.

More details please. 

Are you referring to stdint.h/inttypes.h etc.?
newlib/RTEMS has them, as well as newlib+cygwin

Ralf

Re: GCC 4.1: Buildable on GHz machines only?

[Eric Botcazou]

> For one thing, libgfortran requires c99 support, which is not in
> newlib iiuc.

In practice, no, it doesn't.  F95 works fine on Solaris 2.5.1, which is the 
typical non-C99 native platform.

-- 
Eric Botcazou

Re: GCC 3.4.4 RC2 (& ada/Make-lang.in)

[Georg Bauhaus]

Alexandre Oliva wrote:
On May 16, 2005, Georg Bauhaus <[EMAIL PROTECTED]> wrote:

-   cd ada/doctools && gnatmake -q xgnatugn
+   cd ada/doctools && gnatmake -q --GCC=$(CC) xgnatugn -largs --GCC=$(CC)

Don't you need quotes around $(CC),
Yes, there should be quotes.
(Without them the change is instance of someone messing with
configuration software, based on just his own momentary assumptions. ;-)
And of a good mailing list pointing out his error.)
In fact this change will make the commands consistent with
similar commands in testsuite/ada/acats/run_all.sh, at least WRT syntax.
thanks,
Georg 

Re: GCC 4.1: Buildable on GHz machines only?

[Steven Bosscher]

On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote:

> On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> > 
> > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> > > 
> > > > No, I just don't build gfortran as a cross.  There are many reasons
> > > > why this is a bad idea anyway.
> > > 
> > > Such as?
> > 
> > For one thing, libgfortran requires c99 support, which is not in
> > newlib iiuc.
> 
> More details please. 
> 
> Are you referring to stdint.h/inttypes.h etc.?
> newlib/RTEMS has them, as well as newlib+cygwin

Some other newlib (and non-newlib) targets don't, see PR14325 and
PR16135.  There was also some issue with c99 math functions that I
have not followed closely.  Some fixes for this went in for HP-UX
and Solaris.  I don't know if newlib always provides all the math
functions libgfortran asks for.

Note that I did not mean to imply that gfortran should not be
buildable as a cross, just that I know that there used to be some
problems with this.

Gr.
Steven

Re: GCC 4.1: Buildable on GHz machines only?

[Ralf Corsepius]

On Tue, 2005-05-17 at 12:52 +0200, Steven Bosscher wrote:
> On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> > > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> > > 
> > > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> > > > 
> > > > > No, I just don't build gfortran as a cross.  There are many reasons
> > > > > why this is a bad idea anyway.
> > > > 
> > > > Such as?
> > > 
> > > For one thing, libgfortran requires c99 support, which is not in
> > > newlib iiuc.
> > 
> > More details please. 
> > 
> > Are you referring to stdint.h/inttypes.h etc.?
> > newlib/RTEMS has them, as well as newlib+cygwin
> 
> Some other newlib (and non-newlib) targets don't, see PR14325 and
> PR16135. 

Well, extending the approach I chose to implement in newlib/RTEMS to
other target probably isn't too difficult, as well as it probably might
be possible to merge this approach into GCC.

>  There was also some issue with c99 math functions that I
> have not followed closely.  Some fixes for this went in for HP-UX
> and Solaris.  I don't know if newlib always provides all the math
> functions libgfortran asks for.
Neither do I know for sure, but so far, libgfortran's configure script
hasn't reported any problems.

> Note that I did not mean to imply that gfortran should not be
> buildable as a cross, just that I know that there used to be some
> problems with this.
There still are further problems on some targets (PR21203), but c99 and
math functions don't currenlty seem to be a problem with RTEMS/newlib.

Ralf

Why doesn't gcc.pot use gcc-internal-format?

[Jakub Jelinek]

Hi!

Bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
shows that it is very dangerous to not check format strings
in translations.  No translation of a particular message is always
better than a bad translation that causes compiler crash.

Now, looking at gettext, it seems to support GCC internal
message format, although older one (3.3.x - it doesn't grok e.g. %J,
q, ll and w format flags, %<, %>, %').

exgettext would probably need to pass --flag options in $kopt
(not sure if that needs to be in addition to --keyword or in addition to).

Jakub

Re: Proposed resolution to aliasing issue.

[Nathan Sidwell]

Mark Mitchell wrote:
  struct A {...};
  struct B { ...; struct A a; ...; };
  void f() {
B b;
g(&b.a);
  }
does the compiler have to assume that "g" may access the parts of "b" 
outside of "a".  If the compiler can see the body of "g" than it may be 
able to figure out that it can't access any other parts, or figure out 
which parts it can access, and in that case it can of course use that 
information.  The interesting case, therefore, is when the body of "g" 
is not available, or is insufficient to make a conclusive determination.
I attended a UK C++ panel meeting yesterday, and took the opportunity
to solicit opinions on this.  The question I posed was
struct A {
...
T1 a;
T2 b;
};
void g(T1 &a);
void Foo () {
   A v;
   v.b = 2;
   g (v.a);
   if (v.b == 2) ...
}
Does the compiler have a right to presume v.b does indeed == 2 in the if
condition? -- assuming T2 is a suitable type for that :)
After I explained the optimization (and the related structure splitting
optimization), the general consensus was 'yes that would be a useful
optimization'.  But no one was sufficiently confident of proving it
was allowable.  The opinion was expressed that if it was not allowable,
there was a bug in the std.
The observation was made that if A is non-POD, one cannot play offsetof
tricks to get from A::a to A::b, so the optimization is safe on non-PODs.
(Of course one would have to prove the address of 'v' did not escape,
so I guess the ctor and dtor would need to be trivial or visible.)
One of the panel members is looking at C++'s memory model WRT
multithreading.  This question has a direct impact there too, as
separate threads might be operating on v.a and v.b.  He indicated
he would consider the issue.
I also outlined the approach gcc would take with a compile time
switch and an attribute.  The preference was expressed that
the attribute should be of the form
void badfunc (A & __I_AM_BAD__ m);
rather than
void goodfunc (A & __I_AM_GOOD__ m);
because (a) badfuncs are more than likely rare and (b) it would be a useful
aid to the programmer.[1] Mark outlines an __I_AM_GOOD__ attribute,  I think
it would be better to have both flavours and then the compiler switch can
specify which way the default goes.
nathan
[1] it was of course noted that that looked stunningly like 'restrict', and
the suggestion that it be spelled 'noalias' was jokingly made :)
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Richard Guenther]

On 5/17/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote:
> 
> >>1. Remove the use of config.h and HAVE_*_H.
> >>
> >>2. Modify the generator not to depend on libiberty headers, including
> >>hashtab.h, by substituting a simple dictonary object.
> >>
> >>3. Adjust struct-layout-1.exp accordingly.
> >
> > This is what I would recommend anyhow.
> 
> Done with the attached patch.  Tested on x86_64-unknown-linux-gnu by
> comparing the generated files with and without the patch, as well as by
> running the testsuite.  The time taken to run the struct layout tests
> (including their generation) was not measurably different before and
> after the change.  Applied to 4.0 and mainline.

This broke testing on machines without an installed libiberty.h:

spawn gcc-3.4 -g -o
/tmp/gcc-obj/gcc/testsuite/gcc.dg-struct-layout-1_generate
/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c
/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random_r.c
^M
/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
libiberty.h: No such file or directory^M
/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random_r.c:56:23:
libiberty.h: No such file or directory^M
WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

Note how
  1. it uses $(CC) for building, not the built compiler
  2. it doesn't provide an include path to libiberty.h

Richard.

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Ian Lance Taylor]

Richard Guenther <[EMAIL PROTECTED]> writes:

> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
> libiberty.h: No such file or directory^M
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random_r.c:56:23:
> libiberty.h: No such file or directory^M
> WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
> 
> Note how
>   1. it uses $(CC) for building, not the built compiler

That is correct, as this program is run on the build system to
generate test cases.

>   2. it doesn't provide an include path to libiberty.h

I think that it no longer needs to include libiberty.h--in fact I'm
not sure generate-random.c ever needed it.  Try just removing the
#include.

Ian

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Andreas Schwab]

Ian Lance Taylor  writes:

> Richard Guenther <[EMAIL PROTECTED]> writes:
>
>> Note how
>>   1. it uses $(CC) for building, not the built compiler
>
> That is correct, as this program is run on the build system to
> generate test cases.

Shouldn't it use CC_FOR_BUILD then?

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why doesn't gcc.pot use gcc-internal-format?

[Joseph S. Myers]

On Tue, 17 May 2005, Jakub Jelinek wrote:

> Bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
> shows that it is very dangerous to not check format strings
> in translations.  No translation of a particular message is always
> better than a bad translation that causes compiler crash.
> 
> Now, looking at gettext, it seems to support GCC internal
> message format, although older one (3.3.x - it doesn't grok e.g. %J,
> q, ll and w format flags, %<, %>, %').
> 
> exgettext would probably need to pass --flag options in $kopt
> (not sure if that needs to be in addition to --keyword or in addition to).

Once there's a gettext release supporting GCC 4 formats (NB that %' is a 
format which is not expected to appear in the translated messages, only 
the untranslated ones, and as %< %> %' don't format any arguments it 
doesn't really matter whether they match in translated/untranslated 
formats; they can be handled like %%), I see no problem with updating 
install.texi regarding the required gettext version, patching exgettext 
(mainline and 4.0) and regenerating gcc.pot.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Ian Lance Taylor]

Andreas Schwab <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor  writes:
> 
> > Richard Guenther <[EMAIL PROTECTED]> writes:
> >
> >> Note how
> >>   1. it uses $(CC) for building, not the built compiler
> >
> > That is correct, as this program is run on the build system to
> > generate test cases.
> 
> Shouldn't it use CC_FOR_BUILD then?

No, I was wrong.  It uses the magic of DejaGNU to build the program on
the host system and run it over there, so $(CC) is correct.  See
testsuite/gcc.dg/compat/struct-layout-1.exp
for the details.  In any case it should not use the built compiler.

Ian

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Richard Guenther]

On 17 May 2005 08:59:07 -0400, Ian Lance Taylor  wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
> 
> > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
> > libiberty.h: No such file or directory^M
> > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random_r.c:56:23:
> > libiberty.h: No such file or directory^M
> > WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
> >
> > Note how
> >   1. it uses $(CC) for building, not the built compiler
> 
> That is correct, as this program is run on the build system to
> generate test cases.
> 
> >   2. it doesn't provide an include path to libiberty.h
> 
> I think that it no longer needs to include libiberty.h--in fact I'm
> not sure generate-random.c ever needed it.  Try just removing the
> #include.

It works after removing the libiberty includes from generate-random.c
and generate-random_r.c

Richard.

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Ian Lance Taylor]

Richard Guenther <[EMAIL PROTECTED]> writes:

> It works after removing the libiberty includes from generate-random.c
> and generate-random_r.c

Personally I think this change comes under the "obvious" rule, given
Mark's change yesterday to not link against libiberty.

Ian

Re: GCC 4.1: Buildable on GHz machines only?

[Joel Sherrill <[EMAIL PROTECTED]>]

This is really getting pretty far from the original topic but
I am diving in anyway.
Steven Bosscher wrote:
On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
Until package maintainers take cross-compilation *seriously*, I have
no choice but to do native compilation of a large hunk of the
packages on eval boards that can literally takes *DAYS* to build.
The most amazing fact to me is: Not even GCC seems to take cross-
compilation seriously :(
BS.  Even the large disto builders do cross compilations a lot.
So I suppose you have these general crossbuilding PRs fixed in your
sources:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143

No, I just don't build gfortran as a cross.  There are many reasons
why this is a bad idea anyway.
Why is something broken in the gfortran build infrastructure?
Assuming not, then it should only be a matter of needed functionality
in the target C library and native FP types.  I know gfortran
currently makes assumptions about the FP capabilities of a CPU
and some don't meet that.  But there is no reason one should not
be able use an x86 GNU/Linux system to cross build gfortran for
a powerpc or arm GNU/Linux system.
Oh, and how helpful of you to post that patch to gcc-patches@ too...
NOT!
Personal gripe.. I still don't know why posting a patch with a PR isn't 
sufficient. GCC has two independent systems.  Why can't Bugzilla just 
forward attachments marked as patches?

Is there anywhere in the GCC problem reporting instructions that says
attaching a patch to a PR is insufficient?  I know you don't get that
impression from the Bugzilla page you use to add it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247

I don't build Ada cross either, but AdaCore does, so you could ask
them to help you with this problem.
I don't really think they are the answer here.  GNAT has always been
implemented in Ada and has never been buildable without a native Ada 
compiler.  That's just the way it is.

The issue is what VERSION of GNAT is required to compile version X
of GNAT.  I don't try to track minimum versions required but in this
case, I think it moved up quite a bit.  From install.texi in gcc-4.0.0:
=
In order to build GNAT, the Ada compiler, you need a working GNAT
compiler (GNAT version 3.14 or later, or GCC version 3.1 or later),
including GNAT tools such as @command{gnatmake} and @command{gnatlink},
since the Ada front end is written in Ada (with some
GNAT-specific extensions), and GNU make.
==
So this could be viewed as only a documentation issue except that
one has to know where to get a binary for GNAT to start the build
process with.
Personally, I have always avoided this by building a native GNAT
first and using that to build the cross-GNAT.  It avoids this
issue entirely.
AdaCore has always helped avoid the problem by providing pre-built
binaries for a few platforms.  You can use these to kick-start
the process.
Another one I haven't filed yet, is GCC-4.x not correctly propagating
CFLAGS/CFLAGS_FOR_{BUILD|HOST|TARGET} to newlib in one-tree builds (I am
still investigating).

I don't build with newlib either.
I think that's the point -- no one builds all configurations so
everyone has to be very careful to use the right build magic
to keep them all working.
All these to me are strong indications that GCC-4.x has been poorly
tested in cross compilation.

No, just in the configurations you are using.
Possibly.  RTEMS may be the only non-GNU/Linux embedded cross target 
which tries to stay near the GCC head and is able to reasonably fully 
support languages other than C and C++.

The *-elf targets don't have the filesystem and threading support
required to fully support some of the other language run-times.
And since you're not posting the patches you attach to the bugzilla
PRs you open, you're not exactly helping to make things better either.
Gr.
Steven

--joel

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Richard Guenther]

On 17 May 2005 10:05:58 -0400, Ian Lance Taylor  wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
> 
> > It works after removing the libiberty includes from generate-random.c
> > and generate-random_r.c
> 
> Personally I think this change comes under the "obvious" rule, given
> Mark's change yesterday to not link against libiberty.

Done.

Richard.

Re: GCC 3.4.4

[Jonathan Wakely]

On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:

> I've very nearly ready to release GCC 3.4.4.  If you have objections or 
> high-priority fixes that you think will be required for this release, 
> please speak up within the next 24 hours.

Sorry for the last minute mail ...

It occurs to me that although we're not fixing this in 3.4.4

http://gcc.gnu.org/ml/libstdc++/2005-05/msg00105.html

we could document it, which would be a safe change:

Index: docs/html/debug.html
===
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/debug.html,v
retrieving revision 1.7
diff -u -p -b -B -r1.7 debug.html
--- docs/html/debug.html18 Nov 2003 20:56:07 -  1.7
+++ docs/html/debug.html17 May 2005 09:09:06 -
@@ -283,7 +283,9 @@
   under pedantic debug mode libstdc++ would signal an error. To enable
   the pedantic debug mode, compile your program with
   both -D_GLIBCXX_DEBUG
-  and -D_GLIBCXX_DEBUG_PEDANTIC .
+  and -D_GLIBCXX_DEBUG_PEDANTIC (N.B. due to a bug in GCC
+  3.4.x and 4.0.0 you also need -D_GLIBXX_DEBUG_PEDANTIC
+  to fully enable pedantic mode).

 The following library components provide extra debugging
   capabilities in debug mode:


-- 
"An alcoholic is someone you don't like who drinks as much as you do."
- Dylan Thomas

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Mark Mitchell]

Richard Guenther wrote:
Personally I think this change comes under the "obvious" rule, given
Mark's change yesterday to not link against libiberty.
 
Done.
Yes, this is an obvious patch; thank you.  I did not notice this problem 
because my machine does have a libiberty.h installed.  Would you please 
apply your patch to 4.0 as well, or, if you don't have time, let me know 
so that I can do that?

Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

"No matching function" -- not finding copy constructor

[Paul Koning]

I'm upgrading to V4.0.0 and struggling with some code that's seriously
into templates.  One puzzling error is this one:

keyed_obj.hh:159: error: no matching function for call to 
'CxnIndex::CxnIndex(CxnIndex)'
Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
Indeces.hh:145: note: ... and some more

It's not entirely clear to me why something very much like a copy
constructor is being invoked in the first place.  But the bigger
puzzle is: why isn't the copy constructor being matched?  I would have
thought that any call with a T argument should match a function or
method with an &T argument in its declaration...

   paul

Re: GCC 4.1: Buildable on GHz machines only?

[Joel Sherrill <[EMAIL PROTECTED]>]

Jonathan Wakely wrote:
On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:

* I wasn't aware about this fortran specific patch posting policy. I
never have sent any gcc patch to any other list but gcc-patches for
approval before, so I also had not done so this time.
* How could I know that the responsible maintainers aren't listening to
bugzilla and gcc-patches, but are listening to a fortran specific list,
I even didn't know about until your posting?

For future reference, where patches should be sent is explained here:
http://gcc.gnu.org/lists.html
OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
A search for "patch" in the bug reporting instructions does not mention
anything about cc'ing any patch list.
I'm not trying to be irritating here.  Just pointing out that if there 
is a procedure, it doesn't appear to be referenced in all the right 
places and isn't tied to the PR system.

Given the recent discussions of unfriendly responses, what if a new
person X found and bug and fixed it, they would file a PR with Bugzilla 
and most likely attach the patch.  And then there is a high probability 
that someone would not so kindly tell them they hadn't followed a 
procedure that doesn't appear to be mentioned anywhere they had seen
along the obvious path.

Putting on my CM hat:
  + Procedures do not exist unless they are documented.
  + Procedures that do not get assisted/enforced by tools are ignored.
jon
--joel

Re: "No matching function" -- not finding copy constructor

[Joe Buck]

On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
> I'm upgrading to V4.0.0 and struggling with some code that's seriously
> into templates.  One puzzling error is this one:
> 
> keyed_obj.hh:159: error: no matching function for call to 
> 'CxnIndex::CxnIndex(CxnIndex)'
> Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
> Indeces.hh:145: note: ... and some more
> 
> It's not entirely clear to me why something very much like a copy
> constructor is being invoked in the first place.  But the bigger
> puzzle is: why isn't the copy constructor being matched?  I would have
> thought that any call with a T argument should match a function or
> method with an &T argument in its declaration...

CxnIndex::CxnIndex(CxnIndex&) is not a general copy constructor.  Notice
the non-const reference.  The error message is saying that it's trying
to pass a temporary to a copy constructor.  You would need

CxnIndex::CxnIndex(const CxnIndex&)

to match that.  As for why you need a copy constructor, we'd have to
see the code for that, but this list isn't really the right place for
helping you debug this problem further.

Re: GCC 4.1: Buildable on GHz machines only?

[Jonathan Wakely]

On Tue, May 17, 2005 at 11:05:07AM -0500, Joel Sherrill <[EMAIL PROTECTED]> 
wrote:

> Jonathan Wakely wrote:
> >On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
> >
> >
> >>* I wasn't aware about this fortran specific patch posting policy. I
> >>never have sent any gcc patch to any other list but gcc-patches for
> >>approval before, so I also had not done so this time.
> >>
> >>* How could I know that the responsible maintainers aren't listening to
> >>bugzilla and gcc-patches, but are listening to a fortran specific list,
> >>I even didn't know about until your posting?
> >
> >
> >For future reference, where patches should be sent is explained here:
> >http://gcc.gnu.org/lists.html
> 
> OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
> 
> A search for "patch" in the bug reporting instructions does not mention
> anything about cc'ing any patch list.
> 
> I'm not trying to be irritating here.  Just pointing out that if there 
> is a procedure, it doesn't appear to be referenced in all the right 
> places and isn't tied to the PR system.

I never claimed it was easy to find!  :)

Ralf was right that posting a patch to bugzilla should get seen by the
relevant maintainers ... I was just pointing out that the procedure for
where to post patches *is* documented *somewhere*, however poorly.

jon

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Richard Guenther]

On 5/17/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> 
> >>Personally I think this change comes under the "obvious" rule, given
> >>Mark's change yesterday to not link against libiberty.
> >
> > Done.
> 
> Yes, this is an obvious patch; thank you.  I did not notice this problem
> because my machine does have a libiberty.h installed.  Would you please
> apply your patch to 4.0 as well, or, if you don't have time, let me know
> so that I can do that?

Done.

Richard.

Re: "No matching function" -- not finding copy constructor

[Jonathan Wakely]

On Tue, May 17, 2005 at 09:12:38AM -0700, Joe Buck wrote:

> On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
> > I'm upgrading to V4.0.0 and struggling with some code that's seriously
> > into templates.  One puzzling error is this one:
> > 
> > keyed_obj.hh:159: error: no matching function for call to 
> > 'CxnIndex::CxnIndex(CxnIndex)'
> > Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
> > Indeces.hh:145: note: ... and some more
> > 
> > It's not entirely clear to me why something very much like a copy
> > constructor is being invoked in the first place.  But the bigger
> > puzzle is: why isn't the copy constructor being matched?  I would have
> > thought that any call with a T argument should match a function or
> > method with an &T argument in its declaration...
> 
> CxnIndex::CxnIndex(CxnIndex&) is not a general copy constructor.  Notice
> the non-const reference.  The error message is saying that it's trying
> to pass a temporary to a copy constructor.  You would need
> 
> CxnIndex::CxnIndex(const CxnIndex&)
> 
> to match that.  As for why you need a copy constructor, we'd have to
> see the code for that, but this list isn't really the right place for
> helping you debug this problem further.

One GCC-related point is possibly worth mentioning: GCC is now much
stricter about enforcing the rule that a copy constructor must be
accessible even if the copy will be elided.

See the last entry of http://gcc.gnu.org/bugs.html#nonbugs_cxx

jon

Re: GCC 4.1: Buildable on GHz machines only?

[Joe Buck]

On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
> On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
> > On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> > > On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > > > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > > > > Oh, and how helpful of you to post that patch to gcc-patches@ too...
> > > > > NOT!
> > > >
> > > > Ah, I see you did post it to gcc-patches@, but not to fortran@, which
> > > > is a requirement for gfortran patches -- and the reason why nobody
> > > > has noticed the patch.
> > > >
> > > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02287.html
> > > >
> > > > The patch is OK too.
> > >
> > > Steven, please try to be politer to someone who is trying to help.
> > 
> > How is it helpful to not follow the rules when posting patches
> Quite simple:
> 
> * I wasn't aware about this fortran specific patch posting policy. I
> never have sent any gcc patch to any other list but gcc-patches for
> approval before, so I also had not done so this time.

There is a mention of this policy somewhere on the GCC web, but it's
in the cellar, at the bottom of a locked filing cabinet, with a sign
that says "beware of the leopard".

Or, rather, it's not mentioned on the bugs page, but on the mailing list
description page, which is not a place where it would occur to most people
to look.  Given this, we shouldn't be surprised if people make mistakes.

> > > This kind of tone will only discourage contributors.
> > 
> > My tone was no different than Ralf's toward me.

I can understand why Steven feels singled out; I jumped on him because
I really, really don't want people to be discouraged from submitting
patches, so that's why I objected publicly (rather than privately).

> Well, I admit I had been sarcastic/fatalistic in replying to Steven,
> primarily, because I am pretty much frustrated about GCC's mainstream
> developer's position/attitude on embedded targets.

To be fair, Ralf, I should ask you to be more polite as well, but you
have a perfect right to complain.

I used to be an embedded programmer myself, and while I cared very much
about the size and speed of the embedded code I wound up with, I didn't
care at all about being able to run the compiler itself on a machine that
wasn't reasonably up to date, much less trying to bootstrap the compiler
on an embedded target.  Is that really what we should be aiming for?  As
opposed to just making -Os work really well?  If I could get better embedded
code by having the compiler use a lot of memory, but I could easily afford
a machine with that amount of memory, I would have had no complaint.

It's true that there are many GCC developers who don't care much about
embedded systems, but there are others that care a lot.  But many GCC
developers lack the relevant expertise, 

It therefore seems that we have two *separate* problems: one is that
increased resource consumption makes gcc harder to use as a hosted
compiler on older systems, and the other is that embedded target support
isn't getting the attention it needs (if it weren't for the heroic efforts
of Dan Kegel, it would be far worse).  We shouldn't mix these two
together; it seems sometimes they get mixed solely because too many
free software projects don't support cross-compilation properly, but
that is a bug in those projects.

My evil plans for the next few weekends

[Daniel Berlin]

While my weekdays are booked with real stuff (structure aliasing,
array_ref/mem_ref, dependence, blah blah blah), the next couple weekends
i have plans to try to do some serious tree seperation.

My current evil plan is to try to seperate the really distinct _DECL
nodes into distinct DECL trees, sharing only the minimum they need to be
DECL's (UID, etc).

This is probably going to hurt, and will require things like using
FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
TYPE_DECL's, etc, instead of using DECL_ on both for some fields.

Before i go down this path (because it is a long hard road), does anyone
have any serious objection to having to use properly named macros to
access the trees?  This will probably add more code in some places that
trees all DECL's the same, since they won't be the same anymore, except
for the really really shared bits (again, UID comes to mind).

But you probably shouldn't have been doing that in the first place :)

--Dan

Re: GCC 4.1: Buildable on GHz machines only?

[Joel Sherrill <[EMAIL PROTECTED]>]

Joe Buck wrote:
I used to be an embedded programmer myself, and while I cared very much
about the size and speed of the embedded code I wound up with, I didn't
care at all about being able to run the compiler itself on a machine that
wasn't reasonably up to date, much less trying to bootstrap the compiler
on an embedded target.  Is that really what we should be aiming for?  As
opposed to just making -Os work really well?  If I could get better embedded
code by having the compiler use a lot of memory, but I could easily afford
a machine with that amount of memory, I would have had no complaint.
There are at least three classes of development I have noticed on this
thread:
  (1) self-hosting gcc on slow but traditional hosts (e.g. 68040 UNIX
or old Sun's)
  (2) self-hosted embedded development (e.g. sounds like Peter Barada)
  (3) embedded development using regular cross-compilation
In general all are concerned about lower end CPUs than are used for
the mainstream GCC user on GNU/Linux and other UNIces.
(1) and (2) are similar and probably have similar requirements.  They 
would like building GCC and running it to be possible on what would
be considered low end hardware for main-stream development purposes.

(3) is the model for RTEMS, other RTOSes, no-OS targets, and could
be the model used by (2).  I won't include (1) because they want their
systems to be self supporting and users will compile their own code.
We are all concerned about the time and memory required to build GCC.
But it is a critical concern for (1) and (2) since they are on small 
hosts.  For (3) and RTEMS, it concerns us because the RTEMS Project
provides RPMs for  11 targets and tries to include every language
we can possibly support (C, C++, Ada, FORTRAN, and Java).  I know for 
the targets that it compiles on, RTEMS works well with C, C++, and Ada.
I am unsure about the precise status of RTEMS+Java and FORTRAN is
currently up for discussion.  Our tool build times are thus very long 
and when we follow up by building RTEMS and add-on libraries, it
gets longer.  We struggle to keep up which is why RTEMS reports are
sporadic and tend to cluster nearer a release point.


It's true that there are many GCC developers who don't care much about
embedded systems, but there are others that care a lot.  But many GCC
developers lack the relevant expertise, 
I at least do recognize that.  And some of the problems the embedded
community reports are hard to recognize from native configurations.
It therefore seems that we have two *separate* problems: one is that
increased resource consumption makes gcc harder to use as a hosted
compiler on older systems, and the other is that embedded target support
isn't getting the attention it needs (if it weren't for the heroic efforts
of Dan Kegel, it would be far worse).  We shouldn't mix these two
together; it seems sometimes they get mixed solely because too many
free software projects don't support cross-compilation properly, but
that is a bug in those projects.
You are correct.  Many free libraries have rough edges when cross-building.
One thing that has been on my personal wish list a LONG time is
to get RTEMS configurations to properly run the GCC test suite.  [I 
normally test and report against *-elf since they are similar and 
easier.]  Many tests fail or can't run on the NO OS targets because 
there is assumption of functionality which isn't there.

RTEMS supports a RAM filesystem and POSIX threads which make it possible 
to run more tests than the NO OS targets.  For example, the complete Ada 
validation test suite can be run with near perfect results.  Similarly, 
other languages with  run-time requirements which RTEMS can meet.  It
should be possible to get better quality embedded target results across
more languages.

The problem is that the RTEMS Project does not have the expertise to do 
this.  We need some help from a DejaGNU/GCC testing expert.

Sorry for the length, this is an important issue to me.
--joel

Re: GCC 4.1: Buildable on GHz machines only?

[Joseph S. Myers]

On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote:

> > For future reference, where patches should be sent is explained here:
> > http://gcc.gnu.org/lists.html
> 
> OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
> 
> A search for "patch" in the bug reporting instructions does not mention
> anything about cc'ing any patch list.

The instructions on contributing to GCC, 
, do however link to lists.html for 
details of the appropriate lists, and give a lot of other information 
patch submitters will need to know.  (This information about mailing lists 
used to be duplicated in contribute.html and lists.html, but that way it 
got out of sync.)  I'm sure a patch to bugs.html to say "If you wish to 
submit a patch for a bug, see the instructions 
on contributing to GCC." would be considered.  Likewise I suppose we 
could arrange for the Bugzilla pages for individual bugs to make prominent 
notices about how to contribute patches - the page for entering new bugs 
has a big notice "Before reporting a bug, please read the bug writing 
guidelines, please look at the list of most frequently reported bugs, and 
please search for the bug." so those for individual bugs could have a 
notice pointing patch contributors to contribute.html.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: My evil plans for the next few weekends

[Zack Weinberg]

Daniel Berlin <[EMAIL PROTECTED]> writes:

> While my weekdays are booked with real stuff (structure aliasing,
> array_ref/mem_ref, dependence, blah blah blah), the next couple weekends
> i have plans to try to do some serious tree seperation.
>
> My current evil plan is to try to seperate the really distinct _DECL
> nodes into distinct DECL trees, sharing only the minimum they need to be
> DECL's (UID, etc).
>
> This is probably going to hurt, and will require things like using
> FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> TYPE_DECL's, etc, instead of using DECL_ on both for some fields.

For the record, I support this plan, including the more specific
accessor macro names.

zw

Re: GCC 4.1: Buildable on GHz machines only?

[Alexandre Oliva]

On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:

> you see that 4.0 added "embedded" platforms like arm-none-elf and
> mips-none-elf to the primary platforms list.

These are only embedded targets.  You can't run GCC natively on them,
so they don't help embedded hosts in any way.

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

Re: My evil plans for the next few weekends

[Richard Henderson]

On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
> This is probably going to hurt, and will require things like using
> FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> TYPE_DECL's, etc, instead of using DECL_ on both for some fields.

Can you be more specific on which fields this will be true for?

> Before i go down this path (because it is a long hard road), does anyone
> have any serious objection to having to use properly named macros to
> access the trees?  This will probably add more code in some places that
> trees all DECL's the same, since they won't be the same anymore, except
> for the really really shared bits (again, UID comes to mind).

Depending on what field, yes, I'll object.  There should be a "minimal
decl" for which the "normal" decl stuff should belong to.  DECL_ALIGN,
for instance.

> But you probably shouldn't have been doing that in the first place :)

Disagree.


r~

Re: GCC 4.1: Buildable on GHz machines only?

[Joseph S. Myers]

On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote:

> One thing that has been on my personal wish list a LONG time is
> to get RTEMS configurations to properly run the GCC test suite.  [I normally
> test and report against *-elf since they are similar and easier.]  Many tests
> fail or can't run on the NO OS targets because there is assumption of
> functionality which isn't there.

There are very few NO OS results posted to gcc-testresults and apparently 
none posted on a frequent basis; I expect this situation to change 
shortly.  All those posted (at least this month) seem to get posted with 
subject lines which do not match the normal form produced by test_summary 
and so don't get so readily found by my script which counts how many test 
results postings there are for different versions and targets.  For 
example, "Results for 4.1.020050506(experimental) testsuite on 
mips64-unknown-elf" with the components of the version number all run 
together or "Target: AVR Results for 4.1.0 200505 (experimental) in 
comparison to 4.1.0 20050416 (experimental)".  Ensuring your test results 
use the standard Subject header format makes it more likely they can 
handled properly by sites processing the gcc-testresults postings into 
databases of GCC test status on different targets (such as 
 but other sites have 
done this sort of thing before and may do so in future).

There are however reasonably frequent postings of test results for 
cross-compilers to embedded targets (such as sh4-linux and m32r-linux).

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: My evil plans for the next few weekends

[Daniel Berlin]

On Tue, 2005-05-17 at 10:46 -0700, Richard Henderson wrote:
> On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
> > This is probably going to hurt, and will require things like using
> > FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> > TYPE_DECL's, etc, instead of using DECL_ on both for some fields.
> 
> Can you be more specific on which fields this will be true for?
> 
I'm working this out as i write this, actually, by auditing code through aborts.

It looks like mainly DECL_FIELD_CONTEXT not being accessible as DECL_CONTEXT, 
at least for FIELD_DECL.
I haven't looked heavily at TYPE_DECL yet.


> 
> > Before i go down this path (because it is a long hard road), does anyone
> > have any serious objection to having to use properly named macros to
> > access the trees?  This will probably add more code in some places that
> > trees all DECL's the same, since they won't be the same anymore, except
> > for the really really shared bits (again, UID comes to mind).
> 
> Depending on what field, yes, I'll object.  There should be a "minimal
> decl" for which the "normal" decl stuff should belong to.  DECL_ALIGN,
> for instance.

Yes, i plan on having a common part between the two decls.

I'm talking more about fields that you *can* access right now in a
FIELD_DECL (for example) without using the macros that do
FIELD_DECL_CHECK, and there is some other macro that *does* do a
FIELD_DECL check and accesses the same field.

The main case i've hit so far is DECL_CONTEXT, which is also
DECL_FIELD_CONTEXT, and my current thinking is that in a FIELD_DECL will
be only accessible through DECL_FIELD_CONTEXT (unless we want to
"re-merge" these two fields again and throw it in the common part, and
always call it DECL_CONTEXT).



> 
> > But you probably shouldn't have been doing that in the first place :)
> 
> Disagree.

You disagree, for example, that you shouldn't be using DECL_CONTEXT on
FIELD_DECL?
I'm curious why (unlesss it's because you believe there is no reason to
separate field context and context, of course :P).

Re: GCC 4.1: Buildable on GHz machines only?

[Karel Gardas]

On Tue, 17 May 2005, Alexandre Oliva wrote:
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
you see that 4.0 added "embedded" platforms like arm-none-elf and
mips-none-elf to the primary platforms list.
These are only embedded targets.  You can't run GCC natively on them,
so they don't help embedded hosts in any way.
Yes, but Ralf was complaining about embedded cross-compiling development 
for RTEMS. I have not tried to reply to Peter Barada who complains about 
GCC inablity to be run on embedded targets directly.

Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Mark Mitchell]

Jakub Jelinek wrote:
+ #ifndef WORDS_BIGENDIAN
+   /* On a little-endian machine, if the data is 4-byte aligned we can hash
+  by word for better speed.  This gives nondeterministic results on
+  big-endian machines.  */

WORDS_BIGENDIAN is not being defined in the headers that are included.
I think best would be just to kill this hunk and unconditionally do it the
slower way.
Good point!  I checked in this patch, on mainline and 4.0 branches, 
after testing on x86_64-unknown-linux-gnu.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
2005-05-17  Mark Mitchell  <[EMAIL PROTECTED]>

* gcc.dg/compat/struct-layout-1_generate.c (iterative_hash):
Remove little-endian optimizations. 

Index: struct-layout-1_generate.c
===
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c,v
retrieving revision 1.5
diff -c -5 -p -r1.5 struct-layout-1_generate.c
*** struct-layout-1_generate.c  16 May 2005 22:52:26 -  1.5
--- struct-layout-1_generate.c  17 May 2005 18:22:25 -
*** iterative_hash (const void *k_in /* the 
*** 1223,1247 
len = length;
a = b = 0x9e3779b9;  /* the golden ratio; an arbitrary value */
c = initval;   /* the previous hash value */
  
/* handle most of the key */
- #ifndef WORDS_BIGENDIAN
-   /* On a little-endian machine, if the data is 4-byte aligned we can hash
-  by word for better speed.  This gives nondeterministic results on
-  big-endian machines.  */
-   if (sizeof (hashval_t) == 4 && (((size_t)k)&3) == 0)
- while (len >= 12)/* aligned */
-   {
-   a += *(hashval_t *)(k+0);
-   b += *(hashval_t *)(k+4);
-   c += *(hashval_t *)(k+8);
-   mix(a,b,c);
-   k += 12; len -= 12;
-   }
-   else /* unaligned */
- #endif
  while (len >= 12)
{
a += (k[0] +((hashval_t)k[1]<<8) +((hashval_t)k[2]<<16) 
+((hashval_t)k[3]<<24));
b += (k[4] +((hashval_t)k[5]<<8) +((hashval_t)k[6]<<16) 
+((hashval_t)k[7]<<24));
c += (k[8] +((hashval_t)k[9]<<8) 
+((hashval_t)k[10]<<16)+((hashval_t)k[11]<<24));
--- 1223,1232 

Re: GCC 3.4.4 RC2

[Mark Mitchell]

John David Anglin wrote:
Please download, build, and test.

I've now completed testing on the PA and don't see any major issues.
The only easily fixable issue that showed up in testing was the failure
of 26_numerics/complex/pow.cc under hpux 10.20.  This fails because of
a corner case in the 10.20 math library.  The problem was fixed in the
4.0.0 release.
There are a number of minor testsuite issues, some fixed in 4.0.0.
The failure of badalloc1.C under hpux 11.11 is a testsuite problem
that could be fixed by updating to the 4.1.0 version.
It would have been nice to fix those testsuite issues, but I think it's 
OK that we didn't.  Thanks for testing!

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: My evil plans for the next few weekends

[Richard Kenner]

The main case i've hit so far is DECL_CONTEXT, which is also
DECL_FIELD_CONTEXT

Are there any other cases?  Offhand, I can't think of another DECL field
that's shared by only a subset of DECLs.

Re: My evil plans for the next few weekends

[Richard Henderson]

On Tue, May 17, 2005 at 02:10:48PM -0400, Daniel Berlin wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT, and my current thinking is that in a FIELD_DECL will
> be only accessible through DECL_FIELD_CONTEXT (unless we want to
> "re-merge" these two fields again and throw it in the common part, and
> always call it DECL_CONTEXT).

This particular case wouldn't bother me.


r~

Re: GCC 4.1: Buildable on GHz machines only?

[Gabriel Dos Reis]

Ralf Corsepius <[EMAIL PROTECTED]> writes:

[...]

| Well, I admit I had been sarcastic/fatalistic in replying to Steven,
| primarily, because I am pretty much frustrated about GCC's mainstream
| developer's position/attitude on embedded targets.
| Steven's answers perfectly queue-in into a long history of incidents
| which had lead me to my understanding of "GCC mainstream developers'
| attitude" on "embedded targets", which I already had described in former
| postings.

then, you must have a very selective definition of "GCC mainstream
developers" :-)
A key strenght of GCC is its supports for embedded targets -- as
imperfect and frustrating it might be sometimes.  My own definition of 
"GCC mainstream developers" do not indicate to me that they are
hostile to the "embedded targets"; quite the contrary.
I also understand your mileage varies.

-- Gaby

Re: My evil plans for the next few weekends

[Daniel Berlin]

On Tue, 2005-05-17 at 14:59 -0400, Richard Kenner wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT
> 
> Are there any other cases?  Offhand, I can't think of another DECL field
> that's shared by only a subset of DECLs.
An example is DECL_INITIAL vs DECL_QUALIFIER. You could theoret
There are shared *fields*, but the macros are stricter than DECL_CHECK
(IE FUNCTION_DECL_CHECK or TYPE_DECL_CHECK)  so they can't be accessed
through the wrong macro.

For example, FIELD_DECL and VAR_DECL both use bit_field_flag, for two
different purposes, but the DECL_IN_TEXT_SECTION macro checks to make
sure the node is a VAR_DECL before you can access it as a VAR_DECL, and
the DECL_BIT_FIELD macro makes sure the node is a FIELD_DECL before you
can access it on a FIELD_DECL.

Thus, there is no way we could be using that field unsafely, unless we
were doing it bare (ie tree->decl.bit_field_flag)

I audited the other ones for FIELD_DECL, and most of the "unsafe" macros
(IE just doing DECL_CHECK) are only used in one or two source files, and
looking at the context makes it clear they won't be called on FIELD_DECL
in those cases (IE they are inside if (code == FUNCTION_DECL) or
whatever).


The only ones that appear in more than a few places are DECL_REGISTER vs
DECL_PACKED, DECL_CONTEXT vs DECL_FIELD_CONTEXT, and DECL_INITIAL vs
DECL_QUALIFIER.

--Dan

Re: "No matching function" -- not finding copy constructor

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
| > I'm upgrading to V4.0.0 and struggling with some code that's seriously
| > into templates.  One puzzling error is this one:
| > 
| > keyed_obj.hh:159: error: no matching function for call to 
'CxnIndex::CxnIndex(CxnIndex)'
| > Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
| > Indeces.hh:145: note: ... and some more
| > 
| > It's not entirely clear to me why something very much like a copy
| > constructor is being invoked in the first place.  But the bigger
| > puzzle is: why isn't the copy constructor being matched?  I would have
| > thought that any call with a T argument should match a function or
| > method with an &T argument in its declaration...
| 
| CxnIndex::CxnIndex(CxnIndex&) is not a general copy constructor.  Notice
| the non-const reference.  The error message is saying that it's trying
| to pass a temporary to a copy constructor.  You would need
| 
| CxnIndex::CxnIndex(const CxnIndex&)
| 
| to match that.  As for why you need a copy constructor, we'd have to
| see the code for that, but this list isn't really the right place for
| helping you debug this problem further.

Joe is right.  But I think the diagnostic is very very confusing and
it is not obvious what was going from the type signature.  Please fill a
bugzilla PR and ask for diagnostic enhancement.

Thanks,

-- Gaby
 

Re: GCC 4.1: Buildable on GHz machines only?

[Marcin Dalecki]

On 2005-05-17, at 11:14, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
On Tuesday 17 May 2005 03:16, Joe Buck wrote:
How is it helpful to not follow the rules when posting patches
Quite simple:
* I wasn't aware about this fortran specific patch posting policy. I
never have sent any gcc patch to any other list but gcc-patches for
approval before, so I also had not done so this time.
* How could I know that the responsible maintainers aren't  
listening to
bugzilla and gcc-patches, but are listening to a fortran specific  
list,
I even didn't know about until your posting?
If something goes in to the mainline GCC then it should be required
that the maintainers of it don't stay in their cave and read gcc and  
gcc-patches
at least. This is at least what one can reasonable expect looking
from the outside, since there are no specific gcc-c-patches or gcc-c+ 
+-patches.

Re: GCC 4.1: Buildable on GHz machines only?

[Marcin Dalecki]

On 2005-05-17, at 11:29, Richard Earnshaw wrote:
On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:

No, I just don't build gfortran as a cross.  There are many reasons
why this is a bad idea anyway.
Such as?
The dependence on external packages which don't cross compile well  
for example.

Re: "No matching function" -- not finding copy constructor

[Paul Koning]

> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

 Gabriel> Joe is right.  But I think the diagnostic is very very
 Gabriel> confusing and it is not obvious what was going from the type
 Gabriel> signature.  Please fill a bugzilla PR and ask for diagnostic
 Gabriel> enhancement.

Thanks, that's a good idea.  PR 21631.

paul

Re: GCC 4.1: Buildable on GHz machines only?

[Paul Brook]

On Tuesday 17 May 2005 20:27, Marcin Dalecki wrote:
> On 2005-05-17, at 11:29, Richard Earnshaw wrote:
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> >> No, I just don't build gfortran as a cross.  There are many reasons
> >> why this is a bad idea anyway.
> >
> > Such as?
>
> The dependence on external packages which don't cross compile well
> for example.

What external dependencies? gfortran does not require any target libraries 
other than the standard C library.

It does require gmp/mpfr on the host, but in most cases the host is native, 
and they are dead easy to cross compile anyway.

Paul

Re: GCC 4.1: Buildable on GHz machines only?

[Gerald Pfeifer]

On Tue, 17 May 2005, Joseph S. Myers wrote:
> the page for entering new bugs has a big notice "Before reporting a bug, 
> please read the bug writing guidelines, please look at the list of most 
> frequently reported bugs, and please search for the bug." so those for 
> individual bugs could have a notice pointing patch contributors to 
> contribute.html.

Nice idea.  Daniel, would you mind adding such a link to contribute.html?

Thanks,
Gerald

Re: GCC 4.1: Buildable on GHz machines only?

[Joel Sherrill <[EMAIL PROTECTED]>]

Karel Gardas wrote:
On Tue, 17 May 2005, Alexandre Oliva wrote:
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
you see that 4.0 added "embedded" platforms like arm-none-elf and
mips-none-elf to the primary platforms list.

These are only embedded targets.  You can't run GCC natively on them,
so they don't help embedded hosts in any way.

Yes, but Ralf was complaining about embedded cross-compiling development 
for RTEMS. I have not tried to reply to Peter Barada who complains about 
GCC inablity to be run on embedded targets directly.
Logically Peter's situation is the same as the NetBSD issue with 
building and testing on old hosts.   He is running GNU/Linux on
ColdFire and I suspect his ColdFire target is probably faster and better 
equipped than the old UNIX boxes the BSD folks mentioned.

Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.

[Karel Gardas]

  Hello,
I've tried to meassure some cache misses of 4.0.1 and 4.1.0 C++
compilers by using oprofile on amd64 box while compiling MICO sources
and found that:
0) compiler options used were:
   -I../include  -Wall -D_REENTRANT -D_GNU_SOURCE   -DPIC -fPIC  -c
1) the most expensive seems to be comptypes -- at least from L1 and L2
   DTLB misses point of view (~13%)
2) comptypes is also the most CPU intensive operation since the most
   of time is spent there
3) some other L1 and L2 DTLB misses expensive functions seems to be:
   push_to_top_level(~5%), htab_find_slot_with_hash(~5%),
   ht_lookup_with_hash(~4%), lookup_fnfields_1(~4%)
4) for 4.0.1 every L1 and L2 DTLB miss happens every 2275 CLK event
5) for 4.1.0 every L1 and L2 DTLB miss happens every 2332 CLK event
6) 4.1.0 is a _bit_ faster than 4.0.1
7) tables were produced after three cycles of "make; find . -name '*.o'
   -exec rm \{} \;"
I've thought that L1 and L2 DTLB misses are the most important for the
overall performance or performance degradation, if not please correct
me since this is my first attempt to measure and interpret such data.
First few lines of produced tables are below. One table is for overall
cc1plus run and one is for symbol listing.
Please let me know if you find something like that useful so I will
continue from time to time to provide such data or if it is completely
useless and I will try to help somewhere else.
Thanks!
Karel
GCC 4.0.1 20050514 (prerelease):
silence:~$ 
~/usr/local/gcc-4_0-branch-20050514-mt-allocator-amd64-linux-gnu/bin/c++ -v
Using built-in specs.
Target: amd64-linux-gnu
Configured with: ../gcc-4_0-branch/configure 
--prefix=/home/karel/usr/local/gcc-4_0-branch-20050514-mt-allocator-amd64-linux-gnu
 --enable-shared --enable-threads --enable-languages=c++ --disable-checking 
--enable-__cxa_atexit --disable-multilib --enable-libstdcxx-allocator=mt 
amd64-linux-gnu
Thread model: posix
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 
(No unit mask) count 1000
Counted L1_AND_L2_DTLB_MISSES events (L1 and L2 DTLB misses) with a unit mask 
of 0x00 (No unit mask) count 1000
Counted L1_DTLB_MISSES_L2_DTLB_HITS events (L1 DTLB misses and L2 DTLB hits) 
with a unit mask of 0x00 (No unit mask) count 1000
CPU_CLK_UNHALT...|DATA_CACHE_MIS...|L1_AND_L2_DTLB...|L1_DTLB_MISSES...|
  samples|  %|  samples|  %|  samples|  %|  samples|  %|

  4498408 100.000   2728674 100.000197695 100.000   3734282 100.000 cc1plus
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 
(No unit mask) count 1000
Counted L1_AND_L2_DTLB_MISSES events (L1 and L2 DTLB misses) with a unit mask 
of 0x00 (No unit mask) count 1000
Counted L1_DTLB_MISSES_L2_DTLB_HITS events (L1 DTLB misses and L2 DTLB hits) 
with a unit mask of 0x00 (No unit mask) coun
t 1000
samples  %samples  %samples  %samples  %symbol 
name
1912054.5167  346985   13.4574  2555813.8668  1008702.8451  
comptypes
1347923.1841  84111 3.2621  5996  3.2532  2879698.1223  
ggc_alloc_stat
1306353.0859  1614966.2634  7606  4.1267  474363   13.3796  
lookup_fnfields_1
1001612.3660  5841  0.2265  153   0.0830  12492 0.3523  
record_reg_classes
85299 2.0150  16765 0.6502  350   0.1899  36418 1.0272  
dfs_walk_all
81984 1.9367  13907 0.5394  135   0.0732  39432 1.1122  
find_reloads
78803 1.8615  18008 0.6984  586   0.3179  16583 0.4677  
walk_tree
63327 1.4959  1979  0.0768  130   0.0705  24860 0.7012  
_cpp_lex_direct
54152 1.2792  38433 1.4906  7770  4.2157  88230 2.4886  
ht_lookup_with_hash
52226 1.2337  6949  0.2695  780.0423  2365  0.0667  
_cpp_clean_line
47768 1.1284  40274 1.5620  8978  4.8711  65595 1.8501  
htab_find_slot_with_hash
46236 1.0922  5905  0.2290  710   0.3852  32132 0.9063  
splay_tree_splay_helper
45524 1.0754  55568 2.1551  1725  0.9359  73780 2.0810  
lookup_field_1
44070 1.0410  33720 1.3078  1965  1.0661  47199 1.3313  tsubst
42073 0.9939  9121  0.3537  494   0.2680  20246 0.5710  
grokdeclarator
41105 0.9710  19844 0.7696  581   0.3152  12929 0.3647  
cp_walk_subtrees
37812 0.8932  61645 2.3908  10128 5.4951  6142  0.1732  
push_to_top_level
GCC 4.1.0 20050514 (experimental):
silence:~$ ~/usr/local/gcc-main-20050514/bin/c++ -v
Using built-in specs.
Target: amd64-unknown-linux-gnu
Configured wit

Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.

[Andi Kleen]

Karel Gardas <[EMAIL PROTECTED]> writes:

> I've thought that L1 and L2 DTLB misses are the most important for the
> overall performance or performance degradation, if not please correct
> me since this is my first attempt to measure and interpret such data.

TLB is just for caching the translations from virtual to physical
addresses. Normally the data/instruction cache misses are more
important. There are a few TLB intensive workloads too, but they tend
to use much more memory than gcc normally does.

So I think you should rather use ICACHE_MISSES and 
DATA_CACHE_REFILLS_FROM_SYSTEM,
which measure the "real" L2 caches.

And perhaps run a normal instruction profile (CPU_CLK_UNHALTED) in parallel and
double check the hot spots displayed by the others match the real
time hogs. Note you can use upto three performance counters at the same time.

-Andi

Re: My evil plans for the next few weekends

[Mark Mitchell]

Richard Henderson wrote:
On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:

Depending on what field, yes, I'll object.  There should be a "minimal
decl" for which the "normal" decl stuff should belong to.  DECL_ALIGN,
for instance.

But you probably shouldn't have been doing that in the first place :)
I'm strongly in support of doing what Daniel wants to do.  I've been 
wanting to do it since forever.

In fact, the only things that are probably common to *all* DECLs are (a) 
a name, and (b) a source position, and (c) a scope.

DECL_ALIGN certainly doesn't apply to namespaces, or enumeration 
constants, or type declarations.  (Well, it might presently apply to 
type declarations, but it shouldn't; if someone declares an aligned type 
that should show up on the type.)  I'm not sure if DECL_ALIGN applies to 
functions; maybe it could.

It's perfectly reasonable to have "typed_decl" as a derived class of 
"decl" which contains a type; then "var_decl" and "function_decl" would 
be derived from that, for example.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.1: Buildable on GHz machines only?

[Peter Barada]

>> Yes, but Ralf was complaining about embedded cross-compiling development 
>> for RTEMS. I have not tried to reply to Peter Barada who complains about 
>> GCC inablity to be run on embedded targets directly.
>
>Logically Peter's situation is the same as the NetBSD issue with 
>building and testing on old hosts.   He is running GNU/Linux on
>ColdFire and I suspect his ColdFire target is probably faster and better 
>equipped than the old UNIX boxes the BSD folks mentioned.

Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
BogoMips of my workstation, and with an NFS rootfs, it gets network
bound pretty rapidly and runs even slower compared to a NetBSD machine
with a local disk :)

-- 
Peter Barada
[EMAIL PROTECTED]

Re: Proposed resolution to aliasing issue.

[Mark Mitchell]

Nathan Sidwell wrote:
I attended a UK C++ panel meeting yesterday, and took the opportunity
to solicit opinions on this.  The question I posed was
struct A {
...
T1 a;
T2 b;
};
void g(T1 &a);
void Foo () {
   A v;
   v.b = 2;
   g (v.a);
   if (v.b == 2) ...
}
Does the compiler have a right to presume v.b does indeed == 2 in the if
condition? -- assuming T2 is a suitable type for that :)

After I explained the optimization (and the related structure splitting
optimization), the general consensus was 'yes that would be a useful
optimization'.  But no one was sufficiently confident of proving it
was allowable.  The opinion was expressed that if it was not allowable,
there was a bug in the std.
Will the UK committee open a DR for this?  Or, would you care to send 
mail to Steve Adamczyk about it?

The observation was made that if A is non-POD, one cannot play offsetof
tricks to get from A::a to A::b, so the optimization is safe on non-PODs.
(Of course one would have to prove the address of 'v' did not escape,
so I guess the ctor and dtor would need to be trivial or visible.)
I argued last week that this was not in fact true, in that you can do:
  ptrdiff_t x = &v.b - &v.a;
and then use that instead of "offsetof (Foo, b) - offsetof (Foo, a)".
because (a) badfuncs are more than likely rare and (b) it would be a useful
aid to the programmer.[1] Mark outlines an __I_AM_GOOD__ attribute,  I 
think
it would be better to have both flavours and then the compiler switch can
specify which way the default goes.
Makes sense to me.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 3.4.4

[Mark Mitchell]

Jonathan Wakely wrote:
On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:

I've very nearly ready to release GCC 3.4.4.  If you have objections or 
high-priority fixes that you think will be required for this release, 
please speak up within the next 24 hours.

Sorry for the last minute mail ...
It occurs to me that although we're not fixing this in 3.4.4
http://gcc.gnu.org/ml/libstdc++/2005-05/msg00105.html
we could document it, which would be a safe change:
Great idea!  Go ahead, please.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.1: Buildable on GHz machines only?

[Joel Sherrill <[EMAIL PROTECTED]>]

Peter Barada wrote:
Yes, but Ralf was complaining about embedded cross-compiling development 
for RTEMS. I have not tried to reply to Peter Barada who complains about 
GCC inablity to be run on embedded targets directly.
Logically Peter's situation is the same as the NetBSD issue with 
building and testing on old hosts.   He is running GNU/Linux on
ColdFire and I suspect his ColdFire target is probably faster and better 
equipped than the old UNIX boxes the BSD folks mentioned.

Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
BogoMips of my workstation, and with an NFS rootfs, it gets network
bound pretty rapidly and runs even slower compared to a NetBSD machine
with a local disk :)
I would have thought the CPU itself was comparable to or faster than
a 68040 or 68060 since they was always at much lower clock speeds.
Do you have any local disk or is everything NFS?  If so, that would
be killer for performance.  I remember an old pair of SparcStation 10's
we used to have.  Network builds vs. local disk was already like 5-10x
slower.
How much RAM?
--joel

Re: Proposed resolution to aliasing issue.

[Nathan Sidwell]

Mark Mitchell wrote:

> Will the UK committee open a DR for this?  Or, would you care to send
> mail to Steve Adamczyk about it?
this can be done.  I shall wait until the minutes have been written up.

> 
>> The observation was made that if A is non-POD, one cannot play offsetof
>> tricks to get from A::a to A::b, so the optimization is safe on non-PODs.
>> (Of course one would have to prove the address of 'v' did not escape,
>> so I guess the ctor and dtor would need to be trivial or visible.)
> 
> 
> I argued last week that this was not in fact true, in that you can do:
> 
>   ptrdiff_t x = &v.b - &v.a;
> 
> and then use that instead of "offsetof (Foo, b) - offsetof (Foo, a)".

Does not '&v.b - &v.a' cause the address to 'escape', and therefore
lock down the structure?  If it doesn't, how hard would it be to
make that DTRT?

nathan

-- 
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: GCC 4.1: Buildable on GHz machines only?

[Peter Barada]

>> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
>> BogoMips of my workstation, and with an NFS rootfs, it gets network
>> bound pretty rapidly and runs even slower compared to a NetBSD machine
>> with a local disk :)
>
>I would have thought the CPU itself was comparable to or faster than
>a 68040 or 68060 since they was always at much lower clock speeds.

Oh, its faster than the 040/060 since those topped out at 75Mhz, but
at the same time, the more restricted addressing modes/instructions
require more instructions to acheive the same amount of work, but on
the whole is faster(the imfamous RISC debate).

>Do you have any local disk or is everything NFS?  If so, that would
>be killer for performance.  I remember an old pair of SparcStation 10's
>we used to have.  Network builds vs. local disk was already like 5-10x
>slower.

Its currently NFS all the way. :)

>How much RAM?

128Mb.  I do have some experimental kernel hacks in to allow swapping
via NFS, so you can understand why it can take *days* to build stuff.

-- 
Peter Barada
[EMAIL PROTECTED]

Re: Proposed resolution to aliasing issue.

[Mark Mitchell]

Nathan Sidwell wrote:
Mark Mitchell wrote:

Will the UK committee open a DR for this?  Or, would you care to send
mail to Steve Adamczyk about it?
this can be done.  I shall wait until the minutes have been written up.
Excellent.
The observation was made that if A is non-POD, one cannot play offsetof
tricks to get from A::a to A::b, so the optimization is safe on non-PODs.
(Of course one would have to prove the address of 'v' did not escape,
so I guess the ctor and dtor would need to be trivial or visible.)

I argued last week that this was not in fact true, in that you can do:
 ptrdiff_t x = &v.b - &v.a;
and then use that instead of "offsetof (Foo, b) - offsetof (Foo, a)".

Does not '&v.b - &v.a' cause the address to 'escape', and therefore
lock down the structure?  If it doesn't, how hard would it be to
make that DTRT?
It wouldn't look like escape to (at least some compilers') optimizers 
if, say, the front end folded it to a constant.  So, I'm not sure how to 
express what constitutes escape.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.

[Karel Gardas]

On Tue, 17 May 2005, Andi Kleen wrote:
Karel Gardas <[EMAIL PROTECTED]> writes:
I've thought that L1 and L2 DTLB misses are the most important for the
overall performance or performance degradation, if not please correct
me since this is my first attempt to measure and interpret such data.
TLB is just for caching the translations from virtual to physical
addresses. Normally the data/instruction cache misses are more
important. There are a few TLB intensive workloads too, but they tend
to use much more memory than gcc normally does.
Thanks for TLB explanation!
So I think you should rather use ICACHE_MISSES and 
DATA_CACHE_REFILLS_FROM_SYSTEM,
which measure the "real" L2 caches.
OK, will do, although I'm not so sure ICACHE_MISSES means L2 I cache, 
since DCACHE_MISSES in case of D cache seems to means L1 cache, am I 
right?

And perhaps run a normal instruction profile (CPU_CLK_UNHALTED) in parallel and
double check the hot spots displayed by the others match the real
time hogs. Note you can use upto three performance counters at the same time.
CPU_CLK_UNHALTED was provided in my previous email and the results were 
povided on its basis, i.e. table sorted by CPU_CLK_UNHALTED column. IIRC 
oprofile also warned me that maximum number of perf. counters in used is 
four -- that was after the attempt to throw all cache misses into 
measurement. :-)

Thanks for your corrections/ideas!
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Re: libiberty requirements and ISO C90

[Mark Kettenis]

   From: Ian Lance Taylor 
   Date: 15 May 2005 23:20:14 -0400


   Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
   If we require the libraries, then we can remove a number of files from
   libiberty, at least atexit.c, memchr.c, memcmp.c, memcpy.c, memmove.c,
   memset.c, snprintf.c, strchr.c, strerror.c, strncmp.c, strrchr.c,
   strtol.c, strtoul.c, vfprintf.c, vsprintf.c.  If we don't require the
   libraries, then we can't assume that  declares strerror.  In
   fact, technically we can't even assume that  exists,
   although we do currently have a few cases where it is included without
   being protected by #ifdef HAVE_STRING_H.

Hmm, it seems that snprintf() wasn't in ISO C90 since it's mentioned
as a new addition in ISO C99 according to google.  At least HP-UX
10.20 doesn't have it.  And GDB still builds on vax-dec-ultrix4.0 for
which I'm not sure that it has a full ISO C90 library.  So I hope
you're not seriously proposing to remove these functions from
libiberty.

Mark

Re: GCC 4.1: Buildable on GHz machines only?

[Hugh Sasse]

On Tue, 17 May 2005, Joseph S. Myers wrote:
[...]
shortly.  All those posted (at least this month) seem to get posted with
subject lines which do not match the normal form produced by test_summary
and so don't get so readily found by my script which counts how many test
results postings there are for different versions and targets.  For
example, [Example *very* trimmed -- [EMAIL PROTECTED]
comparison to 4.1.0 20050416 (experimental)".  Ensuring your test results
use the standard Subject header format makes it more likely they can
handled properly by sites processing the gcc-testresults postings into
Is this standard documented (where?), please? I ask because the
script that generates these has few comments, so it's a little
difficult to know what will break when 'meddling' :-) with it.
I know that could sound aggressive/negative, but I don't intend that
tone.  Sometimes the most useful thing I can do is post test
results, so I'd at least like to do that right.
[...]
Aside to those finding the criticisms hard to take: For my part, GCC
has given years of good service, but to raise a problem efficiently
means leaving out the appropriate proportion of praise.
Thank you
Hugh

Re: libiberty requirements and ISO C90

[Ian Lance Taylor]

Mark Kettenis <[EMAIL PROTECTED]> writes:

>From: Ian Lance Taylor 
>Date: 15 May 2005 23:20:14 -0400
> 
> 
>Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
>If we require the libraries, then we can remove a number of files from
>libiberty, at least atexit.c, memchr.c, memcmp.c, memcpy.c, memmove.c,
>memset.c, snprintf.c, strchr.c, strerror.c, strncmp.c, strrchr.c,
>strtol.c, strtoul.c, vfprintf.c, vsprintf.c.  If we don't require the
>libraries, then we can't assume that  declares strerror.  In
>fact, technically we can't even assume that  exists,
>although we do currently have a few cases where it is included without
>being protected by #ifdef HAVE_STRING_H.
> 
> Hmm, it seems that snprintf() wasn't in ISO C90 since it's mentioned
> as a new addition in ISO C99 according to google.  At least HP-UX
> 10.20 doesn't have it.  And GDB still builds on vax-dec-ultrix4.0 for
> which I'm not sure that it has a full ISO C90 library.  So I hope
> you're not seriously proposing to remove these functions from
> libiberty.

I'm not.  And, you're right, snprintf shouldn't be in the list anyhow.

Ian

Re: Proposed resolution to aliasing issue.

[Mike Stump]

On May 17, 2005, at 2:21 PM, Mark Mitchell wrote:
It wouldn't look like escape to (at least some compilers')  
optimizers if, say, the front end folded it to a constant.  So, I'm  
not sure how to express what constitutes escape.
Well, we're going to need to ensure the optimizer can see various  
things.

We need to teach it about the meaning of constants.
One can:
#include "foo.h"
main() {
printf ("%d\n", offsetof (s, m));
}
and then in another file, read and use that on an address.  One can  
also transform it into a #define S_M_OFFSET 8, and #include it.  So,  
I'd claim the optimizer has to know about constants already.

Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.

[Karel Gardas]

[rewritten/remeasured as per suggestion by Andy Kleen]
  Hello,
I've tried to measure some cache misses of 4.0.1 and 4.1.0 C++
compilers by using oprofile on amd64 box while compiling MICO sources
and found that:
0) compiler options used were:
   -I../include  -Wall -D_REENTRANT -D_GNU_SOURCE   -DPIC -fPIC  -c
1) the most expensive seems to be comptypes -- at least from data L2
   refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
   of time is spent there
3) some other data L2 refill expensive functions seems to be:
   push_to_top_level(~6%), compparms(~4%),
   htab_find_slot_with_hash(~3%), ggc_alloc_stat(~3%)
4) for 4.0.1 every data L2 refill happens every 774 (CPU_CLK_UNHALTED
   * 100 / DATA_CACHE_REFILLS_FROM_SYSTEM) CLK event
5) for 4.1.0 every data L2 refill happens every 765 CLK event
6) 4.1.0 is a _bit_ faster than 4.0.1
7) tables were produced after three cycles of "make; find . -name '*.o'
   -exec rm \{} \;"
I don't know if ICACHE_MISSES is that important since I think it
measures L1 I cache misses instead of L2. If I'm not right please
correct me.
First few lines of produced tables are below. One table is for overall
cc1plus run and one is for symbol listing.
Please let me know if you find something like that useful so I will
continue from time to time to provide such data or if it is completely
useless and I will try to help somewhere else.
Thanks!
Karel
GCC 4.0.1 20050514 (prerelease):
silence:~$ 
~/usr/local/gcc-4_0-branch-20050514-mt-allocator-amd64-linux-gnu/bin/c++ -v
Using built-in specs.
Target: amd64-linux-gnu
Configured with: ../gcc-4_0-branch/configure 
--prefix=/home/karel/usr/local/gcc-4_0-branch-20050514-mt-allocator-amd64-linux-gnu
 --enable-shared --enable-threads --enable-languages=c++ --disable-checking 
--enable-__cxa_atexit --disable-multilib --enable-libstdcxx-allocator=mt 
amd64-linux-gnu
Thread model: posix
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 
0x00 (No unit mask) count 1000
Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) 
with a unit mask of 0x1f (All cache states) count 1000
CPU_CLK_UNHALT...|ICACHE_MISSES:...|DATA_CACHE_REF...|
  samples|  %|  samples|  %|  samples|  %|
--
  5937586 100.000   4068766 100.000767082 100.000 cc1plus
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 
0x00 (No unit mask) count 1000
Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) 
with a unit mask of 0x1f (All cache states
) count 1000
samples  %samples  %samples  %symbol name
2821294.7516  84062 2.0660  133054   17.3455  comptypes
2221873.7420  35072 0.8620  14406 1.8780  lookup_fnfields_1
1896613.1942  99075 2.4350  22870 2.9814  ggc_alloc_stat
1639452.7611  10867 0.2671  1238  0.1614  dfs_walk_all
1290722.1738  6189  0.1521  1649  0.2150  record_reg_classes
1159451.9527  11575 0.2845  6508  0.8484  walk_tree
1044661.7594  34266 0.8422  1044  0.1361  find_reloads
78529 1.3226  11466 0.2818  4045  0.5273  splay_tree_splay_helper
71485 1.2039  1881  0.0462  1164  0.1517  _cpp_lex_direct
66814 1.1253  52100 1.2805  23340 3.0427  htab_find_slot_with_hash
66042 1.1123  16046 0.3944  5365  0.6994  lookup_field_1
64969 1.0942  16433 0.4039  19151 2.4966  ht_lookup_with_hash
63059 1.0620  29488 0.7247  20545 2.6783  tsubst
60314 1.0158  1242833.0546  1902  0.2480  grokdeclarator
59543 1.0028  5354  0.1316  3547  0.4624  cp_walk_subtrees
58087 0.9783  518   0.0127  398   0.0519  _cpp_clean_line
57753 0.9727  372   0.0091  630.0082  
dfs_find_final_overrider_pre
50981 0.8586  3283  0.0807  47105 6.1408  push_to_top_level
GCC 4.1.0 20050514 (experimental):
silence:~$ ~/usr/local/gcc-main-20050514/bin/c++ -v
Using built-in specs.
Target: amd64-unknown-linux-gnu
Configured with: ../gcc-main/configure 
--prefix=/home/karel/usr/local/gcc-main-20050514 --enable-shared 
--enable-threads --enable-languages=c++ --disable-checking 
--enable-__cxa_atexit --disable-multilib amd64-unknown-linux-gnu
Thread model: posix
gcc version 4.1.0 20050514 (experimental)
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 
0x0

Re: GCC 4.1: Buildable on GHz machines only?

[Toon Moene]

Peter Barada wrote:
Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
BogoMips of my workstation, and with an NFS rootfs, it gets network
bound pretty rapidly and runs even slower compared to a NetBSD machine
with a local disk :)
Hmmm, Ghz wise and BogoMips wise, this is about half what I have (a 550 
Mhz G4 PowerBook).

Nevertheless, you don't hear *me* complain ...
I build GCC while at work (i.e., while away from the notebook at home :-)
Try it ... it works,
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
News on GNU Fortran 95: http://gfortran.org/

Re: GCC 4.1: Buildable on GHz machines only?

[Joseph S. Myers]

On Tue, 17 May 2005, Hugh Sasse wrote:

> On Tue, 17 May 2005, Joseph S. Myers wrote:
> [...]
> > shortly.  All those posted (at least this month) seem to get posted with
> > subject lines which do not match the normal form produced by test_summary
> > and so don't get so readily found by my script which counts how many test
> > results postings there are for different versions and targets.  For
> > example, [Example *very* trimmed -- [EMAIL PROTECTED]
> > comparison to 4.1.0 20050416 (experimental)".  Ensuring your test results
> > use the standard Subject header format makes it more likely they can
> > handled properly by sites processing the gcc-testresults postings into
> 
> Is this standard documented (where?), please? I ask because the
> script that generates these has few comments, so it's a little
> difficult to know what will break when 'meddling' :-) with it.

It's a de facto standard: don't modify your Subject header from that 
test_summary generates; there are plenty of examples on gcc-testresults of 
what the headers should look like.  You can rewrite the shell script 
output by test_summary - all the test summaries sent by CodeSourcery 
Automatic Testing System rewrite the script to control the From address - 
but preserve the subject header when you do so or when you send the 
summary manually.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

preprocessor/21250 and address of

[Per Bothner]

Opinions on how to handle this bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
This came up because we give  declarations
line 0, but used line 1 in a different date structure.
I fixed the code to consistently use line 0, which is
needed for the --enable-mapped-location unification.
However, we end up with preprocessor output like this:
# 1 "any-file"
# 0 ""
# 1 ""
# 1 "any-file"
Some assemblers complain about line number 0.  This is especially
an issue for people who use cpp to preprocessor assembler, which
of course we don't really support.
My suggested solution: suppress the output of , so
we get:
# 1 "any-file"
# 1 ""
# 1 "any-file"
There should never be anything following , so it's useless
as well as confusing.  Also, if we compile multiple files at once (or
use a compile server), then logically the  declaration
*precede* all the actual code, which suggests that if  is
output it should be the *first* line.  But that would break too much
code.  Simplest and cleanest solution: Just get rid of the 
line in pre-processor output.  This might break some tools that look
at cpp output, but it seems unlikely.  I'll check that -fpreprocessed
doesn't break (I assume the testsuite tests this?), and I'll ask
someone to check distcc.
Objections to this approach?  Other suggestions?  One alternative is
to fix gas to not complain about line number 0.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

[wwwdocs] bugs.html cleanup (was: GCC 4.1: Buildable on GHz machines )only?

[Gerald Pfeifer]

On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote:
>> For future reference, where patches should be sent is explained here:
>> http://gcc.gnu.org/lists.html
> OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?

I'm not sure we should add a link to lists.html from bugs.html, however
when reviewing the current bugs.html page I noticed that it's way too
baroque and committed the following patch.

Any further simplifications and other patches are most welcome!

Gerald

Rephrase some parts to make them shorter.  Omit some details for 
submitting bugs by e-mail.

Index: bugs.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs.html,v
retrieving revision 1.93
diff -u -3 -p -r1.93 bugs.html
--- bugs.html   23 Feb 2005 22:42:09 -  1.93
+++ bugs.html   17 May 2005 20:47:46 -
@@ -53,13 +53,13 @@
 Reporting Bugs
 
 The main purpose of a bug report is to enable us to fix the bug. The
-most important prerequisite for this is that the report must be complete and
-self-contained, which we explain in detail below.
+most important prerequisite for this is that the report must be complete
+and self-contained.
 
 Before you report a bug, please check the 
-list of well-known bugs and, if possible
-in any way, try a current development snapshot.
-If you want to report a bug with versions of GCC before 3.1 we strongly
+list of well-known bugs and, if possible,
+try a current development snapshot.
+If you want to report a bug with versions of GCC before 3.4 we strongly
 recommend upgrading to the current release first.
 
 Before reporting that GCC compiles your code incorrectly, please
@@ -116,10 +116,6 @@ three of which can be obtained from the 
   a successful compilation; this is a symptom of a hardware problem,
   not of a compiler bug (sorry)
 
-  E-mail messages that complement previous, incomplete bug
-  reports. Post a new, self-contained, full bug report instead, if
-  possible as a follow-up to the original bug report
-
   Assembly files (*.s) produced by the compiler, or any
   binary files, such as object files, executables, core files, or
   precompiled header files
@@ -163,17 +159,6 @@ preprocessed file it generates.
 gcc -v -save-temps all-your-options
 source-file
 
-Typically the preprocessed file (extension .i for C or
-.ii for C++, and .f if the preprocessor is used on
-Fortran files) will be large, so please compress the
-resulting file with one of the popular compression programs such as
-bzip2, gzip, zip or compress (in
-decreasing order of preference).  Use maximum compression
-(-9) if available.  Please include the compressed
-preprocessor output in your bug report, even if the source code is
-freely available elsewhere; it makes the job of our volunteer testers
-much easier.
-
 The only excuses to not send us the preprocessed sources are
 (i) if you've found a bug in the preprocessor, (ii) if you've reduced
 the testcase to a small file that doesn't include any other file or
@@ -186,12 +171,6 @@ then try to create a small file that tri
 it in the bug report, although you may want to post parts of it to
 point out assembly code you consider to be wrong.
 
-Whether to use MIME attachments or uuencode is up to
-you.  In any case, make sure the compiler command line, version and
-error output are in plain text, so that we don't have to decode the
-bug report in order to tell who should take care of it.  A meaningful
-subject indicating language and platform also helps.
-
 Please avoid posting an archive (.tar, .shar or .zip); we generally
 need just a single file to reproduce the bug (the .i/.ii/.f preprocessed
 file), and, by storing it in an archive, you're just making our
@@ -204,16 +183,6 @@ make sure the compiler version, error me
 the body of your bug report as plain text, even if needlessly
 duplicated as part of an archive.
 
-If you fail to supply enough information for a bug report to be
-reproduced, someone will probably ask you to post additional
-information (or just ignore your bug report, if they're in a bad day,
-so try to get it right on the first posting :-).  In this case, please
-post the additional information to the bug reporting mailing list, not
-just to the person who requested it, unless explicitly told so.  If
-possible, please include in this follow-up all the information you had
-supplied in the incomplete bug report (including the preprocessor
-output), so that the new bug report is self-contained.
-
 Detailed bug reporting instructions for GNAT
 
 See the previous section for bug reporting

Re: GCC 4.1: Buildable on GHz machines only?

[Peter Barada]

>> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
>> BogoMips of my workstation, and with an NFS rootfs, it gets network
>> bound pretty rapidly and runs even slower compared to a NetBSD machine
>> with a local disk :)
>
>Hmmm, Ghz wise and BogoMips wise, this is about half what I have (a 550 
>Mhz G4 PowerBook).
>
>Nevertheless, you don't hear *me* complain ...

No, but I don't have a disk, so everything has to come over the
network.  I also don't have much ram, so if I start running out of RAM,
it slows to a crawl since it can't cache any source.

>I build GCC while at work (i.e., while away from the notebook at home :-)
>
>Try it ... it works,

Huh?  I can cross-compile GCC, its all the packages that require
native configuration/building

-- 
Peter Barada
[EMAIL PROTECTED]

Re: Proposed resolution to aliasing issue.

[Mark Mitchell]

Mike Stump wrote:
We need to teach it about the meaning of constants.
One can:
#include "foo.h"
main() {
printf ("%d\n", offsetof (s, m));
}
and then in another file, read and use that on an address.  One can  
also transform it into a #define S_M_OFFSET 8, and #include it.  So,  
I'd claim the optimizer has to know about constants already.
I fail to see your point, unless it is that whether or not you spell "8" 
as "8", "&s.x - &s.y", or "offsetof (S, x) - offsetof (S, y)" should not 
matter, in which case I certainly agree.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

libjava build failure?

[Mike Stump]

I'm trying to build top of tree...
make[2]: Leaving directory `/Volumes/mrs3/net/gcc-darwinO2/powerpc- 
apple-darwin8.0.0/libjava'
make[2]: Entering directory `/Volumes/mrs3/net/gcc-darwinO2/powerpc- 
apple-darwin8.0.0/libjava'
make[2]: *** No rule to make target `0', needed by `gnu/awt.list'.   
Stop.
make[2]: Leaving directory `/Volumes/mrs3/net/gcc-darwinO2/powerpc- 
apple-darwin8.0.0/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/Volumes/mrs3/net/gcc-darwinO2'
make: *** [bootstrap] Error 2

:-(  Surely, I'm just unlucky?
$ cat powerpc-apple-darwin8.0.0/libjava/Makefile.deps
java/lang.list: 0
java/lang/Class.class: java/lang.stamp
java/lang.list: 0
java/lang/Object.class: java/lang.stamp
java/lang.list: 0
java/lang/AbstractMethodError.class: java/lang.stamp
java/lang.list: 0
[ ... ]
:-(

Re: Proposed resolution to aliasing issue.

[Mike Stump]

On May 17, 2005, at 4:00 PM, Mark Mitchell wrote:
it is that whether or not you spell "8" as "8", "&s.x - &s.y", or  
"offsetof (S, x) - offsetof (S, y)" should not matter, in which  
case I certainly agree.
Yes, that is it, we agree.

Re: GCC 4.1: Buildable on GHz machines only?

[Jonathan Wilson]

Huh?  I can cross-compile GCC, its all the packages that require
native configuration/building
Is it fesable for people in this sort of situation to build GCC on a fast 
machine but with the final host and target both set to whatever the slower 
machine is (in this case coldfire)
Does GCC even support that?

Re: preprocessor/21250 and address of

[Neil Booth]

Per Bothner wrote:-

> Opinions on how to handle this bug?
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
> 
> This came up because we give  declarations
> line 0, but used line 1 in a different date structure.
> I fixed the code to consistently use line 0, which is
> needed for the --enable-mapped-location unification.
> 
> However, we end up with preprocessor output like this:
> 
> # 1 "any-file"
> # 0 ""
> # 1 ""
> # 1 "any-file"
> 
> Some assemblers complain about line number 0.  This is especially
> an issue for people who use cpp to preprocessor assembler, which
> of course we don't really support.
> 
> My suggested solution: suppress the output of , so
> we get:
> # 1 "any-file"
> # 1 ""
> # 1 "any-file"
> 
> There should never be anything following , so it's useless

Well, there is with -d output dumping.

> as well as confusing.  Also, if we compile multiple files at once (or
> use a compile server), then logically the  declaration
> *precede* all the actual code, which suggests that if  is
> output it should be the *first* line.  

I wanted it to be the first line, but like you say it breaks too much
including GCC's own -fpreprocessed.

> But that would break too much
> code.  Simplest and cleanest solution: Just get rid of the 
> line in pre-processor output.  This might break some tools that look
> at cpp output, but it seems unlikely.

Agreed - we never guarantee the form of -E anyway.

Neil.

Re: preprocessor/21250 and address of

[Zack Weinberg]

Per Bothner <[EMAIL PROTECTED]> writes:

...
> However, we end up with preprocessor output like this:
>
> # 1 "any-file"
> # 0 ""
> # 1 ""
> # 1 "any-file"
>
> Some assemblers complain about line number 0.  This is especially
> an issue for people who use cpp to preprocessor assembler, which
> of course we don't really support.
>
> My suggested solution: suppress the output of , so
> we get:
> # 1 "any-file"
> # 1 ""
> # 1 "any-file"
>
> There should never be anything following , so it's useless
> as well as confusing. 

Stuff does appear between  and  with -g3, -dD,
and possibly some of the other -d switches.  That is why they're
there.  I would have no objection to suppressing it (and  
too) when none of those options is in use.

zw

Re: preprocessor/21250 and address of

[Zack Weinberg]

Neil Booth <[EMAIL PROTECTED]> writes:

>> But that would break too much
>> code.  Simplest and cleanest solution: Just get rid of the 
>> line in pre-processor output.  This might break some tools that look
>> at cpp output, but it seems unlikely.
>
> Agreed - we never guarantee the form of -E anyway.

Just take care not to break -g3 -save-temps.

zw

Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.

[Mike Stump]

On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
   refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
   of time is spent there
I think comptypes can be sped up by canonicalizing types better, and  
also adding a conservative hash and checking it first.

Re: preprocessor/21250 and address of

[Per Bothner]

Zack Weinberg wrote:
Stuff does appear between  and  with -g3, -dD,
and possibly some of the other -d switches.  That is why they're
there.  I would have no objection to suppressing it (and  
too) when none of those options is in use.
In that case it's probably easiest to just hack c-ppoutput.c so line 0
is printed as line 1.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: unexpected hidden symbol in gcc 4.0.0

[Sam Lauber]

> > The documentation for -fvisibility=hidden suggets that this switch is
> > useful for shared libraries, to make things smaller and faster.  It
> > doesn't seem to be appropriate for object libraries.

> It's done *exactly* so that we catch this bug in your configury.

I don't know about you, but forcing a link failure in good
code just because someone screwed up GCC configuration is
probably the of the most worst compiler hacker's
sins.  

Samuel Lauber

-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Re: unexpected hidden symbol in gcc 4.0.0

[Richard Henderson]

On Wed, May 18, 2005 at 05:12:09AM +0100, Sam Lauber wrote:
> I don't know about you, but forcing a link failure in good
> code just because someone screwed up GCC configuration is
> probably the of the most worst compiler hacker's sins.  

But it IS NOT GOOD CODE!  That's the whole point.

Whatever.  Do what you want.  I don't care.



r~

Re: GCC 4.1: Buildable on GHz machines only?

[Ralf Corsepius]

On Tue, 2005-05-17 at 12:11 -0500, Joel Sherrill  wrote:
> Joe Buck wrote:
> > 
> > I used to be an embedded programmer myself, and while I cared very much
> > about the size and speed of the embedded code I wound up with, I didn't
> > care at all about being able to run the compiler itself on a machine that
> > wasn't reasonably up to date, much less trying to bootstrap the compiler
> > on an embedded target.  Is that really what we should be aiming for?
Well, an embedded programmer won't care much about this issue, but as
RTEMS maintainer, I am building and packaging the toolchains - so GCC
building times are a concern to me.

> >  As
> > opposed to just making -Os work really well?
ACK, this is an issue as well. 

ATM, I am experiencing objects being generated by GCC to increase in
size and forcing us to gradually abandon targets with tight memory
requirements. At least one cause of this seems to be GCC abandoning COFF
in favor of ELF, which seems to imply larger memory requirements.

>   If I could get better embedded
> > code by having the compiler use a lot of memory, but I could easily afford
> > a machine with that amount of memory, I would have had no complaint.
ACK.

> There are at least three classes of development I have noticed on this
> thread:
> 
>(1) self-hosting gcc on slow but traditional hosts (e.g. 68040 UNIX
>  or old Sun's)
>(2) self-hosted embedded development (e.g. sounds like Peter Barada)
>(3) embedded development using regular cross-compilation
> 
> In general all are concerned about lower end CPUs than are used for
> the mainstream GCC user on GNU/Linux and other UNIces.
> 
> (1) and (2) are similar and probably have similar requirements.  They 
> would like building GCC and running it to be possible on what would
> be considered low end hardware for main-stream development purposes.
> 
> (3) is the model for RTEMS, other RTOSes, no-OS targets, and could
> be the model used by (2).  I won't include (1) because they want their
> systems to be self supporting and users will compile their own code.
> 
> We are all concerned about the time and memory required to build GCC.
> But it is a critical concern for (1) and (2) since they are on small 
> hosts.  For (3) and RTEMS, it concerns us because the RTEMS Project
> provides RPMs for  11 targets and tries to include every language
> we can possibly support (C, C++, Ada, FORTRAN, and Java).  I know for 
> the targets that it compiles on, RTEMS works well with C, C++, and Ada.
> I am unsure about the precise status of RTEMS+Java
gcj builds for most RTEMS-targets. RTEMS support for libgcj and its
infrastructure is missing and probably won't be implemented any time
soon. A usable gcj+libgcj for RTEMS is not in sight.

>  and FORTRAN is currently up for discussion.
gfortran builds fine for all CPUs, building libgfortran fails for some
CPUs, which don't meet the expectations of gfortran/f95.

Objc builds without problems for all targets.

Ada builds for all CPUs Ada supports, but suffers from general cross-
building deficits and lacks multilibs.

>   Our tool build times are thus very long
> and when we follow up by building RTEMS and add-on libraries, it
> gets longer.  We struggle to keep up which is why RTEMS reports are
> sporadic and tend to cluster nearer a release point.
Be lucky, we can't build libgcj and gnat doesn't support multilibs. I
would not expect us to handle this.

> > It therefore seems that we have two *separate* problems: one is
> that 
> > increased resource consumption makes gcc harder to use as a hosted
> > compiler on older systems, and the other is that embedded target support
> > isn't getting the attention it needs
> [..]
> > it seems sometimes they get mixed solely because too many
> > free software projects don't support cross-compilation properly, but
> > that is a bug in those projects.
> 
> You are correct.  Many free libraries have rough edges when cross-
> building.
My point is: GCC also has them, and could do better wrt. this.

Ralf

Re: GCC 4.1: Buildable on GHz machines only?

[Ranjit Mathew]

Jonathan Wilson wrote:
>>Huh?  I can cross-compile GCC, its all the packages that require
>>native configuration/building
> 
> Is it fesable for people in this sort of situation to build GCC on a fast 
> machine but with the final host and target both set to whatever the slower 
> machine is (in this case coldfire)
> Does GCC even support that?

Yes, this is called a crossed-native build and GCC does
support it. I used to use it some time back for building
GCJ for Win32:

  http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html

You build a crossed-native compiler in two phases:

  1. Build a cross compiler for $TARGET on a fast box.

  2. Use the cross compiler to build a crossed-native
 compiler for $TARGET on the same box.

I used to do it for Win32 simply for the reason that
building under Linux (on the same box) was *way* faster
and less error-prone than under Win32.

I was going to suggest this to Peter myself before
I saw your message.

Ranjit.

PS: Surely this must be one of the longest threads in
recent times on the GCC list!

PPS: I do not see some of the messages, for example, a
couple of messages from Robert Dewar that seem to be
referenced in other messages.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Bootstrap failure in libobjc

[Andreas Jaeger]

On x86_64-linux-gnu I get with current CVS the following bootstrap error:

/cvs/gcc/libobjc/Object.m: In function '-[Object name]':
/cvs/gcc/libobjc/Object.m:101: internal compiler error: in tree_node_structure,
at tree.c:1815
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [Object.lo] Error 1


Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpDfunYJH3ya.pgp
Description: PGP signature