mixing VEC-tors of string & GTY?

[Basile STARYNKEVITCH]

Hello All,

I cannot figure out how to have a vector of strings in a GTY-ed file 

As a simple example, if I add (inside trunk rev.101317) at the end of
gcc/stringpool.c just before the last #include "gt-stringpool.h"

  typedef char* basilestring_t;
  DEF_VEC_P (basilestring_t);
  DEF_VEC_ALLOC_P (basilestring_t,heap);
  static VEC(basilestring_t,heap) *basilestring_vector;

Then I gen a gengtype error:
make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
build/gengtype
/usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type 
`basilestring_t'

Notice that:

  I do not add any additional occurrence of GTY in a already GTY-ed file.

  my added code is quite similar to the following code from gcc/genextract.c
  (which is not gengtype-d)

 typedef char *locstr;
/*later*/
 DEF_VEC_P(locstr);
 DEF_VEC_ALLOC_P(locstr,heap);

Any clues?

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

Re: mixing VEC-tors of string & GTY?

[Andrew Pinski]

> 
> 
> Hello All,
> 
> I cannot figure out how to have a vector of strings in a GTY-ed file 
> 
> As a simple example, if I add (inside trunk rev.101317) at the end of
> gcc/stringpool.c just before the last #include "gt-stringpool.h"
> 
>   typedef char* basilestring_t;
>   DEF_VEC_P (basilestring_t);
>   DEF_VEC_ALLOC_P (basilestring_t,heap);
>   static VEC(basilestring_t,heap) *basilestring_vector;
> 
> Then I gen a gengtype error:
> make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
> build/gengtype
> /usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type 
> `basilestring_t'
> 
> Notice that:
> 
>   I do not add any additional occurrence of GTY in a already GTY-ed file.
> 
>   my added code is quite similar to the following code from gcc/genextract.c
>   (which is not gengtype-d)
> 
>  typedef char *locstr;
> /*later*/
>  DEF_VEC_P(locstr);
>  DEF_VEC_ALLOC_P(locstr,heap);
> 
> Any clues?
> 
> Regards
> -- 
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/ 
> email: basilestarynkevitchnet mobile: +33 6 8501 2359 
> 8, rue de la Faïencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
> 

Re: mixing VEC-tors of string & GTY?

[Basile STARYNKEVITCH]

Le Thu, Jan 04, 2007 at 05:30:37AM -0500, Andrew Pinski écrivait/wrote:
> > 
> > 
> > Hello All,
> > 
> > I cannot figure out how to have a vector of strings in a GTY-ed file 
> > 
> > As a simple example, if I add (inside trunk rev.101317) at the end of
> > gcc/stringpool.c just before the last #include "gt-stringpool.h"
> > 
> >   typedef char* basilestring_t;
> >   DEF_VEC_P (basilestring_t);
> >   DEF_VEC_ALLOC_P (basilestring_t,heap);
> >   static VEC(basilestring_t,heap) *basilestring_vector;
> > 
> > Then I gen a gengtype error:
> > make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
> > build/gengtype
> > /usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type 
> > `basilestring_t'
> > 
> > Notice that:
> > 
> >   I do not add any additional occurrence of GTY in a already GTY-ed file.
> > 
> >   my added code is quite similar to the following code from gcc/genextract.c
> >   (which is not gengtype-d)
> > 
> >  typedef char *locstr;
> > /*later*/
> >  DEF_VEC_P(locstr);
> >  DEF_VEC_ALLOC_P(locstr,heap);
> > 
> > Any clues?
> > 
> > Regards
> > -- 
> > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ 
> > email: basilestarynkevitchnet mobile: +33 6 8501 2359 
> > 8, rue de la Fa?encerie, 92340 Bourg La Reine, France
> > *** opinions {are only mines, sont seulement les miennes} ***
> > 
> 
> 


Andraw Pinksi probably hit the send key too early.
This thread is probably related 
  http://gcc.gnu.org/ml/gcc/2003-03/msg01258.html
but I cannot figure out any solution without patching gengtype, should I 
consider 
a patch like http://gcc.gnu.org/ml/gcc/2003-03/msg01265.html

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

Re: mixing VEC-tors of string & GTY?

[Andrew Pinski]

First sorry about the first email.
> As a simple example, if I add (inside trunk rev.101317) at the end of
> gcc/stringpool.c just before the last #include "gt-stringpool.h"
> 
>   typedef char* basilestring_t;
>   DEF_VEC_P (basilestring_t);
>   DEF_VEC_ALLOC_P (basilestring_t,heap);
>   static VEC(basilestring_t,heap) *basilestring_vector;
> 
> Then I gen a gengtype error:
> make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
> build/gengtype
> /usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type 
> `basilestring_t'

Why do you want a VEC of a character pointer in the first place?
I don't think this is supported at all.


> Notice that:
> 
>   I do not add any additional occurrence of GTY in a already GTY-ed file.
> 
>   my added code is quite similar to the following code from gcc/genextract.c
>   (which is not gengtype-d)
> 
>  typedef char *locstr;
> /*later*/
>  DEF_VEC_P(locstr);
>  DEF_VEC_ALLOC_P(locstr,heap);
> 
> Any clues?

More than just not being gengtype-d, genextract.c is a file that gets built
by the build compiler for a build program and not part of libbackend.

Yes fix gengtype to ignore non heap gc cases.

-- Pinski

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Sandiford]

Paul Eggert <[EMAIL PROTECTED]> writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>> it sounds like that would eliminate most of the problem.  Certainly,
>> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> easy thing to do; that's just a guarantee about constant folding.
>
> Well, no, just to clarify: the GCC code in question actually computed
> "- x", and relied on the fact that the result was INT_MIN if x (an
> unknown integer) happened to be INT_MIN.  Also, now that I'm thinking
> about it, some the Unix v7 atoi() implementation relied on "x + 8"
> evaluating to INT_MIN when x happened to be (INT_MAX - 7).  These are
> the usual kind of assumptions in this area.

I don't know if you're implicitly only looking for certain types of
signed overflow, or if this has been mentioned elsewhere (I admit I had
to skim-read some of the thread) but the assumption that signed overflow
is defined is _very_ pervasive in gcc at the rtl level.  The operand to
a CONST_INT is a signed HOST_WIDE_INT, and its accessor macro -- INTVAL
-- returns a value of that type.  Most arithmetic related to CONST_INTs
is therefore done on signed HOST_WIDE_INTs.  This means that many parts
of gcc would produce wrong code if signed arithmetic saturated, for
example.  (FWIW, this is why I suggested adding a UINTVAL, which Stuart
has since done -- thanks.  However, most of gcc still uses INTVAL.)

Richard

A simple program with a large array segfaults

[Gowri Kumar CH]

Greetings,
I'm running gcc on the latest Ubuntu(Edgy) and I get segfault with the
following program:


#include 
#include 

#define SIZE (INT_MAX>>3)

int main()
{
   int arr[SIZE];
   printf("%d\n",SIZE);
   return 0;
}


bash$  gcc --version
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash$ gcc -Wall arr.c
arr.c: In function 'main':
arr.c:8: warning: unused variable 'arr'

bash$ ./a.out
Segmentation fault (core dumped)

I'm little surprised, why should it segfault. And especially when gcc
doesn't give any error or warning at the time of compilation (I could
use arr[o]=0, to remove the existing warning, but the error still
exists)

Regards,
Gowri Kumar

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Vincent Lefevre]

On 2007-01-03 20:11:35 -0500, drizzle drizzle wrote:
> Installed mpfr and gmp and verified mpfr.h and gmp.h exist in
> /usr/local/include and libmpfr.a , libgmp.so etc exists in
> /usr/local/lib

I assume you got MPFR 2.2.1. You can try to rebuild MPFR with
--enable-shared, in case you have another MPFR version installed
with a shared library (e.g. in /usr/lib) and the linker does
something strange. Also, make sure that GMP and MPFR are compiled
with the same ABI.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: A simple program with a large array segfaults

[Andrew Pinski]

> 
> Greetings,
> I'm running gcc on the latest Ubuntu(Edgy) and I get segfault with the
> following program:
> 
> 
> 


You just overflowed your stack.  Increase the stack size for the program
by using limit/ulimit or use dynamic allocated memory.

This question is more appropriate for gcc-help@ rather than [EMAIL PROTECTED]

