headers
Joe Buck | 1 Oct 2002 01:02

Re: Snapshots of gcc-3.2.1 also available?


> I noticed the tarballs in the ftp://gcc.gnu.org/pub/gcc/snapshots/ directory
> are snapshots of the 3.3-tree.
> 
> But I'm looking for a snapshot of the upcoming gcc-3.2.1, as it is a big
> difference wheter to use a snapshot of a bugfix-release or an all-new version
> ;-)

Are you prevented from using CVS by a firewall?  If not, you can get the
current state of the 3.2-branch (what will become gcc-3.2.1) by anonymous
CVS.  Follow the instructions on

	http://gcc.gnu.org/cvs.html

except that where it says

	cvs -z 9 co gcc

do

	cvs -z 9 co -rgcc-3_2-branch gcc

instead.
Permalink | Reply | 0 comments |
headers
Joe Buck | 1 Oct 2002 01:06

Re: Release schedule

Steven Bosscher wrote:
> FWIW I am all *against* freezing dev branches. GCC developers are
> volunteers, and taking away their fun projects is a bad thing.
> 
> Still I also think there are too many development projects right now, and I
> also believe that it would be good to plan when these major improvements
> should be finished, no matter how hard that may be in a project that depends
> on the time of volunteers.

I think it's reasonable to *request* folks working on fun projects to
consider turning their attention back to trying to stabilize the release
at critical times in the development cycle, but that it's fruitless to try
to bludgeon them into doing so.
Permalink | Reply | 1 comment |
headers
gccadmin | 1 Oct 2002 02:49
Picon
Favicon

gcc-ss-20020930 is now available

gcc-ss-20020930 is now available on 
  ftp://gcc.gnu.org/pub/gcc/snapshots/2002-09-30
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC CVS HEAD.

You'll find:

  gcc-20020930.tar.gz                  The full gcc snapshot, including all
                                       languages runtime libraries.

  gcc-core-20020930.tar.gz             Just the C front end and core compiler.

  gcc-testsuite-20020930.tar.gz        The GCC testsuite.

  gcc-ada-20020930.tar.gz              The Ada language and runtime.

  gcc-g++-20020930.tar.gz              The g++ language and runtime.

  gcc-g77-20020930.tar.gz              The g77 language and runtime.

  gcc-objc-20020930.tar.gz             The Objective-C front end and runtime.

  gcc-java-20020930.tar.gz             The Java front end.

Diffs from 20020923 are available.

Note at times you may find newer directories on the server with limited
permissions.  These represent snapshots that have not yet been verified
as correct, or are known to be incorrect.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandre Oliva | 1 Oct 2002 05:04
Picon
Favicon

Re: module level flags

On Sep 29, 2002, Bruce Korb <bkorb <at> pacbell.net> wrote:

> In this case, the issue is that the aliasing analysis is incomplete.
> If a routine contains explicit code to cast the address of an object
> of type 'a' to pointers to type b, then in the context of that
> routine it is reasonable to presume a '*b' can refer an object 'a'.
> They are equivalent.

Now what if you factor the code that uses *b into a separate function?
All of a sudden, the code stops working because within that separate
function it is not known that *b may alias an object of type stumble?

Now you try to fix this, and you end up either giving up any possible
optimization that the aliasing rules were designed to offer, or
something that is not uniformly consistent, or you choose the behavior
that may seem wrong if you don't take the aliasing rules into account.

