pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

8 views
Skip to first unread message

Basile Starynkevitch

unread,
Mar 29, 2012, 4:02:07 PM3/29/12
to gcc-...@googlegroups.com, g...@gcc.gnu.org

Hello All,

The pre-release candidate 1 of MELT 0.9.5 is available for testing on
http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
as a gzipped tar archive of 4473286 bytes and md5sum ae00b9bd31f481e1bbc406711ca4c2f4.
extracted from MELT branch 185969, march 29th 2012

You could try building it e.g. with
make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7
It seems to be also buildable for GCC 4.6 with
make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6

(both commands sort of work, with perhaps minor issues very late in the build process;
I'm not very afraid of these)

But I'm trying to code a makefile which would autodetect in GCC 4.7 was compiled in C++
mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7
configured in a weird fashion).

So far I tried to code in my Makefile the following trick
############################################################################
## the compiler with which melt.so is used
ifndef MELTGCC
MELTGCC = $(or $(CC),gcc)
endif

## gives yes if MELTGCC has been built with C++ or else the empty string
MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \
`$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)

## The compiler and flags used to build the melt.so plugin and to
## compile MELT generated code. Notice that melt-module.mk use the
## same Make variables. For a melt plugin to GCC 4.7 or later, that
## could be a C++ compiler! eg
## make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7
## hence we add a test if $(MELTGCC) was built with C++ or with C
ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),)
GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat
else
GCCMELT_CC ?= $(or $(CXX),g++)
endif

GCCMELT_CFLAGS ?= -g -O -Wall

$(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= $(GCCMELT_CC) \
flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \
$(MELTGCC_BUILD_WITH_CXX)))
### rest of makefile skipped
#############################################################################

but for some reason it does not work. (Maybe a := versus = make variable thing).

Do you have any suggestions about such things? Assuming a plugin whose source code
should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled in C++ or
in C mode? What am I doing wrong?

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} ***

Romain Geissler

unread,
Mar 29, 2012, 4:45:27 PM3/29/12
to gcc-...@googlegroups.com, g...@gcc.gnu.org

> --
> Message from the http://groups.google.com/group/gcc-melt group.
> About GCC MELT http://gcc-melt.org/ a high level domain specific language to code extensions to the Gnu Compiler Collection

Hi,

You almost got it. You simply need to backslash escape the '+' operator in your regexp.
Also, it would be welcome to allow any blank chars to separate words, not any the space char
(\t for example). Thus, i changed space ' ' by [[:space:]] (tested with GNU grep).

MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \


`$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)

Anyway, as i already told you, you don't look for gengtype and gtype.state at the right place.

Romain Geissler

Basile Starynkevitch

unread,
Mar 29, 2012, 5:03:09 PM3/29/12
to gcc-...@googlegroups.com, Romain Geissler, g...@gcc.gnu.org
On Thu, 29 Mar 2012 22:45:27 +0200
Romain Geissler <romain....@gmail.com> wrote:

> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
> `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
>

Thanks; I applied that patch with


2012-03-29 Romain Geissler <romain....@gmail.com>
* MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep.


(I will test it tomorrow)
Cheers.

Romain Geissler

unread,
Mar 29, 2012, 5:29:40 PM3/29/12
to Basile Starynkevitch, gcc-...@googlegroups.com, g...@gcc.gnu.org

Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit :

> On Thu, 29 Mar 2012 22:45:27 +0200
> Romain Geissler <romain....@gmail.com> wrote:
>
>> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
>> `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
>>
>
> Thanks; I applied that patch with
>
>
> 2012-03-29 Romain Geissler <romain....@gmail.com>
> * MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep.
>
>
> (I will test it tomorrow)
> Cheers.

You've made a typo will copy/pasting part of the line. Look at the dollar $ char
near '=$ (shell)', the space is misplaced. It should be '= $(shell'.

Romain Geissler

Basile Starynkevitch

unread,
Mar 30, 2012, 1:21:38 AM3/30/12
to Romain Geissler, gcc-...@googlegroups.com, g...@gcc.gnu.org
On Thu, 29 Mar 2012 23:29:40 +0200
Romain Geissler <romain....@gmail.com> wrote:
>
> You've made a typo will copy/pasting part of the line. Look at the dollar $ char
> near '=$ (shell)', the space is misplaced. It should be '= $(shell'.


