Re: Building C++ with --enable-languages=c,fortran

[Mikael Morin]

On Saturday 06 August 2011 00:52:02 Thomas Koenig wrote:
> Hello world,
> 
> I just noticed that C++ now appears to be built by default, even when
> only the C and fortran are specified.
Yes, but it doesn't make much difference in practice. The only difference I 
saw is the debugging symbols including the full prototype (not only the 
function name) in the debugger.
WRT to bootstrap time, as usual: it's too long.

Mikael

Re: Building C++ with --enable-languages=c,fortran

[Toon Moene]

On 08/06/2011 11:22 AM, Mikael Morin wrote:


WRT to bootstrap time, as usual: it's too long.


Well, that all depends on your (time) frame of reference, of course.  In 
the summer months leading up to Craig Burley asking for volunteers 
testing g77 (the g77-alpha phase), i.e., during the summer of 1992, a 
bootstrap of GCC (C and C++) took 8 hours on my single 25 Mhz Motorola 
68040 powered Next Station.


With the new gcc, I could build a fresh f2c in minutes, and, using that 
combo (f2c+gcc) a recompile of our weather forecasting code took another 
10 minutes.


Nowadays, on a *4 year old* quad core Core 2 machine, building C, C++, 
Ada and Fortran takes less than 2 hours, so given that I put in 4 times 
as many processors, the rest of the hardware keeps up with providing me 
a bootstrap in 1/4th of the time it took 19 years ago, giving me twice 
the number of front ends plus run time libraries.


I think the outlook is good :-)

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: libgcc: strange optimization

[Paolo Bonzini]

On 08/04/2011 01:10 PM, Andrew Haley wrote:

>>  It's the sort of thing that gets done in threaded interpreters,
>>  where you really need to keep a few pointers in registers and
>>  the interpreter itself is a very long function.  gcc has always
>>  done a dreadful job of register allocation in such cases.

>
>  Sure, but what I have seen people use global register variables
>  for this (which means they get taken away from the register allocator).


Not always though, and the x86 has so few registers that using a
global register variable is very problematic.  I suppose you could
compile the threaded interpreter in a file of its own, but I'm not
sure that has quite the same semantics as local register variables.


Indeed, local register variables give almost the same benefit as globals 
with half the burden.  The idea is that you don't care about the exact 
register that holds the contents but, by specifying a callee-save 
register, GCC will use those instead of memory across calls.  This 
reduces _a lot_ the number of spills.



The problem is that people who care about this stuff very much don't
always read...@gcc.gnu.org  so won't be heard.  But in their own world
(LISP, Forth) nice features like register variables and labels as
values have led to gcc being the preferred compiler for this kind of
work.


/me raises hands.

For GNU Smalltalk, using

#if defined(__i386__)
# define __DECL_REG1 __asm("%esi")
# define __DECL_REG2 __asm("%edi")
# define __DECL_REG3 /* no more caller-save regs if PIC is in use!  */
#endif

#if defined(__x86_64__)
# define __DECL_REG1 __asm("%r12")
# define __DECL_REG2 __asm("%r13")
# define __DECL_REG3 __asm("%rbx")
#endif

...

  register unsigned char *ip __DECL_REG1;
  register OOP * sp __DECL_REG2;
  register intptr_t arg __DECL_REG3;

improves performance by up to 20% if I remember correctly.  I can 
benchmark it if desired.


It does not come for free, in some cases the register allocator does 
some stupid things due to the hard register declaration.  But it gets 
much better code overall, so who cares about the microoptimization.


Of course, if the register allocator did the right thing, or if I could 
use simply


  unsigned char *ip __attribute__(__do_not_spill_me__(20)));
  OOP *sp __attribute__(__do_not_spill_me__(10)));
  intptr_t arg __attrbite__(__do_not_spill_me__(0)));

that would be just fine.

Paolo

Re: Building C++ with --enable-languages=c,fortran

[Steve Kargl]

