Re: 4.3 build failure in driver-i386.c

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 t

Re: omp_get_num_procs() not working on macintosh?

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] = {

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

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 complete

Turning cc1plus into a shared library

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 i

hash_map for OpenVMS?

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

Re: hash_map for OpenVMS?

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

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

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

[plugins] include conventions

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 part

Re: Turning cc1plus into a shared library

> "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

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

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 f

Re: [plugins] include conventions

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

Re: bootstrap broken on mingw

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

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

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 s

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

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

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

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

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

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 ch

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

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

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

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

Re: omp_get_num_procs() not working on macintosh?

> > 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 wit

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

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 test

gcc-4.1-20080218 is now available

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

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

> 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 p

GCC 4.3 branch created, 4.4 opens for stage1

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 w

Double constructors in C++?

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 000

Re: GCC 4.3 branch created, 4.4 opens for stage1

> 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

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

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-sa

Re: GCC 4.3 branch created, 4.4 opens for stage1

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 changi

Re: GCC 4.3 branch created, 4.4 opens for stage1

* 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 confi

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

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 ju

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

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 -maltive

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

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

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

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 hav

Re: GCC 4.3 branch created, 4.4 opens for stage1

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 appro

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

> 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-comp

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

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 s

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

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, g

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

> 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?

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

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

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

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.

Re: Double constructors in C++?

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 ex

Re: Double constructors in C++?

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

Re: Double constructors in C++?

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,

Re: Double constructors in C++?

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 con

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

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