Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 02:22:43 +0200
Romain Geissler  wrote:

> 
> I tried to build the latest melt-branch (not the generated tarball) on a mac.
> Here is the few change required to allow the build (note that it builds but 
> as your
> cc/cxx detection still fails, the generated melt-runtime.o and *.so files 
> can't be
> loaded with gcc build with cxx).

Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen 
generated.
> 
> I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this
> makes no sense to test the availability of the poll function that way : just 
> use
> the function, the compiler will find it out by itself if it is really 
> defined. Moreover,
> this kind of test should be in a configure file, not in a source file. On a 
> mac,
> _POSIX_C_SOURCE is not defined by default, and defining it lead to errors
> while building other parts of GCC.

Do you have any ideas on how to make autoconf things for the MELT plugin?

Also, I was believing MacOSX needs *dylib files not *so one ?

Thanks, 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 mine, sont seulement les miennes} ***

Re: lrzip: extreme compression (but beware its slow decompression speed)

[Con Kolivas]

Jim Meyering  meyering.net> writes:

> 
> In case you're evaluating what compression programs to use...
> 
> This started off as a comparison of xz and lzip,
> but then I added lzrip to the mix.

> I started off by downloading the gcc-4.7.0.tar.bz2 release tarball
> and decompressing it, then recompressing using bzip2, lzip, xz and lrzip:
> (on a 6/12-core Fedora 17 x86_64 system with plenty of RAM)
> 
>   KiB   compression
>  size   time m:ss  file name
> --     -
> 514400 NA  gcc-4.7.0.tar
>  80588  0:58.12gcc-4.7.0.tar.bz2 (-9)
>  59556  6:16.61gcc-4.7.0.tar.lz (-9)
>  58640  5:55.78gcc-4.7.0.tar.xz (-9e)
>  48876  2:46[*]gcc-4.7.0.tar.lrz (-z -L8 -w2000)