Thanks! Corrected.

Basile Starynkevitch

unread,
Mar 30, 2012, 5:40:41 AM3/30/12
to gcc-...@googlegroups.com, Basile Starynkevitch, g...@gcc.gnu.org
Hello

If you want to help me on the makefile issues for the next MELT plugin
release 0.9.5, please extract the MELT plugin from the svn repository, since
I am making small changes (which still don't work) since 0.9.5rc1

The procedure to extract the MELT plugin from the MELT brannch is:

Retrieve the MELT branch if you don't have it

svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt

Go into it

cd gcc-melt

Run the update to be sure to have the latest SVN & to gernerate the REVISION
etc files

./contrib/gcc_update

Run the following script to get the MELT plugin tarball

./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin

You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin
tarball corresponding to your state of the MELT branch

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

Romain Geissler

unread,
Mar 30, 2012, 8:22:43 PM3/30/12
to gcc-...@googlegroups.com, Basile Starynkevitch, g...@gcc.gnu.org

Hi,

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).

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.

Romain Geissler

melt-mac-build.Changelog
melt-mac-build.diff

Basile Starynkevitch

unread,
Mar 31, 2012, 3:07:54 AM3/31/12
to Romain Geissler, gcc-...@googlegroups.com, g...@gcc.gnu.org
On Sat, 31 Mar 2012 02:22:43 +0200
Romain Geissler <romain....@gmail.com> 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: 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} ***

Romain Geissler

unread,
Mar 31, 2012, 4:52:09 AM3/31/12
to Basile Starynkevitch, gcc-...@googlegroups.com, g...@gcc.gnu.org

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

> On Sat, 31 Mar 2012 02:22:43 +0200
> Romain Geissler <romain....@gmail.com> 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

Basile Starynkevitch

unread,
Mar 31, 2012, 6:27:43 AM3/31/12
to Romain Geissler, gcc-...@googlegroups.com, g...@gcc.gnu.org
On Sat, 31 Mar 2012 10:52:09 +0200
Romain Geissler <romain....@gmail.com> wrote:

>
> Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit :
>
> > On Sat, 31 Mar 2012 02:22:43 +0200
> > Romain Geissler <romain....@gmail.com> 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.

Romain Geissler

unread,
Mar 31, 2012, 7:55:30 AM3/31/12
to Basile Starynkevitch, gcc-...@googlegroups.com, g...@gcc.gnu.org

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).

Romain Geissler

unread,
Mar 31, 2012, 8:02:45 AM3/31/12
to Basile Starynkevitch, gcc-...@googlegroups.com, g...@gcc.gnu.org

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.

Basile Starynkevitch

unread,
Mar 31, 2012, 8:38:41 AM3/31/12
to gcc-...@googlegroups.com, Romain Geissler, g...@gcc.gnu.org
On Sat, 31 Mar 2012 14:02:45 +0200
Romain Geissler <romain....@gmail.com> 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

Romain Geissler

unread,
Mar 31, 2012, 9:55:50 AM3/31/12
to Jonathan Wakely, Basile Starynkevitch, gcc-...@googlegroups.com, g...@gcc.gnu.org
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

Alexandre Lissy

unread,
Mar 31, 2012, 10:09:05 AM3/31/12
to gcc-...@googlegroups.com
Le 29/03/2012 22:02, Basile Starynkevitch a �crit :

Building now works, it fails at melt-tiny-tests level, however output is
such a mess I can't even understand where it fails ...