On Sat, Aug 06, 2011 at 03:16:43PM +0200, Toon Moene wrote:
> On 08/06/2011 11:22 AM, Mikael Morin wrote:
> 
> >WRT to bootstrap time, as usual: it's too long.
> 
> Well, that all depends on your (time) frame of reference, of course.  In 
> the summer months leading up to Craig Burley asking for volunteers 
> testing g77 (the g77-alpha phase), i.e., during the summer of 1992, a 
> bootstrap of GCC (C and C++) took 8 hours on my single 25 Mhz Motorola 
> 68040 powered Next Station.
> 
> With the new gcc, I could build a fresh f2c in minutes, and, using that 
> combo (f2c+gcc) a recompile of our weather forecasting code took another 
> 10 minutes.
> 
> Nowadays, on a *4 year old* quad core Core 2 machine, building C, C++, 
> Ada and Fortran takes less than 2 hours, so given that I put in 4 times 
> as many processors, the rest of the hardware keeps up with providing me 
> a bootstrap in 1/4th of the time it took 19 years ago, giving me twice 
> the number of front ends plus run time libraries.
> 
> I think the outlook is good :-)
> 

You left out the crucial hardware spec.  How much memory
did you have 19 years ago compared to the system today?
My experience with g++ is that it will consume more memory
than gcc.  

-- 
Steve

Re: autogen version testing in fixincludes/genfixes

[Marc Glisse]

On Wed, 8 Jun 2011, Andreas Schwab wrote:


Basile Starynkevitch  writes:


And I also believe that the minuscule patch I am proposing in
http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
should work on your system too. Could you try it please?


That's not the point.  The point is, if you patch, you should do it
right.


Hello,

so what's the right way to do it?
(the number of people using 5.12 is increasing, we have to fix it)

1) not test autogen at all. It will fail if it has to fail. Besides,
   nobody has autogen 4.* anymore.
2) instead of grepping Ver. 5., grep for " 5." or GNU, or grep -v for
   " [0-4]".
3) something else.

--
Marc Glisse

PING: PATCH: Use int64 for x86 options

[H.J. Lu]

Ping.  AVX2 support depends on this patch.

Thanks.

On Thu, Aug 4, 2011 at 5:49 PM, H.J. Lu  wrote:
> On Thu, Aug 4, 2011 at 4:44 PM, H.J. Lu  wrote:
>> On Thu, Aug 4, 2011 at 3:46 PM, Joseph S. Myers  
>> wrote:
>>> On Thu, 4 Aug 2011, H.J. Lu wrote:
>>>
 Here is the updated patch to get proper HOST_WIDE_INT bits and 1
 through a new file, opt-gen.c.  OK for trunk?
>>>
>>> Using another generator program like this can't be the best approach
>>> (apart from anything else, when built for the build system hwint.h should
>>> reflect the build system types not the host system types; cf.
>>>  where I suspected that
>>> sort of host/build confusion of causing a reported build failure).
>>>
>>> You want opth-gen.awk to know the number of bits to give errors.  Note
>>> that the errors are given by generating #error into the output file.  It's
>>> easy enough to generate #if conditions into the file that compare with
>>> HOST_BITS_PER_WIDE_INT.
>>>
>>> You want opth-gen.awk to know whether to use 1LL as the shifted constant.
>>> You can easily enough make hwint.h contain a HOST_WIDE_INT_1 macro,
>>> defined to 1L or 1LL as appropriate.
>>>
>>
>>
>> Here is the updated patch.  OK for trunk?
>>
>
> Small update.  Replace 1LL with HOST_WIDE_INT_1 in  PTA_XXX.
> OK for trunk?
>
> Thanks.
>
> --
> H.J.
> ---
> 2011-08-04  H.J. Lu  
>            Igor Zamyatin 
>
>        * hwint.h (HOST_WIDE_INT_1): New.
>
>        * opt-functions.awk (switch_bit_fields): Initialize the
>        host_wide_int field.
>        (host_wide_int_var_name): New.
>        (var_type_struct): Check and return HOST_WIDE_INT.
>
>        * opt-read.awk: Handle HOST_WIDE_INT for "Variable".
>
>        * optc-save-gen.awk: Support HOST_WIDE_INT on var_target_other.
>
>        * opth-gen.awk: Use HOST_WIDE_INT_1 on HOST_WIDE_INT.  Properly
>        check masks for HOST_WIDE_INT.
>
>        * opts-common.c (set_option): Support HOST_WIDE_INT Flag_var.
>
>        * opts.h (cl_option): Add cl_host_wide_int.  Change var_value
>        to HOST_WIDE_INT.
>
>        * config/i386/i386-c.c (ix86_target_macros_internal): Replace int
>        with HOST_WIDE_INT for isa_flag.
>        (ix86_pragma_target_parse): Replace int with HOST_WIDE_INT for
>        isa variables.
>
>        * config/i386/i386.c (ix86_target_string): Replace int with
>        HOST_WIDE_INT for isa.  Use HOST_WIDE_INT_PRINT to print isa.
>        (ix86_target_opts): Replace int with HOST_WIDE_INT on mask.
>        (pta_flags): Removed.
>        (PTA_XXX): Redefined as (HOST_WIDE_INT_1 << X).
>        (pta): Use HOST_WIDE_INT on flags.
>        (builtin_isa): Use HOST_WIDE_INT on isa.
>        (ix86_add_new_builtins): Likewise.
>        (def_builtin): Use HOST_WIDE_INT on mask.
>        (def_builtin_const): Likewise.
>        (builtin_description): Likewise.
>
>        * config/i386/i386.opt (ix86_isa_flags): Replace int with
>        HOST_WIDE_INT.
>        (ix86_isa_flags_explicit): Likewise.
>        (x_ix86_isa_flags_explicit): Likewise.
>