> $ ./lrzip -d -o - gcc-4.7.0.tar.lrz > /dev/null
> 3:36.12 (note, that's 3.5 *minutes* to decompress on a 12-core system)

Nice to see you trying out lrzip. The -z option is really for extreme
compression and not necessarily regular use (think permanent archival,
distribution over slow connections), and definitely not for one time compression
where the expectation is many people will be decompressing it and decompression
speed is crucial. The default options would be a much better choice there where
lrzip basically uses a multi-threaded lzma.

Regards,
Con

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hi Ian, Joseph, and sorry for the delay.

On 03/29/2012 01:43 AM, Ian Lance Taylor wrote:
> Stefano Lattarini  writes:
> 
>>> (I think avoiding info documentation being built in the source directory,
>>> so that builds could use a non-writable source directory, may have been
>>> one part).
>>>
>> There is probably some hack to obtain this effect (it's tested in the 
>> testsuite
>> somewhere), but my opinion is that if you distribute the generated info files
>> you should also have them generated in the source directory, to avoid nasty
>> surprises (for a similar issue, involving yacc and lex, see automake 
>> bug#10852,
>> in particular messages 
>> 
>> and ).
> 
> It's useful to be able to include .info files in releases so that people
> can build the releases without having to have makeinfo installed.
>
I agree on this (as did past Automake maintainers -- in fact Automake 
distributes
generated info files be default).  But I also think that, whenever you 
distribute
generated files, the most sensible and safer thing to do is to have them 
generated
in the srcdir and not in the builddir, so that the tree from a VCS checkout and
the one extracted from a distribution tarball are similar and consistent (I held
a different opinion once, but Akim Demaille later changed my mind on this).

> It's important that it be possible to build with the sources on a
> read-only disk.
>
Yes, and in fact "make distcheck" verifies that this is possible.  However,
assuming it is also possible to *hack* a package with the sources on a read
only disk is not warranted.

In conclusion, I see two possible sane approaches w.r.t. the handling of
generated info files:

  - Have them distributed (automake's default).  This means that they will
be build in the srcdir, not in the builddir: of course, this only affects
the maintainer, since for a user that builds the package from a tarball
those files should *not* be rebuilt, hence there is no problem even if
the user's srcdir is read-only.

  - Don't distribute the generated info files.  To obtain this effect, it is
enough to list the generated into files in the CLEANFILES variable (see
for example the tests 'txinfo23', 'txinfo24' and 'txinfo25' in the automake
testsuite).  In this case, the user will have to to have the 'makeinfo'
program available to build them.

Regards,
  Stefano

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit :

> On Sat, 31 Mar 2012 02:22:43 +0200
> Romain Geissler  wrote:
> 
>> 
>> I tried to build the latest melt-branch (not the generated tarball) on a mac.
>> Here is the few change required to allow the build (note that it builds but 
>> as your
>> cc/cxx detection still fails, the generated melt-runtime.o and *.so files 
>> can't be
>> loaded with gcc build with cxx).
> 
> Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen 
> generated.

Well I know it's autogenerated, that's why i wrote 'Regenerate.' in the 
Changelog.
In such cases, i should not include the regenerated file to the patch ? Is it 
the
maintainer role to run autogen on every patch that affects *.tpl ?

>> 
>> I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this
>> makes no sense to test the availability of the poll function that way : just 
>> use
>> the function, the compiler will find it out by itself if it is really 
>> defined. Moreover,
>> this kind of test should be in a configure file, not in a source file. On a 
>> mac,
>> _POSIX_C_SOURCE is not defined by default, and defining it lead to errors
>> while building other parts of GCC.
> 
> Do you have any ideas on how to make autoconf things for the MELT plugin?

Well I currently don't know, although i already patched the GCC configuration
scripts. It's like all, just need to learn.

> 
> Also, I was believing MacOSX needs *dylib files not *so one ?

Yes dynamic libraries are named *.dylib on a mac because the dynamic
linker dyld looks for *.dylib files, and not *.so files.

OSX makes a difference between a dynamic library you can link (*.dylib)
width dyld and binaries you dynamically load on your own with dlopen
(*.bundle). So on a mac, your melt plugins should have the .bundle
extension.

But as the .so extension is hardcoded almost everywhere, i preferred keeping
the .so extension, like many other projects do (on my computer, i can see
that apache, php, valgrind, ImageMagick, python, gtk and many others just
do the same)

Romain Geissler

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Alfred M. Szmidt]

 - Have them distributed (automake's default).  This means that
   they will be build in the srcdir, not in the builddir: of
   course, this only affects the maintainer, since for a user that
   builds the package from a tarball those files should *not* be
   rebuilt, hence there is no problem even if the user's srcdir is
   read-only.

This has always been the right way to do things.

 - Don't distribute the generated info files.  [...]  In this
   case, the user will have to to have the 'makeinfo' program
   available to build them.

Please don't do this, it causes all kinds of headaches, like the small
fact that makeinfo will now be required to bootstrap.

Re: Proposed plugin API for GCC

[Romain Geissler]

Hi

Le 31 mars 2012 à 02:45, David Malcolm a écrit :

> Here's another proposal then: actually use GObject introspection -
> provide a GObject-based API to GCC.
> 
> In this approach, GCC would gain a dependency on glib and gobject, and
> expose its API via a .gir file.

I don't think adding huge dependencies only for plugins is welcomed.
A C/C++ API is far enough and quite simple to use. People that are willing
to use Gobject or anyhting else are free to wrap the wrappers.

By the way, your proposed API is promising (through i also love
CamelCasing and i'd prefered a C++ API).

Cheers

Romain Geissler

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hi Alfred.

On 03/31/2012 11:08 AM, Alfred M. Szmidt wrote:
>  - Have them distributed (automake's default).  This means that
>they will be build in the srcdir, not in the builddir: of
>course, this only affects the maintainer, since for a user that
>builds the package from a tarball those files should *not* be
>rebuilt, hence there is no problem even if the user's srcdir is
>read-only.
> 
> This has always been the right way to do things.
> 
>  - Don't distribute the generated info files.  [...]  In this
>case, the user will have to to have the 'makeinfo' program
>available to build them.
> 
> Please don't do this, it causes all kinds of headaches, like the small
> fact that makeinfo will now be required to bootstrap.
>
Note there's nothing I'm planning to do, nor I should do, in this regard:
the two setups described above are both already supported by the current
automake implementation (but the last one is not encouraged, even though
it makes perfect sense in some *rare* situations).  I was just pointing
out that you have to choose one of these setups -- so, if you want to
distribute info files, you must accept to have them build in the srcdir.

Regards,
  Stefano

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 10:52:09 +0200
Romain Geissler  wrote:

> 
> Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit :
> 
> > On Sat, 31 Mar 2012 02:22:43 +0200
> > Romain Geissler  wrote:
> > 
> >> 
> >> I tried to build the latest melt-branch (not the generated tarball) on a 
> >> mac.
> >> Here is the few change required to allow the build (note that it builds 
> >> but as your
> >> cc/cxx detection still fails, the generated melt-runtime.o and *.so files 
> >> can't be
> >> loaded with gcc build with cxx).
> > 
> > Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen 
> > generated.


Sorry, my apologies, I didn't saw the patch to melt-build.tpl later in your 
diff.

> Well I know it's autogenerated, that's why i wrote 'Regenerate.' in the 
> Changelog.
> In such cases, i should not include the regenerated file to the patch ? Is it 
> the
> maintainer role to run autogen on every patch that affects *.tpl ?

the melt-build.mk is generated from melt-build.tpl & melt-build.def; after 
running
autogen which generates melt-build.mk in the source tree, we can svn commit.

This is exactly the same practice as for configure generated from configure.ac 
in the
trunk. Contributors patch configure.ac, regenerate configure (both in the 
source tree)
and then svn commit (after patch approval) both.

For MELT, the translator itself (files gcc/melt/generated/{warmelt*.[ch]) and 
some parts
of the runtime (files gcc/melt/generated/meltrunsup*.[ch]) are also generated 
and svn
commit-ed in the trunk. FYI I use make upgrade-warmelt to regenerate them.

I am surprised of your patch which indeed contains gcc/melt-build.tpl:

-## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
-GAWK ?= gawk
+## AWK is needed [+ (. (tpl-file-line))+]
+AWK ?= awk
 

I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC 
also
requires *GNU* awk specifically (and not some other awk). Why the above patch? 
If GNU awk
is called awk on MacOS (like it is on some Linux distributions) just call it 
still GAWK in
makefile things! I'm pretty sure to not be the only one with this convention, 
that GAWK in
Makefile meen that GNU extensions of awk is necessary.


A more general question is the status of plugins on MacOSX. I thought that GCC 
plugins in
general only work for ELF shared object systems with dlopen. It seems that 
gcc/plugin.c
is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatched GCC 
4.7 (FSF
distributed) be built on MacOSX with plugins enabled and working? Does dlopen as
specified by Posix: 
http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html
etc work on MacOSX (in particular when file is NULL and mode contains 
RTLD_GLOBAL)? What
kind of file extension does it requires or appends: *.bundle, *.dylib or *.so 
on MacOSX?
If you think that plugins can easily be made working on MacOSX, please patch 
plugin.c
first if needed (and propose that to the trunk), by taking care of at least 
naming the
suffix needed for them (in a publicly available header exported to plugins), 
then
melt-runtime.h could use that.


This .so suffix is hardwired in melt-runtime.c; I am adding 
MELT_DYNLOADED_SUFFIX
constant to help going to systems with other dlopen-ed dynamic libraries 
suffixes.

I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk

I sadly think that MELT plugin would need autoconf things to be workable on non 
Linux
systems. But I really don't know autoconf (actually, I hate it) and don't know 
how to
start working on that. Can you help?

I just commited svn rev 186039 of MELT branch with some of your and mine 
changes.

I still need to replace the occurrences of .so in the MELT code itself.

Thanks.
-- 
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 mine, sont seulement les miennes} ***

Re: C++ va_list wromng code generation in class::method(...,va_list args) only

[Mikael Pettersson]

Bernd Roesch writes:
 > hello
 > 
 > there is a C++ game called dunelegacy which work on other GCC architecture ok
 > On G++ 68k it compile ok, but produce wrong code, because there seem 
 > something diffrent in
 > va_list. The value of
 > SDL_RWops is transfer wrong.
 > 
 > I do not understand what backend problem is possible to cause this. Please 
 > help.va_list use the
 > builtin GCC functions
 > 
 > this happen on all 68k compilers i test. (3.x and some 4.x)
 > 
 > See also the source attached of this class

Please read  and then enter a bug report in 
gcc's bugzilla.

The source attached here is too incomplete to be useful.

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 03/28/2012 02:19 PM, Stefano Lattarini wrote:
> Hi Joseph, thanks for the feedback.
> On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
>>
>> Is there better transition documentation somewhere?
>>
> Nope, but it would be a good idea to prepare it before starting to deprecate
> the 'cygnus' option.  Maybe even for 1.12.  Thanks for the suggestion.
>
Or even for 1.11.4, which is to be released in two/three days.  What about the
attached patch?  I will push it by this evening if there is no objection.

Thanks,
  Stefano
>From 5bb72934aa7d96e2faa90fa1c59c24f01e83c91f Mon Sep 17 00:00:00 2001
Message-Id: <5bb72934aa7d96e2faa90fa1c59c24f01e83c91f.1333193814.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini 
Date: Sat, 31 Mar 2012 11:04:41 +0200
Subject: [PATCH] docs: deprecate 'cygnus' mode, help the transition

Support for "Cygnus-style" trees (so far enabled by the 'cygnus'
option) will be deprecated in one release of the next major series
(1.12.x) and removed in the next major release after that (1.13).
Better to start warning about this in the manual.

* docs/automake.texi: Warn about the oncoming deprecation of the
'cygnus' mode.  Suggest some idioms that can be used to retain some
effects of the 'cygnus' option.
* THANKS: Update.

>From a suggestion by Joseph S. Myers in automake bug#11034.

Signed-off-by: Stefano Lattarini 
---
 THANKS|1 +
 doc/automake.texi |   68 -
 2 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/THANKS b/THANKS
index 702c97b..a2091ab 100644
--- a/THANKS
+++ b/THANKS
@@ -178,6 +178,7 @@ John Ratliff		autoc...@technoplaza.net
 John R. Cary		c...@txcorp.com
 John W. Coomes		jcoo...@eng.sun.com
 Jonathan Nieder		jrnie...@gmail.com
+Joseph S. Myers		jos...@codesourcery.com
 Josh MacDonald		jm...@cs.berkeley.edu
 Joshua Cowan		jco...@jcowan.reslife.okstate.edu
 js pendry		js.pen...@msdw.com
diff --git a/doc/automake.texi b/doc/automake.texi
index 9b6b8f5..9da5fd9 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -117,7 +117,7 @@ section entitled ``GNU Free Documentation License.''
 * Conditionals::Conditionals
 * Silencing Make::  Obtain less verbose output from @command{make}
 * Gnits::   The effect of @option{--gnu} and @option{--gnits}
-* Cygnus::  The effect of @option{--cygnus}
+* Cygnus::  The effect of @option{--cygnus} (deprecated, soon to be removed)
 * Not Enough::  When Automake is not Enough
 * Distributing::Distributing the Makefile.in
 * API Versioning::  About compatibility between Automake versions
@@ -1943,10 +1943,13 @@ standard is actually published (which may never happen).
 @xref{Gnits}, for more information on the precise implications of the
 strictness level.
 
-Automake also has a special ``cygnus'' mode that is similar to
-strictness but handled differently.  This mode is useful for packages
-that are put into a ``Cygnus'' style tree (e.g., the GCC tree).
-@xref{Cygnus}, for more information on this mode.
+Automake also has a special (and @emph{today deprecated}) ``cygnus'' mode
+that is similar to strictness but handled differently.  This mode is
+useful for packages that are put into a ``Cygnus'' style tree (e.g., older
+versions of the GCC and gdb trees).  @xref{Cygnus}, for more information
+on this mode.  Please note that this mode is deprecated and @emph{will be
+removed in the future automake versions}; you must avoid its use in new
+packages, and should stop using it in existing packages as well.
 
 
 @node Uniform
@@ -2602,6 +2605,8 @@ copied.  The default is to make a symbolic link.
 @opindex --cygnus
 Causes the generated @file{Makefile.in}s to follow Cygnus rules, instead
 of GNU or Gnits rules.  For more information, see @ref{Cygnus}.
+Note that @emph{this mode of operation is deprecated, and will be removed}
+in a future Automake release.
 
 @item -f
 @opindex -f
@@ -10322,10 +10327,15 @@ The file @file{THANKS} is required.
 
 @cindex @option{cygnus} strictness
 
-Some packages, notably GNU GCC and GNU gdb, have a build environment
-originally written at Cygnus Support (subsequently renamed Cygnus
-Solutions, and then later purchased by Red Hat).  Packages with this
-ancestry are sometimes referred to as ``Cygnus'' trees.
+@emph{The features described in this section are deprecated; you must
+not use any of them in new code, and should remove their use from older
+but still maintained code: they will be withdrawn in a future Automake
+release.}
+
+Some packages, notably GNU GCC and GNU gdb, used to have a build
+environment originally written at Cygnus Support (subsequently renamed
+Cygnus Solutions, and then later purchased by Red Hat).  Packages with
+this ancestry are sometimes referred to as ``Cygnus'' trees.
 
 A Cygnus tree has slightly different rules for how a
 @file{Makefile.in} is to be constructed.  Passing @option

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit :

> I am surprised of your patch which indeed contains gcc/melt-build.tpl:
> 
> -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
> -GAWK ?= gawk
> +## AWK is needed [+ (. (tpl-file-line))+]
> +AWK ?= awk
> 
> 
> I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, 
> GCC also
> requires *GNU* awk specifically (and not some other awk). Why the above 
> patch? If GNU awk
> is called awk on MacOS (like it is on some Linux distributions) just call it 
> still GAWK in
> makefile things! I'm pretty sure to not be the only one with this convention, 
> that GAWK in
> Makefile meen that GNU extensions of awk is necessary.

Are you sure you really need GNU awk ? I don't think so ! In my patch, i 
replaced every GAWK
uses in Melt (only the melt files that you ship in the packaged version of 
Melt, there are still
somes instances of Gawk in /contrib/MELT-Plugin-Makefile and in 
/contrib/build-melt-plugin.sh
but those are only for packagers, not for melt users). The gawk usage i 
replaced were trivial
uses that DO NOT use specific GNU awk features (on printing and using the 
{next} command).

I've take a look at the different GCC configure scripts, and it only looks for 
one awk implementation
in that order : for ac_prog in gawk mawk nawk awk. There is no further check 
performed to know
if it is GNU awk or not, as all uses are conforming to the common awk 
specifications.

You may fix my patch so that it first looks for gawk, then mawk, then nawk then 
finally awk. But
again i'd better see this kind of test in a configure script. Usually, if one 
awk program exists (may
it be gawk, mawk or nawk) then awk will also do (typically a symlink to the 
right executable).

On a mac, only the classical awk version is shipped by default by Apple, not 
GNU awk.

> A more general question is the status of plugins on MacOSX. I thought that 
> GCC plugins in
> general only work for ELF shared object systems with dlopen. It seems that 
> gcc/plugin.c
> is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatched 
> GCC 4.7 (FSF
> distributed) be built on MacOSX with plugins enabled and working?

Plugins works fine on Darwin with an unpatched GCC 4.6 or 4.7, you just need to 
know that
building a bundle is made with -bundle -undefined dynamic_lookup instead of 
-shared. My
plugins work, and so does Dragon Egg in the LLVM project.

> Does dlopen as
> specified by Posix: 
> http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html
> etc work on MacOSX (in particular when file is NULL and mode contains 
> RTLD_GLOBAL)?

From the man page shipped by Apple, i see :
If a null pointer is passed in path, dlopen() returns a handle equivalent to 
RTLD_DEFAULT.

So i think the uses of dlopen made by gcc and melt might work on a mac.

> What
> kind of file extension does it requires or appends: *.bundle, *.dylib or *.so 
> on MacOSX?
> If you think that plugins can easily be made working on MacOSX, please patch 
> plugin.c
> first if needed (and propose that to the trunk), by taking care of at least 
> naming the
> suffix needed for them (in a publicly available header exported to plugins), 
> then
> melt-runtime.h could use that.

No extension is required it could be *.anything. By convention, on Darwin, we 
should
call those files *.bundle. I'll patch gcc so that it looks for *.bundle instead 
of *.so. We'll
see if it's accepted.

> This .so suffix is hardwired in melt-runtime.c; I am adding 
> MELT_DYNLOADED_SUFFIX
> constant to help going to systems with other dlopen-ed dynamic libraries 
> suffixes.
> 
> I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk
> 
> I sadly think that MELT plugin would need autoconf things to be workable on 
> non Linux
> systems. But I really don't know autoconf (actually, I hate it) and don't 
> know how to
> start working on that. Can you help?

I might help, just need some time. Building properly melt with a much efficient 
Makefile
is more important for now, I thinl. I'll keep my specific OSX change for me for 
now, until
other things work well on ELF platforms (as the only native OS i have is OSX, I 
don't want
to loose time building GCC in a virtual machine).

> I just commited svn rev 186039 of MELT branch with some of your and mine 
> changes.
> 
> I still need to replace the occurrences of .so in the MELT code itself.
> 
> Thanks.
> -- 
> 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 mine, sont seulement les miennes} ***

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 13:55, Romain Geissler a écrit :

> 
> Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit :
> 
>> I am surprised of your patch which indeed contains gcc/melt-build.tpl:
>> 
>> -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
>> -GAWK ?= gawk
>> +## AWK is needed [+ (. (tpl-file-line))+]
>> +AWK ?= awk
>> 
>> 
>> I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, 
>> GCC also
>> requires *GNU* awk specifically (and not some other awk). Why the above 
>> patch? If GNU awk
>> is called awk on MacOS (like it is on some Linux distributions) just call it 
>> still GAWK in
>> makefile things! I'm pretty sure to not be the only one with this 
>> convention, that GAWK in
>> Makefile meen that GNU extensions of awk is necessary.
> 
> Are you sure you really need GNU awk ? I don't think so ! In my patch, i 
> replaced every GAWK
> uses in Melt (only the melt files that you ship in the packaged version of 
> Melt, there are still
> somes instances of Gawk in /contrib/MELT-Plugin-Makefile and in 
> /contrib/build-melt-plugin.sh
> but those are only for packagers, not for melt users). The gawk usage i 
> replaced were trivial
> uses that DO NOT use specific GNU awk features (on printing and using the 
> {next} command).

I forgot to add add that the awk usages you perform are so trivial that grep 
will also fits your needs
and is a lower dependency than awk.

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 14:02:45 +0200
Romain Geissler  wrote:

> 
> I forgot to add add that the awk usages you perform are so trivial that grep 
> will also fits your needs
> and is a lower dependency than awk.


I am not sure of that. MELT need several awk scripts, make-melt-predefh.awk &
make-warmelt-predef.awk which probably uses some GNU things. (I think that 
printf in AWK
script is a GNU extension).

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 mine, sont seulement les miennes} ***

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Jonathan Wakely]

On 31 March 2012 13:38, Basile Starynkevitch wrote:
>
> (I think that printf in AWK script is a GNU extension).

Nope, it's standard.

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 15:07, Jonathan Wakely a écrit :

> On 31 March 2012 13:38, Basile Starynkevitch wrote:
>> 
>> (I think that printf in AWK script is a GNU extension).
> 
> Nope, it's standard.

Yeah it is. I looked at your the melt files in contrib (that's quite
strange that the Makefile used to build the melt plugin is
located in here through, files in the contrib directory should
not be mandatory to build gcc !).

It seems that among all your gawk uses, including
make-warmelt-predef.awk and make-melt-predefh.awk
the only GNU specific feature is strtonum. But you don't need it,
as the following works with regular awk :

echo 4.7.0  | awk '{split($1,vertab,"."); printf "%d", 
vertab[1]*1000+vertab[2]}'