Thanks,
Andrew Pinski

Re: mixing VEC-tors of string & GTY?

[Basile STARYNKEVITCH]

Le Thu, Jan 04, 2007 at 05:39:23AM -0500, Andrew Pinski écrivait/wrote:
> First sorry about the first email.
> > As a simple example, if I add (inside trunk rev.101317) at the end of
> > gcc/stringpool.c just before the last #include "gt-stringpool.h"
> > 
> >   typedef char* basilestring_t;
> >   DEF_VEC_P (basilestring_t);
> >   DEF_VEC_ALLOC_P (basilestring_t,heap);
> >   static VEC(basilestring_t,heap) *basilestring_vector;
> > 
> > Then I gen a gengtype error:
> > make[2]: Entering directory `/usr/src/Lang/_BasileGgccObj/gcc'
> > build/gengtype
> > /usr/src/Lang/basile-ggcc/gcc/stringpool.c:263: unidentified type 
> > `basilestring_t'
[...]

> Yes fix gengtype to ignore non heap gc cases.

I just submitted the patch
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00222.html which add a
magic comment parsing to have gengtype ignore stuff

Regards.


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

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Guenther]

On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:

Paul Eggert <[EMAIL PROTECTED]> writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>> it sounds like that would eliminate most of the problem.  Certainly,
>> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> easy thing to do; that's just a guarantee about constant folding.
>
> Well, no, just to clarify: the GCC code in question actually computed
> "- x", and relied on the fact that the result was INT_MIN if x (an
> unknown integer) happened to be INT_MIN.  Also, now that I'm thinking
> about it, some the Unix v7 atoi() implementation relied on "x + 8"
> evaluating to INT_MIN when x happened to be (INT_MAX - 7).  These are
> the usual kind of assumptions in this area.

I don't know if you're implicitly only looking for certain types of
signed overflow, or if this has been mentioned elsewhere (I admit I had
to skim-read some of the thread) but the assumption that signed overflow
is defined is _very_ pervasive in gcc at the rtl level.  The operand to
a CONST_INT is a signed HOST_WIDE_INT, and its accessor macro -- INTVAL
-- returns a value of that type.  Most arithmetic related to CONST_INTs
is therefore done on signed HOST_WIDE_INTs.  This means that many parts
of gcc would produce wrong code if signed arithmetic saturated, for
example.  (FWIW, this is why I suggested adding a UINTVAL, which Stuart
has since done -- thanks.  However, most of gcc still uses INTVAL.)


I thought all ints are unsigned in the RTL world as there is I believe no way
to express "signedness" of a mode.  This would have to change of course
if we ever support non two's-complement arithmetic.

Richard.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Sandiford]

"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:
>> Paul Eggert <[EMAIL PROTECTED]> writes:
>> > Mark Mitchell <[EMAIL PROTECTED]> writes:
>> >> it sounds like that would eliminate most of the problem.  Certainly,
>> >> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> >> easy thing to do; that's just a guarantee about constant folding.
>> >
>> > Well, no, just to clarify: the GCC code in question actually computed
>> > "- x", and relied on the fact that the result was INT_MIN if x (an
>> > unknown integer) happened to be INT_MIN.  Also, now that I'm thinking
>> > about it, some the Unix v7 atoi() implementation relied on "x + 8"
>> > evaluating to INT_MIN when x happened to be (INT_MAX - 7).  These are
>> > the usual kind of assumptions in this area.
>>
>> I don't know if you're implicitly only looking for certain types of
>> signed overflow, or if this has been mentioned elsewhere (I admit I had
>> to skim-read some of the thread) but the assumption that signed overflow
>> is defined is _very_ pervasive in gcc at the rtl level.  The operand to
>> a CONST_INT is a signed HOST_WIDE_INT, and its accessor macro -- INTVAL
>> -- returns a value of that type.  Most arithmetic related to CONST_INTs
>> is therefore done on signed HOST_WIDE_INTs.  This means that many parts
>> of gcc would produce wrong code if signed arithmetic saturated, for
>> example.  (FWIW, this is why I suggested adding a UINTVAL, which Stuart
>> has since done -- thanks.  However, most of gcc still uses INTVAL.)
>
> I thought all ints are unsigned in the RTL world as there is I believe no way
> to express "signedness" of a mode.  This would have to change of course
> if we ever support non two's-complement arithmetic.

I'm not sure what you mean.  Yes, "all ints are unsigned in the RTL world"
in the sense that we must use two's complement arithmetic for them --
we have no way of distinguishing what was originally signed from
what was originally unsigned.  But my point was that gcc _stores_ the
integers as _signed_ HOST_WIDE_INTs, and operates on them as such,
even though these signed HOST_WIDE_INTs may actually represent unsigned
integers.  Thus a lot of the arithmetic that gcc does at the rtl level
would be wrong for certain inputs if the _compiler used to build gcc_
assumed that signed overflow didn't wrap.

In other words, it sounds like you took my message to mean that gcc's
rtl code treated signed overflow _in the input files_ as undefined.
I didn't mean that.  I meant that gcc's own code relies on signed
overflow being defined.  I think it was instances of the latter
that Paul was trying to find.

Richard

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Guenther]

On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:

"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:
>> Paul Eggert <[EMAIL PROTECTED]> writes:
>> > Mark Mitchell <[EMAIL PROTECTED]> writes:
>> >> it sounds like that would eliminate most of the problem.  Certainly,
>> >> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> >> easy thing to do; that's just a guarantee about constant folding.
>> >
>> > Well, no, just to clarify: the GCC code in question actually computed
>> > "- x", and relied on the fact that the result was INT_MIN if x (an
>> > unknown integer) happened to be INT_MIN.  Also, now that I'm thinking
>> > about it, some the Unix v7 atoi() implementation relied on "x + 8"
>> > evaluating to INT_MIN when x happened to be (INT_MAX - 7).  These are
>> > the usual kind of assumptions in this area.
>>
>> I don't know if you're implicitly only looking for certain types of
>> signed overflow, or if this has been mentioned elsewhere (I admit I had
>> to skim-read some of the thread) but the assumption that signed overflow
>> is defined is _very_ pervasive in gcc at the rtl level.  The operand to
>> a CONST_INT is a signed HOST_WIDE_INT, and its accessor macro -- INTVAL
>> -- returns a value of that type.  Most arithmetic related to CONST_INTs
>> is therefore done on signed HOST_WIDE_INTs.  This means that many parts
>> of gcc would produce wrong code if signed arithmetic saturated, for
>> example.  (FWIW, this is why I suggested adding a UINTVAL, which Stuart
>> has since done -- thanks.  However, most of gcc still uses INTVAL.)
>
> I thought all ints are unsigned in the RTL world as there is I believe no way
> to express "signedness" of a mode.  This would have to change of course
> if we ever support non two's-complement arithmetic.

I'm not sure what you mean.  Yes, "all ints are unsigned in the RTL world"
in the sense that we must use two's complement arithmetic for them --
we have no way of distinguishing what was originally signed from
what was originally unsigned.  But my point was that gcc _stores_ the
integers as _signed_ HOST_WIDE_INTs, and operates on them as such,
even though these signed HOST_WIDE_INTs may actually represent unsigned
integers.  Thus a lot of the arithmetic that gcc does at the rtl level
would be wrong for certain inputs if the _compiler used to build gcc_
assumed that signed overflow didn't wrap.

In other words, it sounds like you took my message to mean that gcc's
rtl code treated signed overflow _in the input files_ as undefined.
I didn't mean that.  I meant that gcc's own code relies on signed
overflow being defined.  I think it was instances of the latter
that Paul was trying to find.


Yes, I confused that.  It seems that RTL should store integer consts as
unsigned HOST_WIDE_INT instead - the current situation could lead
to problems as you rightfully said.

Richard.

trunk gcc has problems finding crtbegin.o

[Martin Reinecke]

Hi,

current mainline gcc seems to call the linker incorrectly, so that it cannot 
find the crt*.o files:

~/tmp>cat bla.c
int main(void) {}

~/tmp>gcc -v bla.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure 
--prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,fortran 
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20070104 (experimental)
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -quiet -v 
bla.c -quiet -dumpbase bla.c -mtune=generic -auxbase bla -version -o 
/tmp/cc1cwpGv.s
ignoring nonexistent directory 
"/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /afs/mpa/data/martin/ugcc/include
 /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/include
 /usr/include
