Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

After writing an Autoconf macro that determines whether to build
plug-ins with gcc or g++ [0], I realized that nested functions, which my
plug-in uses extensively, are not supported in C++.

Any suggestions on how to address this?

Thanks,
Ludo’.

[0] 
https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=6090&r2=6195

Re: GCC 4.7.0RC: Mangled names in cc1

[Richard Guenther]

2012/3/16 Ludovic Courtès :
> Hi,
>
> After writing an Autoconf macro that determines whether to build
> plug-ins with gcc or g++ [0], I realized that nested functions, which my
> plug-in uses extensively, are not supported in C++.
>
> Any suggestions on how to address this?

Don't use nested functions ;)  GCC is supposed to be buildable with an ISO C99
compiler which does not support nested functions either.

Richard.

> Thanks,
> Ludo’.
>
> [0] 
> https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=6090&r2=6195

Re: The state of glibc libm

[Steven Munroe]

On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote:
> On 2012-03-14 14:40:06 +, Joseph S. Myers wrote:
> > On Wed, 14 Mar 2012, Vincent Lefevre wrote:
> > 
> > > For double-double (IBM long double), I don't think the notion of
> > > correct rounding makes much sense anyway. Actually the double-double
> > > arithmetic is mainly useful for the basic operations in order to be
> > > able to implement elementary functions accurately (first step in
> > > Ziv's strategy, possibly a second step as well). IMHO, on such a
> > > platform, if expl() (for instance) just calls exp(), this is OK.
> > 
Why would that be OK? If we have higher precision long double then the
libm should deliver that higher precision.


> > expl just calling exp - losing 53 bits of precision - seems rather 
> > extreme.  But I'd think it would be fine to say: when asked to compute 
> > f(x), take x' within 10ulp of x, and return a number within 10ulp of 
> > f(x'), where ulp is interpreted as if the mantissa were a fixed 106 bits 
> > (fewer bits for subnormals, of course).  (And as a consequence, accurate 
> > range reduction for large arguments would be considered not to matter for 
> > IBM long double; sin and cos could return any value in the range [-1, 1] 
> > for sufficiently large arguments.)
> 
> After thinking about this, you could assume that you have a 106-bit
> floating-point system (BTW, LDBL_MANT_DIG = 106) and use the same
> method to generate code that provides an accurate implementation
> (if the code generator doesn't assume an IEEE 754 compatible FP
> system). Concerning sin and cos, I think there should be a minimum
> of specification and some consistency (such as sin(x)² + cos(x)²
> being close to 1).
> 
actually back in 2007 I overrode slowexp and slowpow for powerpc/power4
(and later) to use expl, powl on the slow path of exp/pow, instead of
the mpa.h implementation. This provide a nice performance improvement
but does imply some rounding mode issues. 

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

Richard Guenther  skribis:

> 2012/3/16 Ludovic Courtès :
>> Hi,
>>
>> After writing an Autoconf macro that determines whether to build
>> plug-ins with gcc or g++ [0], I realized that nested functions, which my
>> plug-in uses extensively, are not supported in C++.
>>
>> Any suggestions on how to address this?
>
> Don't use nested functions ;)  GCC is supposed to be buildable with an ISO C99
> compiler which does not support nested functions either.

Right, but the nice thing with GCC plug-ins is they can be implemented
using all GNU extensions.

Nested functions can serve as the basis for some form of functional
programming, which some of the APIs lend themselves to very well.
For instance, the plug-in at [0] contains things like:

tree task = task_implementation_task (fn);

tree build_parameter (const_tree lst)
{
  tree param, type;

  type = TREE_VALUE (lst);
  param = build_decl (DECL_SOURCE_LOCATION (task), PARM_DECL,
  create_tmp_var_name ("parameter"),
  type);
  DECL_ARG_TYPE (param) = type;
  DECL_CONTEXT (param) = task;  /* ← closed over variable */

  return param;
}

DECL_ARGUMENTS (task) =
  map (build_parameter,
   list_remove (void_type_p,
TYPE_ARG_TYPES (TREE_TYPE (task;

What if this snippet were to be written in ANSI C99?  The whole ‘map’
paradigm couldn’t be used, because there’d be no way to close over a
local variable.

What about writing it in C++?  Function objects could be passed around
to achieve a similar result, at the expense of conciseness and
interoperability with C.

This is an unfortunate collateral damage, IMO.

Thanks,
Ludo’.

[0] 
https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?view=markup&root=starpu

Re: target_header_dir vs host-x-host

[Ian Lance Taylor]

DJ Delorie  writes:

>> OK, but what's wrong --with-sysroot=/ ?
>
> It should work, it just seems "wrong" for a native compiler to have a 
> sysroot...

I agree that it's a bug, but I'm not sure I think it's the same bug that
you think it is.  Every toolchain has a sysroot, really.  I think it's a
bug that GNU ld only accepts the --sysroot option if configured with
--with-sysroot.  The default sysroot for a native toolchain is /.  That
should be the default even for the unusual case of cross-building a
native toolchain.  Right now it isn't, but the bug is not that the
sysroot is /, it's that the sysroot has to be explicitly specified.

Ian

Re: GCC 4.7.0RC: Mangled names in cc1

[Richard Guenther]

2012/3/16 Ludovic Courtès :
> Hi,
>
> Richard Guenther  skribis:
>
>> 2012/3/16 Ludovic Courtès :
>>> Hi,
>>>
>>> After writing an Autoconf macro that determines whether to build
>>> plug-ins with gcc or g++ [0], I realized that nested functions, which my
>>> plug-in uses extensively, are not supported in C++.
>>>
>>> Any suggestions on how to address this?
>>
>> Don't use nested functions ;)  GCC is supposed to be buildable with an ISO 
>> C99
>> compiler which does not support nested functions either.
>
> Right, but the nice thing with GCC plug-ins is they can be implemented
> using all GNU extensions.
>
> Nested functions can serve as the basis for some form of functional
> programming, which some of the APIs lend themselves to very well.
> For instance, the plug-in at [0] contains things like:
>
>    tree task = task_implementation_task (fn);
>
>    tree build_parameter (const_tree lst)
>    {
>      tree param, type;
>
>      type = TREE_VALUE (lst);
>      param = build_decl (DECL_SOURCE_LOCATION (task), PARM_DECL,
>                          create_tmp_var_name ("parameter"),
>                          type);
>      DECL_ARG_TYPE (param) = type;
>      DECL_CONTEXT (param) = task;  /* ← closed over variable */
>
>      return param;
>    }
>
>    DECL_ARGUMENTS (task) =
>      map (build_parameter,
>           list_remove (void_type_p,
>                        TYPE_ARG_TYPES (TREE_TYPE (task;
>
> What if this snippet were to be written in ANSI C99?  The whole ‘map’
> paradigm couldn’t be used, because there’d be no way to close over a
> local variable.
>
> What about writing it in C++?  Function objects could be passed around
> to achieve a similar result, at the expense of conciseness and
> interoperability with C.
>
> This is an unfortunate collateral damage, IMO.

Well, if you invent new paradigms in your plugin that are not used by GCC
itself but use GCC internals (which all plugins have to do ...) then I know
where the problem lies ;)  I suppose you would be better served by
some of the more high-level plugin packages that let you write GCC plugins
in python or lisp?

Or wait until GCC has fully transitioned to C++ (at least I expect we won't
ever relax the rule that GCC can be built with a C++ compiler) and use
C++0x lambdas.

Richard.

> Thanks,
> Ludo’.
>
> [0] 
> https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?view=markup&root=starpu

Re: GCC 4.7.0RC: Mangled names in cc1

[Basile Starynkevitch]

On Fri, Mar 16, 2012 at 02:04:38PM +0100, Ludovic Courtès wrote:
> 
> What about writing it in C++?  Function objects could be passed around
> to achieve a similar result, at the expense of conciseness and
> interoperability with C.

Well, if your plugin is compiled with C++ and all of GCC is also compiled with 
C++, you might not need interoperability.

> This is an unfortunate collateral damage, IMO.
> 
> Thanks,
> Ludo???.
> 
> [0] 
> https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?view=markup&root=starpu


By the way, your plugin could be an interesting case for MELT, which
obviously provide higher-level functions (since MELT functions are true
closures).

Cheers.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Georg-Johann Lay]

Richard Guenther schrieb:

GCC 4.7.0 Release Candidate available from gcc.gnu.org

A second release candidate for GCC 4.7.0 is available from

 ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314

and shortly its mirrors.  It has been generated from SVN revision 185376.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.


Some days ago I learned that even if there are solutions to reported 
bugs, these solutions is already upstream to trunk and approved to be 
backported to 4.7.1, these bugfixes are prohibited for the 4.7.0 release.


Can someone explain this "fix as few as possible bugs" rule to me?

I don't want to question that precedure, I just want to understand it.

If the reason is "not destabilize the release": What is the advantage of 
having exact the same destabilization at a later point, namely for the 
4.7.1 release in this specific case?


Thanks.

Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Richard Guenther]

On Fri, 16 Mar 2012, Georg-Johann Lay wrote:

> Richard Guenther schrieb:
> > GCC 4.7.0 Release Candidate available from gcc.gnu.org
> > 
> > A second release candidate for GCC 4.7.0 is available from
> > 
> >  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
> > 
> > and shortly its mirrors.  It has been generated from SVN revision 185376.
> > 
> > I have so far bootstrapped and tested the release candidate on
> > x86_64-linux.  Please test it and report any issues to bugzilla.
> 
> Some days ago I learned that even if there are solutions to reported bugs,
> these solutions is already upstream to trunk and approved to be backported to
> 4.7.1, these bugfixes are prohibited for the 4.7.0 release.
> 
> Can someone explain this "fix as few as possible bugs" rule to me?
> 
> I don't want to question that precedure, I just want to understand it.
> 
> If the reason is "not destabilize the release": What is the advantage of
> having exact the same destabilization at a later point, namely for the 4.7.1
> release in this specific case?

The points are as follows

 1) we want to make a release at some point
 2) we want to give people a chance to test the release beforehand,
thus we do a release candidate - main testing focus is that
weird targets get built, to rule out show-stoppers
 3) if we apply changes to a release candidate 2) is invalidated so
we'd need another release candidate - see point 1)
 4) for 4.7.1 there will be a release candidate as well, thus 2)
is re-validated

so the issue is simply that when we have created a RC we don't want
_any_ changes.  Ideally.  Otherwise doing a release candidate is
pointless and we could just release without doing release candidates.

Richard.

Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Jonathan Wakely]

