Re: improving testsuite runtime

[Joern Rennecke]

On Fri, Sep 19, 2008 at 04:08:50PM -0700, Janis Johnson wrote:
> Would it work for you to have a check-init target to set up site.exp
> and whatever else might be needed, a check-fini target to wrap up
> the results, and multiple targets that you can invoke separately in
> between those?  A top-level "make check" would do the start-up stuff,
> run lots of check targets in parallel, and then do the wrap-up at the
> end, perhaps after running the resource hogs sequentially.

Yes, that would be fine.

Re: C/C++ FEs: Do we really need three char_type_nodes?

[Steven Bosscher]

On Fri, Sep 19, 2008 at 6:36 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> @@ -7674,12 +7713,8 @@ build_common_tree_nodes (bool signed_cha
>   unsigned_char_type_node = make_unsigned_type (CHAR_TYPE_SIZE);
>   TYPE_STRING_FLAG (unsigned_char_type_node) = 1;
>
> -  /* Define `char', which is like either `signed char' or `unsigned char'
> - but not the same as either.  */
> -  char_type_node
> -= (signed_char
> -   ? make_signed_type (CHAR_TYPE_SIZE)
> -   : make_unsigned_type (CHAR_TYPE_SIZE));
> +  /* Define `char', which is like either `signed char' or `unsigned char'.  
> */
> +  char_type_node = signed_char ? signed_char_type_node :
> unsigned_char_type_node;
>   TYPE_STRING_FLAG (char_type_node) = 1;

Maybe this is a totally stupid idea in the wrong direction - but would
it help to set the TYPE_CANONICAL the same, e.g.:

Index: tree.c
===
--- tree.c  (revision 140524)
+++ tree.c  (working copy)
@@ -7364,8 +7364,8 @@
  but not the same as either.  */
   char_type_node
 = (signed_char
-   ? make_signed_type (CHAR_TYPE_SIZE)
-   : make_unsigned_type (CHAR_TYPE_SIZE));
+   ? build_distinct_type_copy (signed_char_type_node)
+   : build_distinct_type_copy (unsigned_char_type_node));
   TYPE_STRING_FLAG (char_type_node) = 1;

   short_integer_type_node = make_signed_type (SHORT_TYPE_SIZE);

Gr.
Steven

Re: C/C++ FEs: Do we really need three char_type_nodes?

[Steven Bosscher]

On Sun, Sep 21, 2008 at 2:28 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Index: tree.c
> ===
> --- tree.c  (revision 140524)
> +++ tree.c  (working copy)
> @@ -7364,8 +7364,8 @@
>  but not the same as either.  */
>   char_type_node
> = (signed_char
> -   ? make_signed_type (CHAR_TYPE_SIZE)
> -   : make_unsigned_type (CHAR_TYPE_SIZE));
> +   ? build_distinct_type_copy (signed_char_type_node)
> +   : build_distinct_type_copy (unsigned_char_type_node));

*sigh* Wrong patch.

Index: tree.c
===
--- tree.c  (revision 140524)
+++ tree.c  (working copy)
@@ -7362,10 +7362,16 @@

   /* Define `char', which is like either `signed char' or `unsigned char'
  but not the same as either.  */
-  char_type_node
-= (signed_char
-   ? make_signed_type (CHAR_TYPE_SIZE)
-   : make_unsigned_type (CHAR_TYPE_SIZE));
+  if (signed_char)
+{
+  char_type_node = make_signed_type (CHAR_TYPE_SISE);
+  TYPE_CANONICAL (char_type_node) = signed_char_type_node;
+}
+  else
+{
+  char_type_node = make_unsigned_type (CHAR_TYPE_SISE);
+  TYPE_CANONICAL (char_type_node) = unsigned_char_type_node;
+}
   TYPE_STRING_FLAG (char_type_node) = 1;

   short_integer_type_node = make_signed_type (SHORT_TYPE_SIZE);

Re: Adding to G++: Adding a warning on throwing unspecified exceptions.

[Brian Dessent]

Simon Hill wrote:

> http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
> horrified to see it's not written in C++, and it's loaded with macros
> --- why??).