End of search list.
GNU C version 4.3.0 20070104 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070104 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4b6976291ae40cffc80492b11bf03681
 as -V -Qy -o /tmp/ccgYye0U.o /tmp/cc1cwpGv.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o crtbegin.o 
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0 -L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/../../.. /tmp/ccgYye0U.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc 
--as-needed -lgcc_s --no-as-needed crtend.o /usr/lib/crtn.o

/usr/bin/ld: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status

This probably happens because the crt*.o files are no longer placed into /lib/gcc/i686-pc-linux-gnu/4.3.0/
but rather into /lib/gcc/i686-pc-linux-gnu/.
Is this related to the recent libgcc changes?

Thanks,
  Martin

Re: Top level libgcc checked in

[Daniel Jacobowitz]

On Thu, Jan 04, 2007 at 04:19:17PM +1100, Ben Elliston wrote:
> On Wed, 2007-01-03 at 23:28 -0500, Daniel Jacobowitz wrote:
> 
> > Right now the libgcc configuration is completely tied up with
> > gcc/Makefile.  As parts of the configuration process move from
> > gcc/config/ to libgcc/config/ (or libgcc's configure.ac), we'll
> > be untangling them.  Eventually, it should be possible to build
> > gcc and the target libraries separately.
> 
> So I take it that at this stage we've not commenced the process of
> having libgcc's configury run autoconf tests on the target compiler?
> (Rather than having to hardwire most target details into the t-* files?)
> Any objections to starting down this path?

As Paolo responded, we have already begun - I use autoconf to detect
both visibility support and decimal float support.  I'm not sure how
much else remains to be done, but I'm open to suggestions :-)  I
wonder if it's possible to work out some of the difuncs/tifuncs stuff
based on the size of target types.

-- 
Daniel Jacobowitz
CodeSourcery

Re: trunk gcc has problems finding crtbegin.o

[Daniel Jacobowitz]

On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote:
> /usr/bin/ld: crtbegin.o: No such file: No such file or directory
> collect2: ld returned 1 exit status
> 
> This probably happens because the crt*.o files are no longer placed into 
> /lib/gcc/i686-pc-linux-gnu/4.3.0/
> but rather into /lib/gcc/i686-pc-linux-gnu/.
> Is this related to the recent libgcc changes?

Yes, it's my fault.  The last time I tested make install, they went to
the right place.  I'm building right now to find out what's gone wrong.

-- 
Daniel Jacobowitz
CodeSourcery

Re: trunk gcc has problems finding crtbegin.o

[Daniel Jacobowitz]

On Thu, Jan 04, 2007 at 08:59:51AM -0500, Daniel Jacobowitz wrote:
> On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote:
> > /usr/bin/ld: crtbegin.o: No such file: No such file or directory
> > collect2: ld returned 1 exit status
> > 
> > This probably happens because the crt*.o files are no longer placed into 
> > /lib/gcc/i686-pc-linux-gnu/4.3.0/
> > but rather into /lib/gcc/i686-pc-linux-gnu/.
> > Is this related to the recent libgcc changes?
> 
> Yes, it's my fault.  The last time I tested make install, they went to
> the right place.  I'm building right now to find out what's gone wrong.

I'm not sure how I missed this before; apologies.  I've checked in this
obvious fix.

Relating to what Mark was saying earlier: you can see that this assumes
$(CC) (in the target directory) has the same version as ../gcc/xgcc.
This is not the first place with that sort of assumption.  If you're
building Canadian crosses, remember to use the same source tree to
build the cross compiler and the cross-hosted compiler.  Anything
else is just impossible to support.

-- 
Daniel Jacobowitz
CodeSourcery

2007-01-04  Daniel Jacobowitz  <[EMAIL PROTECTED]>

* Makefile.in (version): Define.

Index: Makefile.in
===
--- Makefile.in (revision 120429)
+++ Makefile.in (working copy)
@@ -181,6 +181,8 @@ export RANLIB_FOR_TARGET
 export libsubdir
 export slibdir
 
+version := $(shell $(CC) -dumpversion)
+
 DECNUMINC = -I$(srcdir)/../libdecnumber -I$(MULTIBUILDTOP)../../libdecnumber
 
 # Specify the directories to be searched for header files.

Re: trunk gcc has problems finding crtbegin.o

[Martin Reinecke]

Daniel Jacobowitz wrote:

On Thu, Jan 04, 2007 at 08:59:51AM -0500, Daniel Jacobowitz wrote:

On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote:

/usr/bin/ld: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status

This probably happens because the crt*.o files are no longer placed into 
/lib/gcc/i686-pc-linux-gnu/4.3.0/

but rather into /lib/gcc/i686-pc-linux-gnu/.
Is this related to the recent libgcc changes?

Yes, it's my fault.  The last time I tested make install, they went to
the right place.  I'm building right now to find out what's gone wrong.


I'm not sure how I missed this before; apologies.  I've checked in this
obvious fix.


Yes, it works again for me. Thanks!

Cheers,
  Martin

Re: A simple program with a large array segfaults

[J.C.]

See the disassembly of the
unoptimized & optimized executables
produced by GCC!!! :)

run.out (inside of the attachment):


#!/bin/sh
cat $0
echo ""
gcc --version
#
# Unoptimized
#
gcc -Wall -S arr.c   # to see arr.s
mv arr.s arr1.s
cat arr1.s
echo ""
gcc -Wall -ggdb2 arr.c
echo ""
gdb --quiet --command=arr.gdb a.out
echo ""
rm -f a.out
#
# Optimized (-Os)
#
gcc -Wall -Os -S arr.c   # to see arr.s
mv arr.s arr2.s
cat arr2.s
echo ""
gcc -Wall -Os -ggdb2 arr.c
echo ""
gdb --quiet --command=arr.gdb a.out
echo ""
rm -f a.out

gcc (GCC) 3.3.5 20040804 (prerelease)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arr.c: In function `main':
arr.c:7: warning: unused variable `arr'
   .file"arr.c"
   .section.rodata
.LC0:
   .string"%d\n"
   .text
.globl main
   .typemain, @function
main:
   pushl%ebp
   movl%esp, %ebp
   subl$1073741848, %esp
   andl$-16, %esp
   movl$0, %eax
   subl%eax, %esp
   movl$268435455, 4(%esp)
   movl$.LC0, (%esp)
   callprintf
   movl$0, %eax
   leave
   ret
   .sizemain, .-main
   .section.note.GNU-stack,"",@progbits
   .ident"GCC: (GNU) 3.3.5 20040804 (prerelease)"

arr.c: In function `main':
arr.c:7: warning: unused variable `arr'

Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
main () at arr.c:8
8   printf("%d\n",SIZE);
Line 8 of "arr.c" starts at address 0x8048377  and ends at 
0x804838b .

Dump of assembler code for function main:
0x08048364 :push   %ebp
0x08048365 :mov%esp,%ebp
0x08048367 :sub$0x4018,%esp
0x0804836d :and$0xfff0,%esp
0x08048370 :mov$0x0,%eax
0x08048375 :sub%eax,%esp
0x08048377 :movl   $0xfff,0x4(%esp)
0x0804837f :movl   $0x8048464,(%esp)
0x08048386 :call   0x8048288 <_init+56>
0x0804838b :mov$0x0,%eax
0x08048390 :leave 
0x08048391 :ret   
End of assembler dump.

Stack level 0, frame at 0xb770:
eip = 0x8048377 in main (arr.c:8); saved eip 0x40036936
source language c.
Arglist at 0xb768, args:
Locals at 0xb768, Previous frame's sp is 0xb770
Saved registers:
 ebp at 0xb768, eip at 0xb76c

arr.c: In function `main':
arr.c:7: warning: unused variable `arr'
   .file"arr.c"
   .section.rodata.str1.1,"aMS",@progbits,1
.LC0:
   .string"%d\n"
   .text
.globl main
   .typemain, @function
main:
   pushl%ebp
   movl%esp, %ebp
   subl$1073741824, %esp
   pushl$268435455
   pushl$.LC0
   callprintf
   leave
   xorl%eax, %eax
   ret
   .sizemain, .-main
   .section.note.GNU-stack,"",@progbits
   .ident"GCC: (GNU) 3.3.5 20040804 (prerelease)"