By looking at your awk calls, i think you've got some errors in
MELT-Plugin-Makefile at the following line:

MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | 
$(GAWK) "/^gcc version/{print $$3}")

Notice the $$3 at the end, showing you only need the version number.
This line currently outputs something like:
gcc version 4.7.0 20120115 (experimental) (GCC)

If you change double quote by single quote like this:
MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | 
$(GAWK) '/^gcc version/{print $$3}')

It'll output:
4.7.0

If you change this, then you'll also have to change this line:
echo "$(MELTGCC_VERSION)"  | $(GAWK) '{split($$3,vertab,"."); printf "%d", 
strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@

to this:
echo "$(MELTGCC_VERSION)"  | $(GAWK) '{split($$1,vertab,"."); printf "%d", 
strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@

(notice $$3 becomes $$1)

Romain Geissler

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 15:55:50 +0200
Romain Geissler  wrote:

> Le 31 mars 2012 à 15:07, Jonathan Wakely a écrit :
> 
> > On 31 March 2012 13:38, Basile Starynkevitch wrote:
> >> 
> >> (I think that printf in AWK script is a GNU extension).
> > 
> > Nope, it's standard.
> 
> Yeah it is. I looked at your the melt files in contrib (that's quite
> strange that the Makefile used to build the melt plugin is
> located in here through, files in the contrib directory should
> not be mandatory to build gcc !).

