Re: testsuite for libgomp and so on...

[Ben Elliston]

On Fri, 2007-09-28 at 12:54 +0800, Zhang Xiaoping wrote:

>There are testsuites for libgomp and libmudflap, but there
> isn't any  testsuite for libcpp, libdecnumber, libiberty, and libssp.

There is a testsuite for libiberty, but it is small.  It mainly tests
the C++ demangler.

There is a testsuite for libdecnumber, too -- it's called "decTest".  It
has some 34,000 tests and takes a long time to run.  We run this via the
GCC testsuite (dectest.exp), but it is disabled by default because it
adds so much time to a typical testsuite run.  I run it manually from
time to time to spot any failures.

libcpp has a testsuite of sorts, GCC's testsuite. ;-)

Cheers, Ben

testsuite for libgomp and so on...

[Zhang Xiaoping]

Hi,

   There are testsuites for libgomp and libmudflap, but there
isn't any  testsuite for libcpp, libdecnumber, libiberty, and libssp.

  I downloads gcc-core-4-2-1 and testsuite. Only test results of
gcc/libgomp/libmudflap had been generated.

  Thanks :)

GCC 4.2.2 RC2 (finally)

[Mark Mitchell]

I'm finally spinning GCC 4.2.2 RC2.

Please do not make any further check-ins to the GCC 4.2 branch, even
those that have been previously approved, without my explicit approval.

I apologize to everyone for the delay in bringing out GCC 4.2.2.

Thanks,

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

Re: Question on GGC

[吴曦]

Sorry, I found it in gccint, thanks :-)

