status of GCC & C++

status of GCC & C++

[Basile Starynkevitch]

Hello All,

It seems that several Linux distributions are shipping a GCC 4.7 compiled by a C++
compiler (probably GCC).

This affects plugins makers, as has been already discussed.

Do we have (e.g. for plugin makers) a nice way to know if a given GCC distribution was
compiled in C or in C++ mode? For instance, compiling a helloworld.c with gcc -v don't
tell anything about the way that GCC compiler has been built. (ie if it has C++ symbols
or C ones in the executable, and knowing that is mandatory for plugins).

Did we cross the C++ rubicon, in other words is GCC 4.8 scheduled to be compilable with a
C compiler (not C++) for the C front-end and the middle-end and the x86_64/GNU/Linux
back-end?

[my imperfect understanding was that GCC 4.7 should have been compilable by either a
standard C89 or a standard C++03 compiler, if not needing a Go or Ada front-end]

When GCC won't be compilable any more by a C (not C++) compiler, should we make that a
prominent & documented change?  I  believe it should also be reflected in our configure
machinery (by rejecting the build of GCC when a C++ compiler is not available).

Regards.

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

Re: status of GCC & C++

[Diego Novillo]

On 3/25/12 1:19 PM, Basile Starynkevitch wrote:

> When GCC won't be compilable any more by a C (not C++) compiler, should we make that a
> prominent&  documented change?  I  believe it should also be reflected in our configure
> machinery (by rejecting the build of GCC when a C++ compiler is not available).

Yes.  For GCC 4.8, we should move to:

- Build all stages with C++
- Remove the option to go back to C.


Diego.

Re: status of GCC & C++

[Eric Botcazou]

> Yes.  For GCC 4.8, we should move to:
>
> - Build all stages with C++
> - Remove the option to go back to C.

That would mean you can start to use C++ in the compiler code although, AFAIK, 
we are still waiting for the long-promised C++ Coding Standard.  That seems 
like putting the car before the horses to me.

-- 
Eric Botcazou

Re: status of GCC & C++

[Diego Novillo]

On 3/25/12 1:32 PM, Eric Botcazou wrote:
>> Yes.  For GCC 4.8, we should move to:
>>
>> - Build all stages with C++
>> - Remove the option to go back to C.
>
> That would mean you can start to use C++ in the compiler code although, AFAIK,
> we are still waiting for the long-promised C++ Coding Standard.  That seems
> like putting the car before the horses to me.

I don't think so.  By simply causing stage 1 to be compilable with a C++ 
compiler, we are making the transition easier.  This is orthogonal to 
the porting effort.

The proposed coding guidelines have been published and will evolve 
(http://gcc.gnu.org/wiki/CppConventions).  No point waiting to settle a 
set of rules that will naturally change over time, as we start using it.


Diego.

Re: status of GCC & C++

[Basile Starynkevitch]

On Sun, 25 Mar 2012 14:04:56 -0400
Diego Novillo <dnovillo@google.com> wrote:

> On 3/25/12 1:28 PM, Basile Starynkevitch wrote:
> > On Sun, 25 Mar 2012 13:25:34 -0400
[...]

> > I would suggest then to put in a core header file (even used by plugins) something like
> > #ifndef __cpluscplus
> > #error GCC and its plugins need to be compiled by a C++ compiler
> > #endif
> >
> > What do you think? And where should we put that?
> 
> First things first.  Stage 1 should be compiled with C++.  We still need 
> someone to volunteer to do that.

Ok. I thought that step was a trivial one.

Now a related question. How can a plugin know that cc1 was compiled with C++ or just with
plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin use
ENABLE_BUILD_WITH_CXX)?

And I don't understand why the GCC 4.7 changes don't advertise loudly on
http://gcc.gnu.org/gcc-4.7/changes.html that the C language is obsolete as the language
in which GCC is coded, and that next release will *need* to be compiled with C++? Or is
something that tells it somewhere, in strong enough words or typography that nobody could
skip it? (I am not sure that a casual user, brave enough to compile GCC 4.7 from source,
did notice that C++ would be soon mandatory to compile GCC).

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

Re: status of GCC & C++

[Basile Starynkevitch]

On Sun, 25 Mar 2012 20:30:31 +0200
Basile Starynkevitch <basile@starynkevitch.net> wrote:
> 
> How can a plugin know that cc1 was compiled with C++ or just with
> plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin use
> ENABLE_BUILD_WITH_CXX)?

Actually, I tend to believe that this is really a bug in GCC 4.7 (specifically). I think
that 
  A)  gcc-4.7 -v should obviously tell if it was compiled in C++ mode or in C mode, since