You seem to refer to g++ as if it's a separate program from gcc but it's
really not.  All of the middle- and back-end code is shared between the
language front-ends, so if you introduce C++ there you now require a
pre-existing C++ bootstrap compiler even for people that have no
interest or need for C++ language support and are only building a C (or
Fortran or Java or Ada) compiler.  A lot of people have a problem with
that because some systems may not have or even want anything more than a
C compiler.

You could of course limit use of C++ to the C++ frontend, similar to how
the Ada frontend is written in Ada.  But I don't think that would do
much to alleviate the issue that you're complaining about because it
would still have to use all the same macros to represent trees and types
and so on to the language independent parts of the compiler.

Nevertheless it's a topic that keeps coming up and there are a number of
people that would like the advantages of better compile time type
checking and so on.  This debate always rages on because there is
constant fear that it will open the door for the more exotic and
unmaintainable C++ features to sneak in, in addition to the higher
bootstrap requirements.  At the moment there is slow progress in getting
things to the point where gcc can at least be built with a C++
compiler.  See also the gcc-in-cxx branch.

> What I'd like to add is something that I've seen many people request,
> and something I really want to use:
> Adding a -W option to check that all function calls and throws comply
> with the throw() clause of the function they are launched from.

You really ought to read the past threads on this topic, for example:






The general consensus is that doing this at compile time cannot give you
anything useful, because the compiler can only see one compilation unit
at a time and so the only thing it can know of all the downstream
functions that are in other CUs is what is provided in the exception
specifiers of the prototypes.  You're essentially trusting that all
exception specifiers for every function in the program and *all* library
code are always present and always correct which is a huge leap of faith
that I don't think is supported by reality.  For example the Boost
rationale basically says they are unusable in practical code except in
special cases:
.

> 1) Is my task a sensible one? Is there anything I have got fundamentally 
> wrong?
> 2) Is there anyone currently doing this? I'd hate to simply duplicate
> their effort.

You should certainly look at EDoc++, mentioned in the above threads.

> I can't find much readable documentation about the source. Does anyone
> have any good documentation links about the overall program flow
> through g++, files/functions etc? I need a primer.

Don't neglect the wiki: 

> 7) To someone new to the g++ source the included documentation seems
> pretty poor and cryptic. README mentions non-existant files,
> INSTALL/README says it's obsolete and redirects to a file "index.html"
> which doesn't yet exist. And why does the documentation have all these
> .texi, .info and (unlinked) manpage .1/.7 files. What's wrong with
> .txt, .html or similar? Shouldn't documentation be available from the
> download instead of having to go online to actually find out how to
> build and read the documentation itself - the documentation doesn't
> really take up much space. In this age do manpages actually have any
> advantages?

The documentation's canonical form is texinfo, i.e. gcc/doc/*.texi. 
Everything else (HTML, PDF, DVI, .info, manpages) is auto-generated from
the texinfo, e.g. "make html", "make pdf", etc.  Whether the generated
files are in your tree depends on whether you're working from a SVN
checkout or a release tarball, but the texinfo sources are always there.

Brian

Pmode != INT (e.g., SImode)

[Michael Eager]

I'm working with a target which has address registers
which are shorter than an integer.  Pmode is defined as
PSImode, not SImode.  There are a limited number of operations
on the address registers, including pre/post-increment/decrement,
but not generalized arithmetic.

I'm running into a number of problems.  Instruction costs
used in loops-ivopts are wildly inflated so loop invariants
are not recognized and it looks like combine doesn't recognize
that it can combine a memory access with an increment into a
single instruction, possibly because of mode differences.

Are there any architectures which have Pmode != INT?

Is this the right way to describe this kind of architecture?

There's a comment in the m32r description:
   The M32R doesn't have full 32 bit pointers, but making this PSImode has
   its own problems (you have to add extendpsisi2 and truncsipsi2).
   Try to avoid it.


--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Adding to G++: Adding a warning on throwing unspecified exceptions.

[NightStrike]

On Sun, Sep 21, 2008 at 12:36 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Simon Hill wrote:
>
>> http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
>> horrified to see it's not written in C++, and it's loaded with macros
>> --- why??).
>
> You seem to refer to g++ as if it's a separate program from gcc but it's
> really not.  All of the middle- and back-end code is shared between the
> language front-ends, so if you introduce C++ there you now require a
> pre-existing C++ bootstrap compiler even for people that have no
> interest or need for C++ language support and are only building a C (or
> Fortran or Java or Ada) compiler.  A lot of people have a problem with

