Results for 4.2.1 testsuite on sparc-sun-solaris2.8

[Dennis Clarke]

bootstrapping with Sun Studio 8 thus :

bash-3.2$ cc -V
cc: Sun C 5.5 Patch 112760-18 2005/06/14
usage: cc [ options] files.  Use 'cc -flags' for details
bash-3.2$ CC -V
CC: Sun C++ 5.5 Patch 113817-20 2007/04/24

All tools in the toolpath were built up to date and passed their
testsuites. Typical revs used were :

bash-3.2$ autoconf --version
autoconf (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the
terms of the GNU General Public License
. There is NO WARRANTY, to the
extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

bash-3.2$ bison --version
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

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-3.2$ expect -v
expect version 5.43.0

bash-3.2$ m4 --version
m4 (GNU M4) 1.4.10
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Rene' Seindal.

I also used : dejagnu  1.4.4
  tcl  8.4.15
  tk   8.4.15
  make 3.81
  libiconv 1.11
  gmp  4.2.1
  mpfr 2.2.1

testsuite report as per : http://gcc.gnu.org/install/finalinstall.html

Output from running srcdir/config.guess.

  bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/config.guess
  sparc-sun-solaris2.8

The output of `gcc -v' for your newly installed gcc.

bash-3.2$ which gcc
/export/home/dclarke/local/bin/gcc
bash-3.2$ file /export/home/dclarke/local/bin/gcc
/export/home/dclarke/local/bin/gcc: ELF 32-bit MSB executable
SPARC Version 1, dynamically linked, not stripped
bash-3.2$ ldd /export/home/dclarke/local/bin/gcc
libiconv.so.2 =>
/export/home/dclarke/local/lib/libiconv.so.2
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
bash-3.2$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-cpu=v7 --enable-threads=posix --disable-nls
--prefix=/export/home/dclarke/local
--with-local-prefix=/export/home/dclarke/local --enable-shared
--enable-languages=c,c++,objc,fortran
--with-gmp=/export/home/dclarke/local
--with-mpfr=/export/home/dclarke/local --enable-bootstrap
Thread model: posix
gcc version 4.2.1

Whether you enabled all languages or a subset of them.

  subset via configure option --enable-languages=c,c++,objc,fortran

The distribution name and version :

  Solaris 8 2/04 s28s_hw4wos_05a SPARC with all patches up to date

  $ uname -a
  SunOS fossil 5.8 Generic_117350-47 sun4m sparc SUNW,SPARCstation-20

  System is a 4-way 60 MHz HyperSparc SUNW,SPARCstation-20
  with 256MB RAM and 512MB swap  [ yes really ]

  Using Sun Solaris based /usr/ccs/bin/as and /usr/ccs/bin/ld


The full configure line used was :

/export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-cpu=v7
--enable-threads=posix --disable-nls
--prefix=/export/home/dclarke/local
--with-local-prefix=/export/home/dclarke/local --enable-shared
--enable-languages=c,c++,objc,fortran
--with-gmp=/export/home/dclarke/local
--with-mpfr=/export/home/dclarke/local --enable-bootstrap


And here is a quick test :


bash-3.2$ cat hello.c
#include 
#include 

hrtime_t start_hrt, end_hrt;

int
main(int argc, char *argv[])
{
start_hrt = gethrtime();
printf ( "Hello World!\n" );
end_hrt = gethrtime();
printf("time = %lld nsec\n", ( end_hrt - start_hrt ) );
return (0);
}
bash-3.2$
bash-3.2$ gcc -c -o hello.o hello.c
bash-3.2$ file hello.o
hello.o:ELF 32-bit MSB relocatable SPARC Version 1
bash-3.2$ gcc -o hello hello.o
bash-3.2$ file hello
hello:  ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
bash-3.2$ ldd hello
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
bash-3.2$ ./hello
Hello World!
time = 347 nsec
bash-3.2$

And a slightly more involved sample with code that calls the mpfr libs:

bash-3.2$ ls -l mpfr_cos.c
-rw-r--r--   1 dclarke  csw 1257 Aug 10 01:36 mpfr_cos.c
bash-3.2$ cat mpfr_cos.c
/**
 * This is a slightly modified code snip that was presented by* *
Jonathan Bober <[EMAIL PROTECTED]> in order to demonstrate the   * *
less than optimal mpfr_sin call versus mpfr_cos. Please see* * the
mpfr maillist for details and follow up by Vincent Lefevre * * and
myself. We all 

Results for 4.2.1 testsuite on sparc-sun-solaris2.8

[Dennis Clarke]

bootstrapping with Sun Studio 8 thus :

bash-3.2$ cc -V
cc: Sun C 5.5 Patch 112760-18 2005/06/14
usage: cc [ options] files.  Use 'cc -flags' for details
bash-3.2$ CC -V
CC: Sun C++ 5.5 Patch 113817-20 2007/04/24

All tools in the toolpath were built up to date and passed their testsuites.
Typical revs used were :

bash-3.2$ autoconf --version
autoconf (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License . There
is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

bash-3.2$ bison --version
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

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-3.2$ expect -v
expect version 5.43.0

bash-3.2$ m4 --version
m4 (GNU M4) 1.4.10
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it. There is
NO WARRANTY, to the extent permitted by law.

Written by Rene' Seindal.

I also used : dejagnu  1.4.4
  tcl  8.4.15
  tk   8.4.15
  make 3.81
  libiconv 1.11
  gmp  4.2.1
  mpfr 2.2.1

testsuite report as per : http://gcc.gnu.org/install/finalinstall.html

Output from running srcdir/config.guess.

  bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/config.guess
  sparc-sun-solaris2.8

The output of `gcc -v' for your newly installed gcc.

bash-3.2$ which gcc
/export/home/dclarke/local/bin/gcc
bash-3.2$ file /export/home/dclarke/local/bin/gcc
/export/home/dclarke/local/bin/gcc: ELF 32-bit MSB executable SPARC
Version 1, dynamically linked, not stripped
bash-3.2$ ldd /export/home/dclarke/local/bin/gcc
libiconv.so.2 =>
/export/home/dclarke/local/lib/libiconv.so.2
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
bash-3.2$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-cpu=v7 --enable-threads=posix --disable-nls
--prefix=/export/home/dclarke/local
--with-local-prefix=/export/home/dclarke/local --enable-shared
--enable-languages=c,c++,objc,fortran --with-gmp=/export/home/dclarke/local
--with-mpfr=/export/home/dclarke/local --enable-bootstrap
Thread model: posix
gcc version 4.2.1

Whether you enabled all languages or a subset of them.

  subset via configure option --enable-languages=c,c++,objc,fortran

The distribution name and version :

  Solaris 8 2/04 s28s_hw4wos_05a SPARC with all patches up to date

  $ uname -a
  SunOS fossil 5.8 Generic_117350-47 sun4m sparc SUNW,SPARCstation-20

  System is a 4-way 60 MHz HyperSparc SUNW,SPARCstation-20
  with 256MB RAM and 512MB swap  [ yes really ]

  Using Sun Solaris based /usr/ccs/bin/as and /usr/ccs/bin/ld


The full configure line used was :

/export/home/dclarke/build/gcc-4.2.1/configure --with-as=/usr/ccs/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7
--enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local
--with-local-prefix=/export/home/dclarke/local --enable-shared
--enable-languages=c,c++,objc,fortran --with-gmp=/export/home/dclarke/local
--with-mpfr=/export/home/dclarke/local --enable-bootstrap


And here is a quick test :


bash-3.2$ cat hello.c
#include 
#include 

hrtime_t start_hrt, end_hrt;

int
main(int argc, char *argv[])
{
start_hrt = gethrtime();
printf ( "Hello World!\n" );
end_hrt = gethrtime();
printf("time = %lld nsec\n", ( end_hrt - start_hrt ) );
return (0);
}
bash-3.2$
bash-3.2$ gcc -c -o hello.o hello.c
bash-3.2$ file hello.o
hello.o:ELF 32-bit MSB relocatable SPARC Version 1
bash-3.2$ gcc -o hello hello.o
bash-3.2$ file hello
hello:  ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
bash-3.2$ ldd hello
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
bash-3.2$ ./hello
Hello World!
time = 347 nsec
bash-3.2$

And a slightly more involved sample with code that calls the mpfr libs:

bash-3.2$ ls -l mpfr_cos.c
-rw-r--r--   1 dclarke  csw 1257 Aug 10 01:36 mpfr_cos.c
bash-3.2$ cat mpfr_cos.c
/**
 * This is a slightly modified code snip that was presented by* *
Jonathan Bober <[EMAIL PROTECTED]> in order to demonstrate the   * * less
than optimal mpfr_sin call versus mpfr_cos. Please see* * the mpfr
maillist for details and follow up by Vincent Lefevre * * and myself. We
all 

Re: can't bootstrap current trunk: internal compiler error: in simplify_subreg,@simplify-rtx.c:4679

[Kaveh R. GHAZI]

On Thu, 9 Aug 2007, Andreas Krebbel wrote:

> Hello,
>
> the bootstrap failure you are seeing is caused by my decompose
> multiword shift patch:
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html
>
> It is the same failure as reported by Andreas Tobler:
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00533.html
>
> I don't have access to a sparc machine. Could you please test the
> following patch?
>
> The patch at least seems to fix it on a cross gcc.
> Bye,
> -Andreas-

I have the same bootstrap error on sparc-sun-solaris2.10.  Your patch does
not fix it for me.  It moves the error to another line:

.../libgcc/../gcc/libgcc2.c: In function '__fixunssfdi':
.../libgcc/../gcc/libgcc2.c:1348: internal compiler error: in
simplify_subreg, at simplify-rtx.c:4674

Try:

cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=v9
-auxbase-strip _fixunssfdi.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fkeep-inline-functions -fPIC -o libgcc2.s

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

libgcc2.i.gz
Description: libgcc2.i.gz

Re: need help with builtin function prototypes

[DJ Delorie]

> I don't know about using reference types, but there are several math
> builtins that "return" multiple values, the extra ones via pointer
> arguments.  E.g. see frexp, lgamma_r, modf, remquo and/or sincos.

Like I said, I'm kinda locked into the syntax.  People have been using
these builtins for many years now.  Everything was fine when we
expanded the builtins to insns before optimization, and we could block
optimizations using RTL, but we don't have that option with tree
optimizations.

Re: need help with builtin function prototypes

[Kaveh R. GHAZI]

On Thu, 9 Aug 2007, DJ Delorie wrote:

> Could someone provide a hint for me?  I'm trying to put in "real"
> prototypes for a builtin function where the arguments don't follow the
> default promotion rules.  Specifically, one of the arguments is a
> reference type (like C++'s "int&").  However, I'm bumping into two
> problems:
>
> 1. The compiler emits a compatibility warning:
>
> dj.c:4: warning: incompatible implicit declaration of built-in function 
> 'mep_and'
>
> 2. The compiler seems to be using the implicit declaration instead of
>the builtin one, resulting in the builtin's arguments being
>incorrect, especially when optimizing:
>
> dj.c:4: error: non-lvalue passed to argument 1 of `mep_and'
>
> Is there a trick to this?  I need this type of functionality because
> some builtins modify multiple values, so a simple return value is
> insufficient, plus this worked with older versions of gcc so our users
> are used to it syntax-wise.

I don't know about using reference types, but there are several math
builtins that "return" multiple values, the extra ones via pointer
arguments.  E.g. see frexp, lgamma_r, modf, remquo and/or sincos.

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

GCC 4.3.0 Status Report (2007-08-09)

[Mark Mitchell]

Summary
---

We entered Stage 2 on July 6th.  I plan to put us into Stage 3 on
September 10th.  At that point, we will accept only bug-fixes -- no
more new features until Stage 1 for GCC 4.4.

Are there any folks out there who have projects for Stage 1 or Stage 2
that they are having trouble getting reviewed?  Any comments
re. timing for Stage 3?

Quality
---

At this point, we have 194 P3-or-higher regressions open against
4.3.0:

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.2.2&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I have not yet triaged the many P3 bugs, so I expect that some of
these will be downgraded.  An interesting fact is that now about half
of the 34 P1s re 4.3-only regressions.  So, we have been introducing
some new and exciting bugs, and we need to fix those.  Do we need
another 1-week stabilization period?

Previous Report
---

http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html

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

Re: [RFC] Migrate pointers to members to the middle end

[Daniel Berlin]

On 8/9/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On 8/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Daniel Berlin wrote:
> >
> > >> This is the source of my current woes, as this may involve virtual
> > >> function resolution, which can't be done with the information
> > >> currently available to the middle end.
> >
> > Ollie, IIRC, you posted an example where, together with your front-end
> > lowering patch (i.e., with the strategy that Daniel is advocating), we
> > don't do some optimization that we could in theory do.  Have you worked
> > out why not?  Perhaps that would shed some light on whether or not it's
> > tractable to recover this information from our current IR.
>
> The example I posted before indicated that the check to determine
> whether or not the member function is virtual wasn't optimized out.
> It didn't know that (fn_ptr & 1) == 0.  That should be easy to fix by
> incorporating pointer alignment requirements in fold_binary().
>
> Offhand, I don't remember what happened with the various other cases,
> but my testing at the time wasn't particularly thorough.  The feedback
> I've gotten so far seems overwhelmingly negative, so I think the next
> step is to revisit the lowering approach, exercise the hell out of it,
> and see what, if any, limitations pop up.
>
> Daniel mentioned something about a pre-existing type-based
> devirtualizer.  I'd be interested to see how it works.  From what I've
> been able to gleam from the GCC code, it seems that such an approach
> would need to hook back into the front end, which is a showstopper
> from an LTO perspective.  It's entirely possible that I'm missing
> something, though.

See
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00744.html

It only calls into the frontend to
1. Fold obj_type_ref_nodes (which would require *lowering* or defining
the semantics of it,  not raising)
2. Determine what is a ctor/dtor (something we do not expose to the middle-end)


>
> Ollie
>

Re: need help with builtin function prototypes

[DJ Delorie]

I'm hoping I can get it to do what I want, if only I can get the MI to
treat the function definition given to it by the target as the one
true definition, and not just some advisory one.

Re: [RFC] Migrate pointers to members to the middle end

[Daniel Berlin]

On 8/9/07, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> > Also in Java it is possible to devirtualize calls in some situations
> > where only a bound on the type is known.  For instance at a call site
> > we might know that all possible targets are derived from a class where
> > the virtual method is final.
>
> Likewise in C++ we might know that a method is effectively final because
> no class overrides it.
>


Just to be clear, we *already* have the class hierarchies in the middle end.

They have been there for a few years now :)

Re: Your Gmail account, [EMAIL PROTECTED], has been created

[Bobby McNulty]

Somebody signed up gcc@gcc.gnu.org to gmail.
Bad sign.

Re: Your Gmail account, [EMAIL PROTECTED], has been created

[Bobby McNulty]

- Original Message - 
From: "Gmail Team" <[EMAIL PROTECTED]>

To: "django porter" 
Sent: Thursday, August 09, 2007 6:21 PM
Subject: Your Gmail account, [EMAIL PROTECTED], has been created



Congratulations on creating your brand new Gmail account,
[EMAIL PROTECTED]
Please keep this email for your records, as it contains an
important verification code that you may need should you ever
encounter problems or forget your password.

You can login to your account at http://mail.google.com/

Enjoy!

The Gmail Team


Verification code: f806a3e9-f1f6e619-bdc37c3949

Re: need help with builtin function prototypes

[Ian Lance Taylor]

DJ Delorie <[EMAIL PROTECTED]> writes:

> Is there a trick to this?  I need this type of functionality because
> some builtins modify multiple values, so a simple return value is
> insufficient, plus this worked with older versions of gcc so our users
> are used to it syntax-wise.

I've never found a good solution for builtins which return multiple
values.  The best approximation I found was to return a magic
structure, and to provide other builtin functions to get the values
from the structure (defining the structure in the backend was
problematic when using C++).

It doesn't sound like that will help you, though, if you are stuck
with the existing syntax.

Ian

Re: [RFC] Migrate pointers to members to the middle end

[Ollie Wild]

On 8/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
> >> This is the source of my current woes, as this may involve virtual
> >> function resolution, which can't be done with the information
> >> currently available to the middle end.
>
> Ollie, IIRC, you posted an example where, together with your front-end
> lowering patch (i.e., with the strategy that Daniel is advocating), we
> don't do some optimization that we could in theory do.  Have you worked
> out why not?  Perhaps that would shed some light on whether or not it's
> tractable to recover this information from our current IR.

The example I posted before indicated that the check to determine
whether or not the member function is virtual wasn't optimized out.
It didn't know that (fn_ptr & 1) == 0.  That should be easy to fix by
incorporating pointer alignment requirements in fold_binary().

Offhand, I don't remember what happened with the various other cases,
but my testing at the time wasn't particularly thorough.  The feedback
I've gotten so far seems overwhelmingly negative, so I think the next
step is to revisit the lowering approach, exercise the hell out of it,
and see what, if any, limitations pop up.

Daniel mentioned something about a pre-existing type-based
devirtualizer.  I'd be interested to see how it works.  From what I've
been able to gleam from the GCC code, it seems that such an approach
would need to hook back into the front end, which is a showstopper
from an LTO perspective.  It's entirely possible that I'm missing
something, though.

Ollie

Your Gmail account, [EMAIL PROTECTED], has been created

[Gmail Team]

Congratulations on creating your brand new Gmail account,
[EMAIL PROTECTED]
Please keep this email for your records, as it contains an
important verification code that you may need should you ever
encounter problems or forget your password.

You can login to your account at http://mail.google.com/

Enjoy!

The Gmail Team


Verification code: f806a3e9-f1f6e619-bdc37c3949

Re: GCC 4.3.0 Status Report (2007-06-29)

[Mark Mitchell]

Andreas Meier wrote:

> You have forgotten the regressions with target milestone 4.2.1 and
> without a target milestone.

Thank you for pointing that out.  The omission of 4.2.1 is definitely
wrong, and I have fixed the front page with this patch.  However, there
should be no regressions without a target milestone, unless I've
explicitly marked them that way, at some point.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.626
diff -c -5 -p -r1.626 index.html
*** index.html  21 Jul 2007 23:13:20 -  1.626
--- index.html  9 Aug 2007 22:52:08 -
*** mission statement.
*** 127,140 
  
http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html";>2007-06-29
(Stage 2).

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
regressions.
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>All
regressions.
  
  
  
  
--- 127,140 
  
http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html";>2007-06-29
(Stage 2).

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.2.2&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
regressions.
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.2.2&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>All
regressions.
  
  
  
  

Re: [RFC] Migrate pointers to members to the middle end

[Mark Mitchell]

Daniel Berlin wrote:

>> This is the source of my current woes, as this may involve virtual
>> function resolution, which can't be done with the information
>> currently available to the middle end.

Ollie, IIRC, you posted an example where, together with your front-end
lowering patch (i.e., with the strategy that Daniel is advocating), we
don't do some optimization that we could in theory do.  Have you worked
out why not?  Perhaps that would shed some light on whether or not it's
tractable to recover this information from our current IR.

Thanks,

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

Re: cfg representation

[Diego Novillo]

On 8/9/07 4:09 PM, Bob Rossi wrote:

> Does anyone know where the code is that does this transformation so I
> can look for myself?

The conversion to GIMPLE does some of that, then the lowering into Low
GIMPLE and the CFG cleanups do the rest.  The files you want to look at
are gimplify.c for all the conversion to GIMPLE, tree-cfg.c for the
building of the CFG and omp-low.c for the conversion into Low GIMPLE.

Documentation on the various parts of this process is a bit spotty, but
you should find details on the various links in the Getting Started
section of the GCC wiki (http://gcc.gnu.org/wiki/GettingStarted)

cfg representation

[Bob Rossi]

Hi,

I've been looking at the cfg that gcc dumps to a file. I'm noticing that
the code is transformed in the cfg. Especially the short circuited
expressions and the ternary operator for C/C++. Is there a particular 
algorithm gcc uses to transform the original AST into the modified version 
in the CFG?

Does anyone know where the code is that does this transformation so I
can look for myself?

Thanks,
Bob Rossi

need help with builtin function prototypes

[DJ Delorie]

Could someone provide a hint for me?  I'm trying to put in "real"
prototypes for a builtin function where the arguments don't follow the
default promotion rules.  Specifically, one of the arguments is a
reference type (like C++'s "int&").  However, I'm bumping into two
problems:

1. The compiler emits a compatibility warning:

dj.c:4: warning: incompatible implicit declaration of built-in function 
'mep_and'

2. The compiler seems to be using the implicit declaration instead of
   the builtin one, resulting in the builtin's arguments being
   incorrect, especially when optimizing:

dj.c:4: error: non-lvalue passed to argument 1 of `mep_and'

Is there a trick to this?  I need this type of functionality because
some builtins modify multiple values, so a simple return value is
insufficient, plus this worked with older versions of gcc so our users
are used to it syntax-wise.

Parameters:

 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7e922d8 precision 32 
min  max 
pointer_to_this  reference_to_this 
>
unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7ee3680>

  
constant invariant 32>
unit size  constant invariant 4>
align 32 symtab 0 alias set -1 canonical type 0xb7e922d8 precision 32 min 
 max 
pointer_to_this >

Implicit function:

 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7ee02d8 precision 32 
min  max 
pointer_to_this  reference_to_this 
>
HI
size  
constant invariant 16>
unit size  constant invariant 2>
align 16 symtab 0 alias set -1 structural equality>

Explicit function:

 >
HI
size  
constant invariant 16>
unit size  constant invariant 2>
align 16 symtab 0 alias set -1 structural equality
arg-types 
unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7f31680>
chain >>>

Re: [RFC] Migrate pointers to members to the middle end

[Joe Buck]

On Thu, Aug 09, 2007 at 02:11:34PM -0700, Joe Buck wrote:
> On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> > Also in Java it is possible to devirtualize calls in some situations
> > where only a bound on the type is known.  For instance at a call site
> > we might know that all possible targets are derived from a class where
> > the virtual method is final.

I wrote:
> Likewise in C++ we might know that a method is effectively final because
> no class overrides it.

Whoops, that didn't come out the way that I intended.  I meant to say that
we might know that a given method (member function) call is effectively
final because no class that the pointer/reference can refer to overrides
the call.

Re: [RFC] Migrate pointers to members to the middle end

[Joe Buck]

On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> Also in Java it is possible to devirtualize calls in some situations
> where only a bound on the type is known.  For instance at a call site
> we might know that all possible targets are derived from a class where
> the virtual method is final.

Likewise in C++ we might know that a method is effectively final because
no class overrides it.

Re: [RFC] Migrate pointers to members to the middle end

[Tom Tromey]

> "Michael" == Michael Matz <[EMAIL PROTECTED]> writes:

Michael> Yes, devirtualization.  But I wonder if you really need class
Michael> hierarchies for this (actually I'm fairly sure you don't).

I'm generally in favor of what you talked about in this note and
others, and also Danny's overall approach of trying to design trees as
a language-neutral IR.

However, I'm not sure I agree with the above assertion.  Specifically,
for Java I think it is sometimes possible to strength reduce interface
calls to virtual calls, but I don't see how this could be done without
class hierarchy information.

Also in Java it is possible to devirtualize calls in some situations
where only a bound on the type is known.  For instance at a call site
we might know that all possible targets are derived from a class where
the virtual method is final.

I have no idea whether these cases matter, but they do exist.  There
are also type-related optimizations that can be done on Java that
don't involve devirtualization.

We have some code kicking around that does devirtualization and some
other things for Java.  We never put this in since it has a huge hack:
the new passes aren't language-neutral and are added at runtime.

Tom

Re: [RFC] Migrate pointers to members to the middle end

[Tom Tromey]

> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:

Ollie> 1.  Is pointer to member migration worthwhile?  Can other languages
Ollie> besides C++ benefit from this?

Not Java.  You might ask Andrea about CLR though.

Ollie> 4.  Is a migration of virtual functions and virtual function tables
Ollie> required?  Are the various language implementations sufficiently
Ollie> similar to be handled by a common infrastructure?

Java has 2 kinds of indirect function call (to be precise, this is the
"C++ ABI".  The binary compatibility ABI is different -- but also
isn't open to this kind of optimization).  Virtual calls are
implemented in a way that is compatible with C++.  Interface calls are
implemented in a different way.

Tom

RE: Bootstrap failure on i386-pc-linux-gnu

[Fu, Chao-Ying]

FX Coudert wrote:

> 
> My automated nightly build failed to bootstrap this evening on i386- 
> pc-linux-gnu. This is for trunk rev. 127311, and the error is:
> 
> > /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ 
> > fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ 
> > gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c   -g - 
> > O2 -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings - 
> > Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - 
> > Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- 
> > macros   -Wno-overlength-strings -Werror- 
> > DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/ 
> > home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/ 
> > gfortran_nightbuild/trunk/gcc/../include -I/home/fx/ 
> > gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/ 
> > gfortran_nightbuild/software/include  -I/home/fx/ 
> > gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/ 
> > gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../ 
> > libdecnumber/home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o  
> > tree.o
> > cc1: warnings being treated as errors
> > /home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function  
> > 'initializer_zerop':
> > /home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing  
> > argument 1 of 'fixed_zerop' discards qualifiers from 
> pointer target  
> > type
> > make[3]: *** [tree.o] Error 1
> > make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ 
> > ibin-20070809/gcc'
> > make[2]: *** [all-stage2-gcc] Error 2
> 
> I filed PR 33031 for this issue.
> 
> Thanks,
> FX
> 

Thanks a lot!  I think this has been fixed by Michael Matz.

2007-08-09  Michael Matz  <[EMAIL PROTECTED]>

* tree.h (fixed_zerop): Declare as taking a const_tree.
* tree.c (fixed_zerop): Take a const_tree.

Regards,
Chao-ying

Re: mips gcc -O1: Address exception error on store doubleword

[Paul Brook]

On Thursday 09 August 2007, Alex Gonzalez wrote:
> Hi,
>
> I'll try to come up with a short test.
>
> I have narrowed it a bit more. The PVAR structure contains a long long
> variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
> take out the long long variable, the compiler uses sdl instructions
> instead of sd and the exception doesn't happen.
>
> Also, if I do
>
> static void varcopy(void *pvar1, void *pvar2)
>
> the compiler uses sdl and avoids the crash.
>
> I am compiling for n32 ABI, so the register size is 64bits.
>
> Any ideas?

This is a bug in whatever calls varcopy. You told the complier that both were 
pointers to 8-byte aligned structures. If you lied, then the compiler is 
eintirely within its rights to generate code that explodes. You need to trace 
the values back to find out where the misalignment is coming from.

Paul

Re: mips gcc -O1: Address exception error on store doubleword

[Alex Gonzalez]

Hi,

I'll try to come up with a short test.

I have narrowed it a bit more. The PVAR structure contains a long long
variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
take out the long long variable, the compiler uses sdl instructions
instead of sd and the exception doesn't happen.

Also, if I do

static void varcopy(void *pvar1, void *pvar2)

the compiler uses sdl and avoids the crash.

I am compiling for n32 ABI, so the register size is 64bits.

Any ideas?

On 8/9/07, David Daney <[EMAIL PROTECTED]> wrote:
> Alex Gonzalez wrote:
> > Hi,
> >
> > I am seeing an address error exception caused by the gcc optimizer -O1.
> >
> > I have narrowed it down to the following function:
> >
> > static void varcopy(PVAR *pvar1, PVAR *pvar2) {
> > memcpy(pvar1,pvar2,sizeof(PVAR));
> > }
> >
> > Being the sizeof(PVAR) 160 bytes.
> >
> > The exception is caused on an sd instruction when the input is not
> > aligned on a doubleword boundary.
> >
> > I was under the assumption that the compiler made sure that it doesn't
> > store a doubleword that is not aligned on a doubleword boundary. Is
> > this a bug in the optimizer?
> >
> > I am using a gcc mips64 cross-compiler,
> >
> > mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001
> >
> > Has anyone experienced this problem before?
> >
> In order to investigate we would need a self contained test case (i.e.
> the definition of PVAR must be included).  Also it would be nice if you
> could try it on a current version of GCC (4.2.1 perhaps).
>
> David Daney
>

Re: mips gcc -O1: Address exception error on store doubleword

[David Daney]

Alex Gonzalez wrote:

Hi,

I am seeing an address error exception caused by the gcc optimizer -O1.

I have narrowed it down to the following function:

static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}

Being the sizeof(PVAR) 160 bytes.

The exception is caused on an sd instruction when the input is not
aligned on a doubleword boundary.

I was under the assumption that the compiler made sure that it doesn't
store a doubleword that is not aligned on a doubleword boundary. Is
this a bug in the optimizer?

I am using a gcc mips64 cross-compiler,

mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001

Has anyone experienced this problem before?
  
In order to investigate we would need a self contained test case (i.e. 
the definition of PVAR must be included).  Also it would be nice if you 
could try it on a current version of GCC (4.2.1 perhaps).


David Daney

Re: mips gcc -O1: Address exception error on store doubleword

[Andreas Schwab]

"Alex Gonzalez" <[EMAIL PROTECTED]> writes:

> I was under the assumption that the compiler made sure that it doesn't
> store a doubleword that is not aligned on a doubleword boundary. Is
> this a bug in the optimizer?

If the pointers are not correctly aligned for their target type then you
are invoking undefined behaviour.  If the aligment of PVAR is at least
doubleword then the compiler may use doubleword accesses for copying.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

mips gcc -O1: Address exception error on store doubleword

[Alex Gonzalez]

Hi,

I am seeing an address error exception caused by the gcc optimizer -O1.

I have narrowed it down to the following function:

static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}

Being the sizeof(PVAR) 160 bytes.

The exception is caused on an sd instruction when the input is not
aligned on a doubleword boundary.

I was under the assumption that the compiler made sure that it doesn't
store a doubleword that is not aligned on a doubleword boundary. Is
this a bug in the optimizer?

I am using a gcc mips64 cross-compiler,

mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001

Has anyone experienced this problem before?

Regards,
Alex

---

For reference,

The resulting code without optimizing is:

81024534 :
varcopy():
81024534:27bdffd0 addiusp,sp,-48
81024538:ffbf0020 sdra,32(sp)
8102453c:ffbe0018 sds8,24(sp)
81024540:ffbc0010 sdgp,16(sp)
81024544:03a0f02d moves8,sp
81024548:3c010009 luiat,0x9
8102454c:242108dc addiuat,at,2268
81024550:0039e02d daddugp,at,t9
81024554:afc4 swa0,0(s8)
81024558:afc50004 swa1,4(s8)
8102455c:8fc4 lwa0,0(s8)
81024560:8fc50004 lwa1,4(s8)
81024564:240600a0 lia2,160
81024568:8f99bd08 lwt9,-17144(gp)
8102456c:0320f809 jalrt9
81024570: nop
81024574:03c0e82d movesp,s8
81024578:dfbf0020 ldra,32(sp)
8102457c:dfbe0018 lds8,24(sp)
81024580:dfbc0010 ldgp,16(sp)
81024584:03e8 jrra
81024588:27bd0030 addiusp,sp,48

While the optimized code is:

8101b9d8 :
varcopy():
8101b9d8:24a200a0 addiuv0,a1,160
8101b9dc: nop
8101b9e0:dca3 ldv1,0(a1)
8101b9e4:dca60008 lda2,8(a1)
8101b9e8:dca70010 lda3,16(a1)
8101b9ec:dca80018 lda4,24(a1)
8101b9f0:fc83 sdv1,0(a0)
8101b9f4:fc860008 sda2,8(a0)
8101b9f8:fc870010 sda3,16(a0)
8101b9fc:fc880018 sda4,24(a0)
8101ba00:24a50020 addiua1,a1,32
8101ba04:14a2fff6 bnea1,v0,8101b9e0 
8101ba08:24840020 addiua0,a0,32
8101ba0c:03e8 jrra
8101ba10: nop
8101ba14: nop

RE: can't bootstrap current trunk on cygwin: tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type

[Dave Korn]

On 09 August 2007 14:39, Christian Joensson wrote:

> cc1: warnings being treated as errors
> ../../gcc/gcc/tree.c: In function 'initializer_zerop':
> ../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop'
> discards qualifiers from pointer target type
> make[3]: *** [tree.o] Error 1
> make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc'
> make[2]: *** [all-stage2-gcc] Error 2
> make[2]: Leaving directory `/usr/local/src/trunk/objdir'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/usr/local/src/trunk/objdir'
> make: *** [bootstrap] Error 2
> 
> 
> Any ideas?

  Yep, see the three other posts we've had about it so far this morning and
maybe give the patch that was in the post just before yours a try


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

can't bootstrap current trunk on cygwin: tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type

[Christian Joensson]

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.24-2   (rev. 1.46 of newlib's stdio.h)
dejagnu  20021217-2 1.4.2.x
expect   20030128-1 5.26
gcc  3.4.4-3
gcc-ada  3.4.4-3
gcc-g++  3.4.4-3
gmp  4.2.1-1
make 3.81-1
mpfr 2.2.1-1
tcltk20060202-1 8.4
w32api   3.10-1

LAST_UPDATED: Thu Aug  9 11:48:38 UTC 2007 (revision 127315)

configure: --disable-nls --without-includ
ed-gettext --enable-version-specific-runtime-libs --without-x
--disable-libgcj --with-system-zlib --enable-threads=posix
--enable-languages=c,c++,fortran,objc,obj-c++,treelang

/usr/local/src/trunk/objdir/./prev-gcc/xgcc
-B/usr/local/src/trunk/objdir/./prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -c   -g -O2 -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common   -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc/gcc/tree.c -o tree.o
cc1: warnings being treated as errors
../../gcc/gcc/tree.c: In function 'initializer_zerop':
../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop'
discards qualifiers from pointer target type
make[3]: *** [tree.o] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [bootstrap] Error 2


Any ideas?

-- 
Cheers,

/ChJ

Re: can't bootstrap current trunk: internal compiler error: in simplify_subreg,@simplify-rtx.c:4679

[Andreas Krebbel]

Hello,

the bootstrap failure you are seeing is caused by my decompose
multiword shift patch:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html

It is the same failure as reported by Andreas Tobler:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00533.html

I don't have access to a sparc machine. Could you please test the
following patch?

The patch at least seems to fix it on a cross gcc.

Bye,

-Andreas-

Index: gcc/lower-subreg.c
===
--- gcc/lower-subreg.c  (revision 127312)
+++ gcc/lower-subreg.c  (working copy)
@@ -1071,7 +1071,7 @@
GET_MODE (SET_DEST (set)),
offset2);
   src_reg = simplify_gen_subreg_concatn (word_mode, op_operand,
- GET_MODE (op_operand),
+ GET_MODE (SET_DEST (set)),
  src_offset);
   if (GET_CODE (op) != ZERO_EXTEND)
 {

RE: ICE on valid code, cse related

[Dave Korn]

On 09 August 2007 13:25, Rask Ingemann Lambertsen wrote:

> On Fri, Aug 03, 2007 at 03:49:32PM +0100, Dave Korn wrote:
>> 
>>   Yes, absolutely so, we already know that there are problems there.  For
>> references, see the threads "Deep CSE bug!"[*] and "Bogus REG_EQUIV note
>> generation"[**] (subject line was wrong, should have been REG_EQUAL all
>> along) from June last year, where we got some way into analysing the
>> problem.  I /think/ that the presence of REG_RETVAL in this particular
>> case is only tangential to the problem; from what I remember of the
>> discussion, this is just about Gcc incorrectly handling reg notes when it
>> decomposes multi-word-size-mode moves into individual word-sized moves.
> 
>All examples so far have had CONST_DOUBLE in the REG_EQUAL note.

  Yes, and?  I don't see what you're getting at here.

>>   Pranav, although there is indeed a bug in the mid-end here, from your
>> point of view the simple and effective workaround should be to implement a
>> movdi pattern (and movsf and movdf if you don't have them yet: it's an
>> absolute requirement to implement movMM for any modes you expect your
>> machine to handle) in the backend.
> 
>If you look at the ia16 back end I posted, you'll notice that it only
> implements movXX for modes of 16 bits or less and AFAIK does not suffer from
> the CSE bug.

  It maybe latent for other reasons, or you may not have triggered it yet, but
I wonder what kind of REG_EQUAL notes do you get when you start passing 32-
(or even 64-) bit values around in 16-bit registers?



cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: ICE on valid code, cse related

[Rask Ingemann Lambertsen]

On Fri, Aug 03, 2007 at 03:49:32PM +0100, Dave Korn wrote:
> 
>   Yes, absolutely so, we already know that there are problems there.  For
> references, see the threads "Deep CSE bug!"[*] and "Bogus REG_EQUIV note
> generation"[**] (subject line was wrong, should have been REG_EQUAL all along)
> from June last year, where we got some way into analysing the problem.  I
> /think/ that the presence of REG_RETVAL in this particular case is only
> tangential to the problem; from what I remember of the discussion, this is
> just about Gcc incorrectly handling reg notes when it decomposes
> multi-word-size-mode moves into individual word-sized moves.

   All examples so far have had CONST_DOUBLE in the REG_EQUAL note.

>   Pranav, although there is indeed a bug in the mid-end here, from your point
> of view the simple and effective workaround should be to implement a movdi
> pattern (and movsf and movdf if you don't have them yet: it's an absolute
> requirement to implement movMM for any modes you expect your machine to
> handle) in the backend.

   If you look at the ia16 back end I posted, you'll notice that it only
implements movXX for modes of 16 bits or less and AFAIK does not suffer from
the CSE bug.

-- 
Rask Ingemann Lambertsen

Fwd: Fixed function compilation order

[Cupertino Miranda]

Here is the answer.

Begin forwarded message:


From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: August 9, 2007 2:31:08 AM CEDT
To: "Cupertino Miranda" <[EMAIL PROTECTED]>
Subject: Re: Fixed function compilation order

On 8/8/07, Cupertino Miranda <[EMAIL PROTECTED]> wrote:


On Aug 9, 2007, at 2:03 AM, Daniel Berlin wrote:


On 8/8/07, Cupertino Miranda <[EMAIL PROTECTED]> wrote:

Hello everyone,

I am currently trying to enable GCC to perform compilation without
having to respect any compilation order, i.e. execute some pass to
any function at any time (it is not only pass reordering).




As what I have seen from (trunk version of) GCC, it doesn't seem an
easy task to be achieved and it might traduce in many complications
later in development.
In that sense I would like to have some opinions and suggestions  
from

you all:



For tree level optimization, this is really not difficult.
For RTL, this is probably going to be really hard.


  - Imagining I am able to change the function context by updating
cfun, etc. Will passes (all_passes) execute without
missing/wrong data, i.e. is all shared data between passes  
accessed/

updated thought pointers such as cfun, etc. ?


What do you mean "missing/wrong" data.


Just as an example, imagine you just executed the pass for the
creation of the CFG and after that, you decided to change context to
another function to perform the same pass.


Let me be clear.  We create CFG/SSA for *all* functions at once right
now, run a bunch of SSA passes, and then run a bunch of passes
per-function.  If you try to do something before this happens, yes,
you will have issues.  The simple answer is "don't do that".
:)

So basically, you can throw your pass in the list of passes and expect
changing functions to work like it does in an IPA pass.

The one datastructure you cannot have stored on multiple functions at
once right now are those related to tree level aliasing.
We are fixing this, but it is not done yet.

Fwd: Fixed function compilation order

[Cupertino Miranda]

Yesterday by mistake I started some private discussion with Daniel.
I will forward his answer too.

Begin forwarded message:


From: Cupertino Miranda <[EMAIL PROTECTED]>
Date: August 9, 2007 2:24:04 AM CEDT
To: Daniel Berlin <[EMAIL PROTECTED]>
Subject: Re: Fixed function compilation order


On Aug 9, 2007, at 2:03 AM, Daniel Berlin wrote:


On 8/8/07, Cupertino Miranda <[EMAIL PROTECTED]> wrote:

Hello everyone,

I am currently trying to enable GCC to perform compilation without
having to respect any compilation order, i.e. execute some pass to
any function at any time (it is not only pass reordering).




As what I have seen from (trunk version of) GCC, it doesn't seem an
easy task to be achieved and it might traduce in many complications
later in development.
In that sense I would like to have some opinions and suggestions  
from

you all:



For tree level optimization, this is really not difficult.
For RTL, this is probably going to be really hard.


  - Imagining I am able to change the function context by updating
cfun, etc. Will passes (all_passes) execute without
missing/wrong data, i.e. is all shared data between passes accessed/
updated thought pointers such as cfun, etc. ?


What do you mean "missing/wrong" data.


Just as an example, imagine you just executed the pass for the  
creation of the CFG and after that, you decided to change context  
to another function to perform the same pass. Will I have to keep  
track of this CFG or it is also available and used (by other  
passes) through the "high level" structures pointed by cfun, etc. ?
The CFG is just an example to possible very small "detail" data- 
structures that might exist in GCC and not such an obvious thing as  
a CFG. ;-)

  - What should I initialise/finalise to be able to perform the
function context change ?


See any IPA pass


I would like to have your opinion and tips on how to approach it and
which problems I might expect to have later.

Thanks in advance,
Cupertino Miranda

can't bootstrap current trunk: internal compiler error: in simplify_subreg, at simplify-rtx.c:4679

[Christian Joensson]

Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u:

binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sparc64
glibc-headers-2.5-3.1.sparc
gmp-2.4.1   (local build from gcc's infrastructure)
mpfr-2.2.1  (local build from gcc's infrastructure)
kernel-2.6.21-1.3149.al3.12.sparc64
libgcc-4.1.1-30.1.sparc
libgcc-4.1.1-30.1.sparc64
libstdc++-4.1.1-30.1.sparc
libstdc++-4.1.1-30.1.sparc64
libstdc++-devel-4.1.1-30.1.sparc
libstdc++-devel-4.1.1-30.1.sparc64
make-3.81-1.1.sparc
tcl-8.4.13-3.al3.sparc

LAST_UPDATED: Thu Aug  9 08:25:16 UTC 2007 (revision 127312)

configure: --enable-__cxa_atexit --enable-shared --with-cpu=v7
--enable-languages=c,c++,fortran,java,objc,obj-c++,treelang
--with-gmp=/usr/local/gmp-mpfr --with-mpfr=/usr/local/gmp-mpfr
--with-long-double-128

/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -g
-fkeep-inline-functions -O2  -O2 -g -O2  -DIN_GCC-W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include
-DHAVE_CC_TLS -o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF
_fixunssfdi.dep -DL_fixunssfdi -c ../../../gcc/libgcc/../gcc/libgcc2.c
\
  -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/../gcc/libgcc2.c: In function '__fixunssfdi':
../../../gcc/libgcc/../gcc/libgcc2.c:1348: internal compiler error: in
simplify_subreg, at simplify-rtx.c:4679

Any ideas? Do you want me to post more info?

-- 
Cheers,

/ChJ

Bootstrap failure on i386-pc-linux-gnu

[FX Coudert]

My automated nightly build failed to bootstrap this evening on i386- 
pc-linux-gnu. This is for trunk rev. 127311, and the error is:


/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ 
fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ 
gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c   -g - 
O2 -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings - 
Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - 
Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- 
macros   -Wno-overlength-strings -Werror- 
DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/ 
home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../include -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/ 
gfortran_nightbuild/software/include  -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../ 
libdecnumber/home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o  
tree.o

cc1: warnings being treated as errors
/home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function  
'initializer_zerop':
/home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing  
argument 1 of 'fixed_zerop' discards qualifiers from pointer target  
type

make[3]: *** [tree.o] Error 1
make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ 
ibin-20070809/gcc'

make[2]: *** [all-stage2-gcc] Error 2


I filed PR 33031 for this issue.

Thanks,
FX

Re: [RFC] Migrate pointers to members to the middle end

[Daniel Berlin]

On 8/8/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > I also haven't necessarily said what Ollie has proposed is a bad idea.
> >  I have simply said the way he has come up with what he proposed is
> > not the way we should go about this.  It may turn out he has come up
> > with exactly the representation we want (though I doubt this, for
> > various reasons).The specification given also doesn't even explain
> > where/how these operations can occur in GIMPLE, and what they do other
> > than "a C++ something something".
> >
> > Also given that someone already wrote a type-based devirtualizer that
> > worked fine, and i don't see how a points-to one is much work, I'd
> > like to see more justification for things like PTRMEM_PLUS_EXPR than
> > "hey, the C++ FE generates this internally".
>
> OK.  It sounds like I need to go into a lot more detail.  The new
> nodes I've proposed aren't actually motivated by the C++ front end,
> but rather by a consideration of the semantics dictated by the C++
> standard.  Naturally, this gives rise to some similarity, but for
> instance, there is no PTRMEM_PLUS_EXPR in the C++ front end, and my
> definition of PTRMEM_CST disagrees with the current node of the same
> name.

Okay, so what exactly does all of the below complexity buy us over
lowering like Michael suggests, given that we can do devirtualization
(which seemed to be the motivating optimiation) without any of this?
We generally only add things to GIMPLE when there is a really
compelling reason.  Other than "it makes us not have to do
optimizations we are not going to stop doing anyway" (IE addition of
constants like you give below).

Certainly, absolutely none of this helps type based devirtualization,
since it wouldn't care about any of the below except PTRMEM_REF.

As the points-to person, I can tell you none of this will give
points-to based devirtualization any benefit over completely lowering
it unless you were to implement flow-sensitive, context-sensitive
points-to (which is at least O(n^6) time, and currently, more than
that space wise).

We would see the lowered form as additions into a constant table, and
figure out the offset into that table, just as you are doing here.

To me, the only benefit is that you expose a higher level concept, but
i don't see any optimization potential except possible value numbering
of PTRMEM_CST nodes, which we get even on the lowered representation.

I'm really not trying to rain on your parade, I just don't see why
it's a win to do this.  I'd be very convinced, however, if there was
something spectacular we could do that we can't do now.  IE if there
are times we will never be able to recover the information, and it
enabled us to do something cool.  I'd also be convinced if there were
tons of passes that could use this info to do something, and it was
non-trivial to reconstruct it (this is why i've always been in favor
of having a point in the compiler were array_ref was allowed on
pointers, or at least, we had the index info for indirect_ref's :P)

Right now, as Mark says, it seems the information is all still there,
even if it is a bit obfuscated, and I don't see why that many things
are going to care about digging it out.

I'd love to hear other opinions on the matter, of course :)



I>
> Let's walk through them:
>
>
> PTRMEM_TYPE
>
> Contains the types of the member (TREE_TYPE) and class
> (TYPE_PTRMEM_BASETYPE) of this pointer to member.  This is hopefully
> self-explanatory.  In the language of the C++ standard, it is the type
> of a "pointer to member of class TYPE_PTRMEM_BASETYPE of type
> TREE_TYPE."  This is the type of PTRMEM_CST's, PTRMEM_PLUS_EXPR's, and
> various variable types (VAR_DECL, FIELD_DECL, PARM_DECL, etc.).
>
>
> PTRMEM_CST
>
> The C++ front end already has a PTRMEM_CST node.  However, the
> existing node only contains a class (PTRMEM_CST_CLASS) and member
> (PTRMEM_CST_MEMBER), and is unable to represent an arbitrary pointer
> to member value.  This is especially evident when dealing with
> multiple inheritance.  Consider the following example:
>
>   struct B { int f (); };
>   struct L : B {};
>   struct R : B {};;
>   struct D : L, R {};
>
>   int (B::*pb)() = &B::f;
>   int (L::*pl)() = pb;
>   int (R::*pr)() = pb;
>   int (D::*pd[2])() = { pl, pr };
>
> In this case, pd[0] and pd[1] both have the same type and point to the
> same member of the same class (B::f), but they point to different base
> class instances of B.  To represent this, we need an offset.  Now, one
> might argue that rather than a numeric offset, we should point to the
> _DECL of the base class subobject, but that breaks down because the
> following is also legal:
>
>   struct B {};
>   struct D : B { int f (); };
>
>   int (D::*pd)() = &D::f;
>   int (B::*pb)() = static_cast(pd);
>
> In this case, pb points to D::f in the derived class.  Since there is
> no subobject to point to, we see that a numeric offset representati