Re: C++, export for templates (was: C++ standard)

[Tarjei Knapstad]

On 2/6/06, Ryan Mansfield <[EMAIL PROTECTED]> wrote:
>
> > Couldn't find anything on it in bugzilla, and I don't think it's worth
> > the effort. IIRC, Herb Sutter and another guy spent 6 months to get it
> > right in the EDG front end (and Herb originally wanted to throw export
> > for templates out of the standard alltogether).
> >
>
> The implementation of export was done by Steve Adamczyk, John Spicer, and
> Daveed Vandevoorde - also known as Edison Design Group (EDG).

Ah, thanks for the correction Ryan. Didn't "remember correctly" at all
aparently - I just vaguely remember this being brought up at a
conference talk a few years ago by who I thought was Sutter, but it
must've been Vandevoorde.

--
Tarjei

[patch] PR22097: libgfortran build failure on mips-sgi-irix6.5

[Rainer Emrich]

This patch fixes bootstrap failure in ligfortran/instrisics/c99_functions.c for
mips-sgi-irix6.5.
This patch applies cleanly to 4.1 and mainline.
It's similiar as http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html
Patch applied, bootstrap finished successfully for 4.1 svn revision 110639.
Testsuite in progress.

There is one open question. Is the "#ifdef __sgi__" the right way to
distinguish between IRIX and other mips systems?

I ask for comments.

Best regards

Rainer


--- gcc-4.1-svn/libgfortran/intrinsics/c99_functions.c  2006-01-17
22:12:03.0 +0100
+++ gcc-4.1-test/libgfortran/intrinsics/c99_functions.c 2006-02-06
19:42:39.0 +0100
@@ -35,6 +35,22 @@ Boston, MA 02110-1301, USA.  */
 #define C99_PROTOS_H WE_DONT_WANT_PROTOS_NOW
 #include "libgfortran.h"

+/* IRIX's  declares a non-C99 compliant implementation of cabs,
+   which takes two floating point arguments instead of a single complex.
+   If  is missing this prevents building of c99_functions.c.
+   To work around this we redirect cabs{,f,l} calls to __gfc_cabs{,f,l}.  */
+
+#ifdef __sgi__
+#ifndef HAVE_COMPLEX_H
+#undef HAVE_CABS
+#undef HAVE_CABSF
+#undef HAVE_CABSL
+#define cabs __gfc_cabs
+#define cabsf __gfc_cabsf
+#define cabsl __gfc_cabsl
+#endif /* HAVE_COMPLEX_H */
+#endif /* __sgi__ */
+
 /* Tru64's  declares a non-C99 compliant implementation of cabs,
which takes two floating point arguments instead of a single complex.
To work around this we redirect cabs{,f,l} calls to __gfc_cabs{,f,l}.  */

RE: Trying to map absolute sections

[Dave Korn]

On 07 February 2006 04:44, Tarun wrote:

> Hi,
> 
> I am trying to map an elf section to absolute address. Is there any way
> that we can restrain the linker (ld) not to relocate a section and place
> it at an absolute address.  
> 
> I have tried placing the absolute address in the Sh_Addr and updating the
> section name as SH_ABS. But it was of no use. 
> 
> 
> Thanks in advance.
> Tarun


  Wrong list.  Binutils is over  --> thataway.

http://sourceware.org/ml/binutils.

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

Re: Machine Dependance

[Rafael Espíndola]

> Hey Paolo thanx  a lot.I got the info I required.
> Can u mention any links that i can use as a reference to understand the dump 
> output of   -fdump-tree-original-raw as AST?

read
GENERIC and GIMPLE: A new tree representation for entire functions
at
http://zenii.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf

> Thanx a lot.
>
> Darthrader


Rafael

Re: fvisibility-inlines-hidden

[Mark Mitchell]

Howard Hinnant wrote:

> Let me rephrase:  It seems to me that fvisibility-inlines-hidden  should
> apply to all inline functions (both member and non-member).   Does
> anyone have an argument for why it should not be this way?

I certainly do not.

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

Re: SOLVED: Wrestling with exceptions on win32 gcj 4.1

[tHE DPR]

hello,