--

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva <at> {redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva <at> {lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer
Permalink | Reply | 14 comments |
headers
Bruce Korb | 1 Oct 2002 05:54

Re: module level flags

Alexandre Oliva wrote:
> 
> On Sep 29, 2002, Bruce Korb <bkorb <at> pacbell.net> wrote:
> 
> > In this case, the issue is that the aliasing analysis is incomplete.
> > If a routine contains explicit code to cast the address of an object
> > of type 'a' to pointers to type b, then in the context of that
> > routine it is reasonable to presume a '*b' can refer an object 'a'.
> > They are equivalent.
> 
> Now what if you factor the code that uses *b into a separate function?

You have that problem with "void*" aliasing or any other kind of
aliasing.  Some you are required to guard against (assume aliasing),
some not.  My claim is that ANSI ought to have considered intptr_t
as being potentially aliased by arbitrary pointers, _exactly_ the
same way void* values are treated.  And, my argument went on, if
you aren't going to support "obvious" cases such as this, then you
should support hard errors on obvious cases.  It is clear you cannot
warn about all potential cases.

> All of a sudden, the code stops working because within that separate
> function it is not known that *b may alias an object of type stumble?

So, to protect users from this catastrophe, you silently destroy
the efficacy of a pointer causing their programs to head south
without a discernible error or even a warning.  Phooey.  It is true
you can stretch stuff into improbable cases whereby you cannot
effectively warn; you cannot detect the aliasing; and you wind up
with a bug.  That's not a sufficient excuse for throwing up your
(Continue reading)

Permalink | Reply | 13 comments |
headers
George H | 1 Oct 2002 06:33
Picon
Favicon

memrefs_conflict_p () for REGs in alias.c

While looking at the following piece of code, in
memrefs_conflict_p () in alias.c
   if (GET_CODE (x) == GET_CODE (y))
    switch (GET_CODE (x)) 
    { 
           ......          

       case REG:
           if (alias_invariant)
           {
               .....
           }
           break;
     }
     ....
     return 1;

I found that it always returns 1 for cse in case of
REG, as the alias_invariant array is NULL. The
alias_invariant is being set in loop unrolling pass
which happens much later than cse.  Thus, in cse we
always assume that the two regs always conflict. This
seems to be too pessimistic as there may be cases
where the addresses contained in two regs may be
different. Can we add some intelligence in the
compiler here?

-gh

__________________________________________________
(Continue reading)

Permalink | Reply | 4 comments |
headers
David S. Miller | 1 Oct 2002 06:35
Picon
Favicon

Re: memrefs_conflict_p () for REGs in alias.c


Remove the "flag_unroll_loops" test in init_alias_analysis() and
see what happens.
Permalink | Reply | 1 comment |
headers
George H | 1 Oct 2002 07:03
Picon
Favicon

Re: memrefs_conflict_p () for REGs in alias.c


--- "David S. Miller" <davem <at> redhat.com> wrote:
> 
> Remove the "flag_unroll_loops" test in
> init_alias_analysis() and
> see what happens.
Ya, I just saw that. that is as good as you specify
-funroll-loop option. it only allocates the memory for
alias_invariant array, but there is no meaningful
information in alias_invariant for cse.

-gh

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Permalink | Reply | 0 comments |
headers
Brad Lucier | 1 Oct 2002 07:12
Picon
Favicon

No bootstraps for mainline on sparc[v9]-sun-solaris2.8

With this configure and build command

#/bin/tcsh
/bin/rm -rf * ; ../configure --prefix=/home/c/lucier/local/gcc-test ; make -j 4 STAGE1_CFLAGS='-O2
-g' bootstrap > & build.log && ( make -j 4 -k check > & check.log ; make mail-report-with-warnings.log ;
./mail-report-with-warnings.log )

bootstrap fails on sparc-sun-solaris2.8 with

/export/u3/lucier/programs/gcc/gcc-3.3/objdir/gcc/xgcc -shared-libgcc
-B/export/u3/lucier/programs/gcc/gcc-3.3/objdir/gcc/ -nostdinc++
-L/export/u3/lucier/programs/gcc/gcc-3.3/objdir/sparc-sun-solaris2.8/libstdc++-v3/src
-L/export/u3/lucier/programs/gcc/gcc-3.3/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs
-B/home/c/lucier/local/gcc-test/sparc-sun-solaris2.8/bin/
-B/home/c/lucier/local/gcc-test/sparc-sun-solaris2.8/lib/ -isystem
/home/c/lucier/local/gcc-test/sparc-sun-solaris2.8/include -nostdinc++
-I/export/u3/lucier/programs/gcc/gcc-3.3/objdir/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8
-I/export/u3/lucier/programs/gcc/gcc-3.3/objdir/sparc-sun-solaris2.8/libstdc++-v3/include
-I../../../../libstdc++-v3/libsupc++ -I../../../../libstdc++-v3/libmath -g -O2
-fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c
../../../../libstdc++-v3/src/localename.cc  -fPIC -DPIC!

 -o .libs/localename.o
../../../../libstdc++-v3/src/localename.cc: In member function `void 
   std::locale::_Impl::_M_replace_categories(const std::locale::_Impl*, 
   unsigned int)':
../../../../libstdc++-v3/src/localename.cc:219: internal compiler error: in 
   int_mode_for_mode, at stor-layout.c:292
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lorenzo Delana | 1 Oct 2002 09:19
Picon
Favicon

Re: -fdump-translation-unit-xml ( patch )


Here is the patch to let a gcc switch `-fdump-translation-unit-xml' to dump 
the .tu file containing an xml like this produced:

~ $ ~/cc1plus -fdump-translation-unit-xml simple.cxx
 X::A<T>::A() virtual X::A<T>::~A() int X::A<T>::fn(int) int X::A<T>::fn(int, 
int)Opening simple.cxx for phase 1 suffix = .class
Opening simple.cxx for phase 0 suffix = .tu
Opened simple.cxx for phase 0

Execution times (seconds)
 varconst              :   0.02 (67%) usr   0.00 ( 0%) sys   0.02 (67%) wall
 TOTAL                 :   0.03             0.00             0.03
~ $ head -n 20 simple.cxx.tu
<?xml version='1.0'?>
<!DOCTYPE GXXTranslationUnit SYSTEM "GXXTranslationUnit.dtd">
<GXXTranslationUnit>

 <node index="1" codename="namespace_decl">
  <field type="_c_" name="name" value="2"/>
  <field type="_s_" name="srcp" value="&lt;internal&gt;:0"/>
  <field type="_c_" name="dcls" value="3"/>
 </node>

 <node index="2" codename="identifier_node">
  <field type="_s_" name="strg" value="::"/>
  <field type="_i_" name="lngt" value="2"/>
 </node>

 <node index="3" codename="namespace_decl">
(Continue reading)

Permalink | Reply | 0 comments |

Gmane