Re: Including GMP/MPFR in GCC repository?

[François-Xavier Coudert]

First, please note that having gfortran testresults for one platform
only means that "some version of the compiler was able to correctly
compile GMP & MPFR", not that "GCC trunk is able to correctly compile
GMP & MPFR". Nevertheless:


* i386-unknown-freebsd (alpha-unknown-freebsd5.4)
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01072.html


I can confirm that GMP & MPFR build fine and run their testsuite
cleanly on i386-unknown-freebsd{4.7,5.4,5.11}. I know Steve Kargl uses
this on x86_64-unknown-freebsd6.1 and it works fine.

As for other BSDs, I can confirm that GMP & MPFR build and run their
testsuite fine on i386-unknown-netbsd2.0.2,
i386-unknown-openbsd{3.7,3.8}.


* sparc-sun-solaris2.10
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01273.html


I can also confirm that GMP & MPFR build and run fine on
i386-unknown-solaris2.9.


* ia64-unknown-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01826.html


I my experience, GMP & MPFR do also work fine on ia64-hpux, but that
requires a recent GMP version (>= 4.2.0, if I remember correctly;
before that, the configury didn't work well for ia64-hpux).

Also, I have had GMP & MPFR building and testing fine on alpha-linux
for some time.

Finally, as S/390 GNU/Linux seems to be considered for inclusion into
this list, it is worthy to note that gfortran is built & regtested on
this platform and variants regularly.

FX

Re: Abt definition for structure tree

[Ben Elliston]

> Can anyone tell me where i can find the definition of tree.

Take a look in tree.h.

Ben

Re: Question about strange register calling truncates to SImode on x86_64

[Kai Tietz]

Hello Michael,

thanks for description. I wasn't aware, that the upper 32 bits are zeroed. 
Does this means that even the stack has to be in the first 4 Gb, too. Or 
does this mov instruction does a sign-extention. 

Best regards,
 i.A. Kai Tietz

Re: building gcc

[Paolo Bonzini]

In particular, I was just wondering how do compile GCC with debug. Not
how to debug it. I tried CFLAGS="-g" ./configure ..., but it still
compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure
trick that will help get me ready to debug gcc, please let me know.


By default, GCC bootstraps itself, and after the first stage it always 
compiles itself with optimization enabled.  So what you need is


./configure --enable-languages=c,c++ --disable-bootstrap
make CFLAGS=-g

(or equivalently, with CFLAGS=-g passed to configure).

Paolo

[PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Hiroki Kaminaga]

Hi,

Regarding the PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413

Is below patch adequate to fix the problem?
Works fine with me, but haven't done any regression test.


Thanks in Advance

(Hiroki Kaminaga)
t
--


Index: gcc/gcc/config/mips/mips.h
===
--- gcc.orig/gcc/config/mips/mips.h
+++ gcc/gcc/config/mips/mips.h
@@ -1152,7 +1152,8 @@ extern const struct mips_cpu_info *mips_
 #define SUBTARGET_CPP_SPEC ""
 #endif
 
-#define CPP_SPEC "%(subtarget_cpp_spec)"
+#define CPP_SPEC "%(subtarget_cpp_spec) %{EB:-meb} %{EL:-mel} \
+%{EB:%{EL:%emay not use both -EB and -EL}}"
 
 /* This macro defines names of additional specifications to put in the specs
that can be used in various specifications like CC1_SPEC.  Its definition

Get pragma's line code

[Matteo Fioroni]

Hi, 
I must get the informations (position in the file,
file where #pragma was found, text that follow the
#pragma in the line) of pragma's line code in C/C++
code.

For do that I think that it's a good idea using the
C/C++ gcc preprocessor.

How can I patch the gcc so it can execute a my
function (e.g that save the informations I need in a
file) when it  detects a pragma directive?

Thanks for help!

Matteo.

__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

[cygwin] libjava/java/lang/natClass.cc:904: error: thread-local storage not supported for this target

[Christian Joensson]

Currently, and it's been there for a while, I get the following error
on gcc trunk:

/usr/local/src/trunk/objdir/./gcc/xgcc -shared-libgcc
-B/usr/local/src/trunk/objdir/./gcc -nostdinc++
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/
-isystem /usr/local/i686-pc-cygwin/include -isystem
/usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc/libjava -I./include -I./gcj -I../../../gcc/libjava
-Iinclude -I../../../gcc/libjava/include
-I../../../gcc/libjava/classpath/include -Iclasspath/include
-I../../../gcc/libjava/classpath/native/fdlibm
-I../../../gcc/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../gcc/libjava/libltdl -I../../../gcc/libjava/libltdl
-I../../../gcc/libjava/.././libjava/../gcc
-I../../../gcc/libjava/../libffi/include -I../libffi/include -fno-rtti
-fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Wextra
-Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local\"
-DTOOLEXECLIBDIR=\"/usr/local/lib/gcc/i686-pc-cygwin/4.2.0\"
-DJAVA_HOME=\"/usr/local\"
-DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-4.2.0.jar\"
-DJAVA_EXT_DIRS=\"/usr/local/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/usr/local/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/usr/local/lib/gcj-4.2.0\"
-DPATH_SEPARATOR=\":\"
-DLIBGCJ_DEFAULT_DATABASE=\"/usr/local/lib/gcj-4.2.0/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.2.0/classmap.db\" -g -O2
-MT java/lang/natClass.lo -MD -MP -MF java/lang/.deps/natClass.Tpo -c
../../../gcc/libjava/java/lang/natClass.cc -o java/lang/natClass.o
../../../gcc/libjava/java/lang/natClass.cc:904: error: thread-local
storage not supported for this target
make[3]: *** [java/lang/natClass.lo] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [all] Error 2

My system is this:

Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages:

binutils 20060817-1 2.17.50 20060817
bison2.3-1  2.3
cygwin   1.5.21-2
dejagnu  20021217-2 1.4.2.x
expect   20030128-1 5.26
gcc  3.4.4-1
gcc-ada  3.4.4-1
gcc-g++  3.4.4-1
gmp  4.1.4-2
make 3.81-1
tcltk20060202-1 8.4
w32api   3.7-1


and the configure was done like this:

../gcc/configure   --enable-nls --without-included-gettext
--enable-version-specific-runtime-libs --without-x --enable-libgcj
--with-system-zlib --enable-threads=posix
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang

Now, am I doing something terribly wrong here or is this a well know "bug"?

--
Cheers,

/ChJ

Re: [cygwin] libjava/java/lang/natClass.cc:904: error: thread-local storage not supported for this target

[Andrew Haley]

Christian Joensson writes:
 > Currently, and it's been there for a while, I get the following error
 > on gcc trunk:
 > 
 > ../../../gcc/libjava/java/lang/natClass.cc:904: error: thread-local
 > storage not supported for this target
 > make[3]: *** [java/lang/natClass.lo] Error 1
 > make[3]: Leaving directory 
 > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
 > make[2]: *** [all-recursive] Error 1
 > make[2]: Leaving directory 
 > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
 > make[1]: *** [all-target-libjava] Error 2
 > make[1]: Leaving directory `/usr/local/src/trunk/objdir'
 > make: *** [all] Error 2
 > 
 > My system is this:
 > 
 > Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages:
 > 
 > binutils 20060817-1 2.17.50 20060817
 > bison2.3-1  2.3
 > cygwin   1.5.21-2
 > dejagnu  20021217-2 1.4.2.x
 > expect   20030128-1  5.26
 > gcc  3.4.4-1
 > gcc-ada  3.4.4-1
 > gcc-g++  3.4.4-1
 > gmp  4.1.4-2
 > make 3.81-1
 > tcltk20060202-1 8.4
 > w32api   3.7-1
 > 
 > 
 > and the configure was done like this:
 > 
 >  ../gcc/configure   --enable-nls --without-included-gettext
 > --enable-version-specific-runtime-libs --without-x --enable-libgcj
 > --with-system-zlib --enable-threads=posix
 > --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang
 > 
 > Now, am I doing something terribly wrong here or is this a well know "bug"?

That __thread variable is surrounded by HAVE_TLS.  There is a
configure test which simply compiles this line:

__thread int foo;

and that configure test must succeed for HAVE_TLS to be set.  So, to
fix this we need to find out if that program did compile, and if so,
how.

--disable-tls in the configure line might solve your problem.

Andrew.

Re: [cygwin] libjava/java/lang/natClass.cc:904: error: thread-local storage not supported for this target

[Brian Dessent]

Andrew Haley wrote:

> That __thread variable is surrounded by HAVE_TLS.  There is a
> configure test which simply compiles this line:
> 
> __thread int foo;
> 
> and that configure test must succeed for HAVE_TLS to be set.  So, to
> fix this we need to find out if that program did compile, and if so,
> how.

Might this have to do with
 which was
committed for a brief while and then subsequently reverted on
?  The
configure machinery in libjava might not be equipped to deal with this
kind of dependency and could require a "make clean".

> --disable-tls in the configure line might solve your problem.

That too.

Brian

Re: building gcc

[Bob Rossi]

On Thu, Oct 12, 2006 at 09:48:13AM +0200, Paolo Bonzini wrote:
> 
> >In particular, I was just wondering how do compile GCC with debug. Not
> >how to debug it. I tried CFLAGS="-g" ./configure ..., but it still
> >compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure
> >trick that will help get me ready to debug gcc, please let me know.
> 
> By default, GCC bootstraps itself, and after the first stage it always 
> compiles itself with optimization enabled.  So what you need is
> 
> ./configure --enable-languages=c,c++ --disable-bootstrap
> make CFLAGS=-g
> 
> (or equivalently, with CFLAGS=-g passed to configure).

Thanks Paolo,

Here's what I have so far.

../gcc/configure CFLAGS="-g" --enable-languages=c,c++ --enable-checking
--disable-bootstrap --prefix=$PWD/../prefixdir

Hopefully I'll be able to debug gcc nicely after this is built. Two
more questions that could save me a lot of time. Do you know where the
abstract syntax tree is stored in GCC after a file is parsed? Does GCC
still create an AST for C/C++, or does it go directly to GIMPLE?

Thanks for the help,
Bob Rossi

Implicit conversions between vectors

[Mark Shinwell]

Currently we permit implicit conversions between vectors whose total
bitsizes are equal but which are divided into differing numbers of subparts.
It seems that in some circumstances this rule is overly lax.  For example
the following code, using vector types (whose definitions I have provided
from the intrinsics header file) defined for the ARM NEON instruction set,
is accepted without error or warning:

...
typedef __builtin_neon_qi int8x8_t  __attribute__ ((__vector_size__ (8)));
typedef __builtin_neon_hi int16x4_t __attribute__ ((__vector_size__ (8)));
...

int8x8_t f (int16x4_t a)
{
  return a;
}

Here, the compiler is not complaining about an attempt to implicitly
convert a vector of four 16-bit quantities to a vector of eight
8-bit quantities.

This lack of type safety is unsettling, and I wonder if it should be fixed
with a patch along the lines of the (not yet fully tested) one below.  Does
that sound reasonable?  It seems right to try to fix the generic code here,
even though the testcase in hand is target-specific.  If this approach
is unreasonable, I guess some target-specific hooks will be needed.

Mark


--


Index: gcc/c-common.c
===
--- gcc/c-common.c  (revision 117639)
+++ gcc/c-common.c  (working copy)
@@ -1014,7 +1014,8 @@ vector_types_convertible_p (tree t1, tre
 && (TREE_CODE (TREE_TYPE (t1)) != REAL_TYPE ||
 TYPE_PRECISION (t1) == TYPE_PRECISION (t2))
 && INTEGRAL_TYPE_P (TREE_TYPE (t1))
-   == INTEGRAL_TYPE_P (TREE_TYPE (t2)));
+   == INTEGRAL_TYPE_P (TREE_TYPE (t2))
+&& TYPE_VECTOR_SUBPARTS (t1) == TYPE_VECTOR_SUBPARTS (t2));
 }

 /* Convert EXPR to TYPE, warning about conversion problems with constants.

Re: Question about strange register calling truncates to SImode on x86_64

[Michael Matz]

Hi,

On Thu, 12 Oct 2006, Kai Tietz wrote:

> thanks for description. I wasn't aware, that the upper 32 bits are 
> zeroed. Does this means that even the stack has to be in the first 4 Gb, 
> too.

Why should it?  I.e. no, it doesn't have to.

> Or does this mov instruction does a sign-extention.

Which mov instruction?


Ciao,
Michael.

Re: Implicit conversions between vectors

[Paolo Bonzini]

This lack of type safety is unsettling, and I wonder if it should be fixed
with a patch along the lines of the (not yet fully tested) one below.  Does
that sound reasonable?  It seems right to try to fix the generic code here,
even though the testcase in hand is target-specific.  If this approach
is unreasonable, I guess some target-specific hooks will be needed.


I'm almost sure this is a regression, and older versions of GCC 
implemented exactly what you propose.


Paolo

Re: [PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Andrew Pinski]

On Thu, 2006-10-12 at 17:06 +0900, Hiroki Kaminaga wrote:
> Hi,
> 
> Regarding the PR:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
> 
> Is below patch adequate to fix the problem?
> Works fine with me, but haven't done any regression test.

As I mentioned in the bug report, the problem is that CC1_SPEC
is the wrong one.

Adding EB/EL to CPP_SPEC will only fix the C/C++/Objective-C front-ends
and no others.

The attached patch is the more correct way to solve this.

Thanks,
Andrew Pinski

Index: mips.h
===
--- mips.h	(revision 117658)
+++ mips.h	(working copy)
@@ -865,13 +865,12 @@ extern const struct mips_rtx_cost_data *
 
 /* CC1_SPEC is the set of arguments to pass to the compiler proper.  */
 
-#ifndef CC1_SPEC
+#undef CC1_SPEC
 #define CC1_SPEC "\
 %{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1} \
 %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
 %{save-temps: } \
 %(subtarget_cc1_spec)"
-#endif
 
 /* Preprocessor specs.  */
 

Re: Implicit conversions between vectors

[Andrew Pinski]

On Thu, 2006-10-12 at 13:03 +0100, Mark Shinwell wrote:
> typedef __builtin_neon_qi int8x8_t  __attribute__ ((__vector_size__ (8)));
> typedef __builtin_neon_hi int16x4_t __attribute__ ((__vector_size__ (8)));
> ...
> 
> int8x8_t f (int16x4_t a)
> {
>return a;
> }

This should error out and it is a regression from previous versions (I
can check which ones but I think 3.4.0 rejected it).  The two targets
that I work on daily at work (including the language extension
specifications), both say this is invalid code and should be rejected.

Thanks,
Andrew Pinski

Re: building gcc

[Ian Lance Taylor]

Bob Rossi <[EMAIL PROTECTED]> writes:

> Hopefully I'll be able to debug gcc nicely after this is built. Two
> more questions that could save me a lot of time. Do you know where the
> abstract syntax tree is stored in GCC after a file is parsed?

I'm not sure what kind of answer you are looking for.  One place to
look is in the cgraph code.

> Does GCC
> still create an AST for C/C++, or does it go directly to GIMPLE?

gcc generates an AST, of sorts, for C++.  For C it goes directly to
GIMPLE (really GENERIC, but they are pretty similar).

Ian

Re: Implicit conversions between vectors

[Mark Shinwell]

Andrew Pinski wrote:

On Thu, 2006-10-12 at 13:03 +0100, Mark Shinwell wrote:

typedef __builtin_neon_qi int8x8_t  __attribute__ ((__vector_size__ (8)));
typedef __builtin_neon_hi int16x4_t __attribute__ ((__vector_size__ (8)));
...

int8x8_t f (int16x4_t a)
{
   return a;
}


This should error out and it is a regression from previous versions (I
can check which ones but I think 3.4.0 rejected it).  The two targets
that I work on daily at work (including the language extension
specifications), both say this is invalid code and should be rejected.


Thanks, will test properly and post to gcc-patches.

Mark

Re: Implicit conversions between vectors

[Ian Lance Taylor]

Mark Shinwell <[EMAIL PROTECTED]> writes:

> Here, the compiler is not complaining about an attempt to implicitly
> convert a vector of four 16-bit quantities to a vector of eight
> 8-bit quantities.
> 
> This lack of type safety is unsettling, and I wonder if it should be fixed
> with a patch along the lines of the (not yet fully tested) one below.  Does
> that sound reasonable?  It seems right to try to fix the generic code here,
> even though the testcase in hand is target-specific.  If this approach
> is unreasonable, I guess some target-specific hooks will be needed.

I personally think it is a good idea to require an explicit cast.
This comes up with C++ overloaded functions as well.  In the backend I
wrote for a vector processor, I added a command line option.


Paolo Bonzini <[EMAIL PROTECTED]> writes:

> I'm almost sure this is a regression, and older versions of GCC
> implemented exactly what you propose.

It's been this way at least since 4.0.


I believe that the problem with changing this unconditionally is that
the Altivec programming guidelines specify the rules which gcc
currently follows: you are permitted to assign one vector variable to
another, without an explicit cast, when the vectors are the same size.
So please check the Altivec programming manual.

Ian

Re: Implicit conversions between vectors

[Mark Shinwell]

Ian Lance Taylor wrote:

I believe that the problem with changing this unconditionally is that
the Altivec programming guidelines specify the rules which gcc
currently follows: you are permitted to assign one vector variable to
another, without an explicit cast, when the vectors are the same size.
So please check the Altivec programming manual.


Will do, thanks.

Mark

Re: Implicit conversions between vectors

[Andrew Pinski]

On Thu, 2006-10-12 at 08:02 -0700, Ian Lance Taylor wrote:
> It's been this way at least since 4.0.
But it was rejected in 3.4.0.

> I believe that the problem with changing this unconditionally is that
> the Altivec programming guidelines specify the rules which gcc
> currently follows: you are permitted to assign one vector variable to
> another, without an explicit cast, when the vectors are the same size.
> So please check the Altivec programming manual.
I already know it says it needs an explict cast and so does the C/C++
Language Extension for CBEA says the same thing because I just made sure
of it last week when I was editing that specifications.

Thanks,
Andrew Pinski

Re: building gcc

[Bob Rossi]

On Thu, Oct 12, 2006 at 06:56:58AM -0400, Bob Rossi wrote:
> On Thu, Oct 12, 2006 at 09:48:13AM +0200, Paolo Bonzini wrote:
> > 
> > >In particular, I was just wondering how do compile GCC with debug. Not
> > >how to debug it. I tried CFLAGS="-g" ./configure ..., but it still
> > >compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure
> > >trick that will help get me ready to debug gcc, please let me know.
> > 
> > By default, GCC bootstraps itself, and after the first stage it always 
> > compiles itself with optimization enabled.  So what you need is
> > 
> > ./configure --enable-languages=c,c++ --disable-bootstrap
> > make CFLAGS=-g
> > 
> > (or equivalently, with CFLAGS=-g passed to configure).
> 
> Thanks Paolo,
> 
> Here's what I have so far.
> 
> ../gcc/configure CFLAGS="-g" --enable-languages=c,c++ --enable-checking
> --disable-bootstrap --prefix=$PWD/../prefixdir

Actually, the CFLAGS="-g" caused a problem. OK, now, as I expected,
I configure with 

../gcc/configure --enable-languages=c,c++ --enable-checking
 --disable-bootstrap --prefix=$PWD/../prefixdir

and the gcc that is put into prefixdir is compiled with -O2 and -g,
which makes it hard to follow in the debugger. Anyone have a clue on how
to compile gcc so only -g is used, and not -O2? Typically, I use the
CFLAGS trick, but it doesn't seem to work for gcc.

Thanks, and sorry for all the noise.

Bob Rossi

Re: building gcc

[Daniel Jacobowitz]

On Thu, Oct 12, 2006 at 12:22:57PM -0400, Bob Rossi wrote:
> and the gcc that is put into prefixdir is compiled with -O2 and -g,
> which makes it hard to follow in the debugger. Anyone have a clue on how
> to compile gcc so only -g is used, and not -O2? Typically, I use the
> CFLAGS trick, but it doesn't seem to work for gcc.

Use CFLAGS="-g" ../gcc-src/configure.  The top level file is still
autoconf 2.13.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Including GMP/MPFR in GCC repository?

[Kaveh R. GHAZI]

On Thu, 12 Oct 2006, [ISO-8859-1] François-Xavier Coudert wrote:

> First, please note that having gfortran testresults for one platform
> only means that "some version of the compiler was able to correctly
> compile GMP & MPFR",

True.

> not that "GCC trunk is able to correctly compile GMP & MPFR".

I'm not sure I agree with your criteria.  We don't need the trunk to
compile GMP/MPFR, we're now talking about *not* including them in the
source tree.  All we need is that some compiler (even non-gcc) is able to
compile these libraries so the user can install it somewhere once and
reuse them every time they build GCC.

One potential problem from relying on these postings is that the poster
was using an older version of GMP/MPFR and the current releases no longer
work on their platform.  But given the extensive platform claims on the
MPFR website, I find that unlikely that they have less portability now.

We won't know for sure until we try, but I think knowing that GMP/MPFR
worked at some point in the past increases the likeligood of success.


> Nevertheless:
> [...]

Thanks very much for this additional confirmation!  That certainly helps
increase my confidence.  If anyone else has additional info they can
contribute I'd very much appreciate it.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: aligned attribute and the new operator (pr/15795)

[Mark Mitchell]

[EMAIL PROTECTED] wrote:


If we are willing to consider an ABI change, I think an approach that
allows new to call some form of memalign would be better than having the
compiler force alignment after calling new.  


Are we open to making an ABI change?


Personally, I think an ABI change, at the compiler level should be off 
the table.  (I say "Personally" to make clear that this is just my 
opinion as a C++ maintainer and as a co-developer of the C++ ABI 
specification, but not an SC decision.  And, for those who may find 
these parentheticals tedious, they're there because some people have 
previously interpreted statements from me as dictates; I'm trying to be 
very careful to make sure it's clear what hat I'm wearing.)


The C++ ABI has actually been stable for years now, which is a huge 
achievement.  We've gotten binary interoperability to work for most 
programs between a lot of C++ compilers, which is a good thing for all. 
 In my opinion, the next change to the C++ ABI should come if (and only 
if) C++0x requires changes.  Even there, I would hope for 
backwards-compatible changes -- for example, mangling for variadic 
templates would ideally be an extension to the current mangling scheme. 
 In other words, we should strive to make it possible to link current 
C++ libraries with C++0x programs, which means that the sort of change 
you're considering would be off the table.


Adding a compiler command-line option to specify the alignment of memory 
returned by "operator new", or a GNU attribute that libstdc++ could add 
to the default declaration (with a system-dependent value, of course), 
etc. seems fine to me, but I'd be very hesitant to change the ABI proper.


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

Re: building gcc

[Bob Rossi]

On Thu, Oct 12, 2006 at 12:25:04PM -0400, Daniel Jacobowitz wrote:
> On Thu, Oct 12, 2006 at 12:22:57PM -0400, Bob Rossi wrote:
> > and the gcc that is put into prefixdir is compiled with -O2 and -g,
> > which makes it hard to follow in the debugger. Anyone have a clue on how
> > to compile gcc so only -g is used, and not -O2? Typically, I use the
> > CFLAGS trick, but it doesn't seem to work for gcc.
> 
> Use CFLAGS="-g" ../gcc-src/configure.  The top level file is still
> autoconf 2.13.

Thanks Daniel! It works now.

Bob Rossi

Re: Including GMP/MPFR in GCC repository?

[Kaveh R. GHAZI]

On Wed, 11 Oct 2006, Steve Kargl wrote:

> Kaveh,
>
> It should be straight forward to modify the current configure tests
> in toplevel for the versions of gmp and mpfr you need.  I would
> recommend at least mpfr 2.2.0 (which would allow me to kill the ugly
> hacks in gfortran).  For gmp, you may be able to use a version as
> old as 4.1.0.
> --
> Steve

Like this?  I combined the two MPFR tests into one and had it stop if
configure can't find the right versions of the libraries.

Tested on sparc-sun-solaris2.10 via "configure" with no GMP/MPFR, with an
older MPFR version and with current versions.  It did the "right thing" in
all cases.

Okay for stage1?

Thanks,
--Kaveh

PS: nuts, I just realized I need up update install.texi accordingly.  If
this patch is acceptable I'll post a followup patch for that.



2006-10-12  Kaveh R. Ghazi  <[EMAIL PROTECTED]>

* configure.in: Require GMP-4.1+ and MPFR-2.2+.
* configure: Regenerate.

diff -rup orig/egcc-SVN20061011/configure.in egcc-SVN20061011/configure.in
--- orig/egcc-SVN20061011/configure.in  2006-09-27 20:01:59.0 -0400
+++ egcc-SVN20061011/configure.in   2006-10-12 13:55:25.073919479 -0400
@@ -1103,24 +1103,24 @@ choke me
 ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); have_gmp=no])

 if test x"$have_gmp" = xyes; then