i was able to solve my problem (see
http://gcc.gnu.org//ml/java/2006-02/msg00047.html) by applying
*any* of the two patches below.

since both patches apply to gcc i'm cc'ing to gcc list too.

i'm not 100% sure if my solution is correct. maybe just some exception data
is mangled in some way.
anyway, now i'm able to run basic swt application, and throw and catch
exceptions.

i'm happy and hope this could help somebody else to use gcj 4.1 on windows.
it would be unfortunate if gcj could not be used for most popular os ;)

so, the first patch makes uw_frame_state_for() function return
_URC_END_OF_STACK earlier, when context->fc->prev == NULL.

--- gcc/unwind-sjlj.c.old   2005-11-17 00:10:39.0 +0200
+++ gcc/unwind-sjlj.c   2006-02-07 14:02:36.0 +0200
@@ -265,7 +265,7 @@
  else
{
  fs->personality = context->fc->personality;
-  return _URC_NO_REASON;
+  return context->fc->prev != NULL ? _URC_NO_REASON :
_URC_END_OF_STACK;
}
}

my second patch makes _Unwind_Backtrace break out of the loop as soon as
_URC_END_OF_STACK is returned, so the trace callback is not called in that
case.

--- gcc/unwind.inc.old  2005-12-17 11:55:11.0 +0200
+++ gcc/unwind.inc  2006-02-07 20:13:38.0 +0200
@@ -292,17 +292,18 @@

  /* Set up fs to describe the FDE for the caller of context.  */
  code = uw_frame_state_for (&context, &fs);
-  if (code != _URC_NO_REASON && code != _URC_END_OF_STACK)
+
+  /* We're done at end of stack.  */
+  if (code == _URC_END_OF_STACK)
+   break;
+
+  if (code != _URC_NO_REASON)
   return _URC_FATAL_PHASE1_ERROR;

  /* Call trace function.  */
  if ((*trace) (&context, trace_argument) != _URC_NO_REASON)
   return _URC_FATAL_PHASE1_ERROR;

-  /* We're done at end of stack.  */
-  if (code == _URC_END_OF_STACK)
-   break;
-
  /* Update context to describe the same frame as fs.  */
  uw_update_context (&context, &fs);
}

bye,
-- dpr

Re: Toplevel bootstrap only - where are we?

[Mark Mitchell]

Daniel Jacobowitz wrote:
> Paolo's recent post on gcc-patches reminded me of all the toplevel
> libgcc changes I have pending.  To recap, the dependence is: if libgcc
> is moved out of the top level, the "configure --disable-bootstrap; make
> bootstrap" approach will no longer work.  Building without a bootstrap
> will be fine, of course - either for cross compilers, or in today's
> sources with "configure --disable-bootstrap; make", or in hypothetical
> future sources with "configure; make" if that goes back to being a
> non-bootstrap target at some point.

This is clearly the path forward.
> So, how many people are still working with old-style GCC subdirectory
> bootstrap?  What blockers are there, besides retraining our fingers?


Moving libgcc to the top level has lots of long term benefits, as has
been discussed.  I don't think it matters that this requires us to
change our habits a little bit.  Like everyone else, I will have to
adjust the odd build script, but this is one of these infrastructure
improvements (like moving to svn) that, while somewhat disruptive, has
big payoff.  And, staying halfway in between is just confusing.

Let's make it happen.

I'll help review patches in this direction, to the extent I can do so
competently.  However, I'll of course defer to the build system
maintainers -- either on particular patches, or in general, if they
determine I'm incompetent.

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

gcc-3.4-20060207 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch 
revision 110725

You'll find:

gcc-3.4-20060207.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20060207.tar.bz2 C front end and core compiler

gcc-ada-3.4-20060207.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20060207.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20060207.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20060207.tar.bz2 Java front end and runtime

gcc-objc-3.4-20060207.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20060207.tar.bz2The GCC testsuite

Diffs from 3.4-20060131 are available in the diffs/ subdirectory.

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

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[John David Anglin]

> I found the cause for the bootstrap failure.
> 
> Normally I pass "-mpa-risc-2-0" to the boostrap compiler.

This bug should now be fixed.  See
.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

precompiled headers tests failed

[Eric Fisher]

Hi,
I think I've got the answer from GCC Bugzilla Bug 11341. It said that
this was possibly a known problem with cygwin. For some reason cygwin
has always had problems with PCH. Then I run the testsuite on the
linux and most of them passed.

Thanks for your time.
Eric.