On 16 March 2012 13:45, Georg-Johann Lay wrote:
> Richard Guenther schrieb:
>>
>> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>
>> A second release candidate for GCC 4.7.0 is available from
>>
>>  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
>>
>> and shortly its mirrors.  It has been generated from SVN revision 185376.
>>
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux.  Please test it and report any issues to bugzilla.
>
>
> Some days ago I learned that even if there are solutions to reported bugs,
> these solutions is already upstream to trunk and approved to be backported
> to 4.7.1, these bugfixes are prohibited for the 4.7.0 release.
>
> Can someone explain this "fix as few as possible bugs" rule to me?
>
> I don't want to question that precedure, I just want to understand it.
>
> If the reason is "not destabilize the release": What is the advantage of
> having exact the same destabilization at a later point, namely for the 4.7.1
> release in this specific case?

If the change goes in to the 4.7 branch as soon as 4.7.0 is released
then it will have weeks or months of testing before the 4.7.1 release.
 If the branch is unstable just after a release then there is more
time for fixes and testing than if it's unstable just before a
release.

Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Georg-Johann Lay]

Richard Guenther schrieb:

On Fri, 16 Mar 2012, Georg-Johann Lay wrote:



Richard Guenther schrieb:


GCC 4.7.0 Release Candidate available from gcc.gnu.org