+  saved_LIBS="$LIBS"
+  LIBS="$LIBS $gmplibs"
   AC_MSG_CHECKING([for correct version of mpfr.h])
-  AC_TRY_COMPILE([#include "gmp.h"
+  AC_TRY_LINK([#include 
 #include ],[
 #if MPFR_VERSION_MAJOR < 2 || (MPFR_VERSION_MAJOR == 2 && MPFR_VERSION_MINOR < 
2)
   choke me
 #endif
-], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([buggy version of MPFR detected])])
-
-  saved_LIBS="$LIBS"
-  LIBS="$LIBS $gmplibs"
-  AC_MSG_CHECKING([for any version of mpfr.h])
-  AC_TRY_LINK([#include 
-#include ], [mpfr_t n; mpfr_init(n);],
-[AC_MSG_RESULT([yes])],  [AC_MSG_RESULT([no]); have_gmp=no])
+  mpfr_t n; mpfr_init(n);
+], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); have_gmp=no])
   LIBS="$saved_LIBS"
 fi
 CFLAGS="$saved_CFLAGS"

+if test x$have_gmp != xyes; then
+  AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.2+.  Try the 
--with-gmp and/or --with-mpfr options.])
+fi
+
 # Flags needed for both GMP and/or MPFR
 AC_SUBST(gmplibs)
 AC_SUBST(gmpinc)