this information is crucial to plugins. On Debian/Sid I don't have a simple way to get
that information.
% /usr/bin/gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.0-1'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c+
+,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c+
+/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu Thread model: posix gcc version 4.7.0 (Debian 4.7.0-1) 

Nothing above tell me about GCC being compiled in C++ flavor


  B) the $(gcc-4.7 -print-file-name=plugin)/ directory should have a header file with
something telling if it was compiled in C++ or C mode. (Perhaps ENABLE_BUILD_WITH_GCC
might have that role in auto-host.h, but then I think it is grossly misnamed).

Since 4.7 is probably the only release of GCC which can be compiled by C and by C++ I
believe it is a bug specific to that release.

I'm sure this bug affect several GCC plugins. It does affect GCC MELT for instance.
https://groups.google.com/forum/?fromgroups#!topic/gcc-melt/PRWr28sQExk

My feeling is that it is not only the plugins' fault (so it is not only a MELT plugin
bug, but a GCC one)


What do you think? Should 4.7.1 provide a fix to correct that? How? Testing simply
ENABLE_BUILD_WITH_GCC makes me feel unhappy; that name is really confusing, if we
understand and use it as GCC_IS_BUILT_WITH_CXX

My wish would be to add, perhaps in gcc/configure.ac of GCC 4.7.1, something which
defines GCCPLUGIN_IN_CXX in e.g.  $(gcc-4.7 -print-file-name=plugin)/plugin-version.h
when gcc-4.7 have been built with a C++ compiler so its plugins need to be compiled with
a C++ compiler. That information should also be accessible (e.g. for plugin makers) thru
some invocation of GCC (perhaps gcc -v).


Cheers 

PS. Compatibility with C++ plugins was already discussed, but I forgot when... Here I
focus on a possible bug of GCC 4.7.

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

Re: status of GCC & C++

[Gabriel Dos Reis]

On Sun, Mar 25, 2012 at 3:10 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> Nothing above tell me about GCC being compiled in C++ flavor

I believe the ones that are not compiled with a C++ compiler have a
--disable-xxx-something
in the output of gcc -v

-- Gaby

Re: status of GCC & C++

[Marc Glisse]

On Sun, 25 Mar 2012, Basile Starynkevitch wrote:

> On Sun, 25 Mar 2012 20:30:31 +0200
> Basile Starynkevitch <basile@starynkevitch.net> wrote:
>>
>> How can a plugin know that cc1 was compiled with C++ or just with
>> plain C?

nm thefile | grep _Z
(possibly nm -D)

You can also look for --disable-bootstrap or --disable-build-with-cxx in 
the configure options. Or you can just assume that it is built as C++, 
which is the default after all. People who have anything different should 
have asked for it and thus know what to expect.

-- 
Marc Glisse

Re: status of GCC & C++

[Eric Botcazou]