-- 
H.J.

Re: Building C++ with --enable-languages=c,fortran

[Toon Moene]

On 08/06/2011 05:14 PM, Steve Kargl wrote:


You left out the crucial hardware spec.  How much memory
did you have 19 years ago compared to the system today?
My experience with g++ is that it will consume more memory
than gcc.


That might be true - I have never experienced memory shortage *building* 
C and C++ in 1992 - I had 16 Mbyte of RAM at that time.


Nowadays I have 4 Gbyte of RAM, but still *bootstrapping* doesn't seem 
to be a problem (certain parts of the weather forecasting system these 
days stretch the virtual memory system, but with 4 Gbyte RAM and 11 
Gbyte SWAP I still survive).


--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Christopher Huang-Leaver]

Hello,

This isn't really a compiler bug, but it's something which the manual
doesn't describe too well so I thought I would point this out.

This page of the manual:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

says this:
"
You should use these macros for testing like this:

  /* Test for a little-endian machine */
  #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__

"
... except you shouldn't !

To test for a little-endian machine you do this;

#include 
#if __BYTE_ORDER  == __LITTLE_ENDIAN

I hope this is helpful.  Keep up the great work!

Regards,

Chris


My test:

#include 
int main()
{
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
std::cout << "small end first\n";
#endif

#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
std::cout << "big end first\n";
#endif

return 0;
}

Output:

small end first
big end first

gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.5
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-altivec --disable-fixed-point --without-ppl --without-cloog
--enable-nls --without-included-gettext --with-system-zlib
--disable-werror --enable-secureplt --enable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/python
--enable-checking=release --enable-java-awt=gtk --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5
p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)


-- 
"They say great science is built on the shoulders of giants - not
here. At Aperture we do all our science from scratch; no hand
holding." - Cave Johnson, CEO Aperture Science.

Follow me on twitter:   @zeonglow

gcc-4.7-20110806 is now available

[gccadmin]

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

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

You'll find:

 gcc-4.7-20110806.tar.bz2 Complete GCC

  MD5=6931db45cfb0e11719b2839fdfa0760b
  SHA1=f5e0eed3e326cbd386d53f24aeb54501abee7f1a

Diffs from 4.7-20110730 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Jie Zhang]

On Sat, Aug 6, 2011 at 5:40 PM, Christopher Huang-Leaver
 wrote:
> Output:
>
> small end first
> big end first
>
> gcc -v
> gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)
>
I got the same result with g++-4.4 (4.4.6), g++-4.5 (4.5.3) on Debian
testing. But with g++-4.6, I got

small end first

on my x86_64-linux-gnu machine. I think it's a bug, but it has been
fixed in g++-4.6.

Regards,
Jie

Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Jonathan Wakely]

On 6 August 2011 22:40, Christopher Huang-Leaver wrote:
> Hello,
>
> This isn't really a compiler bug, but it's something which the manual
> doesn't describe too well so I thought I would point this out.
>
> This page of the manual:
> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

That documentation refers to the latest sources in GCC trunk, not to GCC 4.4

Re: __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ or does it?

[Jie Zhang]

On Sat, Aug 6, 2011 at 9:35 PM, Jonathan Wakely  wrote:
> On 6 August 2011 22:40, Christopher Huang-Leaver wrote:
>> Hello,
>>
>> This isn't really a compiler bug, but it's something which the manual
>> doesn't describe too well so I thought I would point this out.
>>
>> This page of the manual:
>> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros
>
> That documentation refers to the latest sources in GCC trunk, not to GCC 4.4
>
Ha, so it's not a bug. It's a new feature, which doesn't exist before 4.6.

Jie