$ LC_ALL=C make melt-tiny-tests
MELT plugin for MELTGCC= cc to be compiled with GCCMELT_CC= cc
-Wc++-compat flags -g -O -Wall
melt-build.mk:68: unknown melt_make_module_dir ::: directory containing
the *.so files when making MELT
melt-build.mk:117: unknown melt_xtra_cflags ::: th CFLAGS for compiling
extra applicative C code - often empty
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 161190 Mar 27 16:36
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-first.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-first.melt
warmelt-first.melt
'warmelt-first.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-first.melt'
ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/generated/warmelt-genobj+melttime.h
melt-stage0-quicklybuilt/
'melt-stage0-quicklybuilt/warmelt-genobj+melttime.h' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/generated/warmelt-genobj+melttime.h'
ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/generated/warmelt-modes+melttime.h
melt-stage0-quicklybuilt/
'melt-stage0-quicklybuilt/warmelt-modes+melttime.h' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/generated/warmelt-modes+melttime.h'
date +"#melt-stage1/warmelt.modlis generated %F" >
melt-stage1/warmelt.modlis-tmp
echo warmelt-first.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-base.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-debug.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-macro.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-normal.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-normatch.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-genobj.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-outobj.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
echo warmelt-modes.quicklybuilt >> melt-stage1/warmelt.modlis-tmp
/bin/sh move-if-change melt-stage1/warmelt.modlis-tmp
melt-stage1/warmelt.modlis
date +"#melt-stage2/warmelt.modlis generated %F" >
melt-stage2/warmelt.modlis-tmp
echo warmelt-first.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-base.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-debug.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-macro.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-normal.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-normatch.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-genobj.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-outobj.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
echo warmelt-modes.quicklybuilt >> melt-stage2/warmelt.modlis-tmp
/bin/sh move-if-change melt-stage2/warmelt.modlis-tmp
melt-stage2/warmelt.modlis
date +"#melt-stage3/warmelt.modlis generated %F" >
melt-stage3/warmelt.modlis-tmp
echo warmelt-first.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-base.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-debug.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-macro.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-normal.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-normatch.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-genobj.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-outobj.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
echo warmelt-modes.quicklybuilt >> melt-stage3/warmelt.modlis-tmp
/bin/sh move-if-change melt-stage3/warmelt.modlis-tmp
melt-stage3/warmelt.modlis
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 150955 Mar 27 16:36
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-base.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-base.melt
warmelt-base.melt
'warmelt-base.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-base.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 48777 Mar 27 16:36
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-debug.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-debug.melt
warmelt-debug.melt
'warmelt-debug.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-debug.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 238712 Mar 4 14:10
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-macro.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-macro.melt
warmelt-macro.melt
'warmelt-macro.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-macro.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 258799 Mar 9 18:09
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-normal.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-normal.melt
warmelt-normal.melt
'warmelt-normal.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-normal.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 266593 Mar 9 18:09
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-normatch.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-normatch.melt
warmelt-normatch.melt
'warmelt-normatch.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-normatch.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 230228 Mar 29 19:04
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-genobj.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-genobj.melt
warmelt-genobj.melt
'warmelt-genobj.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-genobj.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 206808 Mar 29 19:04
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-outobj.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-outobj.melt
warmelt-outobj.melt
'warmelt-outobj.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-outobj.melt'
from melt-build.tpl line 497
-rw-r--r-- 1 alex alex 143516 Mar 27 16:36
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-modes.melt
cd melt-sources; ln -sv -v -f
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-modes.melt
warmelt-modes.melt
'warmelt-modes.melt' ->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/warmelt-modes.melt'
building quicklybuilt module list melt-default-modules-quicklybuilt.modlis
date +"# MELT module quicklybuilt list
melt-default-modules-quicklybuilt.modlis generated %F" >
melt-default-modules-quicklybuilt.modlis-tmp
echo "# quicklybuilt translator files" >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-first.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-base.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-debug.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-macro.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-normal.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-normatch.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-genobj.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-outobj.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo warmelt-modes.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo "# quicklybuilt application files" >>
melt-default-modules-quicklybuilt.modlis-tmp
echo xtramelt-ana-base.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo xtramelt-ana-simple.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo xtramelt-c-generator.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo xtramelt-opengpu.quicklybuilt >>
melt-default-modules-quicklybuilt.modlis-tmp
echo "# end melt-default-modules-quicklybuilt.modlis" >>
melt-default-modules-quicklybuilt.modlis-tmp
/bin/sh move-if-change melt-default-modules-quicklybuilt.modlis-tmp
melt-default-modules-quicklybuilt.modlis
building optimized module list melt-default-modules-optimized.modlis
date +"# MELT module optimized list
melt-default-modules-optimized.modlis generated %F" >
melt-default-modules-optimized.modlis-tmp
echo "# optimized translator files" >>
melt-default-modules-optimized.modlis-tmp
echo warmelt-first.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-base.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-debug.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-macro.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-normal.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-normatch.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-genobj.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-outobj.optimized >> melt-default-modules-optimized.modlis-tmp
echo warmelt-modes.optimized >> melt-default-modules-optimized.modlis-tmp
echo "# optimized application files" >>
melt-default-modules-optimized.modlis-tmp
echo xtramelt-ana-base.optimized >>
melt-default-modules-optimized.modlis-tmp
echo xtramelt-ana-simple.optimized >>
melt-default-modules-optimized.modlis-tmp
echo xtramelt-c-generator.optimized >>
melt-default-modules-optimized.modlis-tmp
echo xtramelt-opengpu.optimized >> melt-default-modules-optimized.modlis-tmp
echo "# end melt-default-modules-optimized.modlis" >>
melt-default-modules-optimized.modlis-tmp
/bin/sh move-if-change melt-default-modules-optimized.modlis-tmp
melt-default-modules-optimized.modlis
building debugnoline module list melt-default-modules-debugnoline.modlis
date +"# MELT module debugnoline list
melt-default-modules-debugnoline.modlis generated %F" >
melt-default-modules-debugnoline.modlis-tmp
echo "# debugnoline translator files" >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-first.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-base.debugnoline >> melt-default-modules-debugnoline.modlis-tmp
echo warmelt-debug.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-macro.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-normal.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-normatch.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-genobj.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-outobj.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo warmelt-modes.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo "# debugnoline application files" >>
melt-default-modules-debugnoline.modlis-tmp
echo xtramelt-ana-base.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo xtramelt-ana-simple.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo xtramelt-c-generator.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo xtramelt-opengpu.debugnoline >>
melt-default-modules-debugnoline.modlis-tmp
echo "# end melt-default-modules-debugnoline.modlis" >>
melt-default-modules-debugnoline.modlis-tmp
/bin/sh move-if-change melt-default-modules-debugnoline.modlis-tmp
melt-default-modules-debugnoline.modlis
cd ./ ; ln -sv -v -f melt-default-modules-optimized.modlis
melt-default-modules.modlis
'melt-default-modules.modlis' -> 'melt-default-modules-optimized.modlis'
doing melt-tiny-tests from melt-build.tpl line 663