arr.c: In function `main':
arr.c:7: warning: unused variable `arr'

Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
main () at arr.c:8
8   printf("%d\n",SIZE);
Line 8 of "arr.c" starts at address 0x804836d  and ends at 
0x804837c .

Dump of assembler code for function main:
0x08048364 :push   %ebp
0x08048365 :mov%esp,%ebp
0x08048367 :sub$0x4000,%esp
0x0804836d :push   $0xfff
0x08048372 :push   $0x8048444
0x08048377 :call   0x8048288 <_init+56>
0x0804837c :leave 
0x0804837d :xor%eax,%eax
0x0804837f :ret   
End of assembler dump.

Stack level 0, frame at 0xb770:
eip = 0x804836d in main (arr.c:8); saved eip 0x40036936
source language c.
Arglist at 0xb768, args:
Locals at 0xb768, Previous frame's sp is 0xb770
Saved registers:
 ebp at 0xb768, eip at 0xb76c



Bye-bye :)



huge_array_in_stack_crashes.tar.gz
Description: application/gzip

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Vincent Lefevre]

On 2007-01-03 22:19:16 -0500, drizzle drizzle wrote:
> Not 4.3 but 3.4 yes the older version.  And I built and installed mpfr
> and gmp. gmp4.1 and mpfr 2.2.  I dont have a /usr/local/lib64 on my
> system. Did my mpfr/gmp install incorrecly ?

I don't think MPFR install libs in .../lib64 (everytime I tried on an
x86_64 machine, it didn't, but I was using another prefix directory,
in my $HOME). Anyway, MPFR is based on the autotools. So, it would be
a problem with the autotools. But you can change that with the --libdir
configure option:

  --libdir=DIR   object code libraries [EPREFIX/lib]

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: A simple program with a large array segfaults

[Gowri Kumar CH]

Hi andrew,

You just overflowed your stack.  Increase the stack size for the program
by using limit/ulimit or use dynamic allocated memory.

Thanks for the quick reply. By changing the size of the stack the
error goes away.

Is this one of the things which we come to know by experience?
Or
Is there a way to find it out from the core/code generated?
This was a simple program with just a few lines. I'm wondering how
difficult it would be find this sort of errors in a large program.

Regards,
Gowri Kumar
ps : Due apologies, if it's off topic here on this mailing list.

Scheduling

[us tx]

Please does anyone know the answer to the following questions?

1. The operating system (OS) schedules tasks, but gnat allow us to set 
schedule policies such as Round Robin, then how does gnat tell the OS to 
start doing Round Robin scheduling?


2. If someone wants to write a new scheduling policy, what files I need to 
add and update to tell gnat to use my scheduling policy.


For example, if I want tasks to block, even though it does NOT want to use a 
shared data object, but  if another task on the "same" cpu is running and is 
using a shared data object that other tasks on other CPUs need that shared 
data object.


For example, I see for Round Robin, gnat has the following files: 
a-diroro.ads and a-diroro.adb


3.  Which gnat files for tasking and scheduling tell the tasks to use these 
files and how these files hookup to the tasking model?


4. What gnat file is the Scheduling and Tasking file?  I want to see how it 
uses the Round Robin or how scheduling works in gnat?


Thank you for your time
Jane

_
Dave vs. Carl: The Insignificant Championship Series.  Who will win? 
http://clk.atdmt.com/MSN/go/msnnkwsp007001msn/direct/01/?href=http://davevscarl.spaces.live.com/?icid=T001MSN38C07001

Re: mpfr issues when Installing gcc 3.4 on fedora core

[drizzle drizzle]

I am wondering if my all my troubles stem from mpfr not being
installed properly ..
When I configure mpfr I get the following warning. Cud this be an issue ?

checking if gmp.h version and libgmp version are the same... (4.2.1/4.1.4) no
configure: WARNING: 'gmp.h' and 'libgmp' seems to have different versions or
configure: WARNING: we cannot run a program linked with GMP (if you cannot
configure: WARNING: see the version numbers above).
configure: WARNING: However since we can't use 'libtool' inside the configure,
configure: WARNING: we can't be sure. See 'config.log' for details.


And as matt suggested if mpfr is not needed by 3.4, how can I
configure it that way. --disable -mpfr did not help.

thanks for all the hints so far

dz

On 1/4/07, Vincent Lefevre <[EMAIL PROTECTED]> wrote:

On 2007-01-03 22:19:16 -0500, drizzle drizzle wrote:
> Not 4.3 but 3.4 yes the older version.  And I built and installed mpfr
> and gmp. gmp4.1 and mpfr 2.2.  I dont have a /usr/local/lib64 on my
> system. Did my mpfr/gmp install incorrecly ?

I don't think MPFR install libs in .../lib64 (everytime I tried on an
x86_64 machine, it didn't, but I was using another prefix directory,
in my $HOME). Anyway, MPFR is based on the autotools. So, it would be
a problem with the autotools. But you can change that with the --libdir
configure option:

  --libdir=DIR   object code libraries [EPREFIX/lib]

--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Vincent Lefevre]

On 2007-01-04 12:54:34 -0500, drizzle drizzle wrote:
> I am wondering if my all my troubles stem from mpfr not being
> installed properly ..
> When I configure mpfr I get the following warning. Cud this be an issue ?
> 
> checking if gmp.h version and libgmp version are the same... (4.2.1/4.1.4) 
> no
> configure: WARNING: 'gmp.h' and 'libgmp' seems to have different versions or
> configure: WARNING: we cannot run a program linked with GMP (if you cannot
> configure: WARNING: see the version numbers above).
> configure: WARNING: However since we can't use 'libtool' inside the 
> configure,
> configure: WARNING: we can't be sure. See 'config.log' for details.

Yes (now this test is much more reliable in MPFR 2.2.1). You may have
the following problem (quoted from MPFR's INSTALL file):

  Such problems commonly occur under GNU/Linux machines, where default
  header and library paths may be inconsistent: gcc is configured to
  search /usr/local/include by default, while /usr/local/lib is not in
  the default search paths. If you have a GMP version installed in /usr
  (provided by the OS) and a new one installed in /usr/local, then the
  header of the new GMP version and the library of the old GMP version
  will be used! A typical error is the above one in "make check". The
  solution is to add /usr/local/include to your C_INCLUDE_PATH and to
  add /usr/local/lib to your LIBRARY_PATH and LD_LIBRARY_PATH (and/or
  LD_RUN_PATH), as said above. Alternatively, you can use --with-gmp*
  configure options (described above), e.g. --with-gmp=/usr/local, but
  other software that uses GMP and/or MPFR will need correct paths too,
  and environment variables allow to set them in a global way.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Matt Fago]

> drizzle drizzle wrote:
>And as matt suggested if mpfr is not needed by 3.4, how can I
>configure it that way. --disable -mpfr did not help.

MPFR should not have _anything_ to do with any gcc prior to 4.x. Where did you 
get gcc 3.4? A tarball from a gnu mirror or somewhere else? I think either the 
tarball is misnamed or something is terribly wrong with it. 

>checking if gmp.h version and libgmp version are the same... (4.2.1/4.1.4) no
>configure: WARNING: 'gmp.h' and 'libgmp' seems to have different versions or
>configure: WARNING: we cannot run a program linked with GMP (if you cannot
>configure: WARNING: see the version numbers above).
>configure: WARNING: However since we can't use 'libtool' inside the configure,
>configure: WARNING: we can't be sure. See 'config.log' for details.

This means that mpfr needs to be told where gmp is and was probably not built 
correctly. When you configure mpfr use the options:

  --with-gmp-include=DIR  GMP include directory
  --with-gmp-lib=DIR GMP lib directory

Make sure these point to the lib and include directories with the new version 
of gmp. You can also use:

 --libdir=/usr/local/lib64 

if you wish to install the 64-bit libraries there instead of ../lib.

Note that fedora installs a 'bad' version of gmp 4.1.4 that includes a very old 
copy of mpfr. You seem to be picking up the library from this one.

 - Matt

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Vincent Lefevre]