A second release candidate for GCC 4.7.0 is available from

ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314

and shortly its mirrors.  It has been generated from SVN revision 185376.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.


Some days ago I learned that even if there are solutions to reported bugs,
these solutions is already upstream to trunk and approved to be backported to
4.7.1, these bugfixes are prohibited for the 4.7.0 release.

Can someone explain this "fix as few as possible bugs" rule to me?

I don't want to question that precedure, I just want to understand it.

If the reason is "not destabilize the release": What is the advantage of
having exact the same destabilization at a later point, namely for the 4.7.1
release in this specific case?



The points are as follows

 1) we want to make a release at some point
 2) we want to give people a chance to test the release beforehand,
thus we do a release candidate - main testing focus is that
weird targets get built, to rule out show-stoppers
 3) if we apply changes to a release candidate 2) is invalidated so
we'd need another release candidate - see point 1)
 4) for 4.7.1 there will be a release candidate as well, thus 2)
is re-validated

so the issue is simply that when we have created a RC we don't want
_any_ changes.  Ideally.  Otherwise doing a release candidate is
pointless and we could just release without doing release candidates.

Richard.


Ok, so the goal is that the releast is exactly the same as the (last) 
release candidate.


I was just confused by the "please report bugs" which gives rise to the 
(incorrect) assumption that the goal is to actually fix these bugs -- 
only if this is possible in a timely manner, of course, and won't delay 
the release.