Re: Including GMP/MPFR in GCC repository?

[Steve Kargl]

On Thu, Oct 12, 2006 at 02:14:53PM -0400, Kaveh R. GHAZI wrote:
> On Wed, 11 Oct 2006, Steve Kargl wrote:
> >
> > It should be straight forward to modify the current configure tests
> > in toplevel for the versions of gmp and mpfr you need.  I would
> > recommend at least mpfr 2.2.0 (which would allow me to kill the ugly
> > hacks in gfortran).  For gmp, you may be able to use a version as
> > old as 4.1.0.
> 
> Like this?  I combined the two MPFR tests into one and had it stop if
> configure can't find the right versions of the libraries.
> 
> Tested on sparc-sun-solaris2.10 via "configure" with no GMP/MPFR, with an
> older MPFR version and with current versions.  It did the "right thing" in
> all cases.
> 
> Okay for stage1?
> 

The patch looks okay to me, but you'll need one of the
build machinery people to approve the patch.

-- 
Steve

Re: Including GMP/MPFR in GCC repository?

[DJ Delorie]

> Okay for stage1?

Ok, assuming everyone agrees to those versions ;-)

> 2006-10-12  Kaveh R. Ghazi  <[EMAIL PROTECTED]>
> 
>   * configure.in: Require GMP-4.1+ and MPFR-2.2+.
>   * configure: Regenerate.

