Re: 4.3 build failure in driver-i386.c

[Richard Guenther]

On Feb 18, 2008 8:29 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 18, 2008 at 03:58:26AM +0100, Rask Ingemann Lambertsen wrote:
> > On Sun, Feb 17, 2008 at 11:44:18PM +0100, Jakub Jelinek wrote:
> > >
> > > Or we can just duplicate the 2 inline asms for __GNUC__ < 3
> > > or what is the oldest GCC that can handle the alternatives correctly.
> > > The __cpuid asm is short and the other one, while long, doesn't need
> > > changing too often.
> >
> >I'll try to fix it that way.
>
> BTW, I've just tested gcc 3.2.x and 2.96-RH (the oldest I could find around)
> and both handle the alternatives in asm just fine.
> From what I can see in SVN, ASSEMBLER_DIALECT is defined in config/i386.h
> since the merge of the "new" i386 backend by rth in September 1999.
> As 2.96-RH wasn't an official FSF release and nobody probably used it in
> Intel mode anyway, I think __GNUC__ < 3 is the right test.

Yes, this is what my limited search found, too.  Starting with GCC 3.0 we are
handling intel asm syntax.

Richard.

Re: omp_get_num_procs() not working on macintosh?

[Paolo Bonzini]

If so, someone familiar with Darwin needs to provide (a tested) darwin specific
proc.c implementation which can be added to libgomp/config/darwin/proc.c
to replace the libgomp/config/posix/proc.c version.


Here is code that does so:

  #include 
  #include 

  int main()
  {
int mib[2] = { CTL_HW, HW_AVAILCPU };
int result, len;
len = sizeof (result);
sysctl (mib, 2, &result, &len, NULL, 0);
printf ("%d\n", result);
  }

If you need to retrieve the number of processors in the system (i.e. the 
upper bound to HW_AVAILCPU, because the latter may change if a different 
power management modes is activated), you should use HW_NCPU instead.


Paolo

Re: gcc hangs ! (version 4.1.2, Ubuntu 4.1.2-0ubuntu4)

[Andrew Haley]

Sunzir Deepur wrote:

On Feb 17, 2008 3:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:

Sunzir Deepur wrote:

followup:

After a considerabale amount of time (e.g. 15 seconds), something is suddenly
freed, and the compilation completes successfully. afterwards trying
to recompile
the file completes immediately (it is not a big file, so it takes
fraction of a second).
I don't know what is the cause of the hang.. I can tell that while it is hung,
the cpu is not working (gcc doesn't even show in top..).

It's waiting on I/O.  This delay is either network related or a disk is
going to die.  It almost certainly isn't a gcc bug.


Thank you. Any idea how can I further scrutinize this ?


You need to know whether it's waiting for disk or network; I can't help you
with that.  Then you need to think about smartd reporting or somesuch.

Andrew.

Turning cc1plus into a shared library

[Argiris Kirtzidis]

Hi all,

I'm interested in turning cc1plus into a shared library with an API on 
top so that it's possible to:


-Programmatically parse & compile a C++ file
-Parse a file, traverse the internal tree representation and get any C++ 
information that you are looking for
-Parse, make changes to the internal tree, continue with the backend 
processing (so you can, for example, programmatically add security 
checks to all/some functions)


The API should be easy to use not only from C but from other languages 
that can use C libraries.



Is there something similar that is already being developed ?
Any thoughts on the above ?

hash_map for OpenVMS?

[Info IT-BCSB]

Hello,
 
i have a problem and hope you could help me to transport the special
funktion "hash_map" to the OpenVMS system for a special software. This
special software was develop on a linux system with the g++ compiler. Now, i
would like to move this special software to OpenVMS. But OpenVMS has not the
function "hash_map" :-(.
 
What can i do to port only the "hash_map" function from your g++ library to
OpenVMS. Is it possible, that you could give me some hints? Wich file does i
need? The are to lots of files...
 
Thank you very much for your help.
 
Kind regards,
 
Klaus-Dieter Bohn
 
 

 
Klaus-Dieter Bohn
Monreposstr. 49
71634 Ludwigsburg
 
)Phone:   +49 (0)7141 / 46 46 28
(FAX: +49 (0)89 / 14 88 - 21 45 74
*Email:   [EMAIL PROTECTED]

Re: hash_map for OpenVMS?

[Paolo Carlini]

Info IT-BCSB wrote:
> Hello,
>  
> i have a problem and hope you could help me to transport the special
> funktion "hash_map" to the OpenVMS system for a special software. This
> special software was develop on a linux system with the g++ compiler. Now, i
> would like to move this special software to OpenVMS. But OpenVMS has not the
> function "hash_map" :-(.
>   
I do not understand. Any installation of g++ includes the standard
library and therefore also the legacy hash_map extension. Note however
that you will find it in namespace __gnu_cxx
, not std, as provided in .

Paolo.

Re: [PATCH, DOC] PR 31549: move -frtl-abstract-sequences description

[Gabor Loki]

Gerald Pfeifer wrote:

The last time I tried this on ARM it didn't work because there were
ICEs and it might have been fixed by now.

However searching on bugzilla found me these .

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


In the latter Richard wrote "I propose to kill all traces of it unless 
someone steps up and maintains this piece of code and we enable it for 
-Os".


Gabor, what are your plans?  Having a pass which seems to crash more
than anything else doesn't seem useful so I agree with Richard.


Hi guys,

First of all I am sorry, but I was a really busy with other things in the past 
year.
I didn't have enough free time to keep track on CFO related stuffs.

Now, It seems that I can spend more time on CFO. I can't make big promises.
I still don't get too much time for this, but I hope it will be enough to fix 
those
bugs and the regressions.

If it is OK for you I will on this topic.

--Gabor

[plugins] include conventions

[Basile STARYNKEVITCH]

Hello All,

[I hope that the GCC mailing list is the good place for plugins related 
question]


This is a technical newbie question regarding the "plugin" effort (or 
even branch) of GCC.


I suppose that a plugin machinery for GCC offers, for the plugin to be 
compiled, some conventions. In particular, I would imagine that many *.h 
either generated (like gcc/auto-host.h gcc/genrtl.h gcc/gt-*.h 
gcc/tree-check.h in the build directory) or supplied (like gcc/tree.h in 
the source directory) are, in a proper plugin facility, installed or 
copied somewhere else.


My question is where is this stuff conventionnally installed and how.

In other words, how can somebody compile a plugin for GCC on a system 
without GCC build directory?


Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Turning cc1plus into a shared library

[Tom Tromey]

> "Argiris" == Argiris Kirtzidis <[EMAIL PROTECTED]> writes:

Argiris> I'm interested in turning cc1plus into a shared library with
Argiris> an API on top so that it's possible to:

Argiris> The API should be easy to use not only from C but from other
Argiris> languages that can use C libraries.

Argiris> Is there something similar that is already being developed ?
Argiris> Any thoughts on the above ?

There are a few developments in this area.  As far as I know none of
them is focused on turning gcc into a shared library; instead they
work as plugins.

Here's the stuff I'm following:

GCC Plugins branch.  Presented at 2007 GCC Summit.

http://gcc.gnu.org/wiki/GCC_Plugins

Basile's MELT project.  Also from the 2007 Summit, should be made
into a branch soon:

http://gcc.gnu.org/wiki/MiddleEndLispTranslator

GCC Dehydra -- uses javascript as an extension language:

http://wiki.mozilla.org/Dehydra_GCC

(Taras Glek's blog is worth reading -- most Dehydra news is posted
there.)

Finally, for just examining the results (not modifying things as GCC
compiles), you might consider GCC-XML.

http://www.gccxml.org/HTML/Index.html


Whether any of these will make it into GCC is an open question.  I
suggest reading the list archives before re-opening this topic.

Tom

Re: GCC 4.3.0 Status Report (2008-02-14)

[Janis Johnson]

PR target/34526 doesn't show up as a regression but it is in that
on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize
and with the default, non-AltiVec ABI vector registers can be
clobbered by other functions in the same call tree.  An example
of this is 176.gcc from SPEC CPU2000.

The fix at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00094.html
introduces a regression by exposing an existing bug in varargs
passing of generic vectors with "-mno-altivec -mabi=altivec".  I'm
still trying to get that fixed (delayed last week by father's
surgery and daughter's wedding), but even if the fix doesn't make
it in time the fix for vectorization is much more important than
breakage to functionality that probably isn't used in the real world.

RMs, please take a look at this.

Janis

Re: [plugins] include conventions

[Emmanuel Fleury]

Basile STARYNKEVITCH wrote:
> 
> In other words, how can somebody compile a plugin for GCC on a system
> without GCC build directory?

Only if you do not use any of the GCC internal data-structures...
which seems to narrow a lot the interest of GCC plugins. :)

Short answer would be: No.

Regartds
-- 
Emmanuel Fleury

Weekends don't count unless you spend them doing
something completely pointless.
  -- Calvin & Hobbes (Bill Waterson)

Re: bootstrap broken on mingw

[Mark Mitchell]

Weddington, Eric wrote:

Yes, because the one provided with MSYS is from texinfo 4.3, which  
GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo  
4.11, but it's still labeled "technology preview" for now.



I'm in the same boat here, msys-1.0.10, texinfo 4.3.


Is it the case that if you were to install texinfo 4.11, then it would 
build?  If so, I think we should just add a release note that you can't 
build the documentation with the standard installation of MinGW due to 
this issue, and, perhaps, automatically disable building it on MinGW 
systems.


Or, is it the case that the patch to use abs_srcdir means that no matter 
what Texinfo you have, it's not going to work on MinGW?


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

[Jakub Jelinek]

On Mon, Feb 18, 2008 at 09:29:22AM -0800, Janis Johnson wrote:
> PR target/34526 doesn't show up as a regression but it is in that
> on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize
> and with the default, non-AltiVec ABI vector registers can be
> clobbered by other functions in the same call tree.  An example
> of this is 176.gcc from SPEC CPU2000.
> 
> The fix at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00094.html
> introduces a regression by exposing an existing bug in varargs
> passing of generic vectors with "-mno-altivec -mabi=altivec".  I'm
> still trying to get that fixed (delayed last week by father's
> surgery and daughter's wedding), but even if the fix doesn't make
> it in time the fix for vectorization is much more important than
> breakage to functionality that probably isn't used in the real world.

I'd like to understand what exactly would defaulting to the Altivec
ABI for ppc-linux mean.  -mabi=altivec passes some types of vectors
in Altivec registers, but you can hardly pass anything in those registers
if the CPU doesn't support the Altivec ISA.  So, would -m32 be ABI
incompatible with -m32 -mcpu=970 e.g.?
And, will we have still a possibility to choose a broken setup (ATM
-m32 -maltivec, in the future -m32 -maltivec -mabi=no-altivec)?  By broken
I mean that if the code works, it is just by luck; Altivec registers
are neither call-used nor call-saved nor fixed.
I'd like to understand why -m32 -maltivec when -mabi=altivec is not
requested can't make all altivec registers call-used.  Whether something
is call-saved is a part of ABI, you need to save the call-saved registers
in the call frame and have unwind info which can restore them.
The non-altivec ABI doesn't mention the Altivec registers (it predates
them), so they are not call-saved.  But saying that they aren't call-used
is wrong, when functions don't save them.
What would break if in non-altivec ABI all Altivec registers are either
fixed (-mno-altivec) or call-used (-maltivec)?

Jakub

Re: GCC 4.3.0 Status Report (2008-02-14)

[David Edelsohn]

Jakub,

PPC970 and POWER6 support Altivec and that feature is enabled for
those processor by default.  Now with inlining, auto-vectorization, and
copying via Altivec registers, GCC needs to save and restore the registers
correctly for overlapped use enabled implicitly.  PPC64 Linux enables the
Altivec ABI by default, but PPC32 Linux does not.

Currently, GCC for 32-bit powerpc-linux can generate Altivec code
that produces wrong results.  We need to enable Altivec ABI for
powerpc-linux so that Altivec code works correctly and as expected.

Thanks, David

Re: GCC 4.3.0 Status Report (2008-02-14)

[Janis Johnson]

On Mon, 2008-02-18 at 15:25 -0500, Jakub Jelinek wrote:
> On Mon, Feb 18, 2008 at 09:29:22AM -0800, Janis Johnson wrote:
> > PR target/34526 doesn't show up as a regression but it is in that
> > on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize
> > and with the default, non-AltiVec ABI vector registers can be
> > clobbered by other functions in the same call tree.  An example
> > of this is 176.gcc from SPEC CPU2000.
> > 
> > The fix at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00094.html
> > introduces a regression by exposing an existing bug in varargs
> > passing of generic vectors with "-mno-altivec -mabi=altivec".  I'm
> > still trying to get that fixed (delayed last week by father's
> > surgery and daughter's wedding), but even if the fix doesn't make
> > it in time the fix for vectorization is much more important than
> > breakage to functionality that probably isn't used in the real world.
> 
> I'd like to understand what exactly would defaulting to the Altivec
> ABI for ppc-linux mean.  -mabi=altivec passes some types of vectors
> in Altivec registers, but you can hardly pass anything in those registers
> if the CPU doesn't support the Altivec ISA.  So, would -m32 be ABI
> incompatible with -m32 -mcpu=970 e.g.?
> And, will we have still a possibility to choose a broken setup (ATM
> -m32 -maltivec, in the future -m32 -maltivec -mabi=no-altivec)?  By broken
> I mean that if the code works, it is just by luck; Altivec registers
> are neither call-used nor call-saved nor fixed.
> I'd like to understand why -m32 -maltivec when -mabi=altivec is not
> requested can't make all altivec registers call-used.  Whether something
> is call-saved is a part of ABI, you need to save the call-saved registers
> in the call frame and have unwind info which can restore them.
> The non-altivec ABI doesn't mention the Altivec registers (it predates
> them), so they are not call-saved.  But saying that they aren't call-used
> is wrong, when functions don't save them.
> What would break if in non-altivec ABI all Altivec registers are either
> fixed (-mno-altivec) or call-used (-maltivec)?

With -mno-altivec, types defined with __attribute__((vector_size(16)))
are not mapped to AltiVec vector types.  When -mabi=altivec is used
without AltiVec hardware support, there are no AltiVec vector types to
pass as arguments and they are passed in other ways, which are kind of
broken and ought to be fixed eventually (see PR34526) but the code
works.

With -maltivec -mabi=no-altivec, AltiVec vectors are passed by reference
or on the stack or in general registers.  Except for variable argument
lists, this works.  The problem is that the non-AltiVec ABI doesn't call
for saving and restoring AltiVec registers, and other people's attempts
to fix that have failed; that information is from IRC, I don't remember
who tried.  Fixing that would certainly be the best option, but I tried
for something simpler.  Unfortunately changing the default ABI exposed
the va-arg-25.c failure and investigation of that made me realize that
argument passing and function return is not consistent for generic
vectors with and without the AltiVec ABI (PR target/33899).

I changed argument passing and function return of generic vectors to be
consistent with and without the AltiVec ABI for powerpc-linux  and
powerpc64-linux, but in so doing inadvertently changed the behavior for
other powerpc targets as well.  Meanwhile the trunk has been more and
more frozen, so the latest attempt is to switch the default ABI with as
little other change as possible.

For what it's worth I now have a minimal hack to fix va-arg-25.c.

For GCC 4.4 I'd like to get input from the people involved with the
PowerPC-32 and -64 ELF ABIs to regularize passing of generic vectors.

I can look into saving and restoring registers with -maltivec
-mabi=no-altivec but that's likely to take me awhile.

Janis

Re: GCC 4.3.0 Status Report (2008-02-14)

[Jakub Jelinek]

On Mon, Feb 18, 2008 at 03:57:10PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote:
> > What would break if in non-altivec ABI all Altivec registers are either
> > fixed (-mno-altivec) or call-used (-maltivec)?
> 
> I still suggest that the correct choice is to use the same set of
> call-used and call-saved registers without the AltiVec ABI as we do
> with it.  Which has no affect with -mno-altivec, but requires some
> prologue work with -maltivec -mabi=no-altivec.  After that, whether
> the default ABI is AltiVec or not does not much matter to GCC.

That can work too, assuming on ppc-linux we can rely the kernel and libc
handle saving/restoring the altivec regs (guess we can rely on it these
days).  All I'm trying to say is that having an option combination where
some registers are neither fixed, nor call-used, nor call-saved
is a bug (in the current -m32 -maltivec case I think they are officially
call-saved, but nothing saves/restores them).

Jakub

Re: GCC 4.3.0 Status Report (2008-02-14)

[Daniel Jacobowitz]

On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote:
> What would break if in non-altivec ABI all Altivec registers are either
> fixed (-mno-altivec) or call-used (-maltivec)?

I still suggest that the correct choice is to use the same set of
call-used and call-saved registers without the AltiVec ABI as we do
with it.  Which has no affect with -mno-altivec, but requires some
prologue work with -maltivec -mabi=no-altivec.  After that, whether
the default ABI is AltiVec or not does not much matter to GCC.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC 4.3.0 Status Report (2008-02-14)

[Janis Johnson]

On Mon, 2008-02-18 at 16:12 -0500, Jakub Jelinek wrote:
> On Mon, Feb 18, 2008 at 03:57:10PM -0500, Daniel Jacobowitz wrote:
> > On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote:
> > > What would break if in non-altivec ABI all Altivec registers are either
> > > fixed (-mno-altivec) or call-used (-maltivec)?
> > 
> > I still suggest that the correct choice is to use the same set of
> > call-used and call-saved registers without the AltiVec ABI as we do
> > with it.  Which has no affect with -mno-altivec, but requires some
> > prologue work with -maltivec -mabi=no-altivec.  After that, whether
> > the default ABI is AltiVec or not does not much matter to GCC.
> 
> That can work too, assuming on ppc-linux we can rely the kernel and libc
> handle saving/restoring the altivec regs (guess we can rely on it these
> days).  All I'm trying to say is that having an option combination where
> some registers are neither fixed, nor call-used, nor call-saved
> is a bug (in the current -m32 -maltivec case I think they are officially
> call-saved, but nothing saves/restores them).

I have a patch, written since this thread started, that saves and
restores AltiVec registers based on TARGET_ALTIVEC instead of
TARGET_ALTIVEC_ABI.  It passes gcc.target/powerpc tests and 176.gcc
with "-O3 -maltivec -mabi=no-altivec".  I'll post that soon and do
full bootstrap/regtest.

Janis

Re: omp_get_num_procs() not working on macintosh?

[CSights]

> > Perhaps Darwin doesn't define _SC_NPROCESSORS_ONLN
>
> It is defined on Darwin9:
>
> [ibook-dhum] f90/bug% grep _SC_NPROCESSORS_ONLN /usr/include/*
> /usr/include/unistd.h:#define   _SC_NPROCESSORS_ONLN            58
>
> but apparently not for Darwin8.
>
> Dominique

Yep, I'm having trouble with Darwin v 8.

$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; 
root:xnu-792.25.20~1/RELEASE_I386

Re: GCC 4.3.0 Status Report (2008-02-14)

[Janis Johnson]

On Mon, 2008-02-18 at 17:21 -0500, David Edelsohn wrote:
> > Janis Johnson writes:
> 
> Janis> I have a patch, written since this thread started, that saves and
> Janis> restores AltiVec registers based on TARGET_ALTIVEC instead of
> Janis> TARGET_ALTIVEC_ABI.  It passes gcc.target/powerpc tests and 176.gcc
> Janis> with "-O3 -maltivec -mabi=no-altivec".  I'll post that soon and do
> Janis> full bootstrap/regtest.
> 
>   That is not what -maltivec is suppose to control.

What should it control?  I think it should mean to use AltiVec hardware
support where possible, which includes saving and restoring AltiVec
registers that are used within a function.  The only reason I hadn't
tried this change before was that I heard that others had tried it
without success.

This new patch does not affect passing and returning AltiVec types as
controlled by -mabi=[no-]altivec.

Janis

gcc-4.1-20080218 is now available

[gccadmin]

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

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

You'll find:

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

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

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

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

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

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

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

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

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

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

Re: GCC 4.3.0 Status Report (2008-02-14)

[David Edelsohn]

> Janis Johnson writes:

Janis> I have a patch, written since this thread started, that saves and
Janis> restores AltiVec registers based on TARGET_ALTIVEC instead of
Janis> TARGET_ALTIVEC_ABI.  It passes gcc.target/powerpc tests and 176.gcc
Janis> with "-O3 -maltivec -mabi=no-altivec".  I'll post that soon and do
Janis> full bootstrap/regtest.

That is not what -maltivec is suppose to control.

David

GCC 4.3 branch created, 4.4 opens for stage1

[Jakub Jelinek]

Hi!

As I've mentioned last week, I've created branches/gcc-4_3-branch.
The trunk is now 4.4 stage 1, the branch is open for regression bugfixes
and documentation fixes only, but additionally all checkings require
RM approval in addition to normal approval.
Before the release candidate is cut, it would be good to fix the 4 P1
bugs we have now:
PR34950 - Jason/Mark, could you help with this?  It is 4.2/4.3
  regression, so perhaps doesn't need to hold the rc
PR35218 - I believe the latest patch worked for the tester,
  so we now have a patch and just need an approval?
PR35232 - I'm not sure I'm comfortable with a big reload patch
  this late
PR35239 - Rask, do you have a patch for this?
and:
libjava bootstrap problem on i?86-darwin8* - can anyone who can reproduce
  it please try 
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00265.html
  ? Can we have a bugzilla bug for it?
ppc-linux -maltivec stuff - assuming a solution is agreed on quickly

Anything else I'm forgetting?

Jakub

Double constructors in C++?

[Samuel Tardieu]

Hi.

Why are constructors included twice in object code? This is with
GCC 4.3.0 20080214:

% cat t.cc
#include 
class T{
 T(const std::string&);
 int foo();
 int x;
};

T::T(const std::string&) {x=2;}
int T::foo()
{
 x=7;
}

% g++  -c -o t.o t.cc -fomit-frame-pointer -O

% nm -S -C t.o
0018 000b T T::foo()
000c 000b T T::T(std::string const&)
 000b T T::T(std::string const&)

% objdump -D t.o
Disassembly of section .text:

 <_ZN1TC2ERKSs>:
   0:   8b 44 24 04 mov0x4(%esp),%eax
   4:   c7 00 02 00 00 00   movl   $0x2,(%eax)
   a:   c3  ret
   b:   90  nop

000c <_ZN1TC1ERKSs>:
   c:   8b 44 24 04 mov0x4(%esp),%eax
  10:   c7 00 02 00 00 00   movl   $0x2,(%eax)
  16:   c3  ret
  17:   90  nop

0018 <_ZN1T3fooEv>:
  18:   8b 44 24 04 mov0x4(%esp),%eax
  1c:   c7 00 07 00 00 00   movl   $0x7,(%eax)
  22:   c3  ret

The constructor seems to be included twice with the very same code. Is
that expected?

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/

Re: GCC 4.3 branch created, 4.4 opens for stage1

[David Edelsohn]

> Jakub Jelinek writes:

Jakub> As I've mentioned last week, I've created branches/gcc-4_3-branch.
Jakub> The trunk is now 4.4 stage 1, the branch is open for regression bugfixes
Jakub> and documentation fixes only, but additionally all checkings require

I had hoped that you would not open the trunk to 4.4 stage 1 until
GCC 4.3 was released.

David

Re: GCC 4.3.0 Status Report (2008-02-14)

[Mark Mitchell]

Daniel Jacobowitz wrote:

On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote:

What would break if in non-altivec ABI all Altivec registers are either
fixed (-mno-altivec) or call-used (-maltivec)?


I still suggest that the correct choice is to use the same set of
call-used and call-saved registers without the AltiVec ABI as we do
with it.  Which has no affect with -mno-altivec, but requires some
prologue work with -maltivec -mabi=no-altivec.  After that, whether
the default ABI is AltiVec or not does not much matter to GCC.


What does the AltiVec ABI itself actually cover?  Does it say which 
registers are saved by callers vs. callees, or does it just say how to 
pass values in AltiVec registers?


I assume we want to maintain backwards compatibility with existing 
AltiVec-unaware code (i.e., code compiled with -mno-altivec 
-mabi=no-altivec) compiled for Power GNU/Linux?


If so, then we have to use those conventions for which of the base 
registers to save in callers vs. callees.  But, with -maltivec 
-mabi=no-altivec, then we have to save/restore the AltiVec registers. 
If nothing else, why not have the caller assume they are clobbered by 
calls, and, therefore save whatever AltiVec registers its using?  Is 
that what you're suggesting?


Daniel, perhaps you can put a full proposal on the table so that we can 
try to get consensus on thsi?


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.3 branch created, 4.4 opens for stage1

[Joseph S. Myers]

On Mon, 18 Feb 2008, Jakub Jelinek wrote:

> As I've mentioned last week, I've created branches/gcc-4_3-branch.
> The trunk is now 4.4 stage 1, the branch is open for regression bugfixes

Before we start getting 4.4-specific bugs or fixes, all open bugs with 
"4.3" in their summaries need it changing to "4.3/4.4".  (Branching 
checklist item 13.  While we're about it, can we remove the "4.0/" from 
open bugs to keep the summaries from growing ever longer?)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.3 branch created, 4.4 opens for stage1

[Ralf Wildenhues]

* Jakub Jelinek wrote on Tue, Feb 19, 2008 at 12:18:02AM CET:
> PR35218   - I believe the latest patch worked for the tester,
> so we now have a patch and just need an approval?

Yes, the patch is at

and the confirmation at


Cheers,
Ralf

Re: GCC 4.3.0 Status Report (2008-02-14)

[Janis Johnson]

On Mon, 2008-02-18 at 18:58 -0500, David Edelsohn wrote:
>   I misread Janis's latest patch that I approved.
> 
>   The patch was suppose to enable -mabi=altivec when -maltivec is
> enabled, not change the default ABI.
> 
>   For other OSes, -mabi=altivec is the default, so -maltivec just
> works and produces correct code.  If a user enables -maltivec on
> powerpc32-linux explicitly or implicitly (with -mcpu=970 or -mcpu=power6),
> presumably he or she want GCC to produce correct, self-consistent,
> ABI-compliant Altivec code.  Because no other OSes require an explicit
> invocation of -mabi=altivec and most users do not expect to need multiple
> commandline options for correct operation, users are confused.  Therefore,
> the plan is for -maltivec to imply -mabi=altivec for ppc32-linux.
> 
>   In summary, the patch is suppose to make -maltivec produce correct
> code on ppc32-linux.
> 
>   Mark, I appreciate your and Daniel's suggestions, but that is not
> what we wish to implement for ppc32-linux.

I was writing the following while David sent his mail above.  I agree
with him about what changes we should make.

I discussed this on IRC with David Edelsohn and others.  I plan to modify
the patch at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00521.html to
set the default for the AltiVec ABI based on -maltivec; that patch had set
it by default.  That patch will continue to re-enable -mabi=no-altivec,
which had been broken since 4.0.  I had hoped to get this in before the
4.3 release but it probably won't make it and isn't worth holding up the
release.

I have a separate patch to fix the bug in gcc.c-torture/execute/va-arg-25.c
which has always been broken if compiled with -mabi=altivec and was exposed
in testing for last week's patch, which made it a regression.  If the
AltiVec ABI is only the default with -maltivec then that bug will no longer
be a regression for default options so I can wait and fix it more cleanly.

There is no ABI that defines saving and restoring AltiVec registers
without the rest of the AltiVec ABI, so I'll leave that alone.  Users who
explicity use "-maltivec -mabi=no-altivec" will get dangerous code.

There are lots of inconsistencies in passing generic vectors as arguments
and return values, and I'll leave those alone until the PowerPC ELF ABI
group decides what to do with them.

Janis

Re: GCC 4.3.0 Status Report (2008-02-14)

[David Edelsohn]

I misread Janis's latest patch that I approved.

The patch was suppose to enable -mabi=altivec when -maltivec is
enabled, not change the default ABI.

For other OSes, -mabi=altivec is the default, so -maltivec just
works and produces correct code.  If a user enables -maltivec on
powerpc32-linux explicitly or implicitly (with -mcpu=970 or -mcpu=power6),
presumably he or she want GCC to produce correct, self-consistent,
ABI-compliant Altivec code.  Because no other OSes require an explicit
invocation of -mabi=altivec and most users do not expect to need multiple
commandline options for correct operation, users are confused.  Therefore,
the plan is for -maltivec to imply -mabi=altivec for ppc32-linux.

In summary, the patch is suppose to make -maltivec produce correct
code on ppc32-linux.

Mark, I appreciate your and Daniel's suggestions, but that is not
what we wish to implement for ppc32-linux.

Thanks, David

Re: GCC 4.3.0 Status Report (2008-02-14)

[Mark Mitchell]

Janis Johnson wrote:


I discussed this on IRC with David Edelsohn and others.  I plan to modify
the patch at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00521.html to
set the default for the AltiVec ABI based on -maltivec; that patch had set
it by default.  That patch will continue to re-enable -mabi=no-altivec,
which had been broken since 4.0.  I had hoped to get this in before the
4.3 release but it probably won't make it and isn't worth holding up the
release.


OK, that takes the pressure off.  I was wading in here because of the 
request that we put this in 4.3, and I felt that I couldn't in good 
conscience approve that without understanding the details better.  If we 
can take our time, then that's easier.



without the rest of the AltiVec ABI, so I'll leave that alone.  Users who
explicity use "-maltivec -mabi=no-altivec" will get dangerous code.


That seems OK.

However, if I understand correct, some users have probably been 
implicitly using those options because they were using "-mcpu=970", or 
otherwise specifying an AltiVec CPU.  It seems desirable in the abstract 
that this code still be binary-compatible with new -mcpu=970 code, if it 
was "plain C" code not using AltiVec vectors explicitly.  But, I don't 
know if that's technically feasible or not.



There are lots of inconsistencies in passing generic vectors as arguments
and return values, and I'll leave those alone until the PowerPC ELF ABI
group decides what to do with them.


It's certainly good to minimize the number of times we introduce ABI 
changes, so waiting for a definitive plan makes sense.


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

[Mark Mitchell]

David Edelsohn wrote:


The patch was suppose to enable -mabi=altivec when -maltivec is
enabled, not change the default ABI.


OK.

If I understand correctly, then, this is going to be an ABI break for 
32-bit Power GNU/Linux users using an AltiVec CPU (like 970).  In 
particular, if I have code that I compiled with -mcpu=970 (and no other 
options) with GCC 4.2, it's not going to be link-compatible with code 
compiled in the same way for GCC 4.3.  Is that right?  Is that still 
true if I didn't use AltiVec extensions (whether via the AltiVec PEM 
syntax or via GCC's vector extensions)?  In other words, is "plain" C 
code going to be incompatible?


I understand that without making some kind of change things are just 
plain broken.  And, I'm not making a judgment as to the desirability of 
making a change, but I'd like to understand what we're doing and what 
impact it might have on the various stakeholders.


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.3 branch created, 4.4 opens for stage1

[Doug Gregor]

On Feb 18, 2008 6:18 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> As I've mentioned last week, I've created branches/gcc-4_3-branch.
> The trunk is now 4.4 stage 1, the branch is open for regression bugfixes
> and documentation fixes only, but additionally all checkings require
> RM approval in addition to normal approval.
> Before the release candidate is cut, it would be good to fix the 4 P1
> bugs we have now:
> PR34950 - Jason/Mark, could you help with this?  It is 4.2/4.3
>   regression, so perhaps doesn't need to hold the rc
> PR35218 - I believe the latest patch worked for the tester,
>   so we now have a patch and just need an approval?
> PR35232 - I'm not sure I'm comfortable with a big reload patch
>   this late
> PR35239 - Rask, do you have a patch for this?
> and:
> libjava bootstrap problem on i?86-darwin8* - can anyone who can reproduce
>   it please try 
> http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00265.html
>   ? Can we have a bugzilla bug for it?
> ppc-linux -maltivec stuff - assuming a solution is agreed on quickly
>
> Anything else I'm forgetting?

I'd love to get the fix for c++/35022 into this release. It's a
regression marked as an ice-on-invalid, but slight variations on that
test show several issues with variadic templates. The patch is here:

  http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00575.html

The fix itself will only affect code when we're in C++0x mode, so it's
very low-risk. With this fix, nearly all of the non-error-recovery
issues with variadic templates will have been solved, so we'll have a
pretty solid start at C++0x out there for people to start working
with.

  - Doug

Re: GCC 4.3.0 Status Report (2008-02-14)

[David Edelsohn]

> Mark Mitchell writes:

Mark> However, if I understand correct, some users have probably been 
Mark> implicitly using those options because they were using "-mcpu=970", or 
Mark> otherwise specifying an AltiVec CPU.  It seems desirable in the abstract 
Mark> that this code still be binary-compatible with new -mcpu=970 code, if it 
Mark> was "plain C" code not using AltiVec vectors explicitly.  But, I don't 
Mark> know if that's technically feasible or not.

The problem is that "plain C" code can generate Altivec
instructions in multiple ways.  Altivec is used for large, aligned block
moves.  Altivec is used for auto-vectorization, which now is enabled by
default at -O3.  GCC currently can generate incorrect code whether or not
the user explicitly enabled Altivec and whether or not the user explicitly
used Altivec instrinsics.

The Altivec ABI does change the stack alignment.  This should not
create an incompatibility for old code, but new code may not receive the
stack properly aligned without additional dynamic alignment.  The other
issue is argument passing for GCC generic vectors, mentioned by Janis, but
that feature is documented to have "unexpected behavior" and few people
use it.

Thanks, David

Re: GCC 4.3.0 Status Report (2008-02-14)

[Mark Mitchell]

David Edelsohn wrote:

Mark Mitchell writes:


Mark> However, if I understand correct, some users have probably been 
Mark> implicitly using those options because they were using "-mcpu=970", or 
Mark> otherwise specifying an AltiVec CPU.  It seems desirable in the abstract 
Mark> that this code still be binary-compatible with new -mcpu=970 code, if it 
Mark> was "plain C" code not using AltiVec vectors explicitly.  But, I don't 
Mark> know if that's technically feasible or not.


The problem is that "plain C" code can generate Altivec
instructions in multiple ways. 


I was afraid of that.


The Altivec ABI does change the stack alignment.  This should not
create an incompatibility for old code, but new code may not receive the
stack properly aligned without additional dynamic alignment.  The other
issue is argument passing for GCC generic vectors, mentioned by Janis, but
that feature is documented to have "unexpected behavior" and few people
use it.


So, if we wanted to make this interoperate better, we'd have to 
introduce dynamic stack alignment in every externally visible function, 
thereby penalizing the average user who isn't trying to support linking 
with legacy code.  Right?


I suppose that another solution would be to have the linker generate 
stubs.  Let the new code just use the standard ABI, but mark the 
functions in some way to that the linker could generate stubs for calls 
from legacy code.  The stubs would align the stack and then call the 
real function.  That would avoid penalizing the new code, but still 
preserve compatibility.


If you think that's a good idea, though, that doesn't stand in the way 
of the plan you and Janis have presented -- it's a follow-on idea that 
could be implemented if there's enough demand.  That's good.


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2008-02-14)

[Joseph S. Myers]

On Mon, 18 Feb 2008, Janis Johnson wrote:

> There are lots of inconsistencies in passing generic vectors as arguments
> and return values, and I'll leave those alone until the PowerPC ELF ABI
> group decides what to do with them.

Perhaps you'd care to recommend what the semantics *ought* to be, given 
that they're currently inconsistent?  The provisional conclusion at the 
last ABI call was to add ATR-SOFT-VECTOR-64 and ATR-SOFT-VECTOR-128 to the 
ABI taxonomy, recognising that the existence of vector types does not 
depend on the existence of vector registers, but we don't have any 
associated ABI text to describe associated argument-passing and return 
rules, only that for Altivec and SPE vectors conditional on ATR-ALTIVEC 
and ATR-SPE respectively.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.3.0 Status Report (2008-02-14)

[David Edelsohn]

> Mark Mitchell writes:

Mark> So, if we wanted to make this interoperate better, we'd have to 
Mark> introduce dynamic stack alignment in every externally visible function, 
Mark> thereby penalizing the average user who isn't trying to support linking 
Mark> with legacy code.  Right?

As Daniel channeled Geoff (;-) on this thread, powerpc-linux
already has the correct stack alignment.

David

Re: GCC 4.3.0 Status Report (2008-02-14)

[Daniel Jacobowitz]

On Mon, Feb 18, 2008 at 08:16:39PM -0500, David Edelsohn wrote:
>   The Altivec ABI does change the stack alignment.  This should not
> create an incompatibility for old code, but new code may not receive the
> stack properly aligned without additional dynamic alignment.

I thought so, too, but Geoff explained to me that this is wrong.  It
only affects powerpc-eabi.  powerpc-linux already has a sufficiently
aligned stack; it's just not reflected in STACK_BOUNDARY.

On powerpc-linux, if you do not pass or return vector arguments, the
only affect of -mabi=altivec is that AltiVec registers are saved and
restored correctly.

On powerpc-eabi, we would need to dynamically align the stack for
-maltivec to behave.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC 4.3.0 Status Report (2008-02-14)

[Mark Mitchell]

Daniel Jacobowitz wrote:

On Mon, Feb 18, 2008 at 08:16:39PM -0500, David Edelsohn wrote:

The Altivec ABI does change the stack alignment.  This should not
create an incompatibility for old code, but new code may not receive the
stack properly aligned without additional dynamic alignment.


I thought so, too, but Geoff explained to me that this is wrong.  It
only affects powerpc-eabi.  powerpc-linux already has a sufficiently
aligned stack; it's just not reflected in STACK_BOUNDARY.

On powerpc-linux, if you do not pass or return vector arguments, the
only affect of -mabi=altivec is that AltiVec registers are saved and
restored correctly.


So, if I understand correctly, on Power GNU/Linux, this is actually not 
a scary change at all as things will work monotonically better than they 
did before.  Is that right?



On powerpc-eabi, we would need to dynamically align the stack for
-maltivec to behave.


There's certainly somewhat less need for long-term binary compatibility 
on bare-metal targets.  If someone were to need compatibility there, we 
could implement the dynamic stack-alignment.


So, it doesn't sound like there's much to worry about.  Do you agree?

Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Double constructors in C++?

[Ian Lance Taylor]

Samuel Tardieu <[EMAIL PROTECTED]> writes:

> Why are constructors included twice in object code?

This is required by the C++ ABI.

It is, in my opinion, a real bug that gcc does not simply merge
identical constructors.  There are ABI issues with changing, in that
it can change the behaviour of existing code in some very subtle ways
that will probably not break any actual existing code.  We should at
the very least offer this as an ABI_-breaking option for people using
embedded systems or other cases where code size matters.

There is a bug report at http://gcc.gnu.org/PR3187 .

The last patch I know of related to this was
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01147.html .

>  <_ZN1TC2ERKSs>:
> 000c <_ZN1TC1ERKSs>:

Note that although the demangler demangles them to the same string,
the two functions have different names.

Ian

Re: Double constructors in C++?

[Mark Mitchell]

Ian Lance Taylor wrote:

Samuel Tardieu <[EMAIL PROTECTED]> writes:


Why are constructors included twice in object code?


This is required by the C++ ABI.

It is, in my opinion, a real bug that gcc does not simply merge
identical constructors.


I agree.

Up until now, I think all of the patches have introduced additional 
thunks of some kind.  Actually giving both names to the same entry point 
would avoid the ABI problems, and thus be non-controversial.  (The ABI 
explicitly endorses multiple entry points as a solution.)


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Double constructors in C++?

[Mark Mitchell]

Ian Lance Taylor wrote:


I believe that it would be possible to construct some test cases with
shared libraries built in the current regime, including only one
version of the constructor, which will behave strangely in the new
regime.


The ABI explicitly expects you to use multiple entry points, so either 
the ABI is broken, or the strangeness would come from some kind of 
undefined-ness.


However, the ABI does expect that if you have multiple constructor 
bodies for a constructor with vague linkage, then all of the copies are 
in the same COMDAT group.  If I recall correctly, we never fully 
enforced that on all platforms, and if the copies aren't all in the same 
COMDAT group, then, indeed, I can imagine that you could end up with one 
of the constructors coming from one place, and one from another -- which 
might be unfortunate.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Double constructors in C++?

[Ian Lance Taylor]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote:
> > Samuel Tardieu <[EMAIL PROTECTED]> writes:
> >
> >> Why are constructors included twice in object code?
> > This is required by the C++ ABI.
> > It is, in my opinion, a real bug that gcc does not simply merge
> > identical constructors.
> 
> I agree.
> 
> Up until now, I think all of the patches have introduced additional
> thunks of some kind.  Actually giving both names to the same entry
> point would avoid the ABI problems, and thus be non-controversial.
> (The ABI explicitly endorses multiple entry points as a solution.)

I believe that it would be possible to construct some test cases with
shared libraries built in the current regime, including only one
version of the constructor, which will behave strangely in the new
regime.  I haven't actually tried to construct such a case, however.
I also would be happy to say that even if such a case could exist,
that we don't care about it.

Ian

RE: [discuss] When is RBX used for base pointer?

[Ye, Joey]

On Wed, 13 Feb 2008, H.J. Lu wrote:
>>  Recent i386 use arbitrary register as GOT pointer only for leaf
>>  function.  When you call something, the GOT entry uses EBX too.
>>  We use RBX for large PIC model.  But I am with Michael here that I
don't
>>  see reason why choice of register needs to be set in stone.
>>  We can probably use RBX for non-large-PIC and R12 elsewhere.

> Joey ran into issues when he didn't use a hard register to realign
stack.
> It has something to do with reload. We really need some help here with
> reload.  Joey can explain it when he comes from vacation next week.

Michael, Jan,

When aligning stack for those functions who have dynamic stack
allocation, we must use an available callee-saved register in prologue.
We named this hard register DRAP. It is worthwhile to emphasize that
*free* here means "free in prologue". After prologue, a virtual register
will be used instead.

Given the definition of free, we can fix the DRAP register to simplify
the implementation. Original GCC only have limited cases that use
callee-saved register in prologue, such as setting GOT pointer as far as
I know. So choosing the DRAP register is easy: just avoid GOT pointer
register, which is EBX in i386 and RBX in x86_64. As HJ said, R12 is a
good candiate.

It will be more complicated if GOT pointer register is not fixed. In
this case, the DRAP candidate must be avoid using GOT register, or vice
versa. When will current GCC decide the register to use as GOT pointer?

Thanks - Joey