Thanks for explanation.

Johann

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hello,

Richard Guenther  skribis:

> 2012/3/16 Ludovic Courtès :

[...]

> Well, if you invent new paradigms

Hmm, I didn’t invent anything here.

> in your plugin that are not used by GCC itself but use GCC internals
> (which all plugins have to do ...) then I know where the problem lies
> ;) I suppose you would be better served by some of the more high-level
> plugin packages that let you write GCC plugins in python or lisp?

Sure, even Guile-GCC [0].  :-)

(Speaking of which, since it mostly uses Guile’s dynamic FFI to
interface with GCC, and thus dlsyms GCC’s symbols, it will also suffer
from the transition.  How does the Python plug-in handle that?  Is it
written in ANSI C, or does it use ctypes?)

Nevertheless, I found that GNU C provides a nice middle ground.

> Or wait until GCC has fully transitioned to C++ (at least I expect we won't
> ever relax the rule that GCC can be built with a C++ compiler) and use
> C++0x lambdas.

That would be great, but I’d like to support 4.5 and 4.6 as well.

Thanks,
Ludo’.

[0] https://gitorious.org/guile-gcc/guile-gcc

Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

On Fri, Mar 16, 2012 at 03:57:51PM +0100, Georg-Johann Lay wrote:
> I was just confused by the "please report bugs" which gives rise to
> the (incorrect) assumption that the goal is to actually fix these
> bugs -- only if this is possible in a timely manner, of course, and
> won't delay the release.

But we want the bugs (if any) to be reported.  Then we can judge on a case by
case basis how important is it to have the bug fix in the release (as
opposed to e.g. being committed to the branch soon after the release) and
how risky the fix is for the stability of the release (what are the
chances it will break other things).  Some bugfixes (the most urgent
and least risky) can be applied still for the release, other queued
for the branch after the release, others fixed only on the trunk and never
backported, etc.

Jakub

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Fri, Mar 16, 2012 at 6:03 AM, Ludovic Courtès
 wrote:
> Hi,
>
> After writing an Autoconf macro that determines whether to build
> plug-ins with gcc or g++ [0], I realized that nested functions, which my
> plug-in uses extensively, are not supported in C++.
>
> Any suggestions on how to address this?

Patient: Doctor, it hurts when I do this.  Do you have a medication?
Doctor: Yes, don't do it.


>
> Thanks,
> Ludo’.
>
> [0] 
> https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=6090&r2=6195

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès
 wrote:

> Right, but the nice thing with GCC plug-ins is they can be implemented
> using all GNU extensions.

at the risk of having this very discussion.

[...]

> What about writing it in C++?  Function objects could be passed around
> to achieve a similar result, at the expense of conciseness and
> interoperability with C.

Does not compute.  If you are using nested functions, you are not
interested in C interoperability in the first place.

Google Summer of Code 2012 - Call for mentors

[Diego Novillo]

We are glad to announce that GCC has been accepted Google's Summer of
Code 2012 program (GSoC 2012).  Summer of Code is a program sponsored
by Google in which students are paid to contribute to open source
projects.  This will be GCC's 7th year of participation.  For more
information, see http://code.google.com/soc/

Student applications will be accepted from 17 March 2012 to 25 March
2012.  Each student will work with a mentor from the project.  As
we've done in past years, we need to have a set of mentors who are
prepared to work with students.  We would like to encourage any
interested experienced GCC developer to become a mentor for the
project.  Being a mentor does not require that you actually work with
a student: we normally have many more available mentors than we do
students.  All mentor volunteers (and only mentor volunteers) will be
able to see and vote on all student project proposals.