gcc-4.0-20061012 is now available

[gccadmin]

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

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

You'll find:

gcc-4.0-20061012.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20061012.tar.bz2 C front end and core compiler

gcc-ada-4.0-20061012.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20061012.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20061012.tar.bz2  C++ front end and runtime

gcc-java-4.0-20061012.tar.bz2 Java front end and runtime

gcc-objc-4.0-20061012.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20061012.tar.bz2The GCC testsuite

Diffs from 4.0-20061005 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
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: on removal of line number notes at the end of BBs

[Jan Hubicka]

> On Oct 11, 2006, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> 
> >> int x; int f() { x = 0;
> >>   while(1); }
> 
> >> We get line number notes for code only up to "x = 0;".
> 
> > I assume this is only a problem when not optimizing.
> 
> The opposite, actually.  It's optimization that breaks it.
> 
> Of course optimization can change stuff and debug info sometimes is
> lost, but in this case we *do* have code for that loop, so we might as
> well try to preserve the line number info somehow.  We shouldn't drop
> it just because we turn annotated-with-line-numbers jumps into
> fallthru edges that later have to be re-emitted without line numbers.
> 
> > Without looking at the code, the problem looks quite similar to one I
> > fixed here:
> 
> It is similar, indeed, but this removal takes place in RTL.