On 2007-01-04 19:09:23 +0100, Vincent Lefevre wrote:
> On 2007-01-04 12:54:34 -0500, drizzle drizzle wrote:
> [configure warning due to different libgmp and gmp.h versions]
> 
> Yes (now this test is much more reliable in MPFR 2.2.1). You may have
> the following problem (quoted from MPFR's INSTALL file):
> 
>   Such problems commonly occur under GNU/Linux machines, where default
>   header and library paths may be inconsistent: gcc is configured to
>   search /usr/local/include by default, while /usr/local/lib is not in
>   the default search paths. If you have a GMP version installed in /usr
>   (provided by the OS) and a new one installed in /usr/local, then the
>   header of the new GMP version and the library of the old GMP version
>   will be used! A typical error is the above one in "make check". The
>   solution is to add /usr/local/include to your C_INCLUDE_PATH and to
>   add /usr/local/lib to your LIBRARY_PATH and LD_LIBRARY_PATH (and/or
>   LD_RUN_PATH), as said above. Alternatively, you can use --with-gmp*
>   configure options (described above), e.g. --with-gmp=/usr/local, but
>   other software that uses GMP and/or MPFR will need correct paths too,
>   and environment variables allow to set them in a global way.

In case you still get the warning after trying that, I think that one
can get the same kind of problems when the ABI is incorrect, e.g. a
32-bit GMP library in /usr/lib, a 64-bit GMP library in /usr/local/lib
and a MPFR build in the 32-bit ABI (contrary to GMP, MPFR doesn't
change the ABI by default): the 64-bit GMP library will be skipped,
and the GMP library will be taken from /usr/lib (whereas the gmp.h
will still be taken from /usr/local/include).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Joe Buck]

On Thu, Jan 04, 2007 at 07:25:03PM +0100, Vincent Lefevre wrote:
> In case you still get the warning after trying that, I think that one
> can get the same kind of problems when the ABI is incorrect, e.g. a
> 32-bit GMP library in /usr/lib, a 64-bit GMP library in /usr/local/lib
> and a MPFR build in the 32-bit ABI (contrary to GMP, MPFR doesn't
> change the ABI by default): the 64-bit GMP library will be skipped,
> and the GMP library will be taken from /usr/lib (whereas the gmp.h
> will still be taken from /usr/local/include).

It is an annoying problem that MPFR and GMP follow inconsistent rules.
For example, if you configure the current version of both on a
sparc-sun-solaris machine, GMP will build a 64-bit version and MPFR
will build a 32-bit version.

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Vincent Lefevre]

On 2007-01-04 10:42:35 -0800, Joe Buck wrote:
> It is an annoying problem that MPFR and GMP follow inconsistent rules.

Yes, but this problem is not only between MPFR and GMP. Even if MPFR
chose the GMP rules, there would be problems with other software. I
don't know any software other than GMP that chooses an ABI different
from the default one, and I think that's the reason why when GMP is
built by ports/packages, the ABI is changed back to the default one
(well, this seems to be the general case).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: mpfr issues when Installing gcc 3.4 on fedora core

[drizzle drizzle]

Still no luck so far .. I got the gcc3.4 from the gcc archive. Any way
I can make gcc 3.4 not use these libraries ?

thanks
dz

On 1/4/07, Joe Buck <[EMAIL PROTECTED]> wrote:

On Thu, Jan 04, 2007 at 07:25:03PM +0100, Vincent Lefevre wrote:
> In case you still get the warning after trying that, I think that one
> can get the same kind of problems when the ABI is incorrect, e.g. a
> 32-bit GMP library in /usr/lib, a 64-bit GMP library in /usr/local/lib
> and a MPFR build in the 32-bit ABI (contrary to GMP, MPFR doesn't
> change the ABI by default): the 64-bit GMP library will be skipped,
> and the GMP library will be taken from /usr/lib (whereas the gmp.h
> will still be taken from /usr/local/include).

It is an annoying problem that MPFR and GMP follow inconsistent rules.
For example, if you configure the current version of both on a
sparc-sun-solaris machine, GMP will build a 64-bit version and MPFR
will build a 32-bit version.

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Richard Guenther]

On 1/4/07, drizzle drizzle <[EMAIL PROTECTED]> wrote:

Still no luck so far .. I got the gcc3.4 from the gcc archive. Any way
I can make gcc 3.4 not use these libraries ?


3.4 doesn't use gmp or mpfr, gfortran introduces this dependency but it
appears with 4.0 or newer only.

Richard.

Re: A simple program with a large array segfaults

[Mike Stump]

On Jan 4, 2007, at 8:49 AM, Gowri Kumar CH wrote:

Is this one of the things which we come to know by experience?


Yes.


Is there a way to find it out from the core/code generated?


No.  You'd have to have someone tell you, or read up on a UNIX  
internals book or find a good C book.


I'm wondering how difficult it would be find this sort of errors in  
a large program.


You would be able to find this type of problem fairly easily in a  
large program, now.  :-)

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Matt Fago]

>From: drizzle drizzle <[EMAIL PROTECTED]>
>Still no luck so far .. I got the gcc3.4 from the gcc archive. Any way
>I can make gcc 3.4 not use these libraries ?


What is the exact file name and URL? I will download the same tarball and try 
to build it on my fc6 box.

 - M

Re: mixing VEC-tors of string & GTY?

[Mike Stump]

On Jan 4, 2007, at 2:26 AM, Basile STARYNKEVITCH wrote:

I cannot figure out how to have a vector of strings in a GTY-ed file



F_VEC_ALLOC_P(locstr,heap);

Any clues?


Do a vec of:

struct bar {
char *field;
}

and skip the field, and add the GTY markers.  Should work.

libgcc

[Mike Stump]

In libgcc/Makefile I find:

  MAKEINFO = @MAKEINFO@

and

  PERL = @PERL@

Seems like they should be always substituted, if they are going to  
always be in there, or, if they are never used, removed.

Fwd: Bugzilla internal error

[Daniel Berlin]

Guys, i changed the cookie  prevent this error, and to stop it from
continually asking for logins.

Please clear your current gcc.gnu.org bugzilla cookie from your
browser, or both this error, and getting asked for logins on every
page, will continue.

-- Forwarded message --
From: Paolo Carlini <[EMAIL PROTECTED]>
Date: Jan 4, 2007 2:25 PM
Subject: Bugzilla internal error
To: [EMAIL PROTECTED]


Hi Danny,

for some reason, Bugzilla undergoes an internal error when I try to add
a small patch to PR libstdc++/30365:

undef error - Undefined subroutine Fh::slice at
data/template/template/en/default/global/hidden-fields.html.tmpl line 58

Can you look into it?

Thanks,
Paolo.

Re: Fwd: Bugzilla internal error

[Paolo Carlini]

Daniel Berlin wrote:


Guys, i changed the cookie  prevent this error, and to stop it from
continually asking for logins.


I'm not sure to understand, I never had problems before...


Please clear your current gcc.gnu.org bugzilla cookie from your
browser, or both this error, and getting asked for logins on every
page, will continue.


Anyway, ok, done, now it works.

Thanks,
Paolo.

Re: mpfr issues when Installing gcc 3.4 on fedora core

[drizzle drizzle]

I configure with --enable-languages=c,c++ . Shudnt that disable gfortran ?

thanks
dz

On 1/4/07, Richard Guenther <[EMAIL PROTECTED]> wrote:

On 1/4/07, drizzle drizzle <[EMAIL PROTECTED]> wrote:
> Still no luck so far .. I got the gcc3.4 from the gcc archive. Any way
> I can make gcc 3.4 not use these libraries ?

3.4 doesn't use gmp or mpfr, gfortran introduces this dependency but it
appears with 4.0 or newer only.

Richard.

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Richard Guenther]

On 1/4/07, drizzle drizzle <[EMAIL PROTECTED]> wrote:

I configure with --enable-languages=c,c++ . Shudnt that disable gfortran ?


You are not configuring gcc 3.4.

Richard.


thanks
dz

On 1/4/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 1/4/07, drizzle drizzle <[EMAIL PROTECTED]> wrote:
> > Still no luck so far .. I got the gcc3.4 from the gcc archive. Any way
> > I can make gcc 3.4 not use these libraries ?
>
> 3.4 doesn't use gmp or mpfr, gfortran introduces this dependency but it
> appears with 4.0 or newer only.
>
> Richard.
>

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Matt Fago]

>From: drizzle drizzle <[EMAIL PROTECTED]>
>
>svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_3_4_6_release

This is checking out the latest trunk, not version 3.4. The last argument only 
changes the name of the directory name on your local machine. The 'svn://'  is 
what specifies the tag (in this case 'trunk').

 - Matt