As last year, I will act as administrator for the program and Ian will
be our backup admin.  We will accept as a mentor anybody who is listed
as a maintainer of some part of GCC in the MAINTAINERS file.  If you
are not a maintainer but still want to be a mentor, we are open to
being convinced.

To become a mentor, you need to go http://socghop.appspot.com/ and
create an account.  Then click on "Apply to become a mentor" over on
the left and select the GCC project.  If you are a returning mentor,
you can use the same login ID you created in the past.  For
documentation on applying and managing your mentor profile, see
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2012/userguide#depth_mentor


Thanks.

Diego and Ian.

GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[David Malcolm]

On Fri, 2012-03-16 at 16:17 +0100, Ludovic Courtès wrote:
> Hello,
> 
> Richard Guenther  skribis:
> 
> > 2012/3/16 Ludovic Courtès :
> 
> [...]
> 
> > Well, if you invent new paradigms
> 
> Hmm, I didn’t invent anything here.
> 
> > in your plugin that are not used by GCC itself but use GCC internals
> > (which all plugins have to do ...) then I know where the problem lies
> > ;) I suppose you would be better served by some of the more high-level
> > plugin packages that let you write GCC plugins in python or lisp?
> 
> Sure, even Guile-GCC [0].  :-)
> 
> (Speaking of which, since it mostly uses Guile’s dynamic FFI to
> interface with GCC, and thus dlsyms GCC’s symbols, it will also suffer
> from the transition.  How does the Python plug-in handle that?  Is it
> written in ANSI C, or does it use ctypes?)

The python plugin is written in plain C, much of it autogenerated.  It
mostly dynamically links to GCC, but uses weak references on some of
GCC's symbols (e.g. when using symbols that only exist in the C++
frontend), so we'll see how well that works.

I have to admit to being nervous about the GCC change to C++.
Elaborating on this further may degenerate into a rant, so here goes,
and I apologize in advance.

I should stress at the this point that I don't speak for Red Hat here;
this is just my own opinion (based on having spent much of the last year
working on the gcc python plugin, and having spent many years involved
in free software).

The C++ move is making things more difficult for plugin authors, but
that's a symptom of not having a plugin API.

It's perfectly possible to write clean, maintainable code in C that
implements object-oriented ideas such as information hiding, dynamic
dispatch according to type, and so on.  See e.g. CPython or GObject for
examples.

What I'm really hoping for from GCC is a move towards a collection of
libraries that can be embedded in (license-compatible) apps: LLVM is
gaining ground for the use case of programs that need JIT-compilation
(e.g. the X server, or a JVM).  I appreciate that JIT compilation has
different characteristics to a classic ahead-of-time compiler.

C++ is likely to make it more difficult to embed GCC into such apps
(e.g. nasty ordering issues for globals with non-empty constructors; ABI
differences e.g. relating to exception handling; extra complexity of
linking); everyone large free software that uses C++ chooses a subset of
the language to use (this could be enforced with a plugin to the
compiler!)

What use cases would a rearchitected GCC have?  I may not win friends
here by posting this link, but, to be frank, see:
  http://llvm.org/ProjectsWithLLVM/
Some examples:
  * the X server: llvmpipe is a software implementation of OpenGL:
compiling OpenGL shader programs into machine code for the CPU for the
case where the GPU isn't up to the job (or for which the vendor isn't
providing specs).
  * IcedTea is using LLVM to add JIT compilation for Java code (see
http://icedtea.classpath.org/wiki/ZeroSharkFaq#Why_was_Shark_written.3F
)
  * JIT compilation within dynamic languages: e.g. Unladen Swallow
(though that's a dead project; most of the time and energy was spent
fixing bugs in LLVM)
  * static analysis tools
  * anywhere we're writing plugins.  Building standalone tools and just