Yep, I guess it is cfglayout just replacing the jump with fresh one.
Adding code to record locators on edges in the same field as tree level
code does already is probably not too dificult.  I can try to get it
done next week...

Honza

Tree node questions

[Brendon Costa]

Hi all,

If I have a FUNCTION_DECL node that returns non-null for
DECL_TEMPLATE_INFO() then it is a template or template instantiation.
How can I tell if it is a full instantiation (I.e. not general
template or partial specialisation)?

Does this also apply to nodes that represent template types
(structs/classes)?


Also up to now I have been using my own "tree walker" as I seem to be
unable to get walk_tree to work as I need. I have come across a few
problems in my own tree walker and need to change it, but before I do
I thought I would see if there already exists something that works
similarly.

Basically I would like to know the current "tree depth" and context
for the parent nodes in the tree as it is walked down.

Is there any way of getting the current depth and node context using
walk_tree or a similar function?


One final question. Are there any functions and if so what types that
are skipped by gimplify_function_tree defined in gimplify.c?


Thanks,
Brendon.

Re: [PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Hiroki Kaminaga]

From: Andrew Pinski <[EMAIL PROTECTED]>
> As I mentioned in the bug report, the problem is that CC1_SPEC
> is the wrong one.
(snip)
> The attached patch is the more correct way to solve this.