No, it is not strange: indeed the MELT *branch* has a file 
contrib/MELT-Plugin-Makefile
which is used for the *MELT* plugin (but is useless for the MELT *branch*, 
which has its
own gcc/Makefile.in).

But the MELT plugin is not useful for the MELT branch. When you build a 
gcc-melt from the
MELT branch, there is no melt.so file involved, the melt-runtime.o is 
statically linked
inside cc1 (and cc1plus, etc etc...) and the MELT runtime is automagically 
started as a
pseudo-plugin without any dlopen-ing. the MELT initialization phase is indeed 
dlopen-ing
MELT modules (as does the melt.so plugin for a regular GCC), because toplev.c 
of the MELT
branch calls melt_initialize() and melt_finalize().

So, when building the MELT *branch* (which few people do), you don't need or use
contrib/MELT-Plugin-Makefile.

When I extract the MELT plugin from the MELT branch (e.g. for MELT plugin 
releases) with
the procedure in 
https://groups.google.com/group/gcc-melt/msg/083091abb7f30c39?hl=en the
MELT-Plugin-Makefile is becoming the Makefile for the extracted plugin. But the 
MELT
branch don't need it, so it sits in rightly contrib/MELT-Plugin-Makefile


> It seems that among all your gawk uses, including
> make-warmelt-predef.awk and make-melt-predefh.awk
> the only GNU specific feature is strtonum. But you don't need it,
> as the following works with regular awk :
> 
> echo 4.7.0  | awk '{split($1,vertab,"."); printf "%d", 
> vertab[1]*1000+vertab[2]}'
> 
> By looking at your awk calls, i think you've got some errors in
> MELT-Plugin-Makefile at the following line:
> 
> MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 
> | $(GAWK) "/^gcc version/{print $$3}")