Re: libgcc

[Daniel Jacobowitz]

On Thu, Jan 04, 2007 at 12:17:49PM -0800, Mike Stump wrote:
> In libgcc/Makefile I find:
> 
>   MAKEINFO = @MAKEINFO@
> 
> and
> 
>   PERL = @PERL@
> 
> Seems like they should be always substituted, if they are going to  
> always be in there, or, if they are never used, removed.

The latter; feel free to remove them :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Gerald Pfeifer]

On Thu, 4 Jan 2007, Matt Fago wrote:
>>From: drizzle drizzle <[EMAIL PROTECTED]>
>>
>>svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_3_4_6_release
> This is checking out the latest trunk, not version 3.4. The last argument 
> only changes the name of the directory name on your local machine. The 
> 'svn://'  is what specifies the tag (in this case 'trunk').

Drizzle drozzle, booble bubble, or whatever,

please refer to our fine documentation at http://gcc.gnu.org/svn.html#tags
for how to check out using SVN.

For releases, you can also obtain tarballs from 
http://gcc.gnu.org/mirrors.html.

Gerald

Re: Fwd: Bugzilla internal error

[Daniel Berlin]

On 1/4/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:

Daniel Berlin wrote:

> Guys, i changed the cookie  prevent this error, and to stop it from
> continually asking for logins.

I'm not sure to understand, I never had problems before...


Others have :)


> Please clear your current gcc.gnu.org bugzilla cookie from your
> browser, or both this error, and getting asked for logins on every
> page, will continue.

Anyway, ok, done, now it works.

Thanks,
Paolo.

gcc-4.0-20070104 is now available

[gccadmin]

Snapshot gcc-4.0-20070104 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20070104/
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 120450

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.0-20061228 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.

PATCH for Re: 3 new GCC mirrors

[Gerald Pfeifer]

On Thu, 21 Dec 2006, Marco Rinaudo - Internet.bs Corp. wrote:
> I am pleased to announce 3 new GCC mirrors located in London (UK), Hong 
> Kong and Toronto (CANADA), daily resync.

Thanks!  These servers seem to be well connected.

> Please feel free to add the 3 mirrors to the official list of mirrors
> located here: http://gcc.gnu.org/mirrors.html

I just committed the patch below to properly document this.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.176
diff -u -3 -p -r1.176 mirrors.html
--- mirrors.html3 Jan 2007 21:50:31 -   1.176
+++ mirrors.html4 Jan 2007 23:08:02 -
@@ -28,7 +28,9 @@ Key fingerprint = 90AA 4704 69D3 965A 87
 
 Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, 
thanks to Antonin dot Sprinzl at tuwien dot ac dot at
 Brasil (no snapshots): ftp://ftp.softaplic.com.br/pub/sourceware/gcc/";>ftp.softaplic.com.br
+Canada, Toronto: http://gcc-ca.internet.bs";>http://gcc-ca.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 China: ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/,
 thanks to David Deng (david99deng at yahoo dot com)
+China, Hong Kong: http://gcc-hk.internet.bs";>http://gcc-hk.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 
dot fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks 
to ftpmaint at irisa dot fr
 France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, 
thanks to ftpmaint at uvsq dot fr
@@ -45,6 +47,7 @@ Key fingerprint = 90AA 4704 69D3 965A 87
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600 dot sk)
 Taiwan: ftp://ftp.nctu.edu.tw/computer-languages/C/gcc/";>ftp.nctu.edu.tw, 
thanks to ftpadm at ftp dot nctu dot edu dot tw
 UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/,
 thanks to mirror at mirrorservice dot org
+UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 US, Virginia: ftp://mirrors.rcn.net/pub/sourceware/gcc/";>mirrors.rcn.net (also 
available via http://mirrors.rcn.net/pub/sourceware/gcc/";>http)
 US, St. Louis (no snapshots): ftp://mirrors.laffeycomputer.com/pub/gcc.gnu.org/pub/gcc/";>mirrors.laffeycomputer.com,
 thanks to mirrormaster at laffey dot biz
 

Re: Retiring IPA-branch

[Gerald Pfeifer]

On Tue, 2 Jan 2007, Jan Hubicka wrote:
> I would hope to retire that branch, since it has gained a lot of
> dust and also a lot of things has been renamed while merging to mainline
> making it outdated.

I assume you will update svn.html accordingly once this is done...

> At the end of stage 1 I would also like to open new branch targeted to
> further improvements and cleanups of IPA infrastructure that can
> co-exist in parallel with LTO branch solving other aspects we need to
> address before getting useable link time optimization.

...and when you are going to create the new branch?  ;-)

Gerald

Re: Do we want non-bootstrapping "make" back?

[Eric Botcazou]

> Once upon a time, the --disable-bootstrap configure option wasn't
> necessary.  "make" built gcc, and "make bootstrap" bootstrapped it.
>
> Is this behavior useful?  Should we have it back again?

Is this a genuine question or some subtle attempt at mimicing Paul Eggert's 
cleverness to spark your own gigantic thread? :-)  Certainly, doing a mere 
build with "make" and a complete bootstrap with "make bootstrap" was rather 
reasonable, but you and other build machinery wizards convinced us that this 
would be a pain to support with toplevel bootstrap.  So what has changed?

-- 
Eric Botcazou

RFC: Implementation of ELF sharable sections

[H. J. Lu]

Here is one implementation of ELF sharable section proposal:

http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d

Several people have expressed interests. I post it here for comments.
I used OS specific values. If we get consensus, I can change those
values to generic range.


H.J.
bfd/

2007-01-04  H.J. Lu  <[EMAIL PROTECTED]>

* elf-bfd.h (_bfd_elf_sharable_com_section): New.
(_bfd_elf_add_sharable_symbol): Likewise.
(_bfd_elf_sharable_section_from_bfd_section): Likewise.
(_bfd_elf_sharable_symbol_processing): Likewise.
(_bfd_elf_sharable_common_definition): Likewise.
(_bfd_elf_sharable_common_section_index): Likewise.
(_bfd_elf_sharable_common_section): Likewise.
(_bfd_elf_sharable_merge_symbol): Likewise.

* elf.c (special_sections_g): Add ".gnu.linkonce.shrb" and
".gnu.linkonce.shrd".
(special_sections_s): Add ".sharable_bss" and ".sharable_data".
(get_program_header_size): Handle PT_GNU_SHR segment.
(_bfd_elf_map_sections_to_segments): Likewise.
(assign_file_positions_for_load_sections): Likewise.

* elf32-i386.c (elf_i386_link_hash_table): Add sdynsharablebss
and srelsharablebss fields.
(elf_i386_link_hash_table_create): Initialize sdynsharablebss
and srelsharablebss.
(elf_i386_create_dynamic_sections): Handle sdynsharablebss and
srelsharablebss.
(elf_i386_adjust_dynamic_symbol): Likewise.
(elf_i386_size_dynamic_sections): Likewise.
(elf_i386_finish_dynamic_symbol): Likewise.
(elf_backend_add_symbol_hook): Defined.
(elf_backend_section_from_bfd_section): Likewise.
(elf_backend_symbol_processing): Likewise.
(elf_backend_common_section_index): Likewise.
(elf_backend_common_section): Likewise.
(elf_backend_common_definition): Likewise.
(elf_backend_merge_symbol): Likewise.

* elf64-x86-64.c (elf64_x86_64_link_hash_table): Add
sdynsharablebss and srelsharablebss fields.
(elf64_x86_64_link_hash_table_create): Initialize sdynsharablebss
and srelsharablebss.
(elf64_x86_64_create_dynamic_sections): Handle sdynsharablebss
and srelsharablebss.
(elf64_x86_64_adjust_dynamic_symbol): Likewise.
(elf64_x86_64_size_dynamic_sections): Likewise.
(elf64_x86_64_finish_dynamic_symbol): Likewise.
(elf64_x86_64_add_symbol_hook): Handle sharable symbols.
(elf64_x86_64_elf_section_from_bfd_section): Likewise.
(elf64_x86_64_symbol_processing): Likewise.
(elf64_x86_64_merge_symbol): Likewise.
(elf64_x86_64_common_definition): Handle sharable sections.
(elf64_x86_64_common_section_index): Likewise.
(elf64_x86_64_common_section): Likewise.