Thanks alot!


(Hiroki Kaminaga)
t
--

Additional tree node questions.

[Brendon Costa]

Sorry about the separate email.

In addition to the previous questions I want to ask if there is a
better way of achieving finding the type nodes for a functions
exception specification list.

For each FUNCTION_DECL node I find, I want to determine what its
exception specification list is. I.e. the throws() statement in its
prototype.

For example:

Function1();
Function2() throws();
Function3() throws(int, float);

Where 1 has no specification list, 2 has a empty list and 3 has a list
that allows int and float exceptions to pass through.

What is the best way to find the type nodes for this exception spec
list? I am doing it in a very cumbersome way at the moment and was
wondering if there exists an elegant way to achieve this?

I currently assume that ANY EH_FILTER_EXPR node i find while parsing
the contents of a FUNCTION_DECL defines a spec list (and if I don't
find one then it allows all exceptions to pass through). I don't think
this is correct though. Is it? I then use EH_FILTER_MUST_NOT_THROW()
and EH_FILTER_TYPES() to gather my information from this node.

Is there a better way of achieving this?

Thanks,
Brendon.

Re: [PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Hiroki Kaminaga]

From: Andrew Pinski <[EMAIL PROTECTED]>
> On Thu, 2006-10-12 at 17:06 +0900, Hiroki Kaminaga wrote:
> > Hi,
> > 
> > Regarding the PR:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
> > 
> > Is below patch adequate to fix the problem?
> > Works fine with me, but haven't done any regression test.
> 
> As I mentioned in the bug report, the problem is that CC1_SPEC
> is the wrong one.
> 
> Adding EB/EL to CPP_SPEC will only fix the C/C++/Objective-C front-ends
> and no others.
> 
> The attached patch is the more correct way to solve this.