linking is often preferable.  See e.g.:
http://blogs.gnome.org/jessevdk/2011/09/10/gedit-clang-plugin-progress/
where (if I'm reading it right) the gedit editor has gained a plugin
that embeds parts of LLVM.


Proposed outcome

GCC becomes a family of shared libraries that can be dynamically and
statically linked.  The executables become a thin wrapper that invoke
these libraries (perhaps statically linked to minimize startup costs).

Note that I'm *not* proposing a license change.  The code that uses
these libraries would need to be license-compatible with GCC.

The ideal outcome would be to dynamically link this code into a
multi-threaded process, in which multiple dynamically-linked libraries
within the process are linked against the GCC library, working
independently, without knowing that each one is using the library.

Such an reorganization could be worthy of bump to the major-release id
(e.g. "gcc 5")

Current architectural issues
-
GCC is currently a large body of single-threaded code that is compiled
and linked into multiple large executables. 

Issues:
* lots of global state: global variables, static locals, etc.
* related to the above: function often have side-effects
* memory management: custom allocator, with garbage collection.  I'm not
sure how the GC code locates roots on the stack, and I suspect that's
there's currently an assumption there there aren't multiple threads
within the process
* process termination: code can call abort() to handle errors, rather
than being able to report back an error state.  It may be acceptable for
a standalone executable to call "abort", but it's not acceptable when a
library that y

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Diego Novillo]

On Fri, Mar 16, 2012 at 13:19, David Malcolm  wrote:

> Hope this is constructive.

It is.

Parts of your proposal are instances of the modularity effort that has
been going on for some time.  It also touches on some of the same
topics discussed in http://gcc.gnu.org/wiki/ImprovementProjects.

It would be great if you could add this to that page so we can keep
all these ideas in a centralized location.


Thanks.  Diego.

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Gabriel Dos Reis]

On Fri, Mar 16, 2012 at 12:19 PM, David Malcolm  wrote:

> C++ is likely to make it more difficult to embed GCC into such apps
> (e.g. nasty ordering issues for globals with non-empty constructors;

If you were going to write an API in C and you have no globals that
require a dynamic initialization, there is not reason you would need
one just because you use C++.

-- Gaby

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Joseph S. Myers]

On Fri, 16 Mar 2012, David Malcolm wrote:

> Proposed outcome
[...]
> Current architectural issues
[...]

Not many people commented on the architectural goals document Diego and I 
posted at .  Many of your 
ideas seem potentially useful additions to it.  I hope Diego will have 
time soon to push more of the goals and development conventions through 
community approval and move them to the main website; as we do this, 
detailed feedback from people interested in these issues is certainly 
welcome.

> * no namespacing: seemingly arbitrary naming convention for symbols.
> Would want to add some namespace prefix to the public symbols (vars and
> fns), and to the types.

Namespaces are one thing that could well be addressed using C++ namespaces 
(both for GCC itself, and for particular areas within it).

> * actually implementing the thing!

Yes.  Agreement on general goals is certainly useful; it provides an 
overall context for patch review so a modularity patch doesn't get 
unhelpful comments to the effect that "this whole modularity idea is 
ill-conceived".  But what's really needed is the investment of many 
person-years in improvements directed towards well-defined goals.

> It seems that GCC has provided an API for registering plugins, but no
> API for the plugins to then actually use...  Perhaps the C++ move would

As regards the limited number of places where plugins get called, the idea 
(I think) is that as and when a plugin author wants plugins to be involved 
at a particular point in GCC, they should contribute appropriate patches 
(rather than GCC developers speculatively guessing what plugins might 
want).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Jonathan Wakely]

On 16 March 2012 17:19, David Malcolm wrote:
>
> What I'm really hoping for from GCC is a move towards a collection of
> libraries that can be embedded in (license-compatible) apps: LLVM is
> gaining ground for the use case of programs that need JIT-compilation
> (e.g. the X server, or a JVM).  I appreciate that JIT compilation has
> different characteristics to a classic ahead-of-time compiler.
>
> C++ is likely to make it more difficult to embed GCC into such apps

It seems to work for LLVM and Clang.

About GCJ compiler

[Mao Ito]

To whom may it concern,

Nice to meet you. I am Mao Ito and a graduate student at the University of 
Wisconsin-Madison.
I am working on a course project. My topic is something like "High Performance 
Architecture for Java Programming Language on mobile phones". On this project, 
I am planning to use GCJ to cross-compile Java for ARM.
I am planning to add some extra ISAs(Instruction Set Architecture). But, if I 
add an extra ISAs, as you know, I have to generate binary codes corresponding 
to my new architecture. My question is if I can modify GCJ for my purpose. Is 
it possible to get source codes and customize it?

Sincerely,
Mao Ito