* elflink.c (_bfd_elf_create_dynamic_sections): Handle
.dynsharablebss section.
(_bfd_elf_sharable_com_section): New.
(get_sharable_common_section): Likewise.
(_bfd_elf_add_sharable_symbol): Likewise.
(_bfd_elf_sharable_section_from_bfd_section): Likewise.
(_bfd_elf_sharable_symbol_processing): Likewise.
(_bfd_elf_sharable_common_definition): Likewise.
(_bfd_elf_sharable_common_section_index): Likewise.
(_bfd_elf_sharable_common_section): Likewise.
(_bfd_elf_sharable_merge_symbol): Likewise.

* elfxx-ia64.c (elfNN_ia64_add_symbol_hook): Handle sharable
symbols.
(elf_backend_add_symbol_hook): Defined.
(elf_backend_section_from_bfd_section): Likewise.
(elf_backend_symbol_processing): Likewise.
(elf_backend_common_section_index): Likewise.
(elf_backend_common_section): Likewise.
(elf_backend_common_definition): Likewise.
(elf_backend_merge_symbol): Likewise.

binutils/

2007-01-04  H.J. Lu  <[EMAIL PROTECTED]>

* readelf.c (dump_relocations): Handle sharable sections.
(get_segment_type): Handle sharable segment.
(get_symbol_index_type): Handle sharable sections.

gas/

2007-01-04  H.J. Lu  <[EMAIL PROTECTED]>

* config/obj-elf.c (obj_elf_sharable_common): New.
(elf_pseudo_table): Add "sharable_common".
(obj_elf_change_section): Handle sharable sections.

include/elf/

2007-01-04  H.J. Lu  <[EMAIL PROTECTED]>

* common.h (PT_GNU_SHR): New.
(SHF_GNU_SHARABLE): Likewise.
(SHN_GNU_SHARABLE_COMMON): Likewise.

ld/

2007-01-04  H.J. Lu  <[EMAIL PROTECTED]>

* emulparams/elf64_ia64.sh (SHARABLE_SECTIONS): Set to yes.
* emulparams/elf_i386.sh (SHARABLE_SECTIONS): Likewise.
* emulparams/elf_x86_64.sh (SHARABLE_SECTIONS): Likewise.

* emultempl/elf32.em: Include "elf-bfd.h".
(gld${EMULATION_NAME}_place_orphan): Don't allow orphaned
sharable sections.

* scripttempl/elf.sc: Support sharable sections.

--- binutils/bfd/elf-bfd.h

getting better info out of Bugzilla

[Joe Buck]

Hi,

RMS has been bugging the Steering Committee about the the bug backlog; he
is worried about its size.  In trying to put together some answers for
him, I was struggling with the fact that it is very difficult to tell,
with four open lines of development (4.0, 4.1, 4.2, 4.3), which bugs are
in which versions, and to distinguish shipping bugs from development bugs.
For any individual bug, you can usually tell by reading the entire
Bugzilla history, but this isn't feasible when dealing with several
hundred.

We actually have fields that are supposed to answer this question:
"Known to Fail" and "Known to Work".  However, these fields are not
being set in a consistent manner, and aren't being updated when the
situation changes.

I'd like to get to the point where I can quickly get an answer to
questions like "How many P1 bugs affect gcc-4.1.1".  I think the cleanest
way to do that is to at least have correct Known to work/fail status for
the most serious bugs, for the most recent release (ideally all release
branches as well).  It will be a big job to clean this up, but I'd like to
ask maintainers to try to remember to update these fields when a bug is
fixed on a given branch.  Also, when reviewing the status of a given bug,
if you can make Known to work/Known to fail more accurate, please do.

Because there are so many open bugs, it's probably best to start with the
P1 bugs.

Re: Do we want non-bootstrapping "make" back?

[Daniel Jacobowitz]

On Fri, Jan 05, 2007 at 12:18:53AM +0100, Eric Botcazou wrote:
> > Once upon a time, the --disable-bootstrap configure option wasn't
> > necessary.  "make" built gcc, and "make bootstrap" bootstrapped it.
> >
> > Is this behavior useful?  Should we have it back again?
> 
> Is this a genuine question or some subtle attempt at mimicing Paul Eggert's 
> cleverness to spark your own gigantic thread? :-)

Ahem.

> Certainly, doing a mere 
> build with "make" and a complete bootstrap with "make bootstrap" was rather 
> reasonable, but you and other build machinery wizards convinced us that this 
> would be a pain to support with toplevel bootstrap.  So what has changed?

Not much.  I'm convinced it would be feasible, but definitely not easy,
so I wanted to see how much interest there was - seems like some, but
not a lot.

-- 
Daniel Jacobowitz
CodeSourcery

How to dedicate a register for special purpose in gcc?

[吴曦]

Hi,
How can I dedicate a register for special purpose, that means,
the dedicated register only appears in the inserted code of my own,
but never allocated in the rest of code. I have read some doc(gcc int)
about the register usage but still have no idea.

I would *really* appreciate any help I can get on this issue!
Xi Wu

Re: How to dedicate a register for special purpose in gcc?

[Daniel Jacobowitz]

On Fri, Jan 05, 2007 at 12:53:16PM +0800,  wrote:
> Hi,
> How can I dedicate a register for special purpose, that means,
> the dedicated register only appears in the inserted code of my own,
> but never allocated in the rest of code. I have read some doc(gcc int)
> about the register usage but still have no idea.
> 
> I would *really* appreciate any help I can get on this issue!

Take a look at -ffixed-REG.

-- 
Daniel Jacobowitz
CodeSourcery

Re: getting better info out of Bugzilla

[Andrew Pinski]

On Thu, 2007-01-04 at 17:26 -0800, Joe Buck wrote:
> Hi,
> We actually have fields that are supposed to answer this question:
> "Known to Fail" and "Known to Work".  However, these fields are not
> being set in a consistent manner, and aren't being updated when the
> situation changes.

I have been trying to keep those up to date the best I can, but usually
I only set them for one compiler version in a series like 2.95.3 or
3.3.1.  I try to include the version which is the last known to work in
the "known to work".

The other thing I usually do is when a problem was fixed in 4.1.2 and
4.0.4 I try to keep the "know to work/fail" fields correctly so that we
know that it was fixed in 4.1.2 but failed in 4.1.1.  This also allows
us and others to keep track of what was fixed when.

Thanks,
Andrew Pinski

Re: How to dedicate a register for special purpose in gcc?

[Ian Lance Taylor]

"吴曦" <[EMAIL PROTECTED]> writes:

> How can I dedicate a register for special purpose, that means,
> the dedicated register only appears in the inserted code of my own,
> but never allocated in the rest of code. I have read some doc(gcc int)
> about the register usage but still have no idea.

This question is not appropriate for this mailing list.  It would be
appropriate for [EMAIL PROTECTED]  Thanks.

One easy way to do this is to use a global register variable:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Global-Reg-Vars.html

Another is to use the -ffixed-REG option.  See the documentation.

Ian

GCC 4.1.2 Status Report [2007-01-04]

[Mark Mitchell]

I've decided to focus next on GCC 4.1.2.  After GCC 4.1.2, I will focus
on GCC 4.2.0.  At this point, I expect GCC 4.3 to remain in Stage 1 for
some time, while we work on GCC 4.1.2 and GCC 4.2.0.  So, I've been
looking at the GCC 4.1.2 Bugzilla entries.