> The proposed coding guidelines have been published and will evolve
> (http://gcc.gnu.org/wiki/CppConventions).  No point waiting to settle a
> set of rules that will naturally change over time, as we start using it.

That isn't what was decided when the transition to C++ was proposed though.
It was agreed that a set of Coding Conventions would be published before the 
switch to C++.  If you think that the above conventions are in good enough a 
shape to be proposed, then propose them for inclusion in
  http://gcc.gnu.org/codingconventions.html

-- 
Eric Botcazou

Re: status of GCC & C++

[Diego Novillo]

On Sun, Mar 25, 2012 at 17:36, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> The proposed coding guidelines have been published and will evolve
>> (http://gcc.gnu.org/wiki/CppConventions).  No point waiting to settle a
>> set of rules that will naturally change over time, as we start using it.
>
> That isn't what was decided when the transition to C++ was proposed though.

Really?  To start *writing* in C++, sure we want at least an initial
version of the coding guidelines.  I pointed to those, because they
look like a reasonable start.

To start *building* in C++, I do not think we need to agree on the
coding guidelines.  We are already doing stages 2 and 3, doing stage 1
is a straightforward next step.

> It was agreed that a set of Coding Conventions would be published before the
> switch to C++.  If you think that the above conventions are in good enough a
> shape to be proposed, then propose them for inclusion in
>  http://gcc.gnu.org/codingconventions.html

This needs to be done, yes.  But not for simply building with C++.


Diego.

Re: status of GCC & C++

[Gabriel Dos Reis]

On Sun, Mar 25, 2012 at 4:45 PM, Diego Novillo <dnovillo@google.com> wrote:

> To start *building* in C++, I do not think we need to agree on the
> coding guidelines.  We are already doing stages 2 and 3, doing stage 1
> is a straightforward next step.

I agree with Diego that to start building only with a C++ compiler, we
do not need
to have approved a C++ coding convention.

I also think that the current wiki page is still at brainstorming
phase than a sufficiently
complete and coherent set.  It needs further flushing.  For example, I do not
believe it makes sense to ban both simple templates (for writing containers)
and virtual functions (or to that matter multiple inheritance).  There
are forms of those
features that need to be properly restricted (e.g. it would a real
mistake to go
banana with the "advanced" template (meta)programming stuff.)
Similarly, some of the
control/flow and path can be significantly reduced (and bugs fixed!)
if simple exception
handling is allowed -- think of all those bugs caused by failure to
exit early on
error_mark_node.

-- Gaby

Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

[David Malcolm]

On Sun, 2012-03-25 at 22:10 +0200, Basile Starynkevitch wrote:
> On Sun, 25 Mar 2012 20:30:31 +0200
> Basile Starynkevitch <basile@starynkevitch.net> wrote:
> > 
> > How can a plugin know that cc1 was compiled with C++ or just with
> > plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin use
> > ENABLE_BUILD_WITH_CXX)?
> 
[...snip discussion of various ways to try to "ask" GCC  whether it was
built with a C or a C++ compiler...]

> Since 4.7 is probably the only release of GCC which can be compiled by C and by C++ I
> believe it is a bug specific to that release.
> 
> I'm sure this bug affect several GCC plugins. It does affect GCC MELT for instance.
> https://groups.google.com/forum/?fromgroups#!topic/gcc-melt/PRWr28sQExk

As noted in another thread, it also affects the Python plugin:
https://fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000202.html
https://fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000204.html

> My feeling is that it is not only the plugins' fault (so it is not only a MELT plugin
> bug, but a GCC one)
> 
> 
> What do you think? Should 4.7.1 provide a fix to correct that? How? Testing simply
> ENABLE_BUILD_WITH_GCC makes me feel unhappy; that name is really confusing, if we
> understand and use it as GCC_IS_BUILT_WITH_CXX

Presumably a fix would be for the plugin's configuration phase to have a
test that tries to build a test plugin and run it, first building with a
C compiler, then a C++ compiler, and decides what compiler the real
plugin should be built with accordingly.

Presumably the only APIs that are guaranteed for use by plugins so far
are the ones directly relating to plugins themselves:
  * plugin_default_version_check
  * register_callback

I'd hoped that a suitable feature test might be a minimal test plugin
that simply tries to call plugin_default_version_check() in its init
function: that way the plugin_init can only run if the dynamic link
succeeds, and you've got the correct compiler.

However, annoyingly, in gcc-plugin.h
http://gcc.gnu.org/viewcvs/trunk/gcc/gcc-plugin.h?revision=184997&view=markup
'extern "C"' guards are present around the relevant declarations, making
these symbols unsuitable for use in a configure-time test.

So are there any plugin-visible symbols that aren't yet wrapped in an
extern "C"?