2007/9/28, 吴曦 <[EMAIL PROTECTED]>:
> 2007/9/27, Zdenek Dvorak <[EMAIL PROTECTED]>:
> > Hello,
> >
> > > I have several global variables which are of type rtx. They are used
> > > in flow.c ia64.c and final.c. As stated in the internal doc with
> > > types. I add GTY(()) marker after the keyword 'extern'. for example:
> > >  extern GTY(()) rtx a;
> > > these 'extern's are added in regs.h which is included in flow.c ia64.c
> > > and final.c
> > >
> > > However, I init 'a' at ia64_compute_frame which is defined in ia64.c
> > > but found 'a' incorrectly collected by ggc_collect. (I watch the
> > > memory location which is allocated for a, and found it is collected by
> > > GGC.
> > >
> > > Is there any thing I forget to do ?
> >
> > you need to add regs.h to GTFILES in Makefile.in.
> >
> > Zdenek
> >
> Thanks. I found GCC generate the file gtype-desc.c to handle these
> definitions, But how does GCC find the corresponded definition for
> 'extern GTY(()) rtx a' ? Once I want to define the variable in a new
> file or extern this variable in a new header file, it will throw the
> error that 'the initializer is not constant' (I think the error is due
> to GCC can not correlate the 'extern' and 'definition'). Would you
> give more details on this problem, especially if want to define and
> extern this variable in new files.
>

Re: Question on GGC

[吴曦]

2007/9/27, Zdenek Dvorak <[EMAIL PROTECTED]>:
> Hello,
>
> > I have several global variables which are of type rtx. They are used
> > in flow.c ia64.c and final.c. As stated in the internal doc with
> > types. I add GTY(()) marker after the keyword 'extern'. for example:
> >  extern GTY(()) rtx a;
> > these 'extern's are added in regs.h which is included in flow.c ia64.c
> > and final.c
> >
> > However, I init 'a' at ia64_compute_frame which is defined in ia64.c
> > but found 'a' incorrectly collected by ggc_collect. (I watch the
> > memory location which is allocated for a, and found it is collected by
> > GGC.
> >
> > Is there any thing I forget to do ?
>
> you need to add regs.h to GTFILES in Makefile.in.
>
> Zdenek
>
Thanks. I found GCC generate the file gtype-desc.c to handle these
definitions, But how does GCC find the corresponded definition for
'extern GTY(()) rtx a' ? Once I want to define the variable in a new
file or extern this variable in a new header file, it will throw the
error that 'the initializer is not constant' (I think the error is due
to GCC can not correlate the 'extern' and 'definition'). Would you
give more details on this problem, especially if want to define and
extern this variable in new files.

context-sensitive keywords, revisited

[Ben Elliston]

I would like to raise the idea of implementing a new patch for
context-sensitive keywords for Altivec support in GCC.  This thread from
late 2003 discusses a way forward for various Altivec features, much of
which has been thrashed out:

   http://gcc.gnu.org/ml/gcc/2003-12/msg01440.html

There were two degrees of opposition to context-sensitive keywords:

  (1) outright opposition to it in principle;
  (2) agreement in principle, but conditional on a 
  clean and simple implementation

Geoff Keating wrote back then:

  "Item (2), the context-sensitive vector keyword, as a
   standalone patch, as simple and clean as possible, and
   including clear and precise documentation on exactly when
   'vector' gets treated as a keyword.  This patch might be
   integrated into the mainline, if it's sufficiently clean; if
   not, it can go into contrib/ and Apple will keep it as a
   local patch."

I would like to ask the relevant maintainers if such a patch,
sufficiently well written, would be accepted into GCC during the next
stage 1 period?  If so, are there any preferred approaches to the
implementation?  I gather that the conditional macro technique was not
very popular.

Thanks, Ben

-- 
Ben Elliston <[EMAIL PROTECTED]>
Australia Development Lab, IBM

Re: missing optimization - don't compute return value not used?

[Joe Buck]

On Thu, Sep 27, 2007 at 01:17:58PM -0500, Aaron W. LaFramboise wrote:
> I think the biggest problem here is that GCC will not elide calls to the 
> allocator.  This is a subject of some controversy--even though its 
> probably difficult to do such optimization anyway.  It's not quite clear 
> that such optimization is legal under the as-if rule.

> For example, the code you have written will throw std::bad_alloc if your 
> system is out of memory.  The code that you would like it to be 
> optimized to would not do that, which is a behavior change.

The problem with such an argument is that the standard does not say
anything about how much memory you have.  Also, since eliding a copy
constructor will, in general, reduce the number of calls to operator new,
we are already doing optimizations that might eliminate a bad_alloc
throw.  Of course, eliding copy constructors (even if there are side
effects) is explicitly blessed by the standard.

Considering memory allocation inside a constructor as a side effect
that must be preserved has some interesting and not-very-desirable
effects.  Consider

int foo1() {
std::vector unused_v(5);
return 1;
}

int foo2() {
int unused_a[5];
return 1;
}

gcc -Wall will issue a warning about foo2, but not about foo1.
That's because the constructor "does something" to unused_v.

Now, there are some cases where we really do construct an object
just for its side effect, particularly with the "resource allocation
by initialization" pattern.

But it would be cool if there were a way to mark a class somehow
to indicate that it works like a value, meaning that it can be
optimized as such, and that a warning would be appreciated if it
is unused after construction.

Re: missing optimization - don't compute return value not used?

[Aaron W. LaFramboise]

Richard Li wrote:


Right, page 211 of the C++ standard (2003) explains when copy-ctor and
dtor are allowed to be optimized away. But the two circumstances are
both like this:
A is constructed; A is copy-constructed to B; A is destructed
Here A is a temporary object in some sense, and the standard allows
for directly constructing B.
However, Neal expected the compiler to optimize "A is constructed; A
is destructed" away. I find nowhere in the standard that allows this.


I think it would fall under the "as-if" rule.  The special rules you 
mention are only necessary if it causes a behavior change.


I think the biggest problem here is that GCC will not elide calls to the 
allocator.  This is a subject of some controversy--even though its 
probably difficult to do such optimization anyway.  It's not quite clear 
that such optimization is legal under the as-if rule.


For example, the code you have written will throw std::bad_alloc if your 
system is out of memory.  The code that you would like it to be 
optimized to would not do that, which is a behavior change.


This has been discussed a few times before.  See, for example, this 
thread .


So, you should probably never count on an optimizer removing calls to 
anything that touches memory management.  What's usually done, as 
Richard Li points out, is to write your code in such a way that such 
optimization is not necessary.

LLVM 2.1 Release

[Chris Lattner]

Hi All,

If you're interested, LLVM 2.1 was recently released.  You can read  
about it here:


http://llvm.org/releases/2.1/docs/ReleaseNotes.html#whatsnew
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2007-September/ 
24.html


... and get it here:
http://llvm.org/releases/download.html#2.1

-Chris

http://nondot.org/sabre/
http://llvm.org/

Profile information - CFG

[Hariharan Sandanagobalane]

Hello,
I am implementing support for PBO on picochip port of GCC (not yet 
submitted to mainline).


I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the 
profile information, the former containing the flow graph 
information(compile-time) and later containing the edge profile 
information(run-time). The CFG information seems to be getting emitted 
quite early in the compilation process(pass_tree_profile). Is the 
instrumentation also done at this time? If it is, as later phases change 
CFG, how is the instrumentation code sanity maintained? If it isnt, How 
would you correlate the CFG in gcno file to the actual CFG at 
execution(that produces the gcda file)?


As for our port's case, we are already able to generate profile 
information using our simulator/hardware, and it is not-too-difficult 
for me to format that information into .gcno and .gcda files. But, i 
guess the CFG that i would have at runtime would be quite different from 
the CFG at initial phases of compilation (even at same optimization 
level). Any suggestions on this? Would i be better off keeping the gcno 
file that GCC generates, try to match the runtime-CFG to the one on the 
gcno file and then write gcda file accordingly?


Has anyone tried inserting profile information from outside of the GCC 
instrumentation back into the compiler? Could you please let me know how 
you handled this?


In general, does anyone have any numbers on the performance improvements 
that PBO brings in for GCC?


Thanks in advance.

Regards
Hari

Re: Question on GGC

[Zdenek Dvorak]

Hello,

> I have several global variables which are of type rtx. They are used
> in flow.c ia64.c and final.c. As stated in the internal doc with
> types. I add GTY(()) marker after the keyword 'extern'. for example:
>  extern GTY(()) rtx a;
> these 'extern's are added in regs.h which is included in flow.c ia64.c
> and final.c
> 
> However, I init 'a' at ia64_compute_frame which is defined in ia64.c
> but found 'a' incorrectly collected by ggc_collect. (I watch the
> memory location which is allocated for a, and found it is collected by
> GGC.
> 
> Is there any thing I forget to do ?

you need to add regs.h to GTFILES in Makefile.in.

Zdenek

Question on GGC

[吴曦]

Hi.
I have several global variables which are of type rtx. They are used
in flow.c ia64.c and final.c. As stated in the internal doc with
types. I add GTY(()) marker after the keyword 'extern'. for example:
 extern GTY(()) rtx a;
these 'extern's are added in regs.h which is included in flow.c ia64.c
and final.c

However, I init 'a' at ia64_compute_frame which is defined in ia64.c
but found 'a' incorrectly collected by ggc_collect. (I watch the
memory location which is allocated for a, and found it is collected by
GGC.

Is there any thing I forget to do ?

Any help is truly appreciated

Thanks :-)

Re: $RANLIB not passed to libiberty

[Paolo Bonzini]

Rask Ingemann Lambertsen wrote:

   I'm having a look at building GCC with OpenWatcom to reduce build
times. There seems to be something wrong with the build machinery:


Can you try this patch? RANLIB_FOR_BUILD was defined nowhere, hence it 
was passed as empty to configure and detected (incorrectly) to be 
"ranlib" instead of "owranlib".


This dates back more or less to the dawn of time^Whaving a separate 
directory for build-side libraries 
(http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01576.html).  This evolved 
into more complete support over time (including e.g. building 
flex/bison/texinfo that can be used when building other tools, which in 
turn evolved into toplevel fixincludes), but this bit was always missing.


(It might even be that it worked with Cygnus configure, and stopped 
working after autoconfiscation).


If it works, feel free to apply it.

Paolo
2007-09-27  Paolo Bonzini  <[EMAIL PROTECTED]>

* Makefile.tpl (AR_FOR_BUILD, AS_FOR_BUILD, CXX_FOR_BUILD,
DLLTOOL_FOR_BUILD, GCJ_FOR_BUILD, GFORTRAN_FOR_BUILD,
LDFLAGS_FOR_BUILD, LD_FOR_BUILD, NM_FOR_BUILD, RANLIB_FOR_BUILD,
WINDMC_FOR_BUILD, WINDRES_FOR_BUILD): Use autoconf substitutions.
* configure.ac: Default them to host tools for $host = $build.
Subst them.

* configure: Regenerate.
* Makefile.in: Regenerate.

Index: Makefile.tpl
===
--- Makefile.tpl(revision 127728)
+++ Makefile.tpl(working copy)
@@ -251,10 +251,21 @@ PWD_COMMAND = $${PWDCMD-pwd}
 
 # compilers to use to create programs which must be run in the build
 # environment.
+AR_FOR_BUILD = @AR_FOR_BUILD@
+AS_FOR_BUILD = @AS_FOR_BUILD@
 CC_FOR_BUILD = @CC_FOR_BUILD@
 CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
-
-CXX_FOR_BUILD = $(CXX)
+CXXFLAGS_FOR_BUILD = @CXXFLAGS_FOR_BUILD@
+CXX_FOR_BUILD = @CXX_FOR_BUILD@
+DLLTOOL_FOR_BUILD = @DLLTOOL_FOR_BUILD@
+GCJ_FOR_BUILD = @GCJ_FOR_BUILD@
+GFORTRAN_FOR_BUILD = @GFORTRAN_FOR_BUILD@
+LDFLAGS_FOR_BUILD = @LDFLAGS_FOR_BUILD@
+LD_FOR_BUILD = @LD_FOR_BUILD@
+NM_FOR_BUILD = @NM_FOR_BUILD@
+RANLIB_FOR_BUILD = @RANLIB_FOR_BUILD@
+WINDMC_FOR_BUILD = @WINDMC_FOR_BUILD@
+WINDRES_FOR_BUILD = @WINDRES_FOR_BUILD@
 
 # Special variables passed down in EXTRA_GCC_FLAGS.  They are defined
 # here so that they can be overridden by Makefile fragments.
Index: configure.ac
===
--- configure.ac(revision 127728)
+++ configure.ac(working copy)
@@ -1047,9 +1047,31 @@ if test -z "${CC}" && test "${build}" = 
 fi
 
 if test "${build}" != "${host}" ; then
+  AR_FOR_BUILD=${AR_FOR_BUILD-ar}
+  AS_FOR_BUILD=${AS_FOR_BUILD-as}
   CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
+  CXX_FOR_BUILD=${CXX_FOR_BUILD-g++}
+  GCJ_FOR_BUILD=${GCJ_FOR_BUILD-gcj}
+  GFORTRAN_FOR_BUILD=${GFORTRAN_FOR_BUILD-gfortran}
+  DLLTOOL_FOR_BUILD=${DLLTOOL_FOR_BUILD-dlltool}
+  LD_FOR_BUILD=${LD_FOR_BUILD-ld}
+  NM_FOR_BUILD=${NM_FOR_BUILD-nm}
+  RANLIB_FOR_BUILD=${RANLIB_FOR_BUILD-ranlib}
+  WINDRES_FOR_BUILD=${WINDRES_FOR_BUILD-windres
+  WINDMC_FOR_BUILD=${WINDMC_FOR_BUILD-windmc
 else
+  AR_FOR_BUILD="\$(AR)"
+  AS_FOR_BUILD="\$(AS)"
   CC_FOR_BUILD="\$(CC)"
+  CXX_FOR_BUILD="\$(CXX)"
+  GCJ_FOR_BUILD="\$(GCJ)"
+  GFORTRAN_FOR_BUILD="\$(GFORTRAN)"
+  DLLTOOL_FOR_BUILD="\$(DLLTOOL)"
+  LD_FOR_BUILD="\$(LD)"
+  NM_FOR_BUILD="\$(NM)"
+  RANLIB_FOR_BUILD="\$(RANLIB)"
+  WINDRES_FOR_BUILD="\$(WINDRES)"
+  WINDMC_FOR_BUILD="\$(WINDMC)"
 fi
 
 AC_PROG_CC
@@ -2314,6 +2336,8 @@ esac
 # Allow the user to override the flags for
 # our build compiler if desired.
 CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-${CFLAGS}}
+CXXFLAGS_FOR_BUILD=${CXXFLAGS_FOR_BUILD-${CFLAGS}}
+LDFLAGS_FOR_BUILD=${LDFLAGS_FOR_BUILD-${CFLAGS}}
 
 # On Canadian crosses, we'll be searching the right directories for
 # the previously-installed cross compiler, so don't bother to add
@@ -2381,7 +2405,21 @@ AC_SUBST(target_configargs)
 
 
 # Build tools.
+AC_SUBST(AR_FOR_BUILD)
+AC_SUBST(AS_FOR_BUILD)
 AC_SUBST(CC_FOR_BUILD)
+AC_SUBST(CFLAGS_FOR_BUILD)
+AC_SUBST(CXXFLAGS_FOR_BUILD)
+AC_SUBST(CXX_FOR_BUILD)
+AC_SUBST(DLLTOOL_FOR_BUILD)
+AC_SUBST(GCJ_FOR_BUILD)
+AC_SUBST(GFORTRAN_FOR_BUILD)
+AC_SUBST(LDFLAGS_FOR_BUILD)
+AC_SUBST(LD_FOR_BUILD)
+AC_SUBST(NM_FOR_BUILD)
+AC_SUBST(RANLIB_FOR_BUILD)
+AC_SUBST(WINDMC_FOR_BUILD)
+AC_SUBST(WINDRES_FOR_BUILD)
 AC_SUBST(config_shell)
 
 # Generate default definitions for YACC, M4, LEX and other programs that run
@@ -2466,7 +2504,6 @@ NCN_STRICT_CHECK_TOOLS(OBJDUMP, objdump)
 AC_SUBST(CC)
 AC_SUBST(CXX)
 AC_SUBST(CFLAGS)
-AC_SUBST(CFLAGS_FOR_BUILD)
 AC_SUBST(CXXFLAGS)
 
 # Target tools.