Corrected and commited svn rev 186044.

Thanks
-- 
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 mine, sont seulement les miennes} ***

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 03/31/2012 01:38 PM, Stefano Lattarini wrote:
> On 03/28/2012 02:19 PM, Stefano Lattarini wrote:
>> Hi Joseph, thanks for the feedback.
>> On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
>>>
>>> Is there better transition documentation somewhere?
>>>
>> Nope, but it would be a good idea to prepare it before starting to deprecate
>> the 'cygnus' option.  Maybe even for 1.12.  Thanks for the suggestion.
>>
> Or even for 1.11.4, which is to be released in two/three days.  What about the
> attached patch?  I will push it by this evening if there is no objection.
> 
Applied to maint, merged into master and branch-1.11, and pushed.

Regards,
  Stefano

Plugins always enabled in GCC 4.8?

[Basile Starynkevitch]

Hello All,

If we want to aim towards a more modular GCC made of several shared libraries, 
it seems
that we are requiring the host system to have dynamic libraries (which is not a 
big deal
today; all the major OSes running on developers desktop or laptop have them). 

In that case, I think that we should always --enable-plugin at configure time, 
hence
making that configure switch useless (since always on).

What do you think?

Do we aim at running next GCC on systems without dynamic libraries or withour 
plugins?
(If yes, why and which ones)?