Your patch would cause `-profile' option not to set `-p' to cc1. Is this OK?


Best Regards,

(Hiroki Kaminaga)
t
--

abt compiler flags

[Mohamed Shafi]

Hello all,

During regression tests if i want to disable some features like trampolines i 
can give -DNO_TRAMPOLINES
as an compiler flag.

Do i have similar flags for profiling and PIC?

thanks in advance

Regards,
Shafi

Re: [PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Andrew Pinski]

On Fri, 2006-10-13 at 14:32 +0900, Hiroki Kaminaga wrote:
> > The attached patch is the more correct way to solve this.
> 
> Your patch would cause `-profile' option not to set `-p' to cc1. Is this OK?
Not really, the following patch on top of the previous fixes the above
problem:
Index: config/mips/linux.h
===
--- config/mips/linux.h (revision 117683)
+++ config/mips/linux.h (working copy)
@@ -49,6 +49,8 @@ Boston, MA 02110-1301, USA.  */
 #undef MD_EXEC_PREFIX
 #undef MD_STARTFILE_PREFIX

+#define SUBTARGET_CC1_SPEC "%{profile:-p}"
+
 /* If we don't set MASK_ABICALLS, we can't default to PIC.  */
 #undef TARGET_DEFAULT
 #define TARGET_DEFAULT MASK_ABICALLS