I think java requires c++.

Re: Adding to G++: Adding a warning on throwing unspecified exceptions.

[Kaveh R. GHAZI]

On Sun, 21 Sep 2008, NightStrike wrote:

> On Sun, Sep 21, 2008 at 12:36 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> > Simon Hill wrote:
> >
> >> http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
> >> horrified to see it's not written in C++, and it's loaded with macros
> >> --- why??).
> >
> > You seem to refer to g++ as if it's a separate program from gcc but it's
> > really not.  All of the middle- and back-end code is shared between the
> > language front-ends, so if you introduce C++ there you now require a
> > pre-existing C++ bootstrap compiler even for people that have no
> > interest or need for C++ language support and are only building a C (or
> > Fortran or Java or Ada) compiler.  A lot of people have a problem with
>
> I think java requires c++.

It does, but only to build the target libraries, not to bootstrap.  It
uses the just-built G++ to do that.

Ada is the only frontend right now where you need a pre-existing compiler
other than C to *bootstrap* it.

Re: no symbol in current context problem when debug the program in gdb

[Daniel Jacobowitz]

On Sat, Sep 20, 2008 at 03:55:00PM +0200, Kai Henningsen wrote:
> Isn't this a case of the stuff that the
> var-tracking-assignments-branch
> (http://gcc.gnu.org/wiki/Var_Tracking_Assignments) tries to fix?

No, it was specific to cloned functions.  Some cgraph bug, I don't
remember the PR.

-- 
Daniel Jacobowitz
CodeSourcery

Re: C/C++ FEs: Do we really need three char_type_nodes?

[Daniel Jacobowitz]

On Sat, Sep 20, 2008 at 11:46:48AM -0400, Diego Novillo wrote:
> This is not really possible because when lto1 runs, it needs to have a
> unique version of char_type_node and the multiple .o files will
> potentially have different versions of it.  In essence, char_type_node
> needs not exist in GIMPLE or we have to standardize it to either
> signed_char_type_node or unsigned_char_type_node.
> 
> So, when we go into GIMPLE, all the instances of char_type_node need
> to be converted into unsigned_char_type_node or signed_char_type_node.
>  This way different CUs can have different notions of char signedness
> explicitly outlined in the IL.

This seems like it would be fraught with pitfalls; maybe it would be
easier to have the streamed char_type_node indicate its signedness?

- Has the story for debug info been figured out yet?  Char is not
signed char to GDB.

- What about binding to templates or overloaded functions?

-- 
Daniel Jacobowitz
CodeSourcery

gcc-4.4-20080919 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 140502

You'll find:

gcc-4.4-20080919.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20080919.tar.bz2 C front end and core compiler

gcc-ada-4.4-20080919.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20080919.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20080919.tar.bz2  C++ front end and runtime

gcc-java-4.4-20080919.tar.bz2 Java front end and runtime

gcc-objc-4.4-20080919.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20080919.tar.bz2The GCC testsuite

Diffs from 4.4-20080912 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

FAIL: gcc.target/mips/octeon-exts-2.c scan-assembler-times

[David Daney]

Adam,

As shown here:

http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01775.html

gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1

Do you know if it is failing universally or only on non-octeon targets?

David Daney

FAIL: gcc.target/mips/octeon-exts-2.c scan-assembler-times

[David Daney]

Adam,

As shown here:

http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01775.html

gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1

Do you know if it is failing universally or only on non-octeon targets?

David Daney

Re: C/C++ FEs: Do we really need three char_type_nodes?

[Mark Mitchell]

Steven Bosscher wrote:

> +  if (signed_char)
> +{
> +  char_type_node = make_signed_type (CHAR_TYPE_SISE);
> +  TYPE_CANONICAL (char_type_node) = signed_char_type_node;
> +}

I don't think this is a good idea.  TYPE_CANONICAL is used for
type-comparison at the language level, and "char" and "signed char" are
different types -- even when "char" is signed.

For example:

   char* q;
   signed char *p = q;

is not valid without a cast.

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