(FWIW I've been working on a possible plugin API for GCC, similar to the
one I posted in my earlier mail, trying to get my python plugin to
compile against it, but I don't have anything working yet)

> My wish would be to add, perhaps in gcc/configure.ac of GCC 4.7.1, something which
> defines GCCPLUGIN_IN_CXX in e.g.  $(gcc-4.7 -print-file-name=plugin)/plugin-version.h
> when gcc-4.7 have been built with a C++ compiler so its plugins need to be compiled with
> a C++ compiler. That information should also be accessible (e.g. for plugin makers) thru
> some invocation of GCC (perhaps gcc -v).

Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

[Joseph S. Myers]

On Mon, 26 Mar 2012, David Malcolm wrote:

> Presumably a fix would be for the plugin's configuration phase to have a
> test that tries to build a test plugin and run it, first building with a
> C compiler, then a C++ compiler, and decides what compiler the real
> plugin should be built with accordingly.

We've previously discussed providing some generic configure / build 
support for plugins (standard autoconf macros intended for use in a 
plugin's build system, for example).  If in future plugins are supported 
on Windows hosts (or any other hosts that lack a -rdynamic equivalent) 
then such generic support will be increasingly useful because of the need 
to link plugins on such hosts against a shared library or libraries that 
contain most of GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

[David Malcolm]

On Mon, 2012-03-26 at 17:07 +0000, Joseph S. Myers wrote:
> On Mon, 26 Mar 2012, David Malcolm wrote:
> 
> > Presumably a fix would be for the plugin's configuration phase to have a
> > test that tries to build a test plugin and run it, first building with a
> > C compiler, then a C++ compiler, and decides what compiler the real
> > plugin should be built with accordingly.
> 
> We've previously discussed providing some generic configure / build 
> support for plugins (standard autoconf macros intended for use in a 
> plugin's build system, for example).  If in future plugins are supported 
> on Windows hosts (or any other hosts that lack a -rdynamic equivalent) 
> then such generic support will be increasingly useful because of the need 
> to link plugins on such hosts against a shared library or libraries that 
> contain most of GCC.

I suppose now is a bad time to mention that my python plugin *doesn't*
use autoconf for its configure script - I didn't want to use m4 given
that python is available.  I'm sure I'll figure something out though.

Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

[Basile Starynkevitch]

On Mon, 26 Mar 2012 13:13:22 -0400
David Malcolm <dmalcolm@redhat.com> wrote:

> On Mon, 2012-03-26 at 17:07 +0000, Joseph S. Myers wrote:
> > On Mon, 26 Mar 2012, David Malcolm wrote:
> > 
> 
> I suppose now is a bad time to mention that my python plugin *doesn't*
> use autoconf for its configure script - I didn't want to use m4 given
> that python is available.  I'm sure I'll figure something out though.

For what it is worth, the MELT plugin don't use autoconf.

And I still think that GCC 4.7.1 should be able to tell by itself if it was compiled by C
or by C++.

Cheers.


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

Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

[Romain Geissler]

Hi,

Le 26 mars 2012 à 20:33, Basile Starynkevitch a écrit :

> 
> And I still think that GCC 4.7.1 should be able to tell by itself if it was compiled by C
> or by C++.
> 

Actually you can already find it for every GCC version you are interested in (4.6.x and 4.7.x), with very little logic, as it was pointed out to you yesterday here http://gcc.gnu.org/ml/gcc/2012-03/msg00381.html and here http://gcc.gnu.org/ml/gcc/2012-03/msg00382.html (the solution with gcc -v as using nm is not a portable solution).

This will work in most case : the targeted GCC you want to build a plugin for can be run on the build machine.

If you need to be able to cross-build a plugin on arch A for a targeted GCC running on host arch B, then you won't be able to invoke gcc -v.

Anyway there is a a solution that works all the time, all you need is being able to grep in a file for a given pattern. Just take a look at the following file :  $(gcc -print-file-name=plugin)/include/auto-host.h

You'll find something like this :

/* Define if building with C++. */
#ifndef USED_FOR_TARGET
#define ENABLE_BUILD_WITH_CXX 1
#endif

So that's it, you already got all you need for all version.

Cheers

Romain Geissler

Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

[Basile Starynkevitch]

On Mon, 26 Mar 2012 22:34:22 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:

> Hi,
> You'll find something like this :
> 
> /* Define if building with C++. */
> #ifndef USED_FOR_TARGET
> #define ENABLE_BUILD_WITH_CXX 1
> #endif
> 
> So that's it, you already got all you need for all version.
> 

I did mention ENABLE_BUILD_WITH_CXX in previous email, but I am not very satisfied by
this solution.

I really think that GCC 4.7 should explicitly tell, e.g. thru gcc -v, how it was compiled
(ie in C or in C++ mode).

This would help a lot plugin package makers (not the same as plugin developers).

Cheers.


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

Re: status of GCC & C++

[Ludovic Courtès]

Hi Basile,

Basile Starynkevitch <basile@starynkevitch.net> skribis:

> Do we have (e.g. for plugin makers) a nice way to know if a given GCC distribution was
> compiled in C or in C++ mode?

I’ve written an Autoconf macro that does that:

  http://gcc.gnu.org/ml/gcc/2012-03/msg00240.html

Thanks,
Ludo’.

Re: status of GCC & C++

[Eric Botcazou]

> Really?  To start *writing* in C++, sure we want at least an initial
> version of the coding guidelines.  I pointed to those, because they
> look like a reasonable start.
>
> To start *building* in C++, I do not think we need to agree on the
> coding guidelines.  We are already doing stages 2 and 3, doing stage 1
> is a straightforward next step.

If we start building in C++, then this would mean that you can start to use
C++ in the code.  And we agreed to settle on a set of coding guidelines before 
starting to use C++ in the code.

Building stage 1 with a C++ compiler has zero value if you don't use C++ in 
the code.  It probably even has a negative value, since it gratuitously makes 
it harder to build the compiler on exotic platforms.

-- 
Eric Botcazou