Thanks,
Andrew Pinski

Re: [PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Hiroki Kaminaga]

From: Andrew Pinski <[EMAIL PROTECTED]>
> > Your patch would cause `-profile' option not to set `-p' to cc1. Is this OK?
> Not really, the following patch on top of the previous fixes the above
> problem:
> Index: config/mips/linux.h
> ===
> --- config/mips/linux.h (revision 117683)
> +++ config/mips/linux.h (working copy)
> @@ -49,6 +49,8 @@ Boston, MA 02110-1301, USA.  */
>  #undef MD_EXEC_PREFIX
>  #undef MD_STARTFILE_PREFIX
> 
> +#define SUBTARGET_CC1_SPEC "%{profile:-p}"
> +
>  /* If we don't set MASK_ABICALLS, we can't default to PIC.  */
>  #undef TARGET_DEFAULT
>  #define TARGET_DEFAULT MASK_ABICALLS

How about appending to CC1_SPEC?

-#ifndef CC1_SPEC
+#undef CC1_SPEC
 #define CC1_SPEC "\
 %{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1} \
 %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
 %{save-temps: } \
-%(subtarget_cc1_spec)"
+%(subtarget_cc1_spec) %{profile:-p}"
-#endif

Other architecture seems to set %{profile:-p} to CC1_SPEC.


Best Regards,

(Hiroki Kaminaga)
t
--

Re: abt compiler flags

[Ben Elliston]

> During regression tests if i want to disable some features like
> trampolines i can give -DNO_TRAMPOLINES as an compiler flag.
> 
> Do i have similar flags for profiling and PIC?

You might like to check the manual.  All of the answers you're looking
for (well, okay, most) will be there:

  http://gcc.gnu.org/onlinedocs/

Cheers, Ben

Re: [PATCH][RFC] -EB / -EL don't properly affect gcc predefined symbols

[Andrew Pinski]

On Fri, 2006-10-13 at 14:45 +0900, Hiroki Kaminaga wrote:
> How about appending to CC1_SPEC?
> 
> -#ifndef CC1_SPEC
> +#undef CC1_SPEC
>  #define CC1_SPEC "\
>  %{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1} \
>  %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
>  %{save-temps: } \
> -%(subtarget_cc1_spec)"
> +%(subtarget_cc1_spec) %{profile:-p}"
> -#endif
> 
> Other architecture seems to set %{profile:-p} to CC1_SPEC.

Problem is that mips-irix does not want the profile as far as I can tell
which is why the SUBTARGET_CC1_SPEC is a good second idea of where it
should be defined.

Thanks,
Andrew Pinski