Likewise, I also hope that next GCC will be only C++ compilable (and that we 
remove the
ability to compile it with C)


More generally, I would like a description, or a list of host systems for GCC. 
What kind
of system services [e.g. dlopen, time, ...] to we require GCC to access to?


Regards.
-- 
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 mine, sont seulement les miennes} ***

gcc-4.7-20120331 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch 
revision 186050

You'll find:

 gcc-4.7-20120331.tar.bz2 Complete GCC

  MD5=87c2ec844cfd6782afda14d12b997c01
  SHA1=16ff27c5aa68395b82c7e9530f115760efac341c

Diffs from 4.7-20120324 are available in the diffs/ subdirectory.

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

[proposal] make gcc5 become the base of GNU operating system

[Jacky Lau]

There are two trends in the computer industry:
1) there are a variety of CPU architectures exist in any one area. For
example, in the server area, there are power, sparc, mips, x86, and
even arm, in the mobile internet device area, there are arm, x86, and
even mips.
2) new programming language is emerging, and some became popular. For
example, scala, google go, as well as a variety of domain-specific
language (DSL).

So I think that the next-generation operating system architecture will
be a micro-kernel that contains a language virtual machine, plus a
variety of system components which was writen by different languages.
Components outside the kernel in form of bytecode and executed by the
in-kernel JIT VM. In this type of operating system, developers can
select the most suitable language to develop the various components.
Developer can even develop a new general-purpose programming language
or domain-specific language if he can't find a suitable language. For
example, a device driver language for writing device driver.

In this architecture, compiler technology has become the
infrastructure. This is what gcc good at. Therefore, we should
consider make gcc5 become the base of the real Gnu-isNot-Unix
operating system. First we should define the VM and bytecode and then
write the the JIT VM, followed by make the core of gcc as libraries,
and provides them to compiler. IMHO, the micro-kernel is not
necessarily l4, the operating system interface may not be posix,
driver can be writen by using a DSL.

This operating system sounds like Inferno, or Jxos/JNode, or
Singularity/Midori. Indeed, I think that this operating system can
adapt to future of the computer industry. For those who consider too
much on performance, I hope you will think about why is human rather
than tiger or lion rule the earth.

In addition there are two trends: multicore cpu has become popular,
and cloud computing has become popular. The MIT's fos, and the ETH
Zurich's Barrelfish are two research OS which was developed in
response to this change, and can be used for refering. I really want
GNU to be a technically innovative operating system rather than
another UNIX.