(I'm sure one of your New Year's resolutions was "I shall fix more
regressions in 2007."  If not, it's not too late!)

Bugzilla has entries for 156 P1-P3 regressions.  Of course, some of the
P3s will in fact end up being P4 or P5, so that is not an entirely
accurate count.  There are 18 P1 regressions.  However, I am only aware
of two regressions relative to 4.1.0 or 4.1.1, as recorded here:

http://gcc.gnu.org/wiki/GCC_4.1.2_Status#preview

If you know of more, please let me know, and please update the Wiki page.

I'm not going to let bugs which existed in 4.1.[01] block 4.1.2 -- but I
am going to take a hard line on P1 regressions relative to the previous
4.1.x releases, and I'm going to grumble a lot about P2s.

So, I think we're relatively close to being able to do a 4.1.2 release.
 Let's tentatively plan on a first release candidate on or about January
19th, with a final release approximately a week later.

Thanks,

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

Re: trunk gcc has problems finding crtbegin.o

[Philippe Schaffnit]

Hi!

Thanks a lot for fixing that in such a speedy manner.

Philippe

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 04, 2007 at 08:59:51AM -0500, Daniel Jacobowitz wrote:
> > On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote:
> > > /usr/bin/ld: crtbegin.o: No such file: No such file or directory
> > > collect2: ld returned 1 exit status
> > >
> > > This probably happens because the crt*.o files are no longer placed into
> > > /lib/gcc/i686-pc-linux-gnu/4.3.0/
> > > but rather into /lib/gcc/i686-pc-linux-gnu/.
> > > Is this related to the recent libgcc changes?
> >
> > Yes, it's my fault.  The last time I tested make install, they went to
> > the right place.  I'm building right now to find out what's gone wrong.
> 
> I'm not sure how I missed this before; apologies.  I've checked in this
> obvious fix.
> 
> Relating to what Mark was saying earlier: you can see that this assumes
> $(CC) (in the target directory) has the same version as ../gcc/xgcc.
> This is not the first place with that sort of assumption.  If you're
> building Canadian crosses, remember to use the same source tree to
> build the cross compiler and the cross-hosted compiler.  Anything
> else is just impossible to support.
> 
> --
> Daniel Jacobowitz
> CodeSourcery
> 
> 2007-01-04  Daniel Jacobowitz  <[EMAIL PROTECTED]>
> 
> * Makefile.in (version): Define.
> 
> Index: Makefile.in
> ===
> --- Makefile.in (revision 120429)
> +++ Makefile.in (working copy)
> @@ -181,6 +181,8 @@ export RANLIB_FOR_TARGET
>  export libsubdir
>  export slibdir
> 
> +version := $(shell $(CC) -dumpversion)
> +
>  DECNUMINC = -I$(srcdir)/../libdecnumber -I$(MULTIBUILDTOP)../../libdecnumber
> 
>  # Specify the directories to be searched for header files.

Re: Do we want non-bootstrapping "make" back?

[Eric Botcazou]

> Not much.  I'm convinced it would be feasible, but definitely not easy,
> so I wanted to see how much interest there was - seems like some, but
> not a lot.

Would this comprise retrofitting the support into the 4.2 branch?

-- 
Eric Botcazou

Suspicious expand_complex_division() in tree-comlpex.c

[Marcin Dalecki]

Peeking at the implementation of the expand_complex_division() function
inside tree-complex.c I have compared the conditions for satisfying  
the -fcx-limited-range and flag_isoc99

condition. And thus I have some questions about the logics of it.
In esp. the following lines (starting at 1222 inside the file):

case PAIR (ONLY_REAL, VARYING):
case PAIR (ONLY_IMAG, VARYING):
case PAIR (VARYING, VARYING):
  switch (flag_complex_method)
{
case 0:
==
This is the "quick and don't care about overflow case". This seems  
just fine.


  /* straightforward implementation of complex divide acceptable.  */
  expand_complex_div_straight (bsi, inner_type, ar, ai, br, bi, code);
  break;

case 2:
==
This is supposed to be the ISO C99 conforming full overflow robust case.
Fine.
  if (SCALAR_FLOAT_TYPE_P (inner_type))
{
  expand_complex_libcall (bsi, ar, ai, br, bi, code);
==
However here the break is causing update_complex_assignment() to be  
called TWICE
IN A ROW. I guess it should be a return statement instead. Much like  
in the case

of the multiply by intrinsic function. That's suspicious.

  break;
}
  /* FALLTHRU */
==
The intrinsic function got expanded...

case 1:
==
And now we are expanding the supposedly a bit less precise version of  
the division
directly behind it? This doesn't to be the same kind of "overflow  
robustness logic"

as in the case of multiplication.

  /* wide ranges of inputs must work for complex divide.  */
  expand_complex_div_wide (bsi, inner_type, ar, ai, br, bi, code);
  break;

default:
  gcc_unreachable ();
}
  return;

default:
  gcc_unreachable ();

Thus my question to whoever looked at this code close enough is:

1. Is the FALLTHRU really OK?
2. Shouldn't the logic when to decide which kind of implementation to  
take

not look a bit more like in the multiplication case?

Marcin Dalecki

Re: Suspicious expand_complex_division() in tree-comlpex.c

[Andrew Pinski]

> 
> Peeking at the implementation of the expand_complex_division() function
> inside tree-complex.c I have compared the conditions for satisfying  
> the -fcx-limited-range and flag_isoc99
> condition. And thus I have some questions about the logics of it.
> In esp. the following lines (starting at 1222 inside the file):
> 
> IN A ROW. I guess it should be a return statement instead. Much like  
> in the case
> of the multiply by intrinsic function. That's suspicious.

The break gets out of the inner switch statement and right after
that is a return and not out of the if.

> 
> break;
>   }
> /* FALLTHRU */
> ==
> The intrinsic function got expanded...
> 
>   case 1:
> ==
> And now we are expanding the supposedly a bit less precise version of  
> the division
> directly behind it? This doesn't to be the same kind of "overflow  
> robustness logic"
> as in the case of multiplication.

The fall through is for non fp complex types, yes they exist in GCC
and in GNU C.

> Thus my question to whoever looked at this code close enough is:
> 
> 1. Is the FALLTHRU really OK?

yes, see above. Plus the fall through is only for non fp types.

> 2. Shouldn't the logic when to decide which kind of implementation to  
> take
> not look a bit more like in the multiplication case?

It is the same in general anyways but division is the one that is
different between flag_complex_method==0 and flag_complex_method==1.

Thanks,
Andrew Pinski

Re: Suspicious expand_complex_division() in tree-comlpex.c

[Marcin Dalecki]

Wiadomość napisana w dniu 2007-01-05, o godz08:36, przez Andrew Pinski:




Thus my question to whoever looked at this code close enough is:

1. Is the FALLTHRU really OK?


yes, see above. Plus the fall through is only for non fp types.


Yes I see now... a quite complicated way to express the choice logic:

1. if -fcx-limited-range is set go straight for the quick overflowing  
version.

2. be strict in case of ISO C99.
3. handle floaing poing divisions more precisely then multiplications  
else.



2. Shouldn't the logic when to decide which kind of implementation to
take
not look a bit more like in the multiplication case?


It is the same in general anyways but division is the one that is
different between flag_complex_method==0 and flag_complex_method==1.


OK. This confirms that the three state flag_complex_method could be
eliminated, and fcx_limited_range used directly instead.
(My final goal is of course something in the way of #pragma STDC  
CX_LIMITED_RANGE)...


Marcin Dalecki

Re: Suspicious expand_complex_division() in tree-comlpex.c

[Andrew Pinski]

> 
> 
> 
> Yes I see now... a quite complicated way to express the choice logic:
> 
> 1. if -fcx-limited-range is set go straight for the quick overflowing  
> version.
> 2. be strict in case of ISO C99.
> 3. handle floaing poing divisions more precisely then multiplications  
> else.

if you look at where flag_complex_method is defined in toplev.c:
there is a nice comment:
/* 0 means straightforward implementation of complex divide acceptable.
   1 means wide ranges of inputs must work for complex divide.
   2 means C99-like requirements for complex multiply and divide.  */


> 
> >> 2. Shouldn't the logic when to decide which kind of implementation to
> >> take
> >> not look a bit more like in the multiplication case?
> >
> > It is the same in general anyways but division is the one that is
> > different between flag_complex_method==0 and flag_complex_method==1.
> 
> OK. This confirms that the three state flag_complex_method could be
> eliminated, and fcx_limited_range used directly instead.
> (My final goal is of course something in the way of #pragma STDC  
> CX_LIMITED_RANGE)...

No, they cannot.
We default to flag_complex_method == 1.
Then with -fcx-limited-range we get = 0:
  /* With -fcx-limited-range, we do cheap and quick complex arithmetic.  */
  if (flag_cx_limited_range)
flag_complex_method = 0;

And with -std=c99, we get 2:
  /* C99 requires special handling of complex multiplication and division;
 -ffast-math and -fcx-limited-range are handled in process_options.  */
  if (flag_isoc99)
flag_complex_method = 2;

I don't see why you think we can elimitate the three state variable.

We allow complex types in GNU C89.  Plus other front-ends use complex types
so getting rid of the three state variable will cause regressions in
say fortran.

-- Pinski