melt-sayhello.args:-fplugin=/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt.so
-I
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
-o /dev/null -Wno-shadow -fplugin-arg-melt-mode=translatefile
-fplugin-arg-melt-module-makefile=melt-module.mk
-fplugin-arg-melt-module-make-command=make
-fplugin-arg-melt-module-cflags='-I
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
-I
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/generated
-DIN_GCC -DMELT_IS_PLUGIN -I
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/include -I
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/include/c-family '
-fplugin-arg-melt-tempdir=. -fplugin-arg-melt-arg=melt-sayhello.melt
-frandom-seed=127425777697840145420f9a
-fplugin-arg-melt-module-path=/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-modules
-fplugin-arg-melt-source-path=/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-sources
-fplugin-arg-melt-workdir=melt-workdir
-fplugin-arg-melt-inhibit-auto-build
-fplugin-arg-melt-output=melt-sayhello empty-file-for-melt.c
***** doing melt-sayhello from melt-build.tpl line 671
cc -c @melt-sayhello.args
cc1: warning: MELT with bad builtin source directory
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/melt-sources : No
such file or directory [enabled by default]
cc1: warning: MELT with bad builtin module directory
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/melt-modules : No
such file or directory [enabled by default]
cc1: warning: MELT cannot access module makefile
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/melt-module.mk :
No such file or directory [enabled by default]
cc1: note: MELT INFORM [#0]: reading from file - melt-sayhello.melt
cc1: warning: MELT expanding a short (1) list of s-expressions [enabled
by default]
cc1: warning: MELT expanded list of 1 s-expressions into short list of 1
source elements [enabled by default]
cc1: warning: MELT expanded few (1) expresssions [enabled by default]
cc1: note: MELT generating C code of module melt-sayhello
cc1: note: MELT generated same file melt-sayhello.c in
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
cc1: note: MELT generated C code of module melt-sayhello with 0
secondary files in 0 CPU millisec.

melt-sayhello-run.args:-fplugin=/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt.so
-I
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
-o /dev/null -Wno-shadow -fplugin-arg-melt-mode=runfile
-fplugin-arg-melt-module-makefile=melt-module.mk
-fplugin-arg-melt-module-make-command=make
-fplugin-arg-melt-module-cflags='-I
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
-I
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt/generated
-DIN_GCC -DMELT_IS_PLUGIN -I
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/include -I
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/include/c-family '
-fplugin-arg-melt-tempdir=.
-fplugin-arg-melt-init=@melt-default-modules-quicklybuilt
-fplugin-arg-melt-arg=melt-sayhello.melt
-frandom-seed=127425777697840145420f9a
-fplugin-arg-melt-module-path=/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-modules
-fplugin-arg-melt-source-path=/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-sources
-fplugin-arg-melt-workdir=melt-workdir
-fplugin-arg-melt-inhibit-auto-build
-fplugin-arg-melt-output=melt-sayhello empty-file-for-melt.c
***** doing melt-sayhello-run from melt-build.tpl line 681
cc -c @melt-sayhello-run.args
cc1: warning: MELT with bad builtin source directory
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/melt-sources : No
such file or directory [enabled by default]
cc1: warning: MELT with bad builtin module directory
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/melt-modules : No
such file or directory [enabled by default]
cc1: warning: MELT cannot access module makefile
/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.7.0/plugin/melt-module.mk :
No such file or directory [enabled by default]
cc1: note: MELT INFORM [#152]: reading from file - melt-sayhello.melt
cc1: warning: MELT expanding a short (1) list of s-expressions [enabled
by default]
cc1: warning: MELT expanded list of 1 s-expressions into short list of 1
source elements [enabled by default]
cc1: warning: MELT expanded few (1) expresssions [enabled by default]
cc1: note: MELT generating C code of module melt-sayhello
cc1: note: MELT generated same file melt-sayhello.c in
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
cc1: note: MELT generated C code of module melt-sayhello with 0
secondary files in 0 CPU millisec.

MELT is building binary melt-sayhello from source melt-sayhello with
flavor quicklybuilt
@+@melt-module inf=
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-workdir/melt-sayhello.3960e30119d46b6e1fffbb9d2b565600.quicklybuilt.so
at=
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-sayhello.quicklybuilt.so
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-sayhello.quicklybuilt.so'
->
'/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7/melt-workdir/melt-sayhello.3960e30119d46b6e1fffbb9d2b565600.quicklybuilt.so'
cc1: note: MELT plugin has built module melt-sayhello flavor
quicklybuilt in
/home/alex/BuildSystem/gcc-plugin-melt/BUILD/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7
hello_from_MELT on Sat Mar 31 16:02:31 2012 pid 19794
[ -d include-fixed ] && echo -Iinclude-fixed/ >> meltframe.args-tmp
make: *** [melt-tiny-tests] Error 1

Alexandre Lissy

unread,
Mar 31, 2012, 10:13:09 AM3/31/12
to gcc-...@googlegroups.com
Le 31/03/2012 16:09, Alexandre Lissy a �crit :

changing "[ -d include-fixed ] && echo -Iinclude-fixed/ >>
meltframe.args-tmp" to "[ -d include-fixed ] && echo -Iinclude-fixed/ >>
meltframe.args-tmp || true" did the trick. However I dunno if it's okay.

Basile Starynkevitch

unread,
Mar 31, 2012, 10:30:14 AM3/31/12
to Romain Geissler, Jonathan Wakely, gcc-...@googlegroups.com, g...@gcc.gnu.org
On Sat, 31 Mar 2012 15:55:50 +0200
Romain Geissler <romain....@gmail.com> 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

Alexandre Lissy

unread,
Mar 31, 2012, 11:02:11 AM3/31/12
to gcc-...@googlegroups.com
Le 31/03/2012 16:13, Alexandre Lissy a �crit :

After building and installing rc1, here is what I get when trying to
build talpo:
g++ -fplugin=melt -fplugin-arg-melt-mode=translatetomodule
-fplugin-arg-melt-tempdir=. -fplugin-arg-melt-arg=talpo_init_test.melt
-c empty.c
cc1plus: note: MELT INFORM [#0]: reading from file - talpo_init_test.melt
cc1plus: note: MELT generating C code of module talpo_init_test
talpo_init_test.melt:1:2: error: Melt Error[#0]: undefined operator;
unknown name - COMMENT
talpo_init_test.melt:26:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFPRIMITIVE
talpo_init_test.melt:32:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFCLASS
talpo_init_test.melt:42:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFCLASS
talpo_init_test.melt:56:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFCLASS
talpo_init_test.melt:66:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFINSTANCE
talpo_init_test.melt:72:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFINSTANCE
talpo_init_test.melt:78:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFINSTANCE
talpo_init_test.melt:83:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:94:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:112:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:131:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:171:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:186:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:205:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:224:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFCLASS
talpo_init_test.melt:240:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:287:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:314:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:379:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:395:2: error: Melt Error[#0]: undefined operator;
unknown name - DEFUN
talpo_init_test.melt:423:2: error: Melt Error[#0]: undefined operator;
unknown name - EXPORT_CLASS
talpo_init_test.melt:429:2: error: Melt Error[#0]: undefined operator;
unknown name - EXPORT_VALUES

Alexandre Lissy

unread,
Mar 31, 2012, 11:04:48 AM3/31/12
to gcc-...@googlegroups.com, Pierre Vittet, Basile Starynkevitch
Le 31/03/2012 17:02, Alexandre Lissy a �crit :

Sorry, full trace is here:
$ LC_ALL=C bm -l SPECS/talpo.spec
creating package list
processing package talpo-0.0.20120331.2gitdb98987-1
building source and binary packages
Executing(%prep): /bin/sh -e
/home/alex/BuildSystem/talpo/BUILDROOT/rpm-tmp.45667
+ umask 022
+ cd /home/alex/BuildSystem/talpo/BUILD
+ '[' 1 -eq 1 ']'
+ '[' 1 -eq 1 ']'
+ '[' 1 -eq 1 ']'
+ cd /home/alex/BuildSystem/talpo/BUILD
+ rm -rf talpo-0.0.20120331.2gitdb98987
+ /usr/bin/bzip2 -dc
/home/alex/BuildSystem/talpo/SOURCES/talpo-0.0.20120331.2gitdb98987.tar.bz2
+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd talpo-0.0.20120331.2gitdb98987
+ exit 0
Executing(%build): /bin/sh -e
/home/alex/BuildSystem/talpo/BUILDROOT/rpm-tmp.45667
+ umask 022
+ cd /home/alex/BuildSystem/talpo/BUILD
+ cd talpo-0.0.20120331.2gitdb98987
+ '[' 1 -eq 1 ']'
+ '[' 1 -eq 1 ']'
+ make -f Makefile-plugin CC=g++
touch empty.c
rm -vf talpo.modlis
echo talpo_init_test talpo_test_search_cond talpo_test_followed_by
talpo_test_immediatly_followed_by talpo_arg_direct_arg talpo_arg_pragma
talpo_arg_from_file talpo_dispatcher | sed 's/ /\n/g' >talpo.modlis

cc1plus: error: MELT fatal failure from warmelt-outobj.melt:4854 [MELT
built Mar 31 2012]
cc1plus: error: MELT failed at warmelt-outobj.melt:4854 in directory
/home/alex/BuildSystem/talpo/BUILD/talpo-0.0.20120331.2gitdb98987

SHORT BACKTRACE[#0] MELT fatal failure;
#1:<TRANSLATE_MACROEXPANDED_LIST @warmelt-outobj.melt:4760>
warmelt-outobj.fdbbdeeb1fba1830fd30df48874cd0a9.optimized.so
?
#2:<COMPILE_LIST_SEXPR @warmelt-outobj.melt:5048>
warmelt-outobj.fdbbdeeb1fba1830fd30df48874cd0a9.optimized.so
?
#3:<TRANSLATE_TO_C_ONE_OR_MORE_MELT_FILES @warmelt-outobj.melt:5110>
warmelt-outobj.fdbbdeeb1fba1830fd30df48874cd0a9.optimized.so
?
#4:<TRANSLATE_TO_FLAVORED_MODULE @warmelt-modes.melt:3541>
warmelt-modes.2a39abc92c8e7eb0bb12636d64777968.optimized.so
?
#5:<TRANSLATETOMODULE_DOCMD @warmelt-modes.melt:3589>
warmelt-modes.2a39abc92c8e7eb0bb12636d64777968.optimized.so
?
#6:_ melt-runtime.c:9466 <meltgc_do_initial_mode before apply>

#7:_ melt-runtime.c:9747:: meltgc_load_modules_and_do_mode before
do_initial_mode mode translatetomodule
.

cc1plus: error: MELT failure with loaded module #1:
warmelt-first.f89df7fc05cc2c1a952077a7fd0e1229.optimized.so
cc1plus: error: MELT failure with loaded module #2:
warmelt-base.d5c0711d58c4cce969a924cded192217.optimized.so
cc1plus: error: MELT failure with loaded module #3:
warmelt-debug.b50a0f1337fb3a3689b4ac236de59b5d.optimized.so
cc1plus: error: MELT failure with loaded module #4:
warmelt-macro.813ea3da1151923e7a1bdc615e78588c.optimized.so
cc1plus: error: MELT failure with loaded module #5:
warmelt-normal.b2223f3d711da6a3a4ba8057be18d0fa.optimized.so
cc1plus: error: MELT failure with loaded module #6:
warmelt-normatch.65ae59319ae2f4a3a6aeccf191945159.optimized.so
cc1plus: error: MELT failure with loaded module #7:
warmelt-genobj.b37c55425095fb63898fc9c735597232.optimized.so
cc1plus: error: MELT failure with loaded module #8:
warmelt-outobj.fdbbdeeb1fba1830fd30df48874cd0a9.optimized.so
cc1plus: error: MELT failure with loaded module #9:
warmelt-modes.2a39abc92c8e7eb0bb12636d64777968.optimized.so
cc1plus: error: MELT failure with loaded module #10:
xtramelt-ana-base.6af058ebeaea408ae4fda16bbc7a7748.optimized.so
cc1plus: error: MELT failure with loaded module #11:
xtramelt-ana-simple.affb37750c8054ea2acb7ef9f0b427df.optimized.so
cc1plus: error: MELT failure with loaded module #12:
xtramelt-c-generator.5dabebb49ace73461ed7408ccc760557.optimized.so
cc1plus: error: MELT failure with loaded module #13:
xtramelt-opengpu.3759c43db3c567bb883f8d6c0122d0ef.optimized.so
cc1plus: error: MELT got fatal failure from warmelt-outobj.melt:4854
cc1plus: fatal error: MELT translation of talpo_init_test halted after
normalization: got 23 MELT errors
compilation terminated.
make: *** [talpo_init_test.so] Error 1
error: Bad exit status from
/home/alex/BuildSystem/talpo/BUILDROOT/rpm-tmp.45667 (%build)


RPM build errors:
Bad exit status from
/home/alex/BuildSystem/talpo/BUILDROOT/rpm-tmp.45667 (%build)
error: failed!


Basile Starynkevitch

unread,
Mar 31, 2012, 3:01:23 PM3/31/12
to gcc-...@googlegroups.com, Alexandre Lissy, Pierre Vittet
On Sat, 31 Mar 2012 17:04:48 +0200
Alexandre Lissy <ali...@mandriva.com> wrote:


> >>> -fplugin-arg-melt-workdir=melt-workdir
> >>> -fplugin-arg-melt-inhibit-auto-build
> >>> -fplugin-arg-melt-output=melt-sayhello empty-file-for-melt.c
> >>> ***** doing melt-sayhello from melt-build.tpl line 671
> >>> cc -c @melt-sayhello.args

Ok, I think I really can't avoid autoconf for the MELT plugin 0.9.5


The reason is that everything in MELT should know how to compile MELT generated files
(even when running MELT with eg runfile MELT mode), in particular because MELT is itself
running a make with melt-module.mk etc..

So I have to autoconf at least the choice of C or C++, etc etc.

Do you have an idea of how should I start?

Cheers.

PS. The point is that I hate autoconf and don't understand really how to make simple
things. Also, I don't want to mess the MELT plugin with the MELT branch, which also uses
autoconf (since GCC uses it).

Alexandre Lissy

unread,
Mar 31, 2012, 4:02:52 PM3/31/12
to gcc-...@googlegroups.com
Le 31/03/2012 21:01, Basile Starynkevitch a �crit :

> On Sat, 31 Mar 2012 17:04:48 +0200
> Alexandre Lissy <ali...@mandriva.com> wrote:
>
>
>>>>> -fplugin-arg-melt-workdir=melt-workdir
>>>>> -fplugin-arg-melt-inhibit-auto-build
>>>>> -fplugin-arg-melt-output=melt-sayhello empty-file-for-melt.c
>>>>> ***** doing melt-sayhello from melt-build.tpl line 671
>>>>> cc -c @melt-sayhello.args
>
> Ok, I think I really can't avoid autoconf for the MELT plugin 0.9.5
>
>
> The reason is that everything in MELT should know how to compile MELT generated files
> (even when running MELT with eg runfile MELT mode), in particular because MELT is itself
> running a make with melt-module.mk etc..
>
> So I have to autoconf at least the choice of C or C++, etc etc.
>
> Do you have an idea of how should I start?
>
> Cheers.
>
> PS. The point is that I hate autoconf and don't understand really how to make simple
> things. Also, I don't want to mess the MELT plugin with the MELT branch, which also uses
> autoconf (since GCC uses it).

I can't stand autoconf myself :)

>
>
>


Basile Starynkevitch

unread,
Apr 2, 2012, 6:30:51 AM4/2/12
to gcc-...@googlegroups.com, g...@gcc.gnu.org
Hello All,

It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC 4.6 or 4.7.

################################################################
NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7
[[April 2nd 2012]] release candidate 2

Alternative infix syntax is abandoned (it was never implemented)

Accept $(sub sepxr) in macro-string and $[seq sepxr]

Handle SIGIO Unix signals with asynchronous input channels
(experimental feature)

Can be compiled by C++ (since GCC 4.7 often is)

All the values are translated to melt_ptr_t variables, not void*
ones.
###############################################################

I believe it should work for a GCC 4.7 compiled in C++ mode.
Thanks to Alexnadre Lissy & Romain Geissler for their help.

Please test and report bugs or build success or failure on
gcc-...@googlegroups.com list.

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

Basile Starynkevitch

unread,
Apr 2, 2012, 6:35:25 AM4/2/12
to Basile Starynkevitch, gcc-...@googlegroups.com, g...@gcc.gnu.org
On Mon, Apr 02, 2012 at 12:30:51PM +0200, Basile Starynkevitch wrote:
> Hello All,
>
> It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC 4.6 or 4.7.

MELT is a high-level domain specific language to extend GCC



> ################################################################
> NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7
> [[April 2nd 2012]] release candidate 2
>
> Alternative infix syntax is abandoned (it was never implemented)
>
> Accept $(sub sepxr) in macro-string and $[seq sepxr]
>
> Handle SIGIO Unix signals with asynchronous input channels
> (experimental feature)
>
> Can be compiled by C++ (since GCC 4.7 often is)
>
> All the values are translated to melt_ptr_t variables, not void*
> ones.
> ###############################################################
>
> I believe it should work for a GCC 4.7 compiled in C++ mode.
> Thanks to Alexnadre Lissy & Romain Geissler for their help.
>
> Please test and report bugs or build success or failure on
> gcc-...@googlegroups.com list.


Sorry, I forgot the download information

The release candidate 2 of MELT plugin 0.9.5 is still perhaps buggy but is available from
http://gcc-melt.org/melt-0.9.5rc2-plugin-for-gcc-4.6-or-4.7.tar.gz
as a gzipped tar archive of 4476348 bytes and md5sum 75e528535b05a03f452b55018b6b085b.

You could try building it e.g. with

make CC=gcc-4.7 CXX=g++-4.7
or perhaps with
make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7.

Please report bugs on gcc-melt list. It is extracted from MELT branch svn revision 186078, april 2nd 2012.

Cheers.

Reply all
Reply to author
Forward
0 new messages