Announce: MELT plugin (0.7) release candidate 5 for GCC 4.6
Hello All,
I am announcing the release candidate #5 of the MELT plugin (v0.7)
replacing previous rc (an rc4 was made available on gcc-melt.org
yesterday but I didn't announce it and corrected a minor bug since.).
You can download it from
http://gcc-melt.org/melt-0.7rc5-plugin-for-gcc-4.6.tgz a gzip-ed tar
archive of 3347550 bytes of md5sum 6acf75007ae21052393885c746bfbf95
(april 17th 2011). It is extracted from MELT branch svn revision
172605. The version number 0.7 of the MELT plugin is unrelated to the
version of the GCC Compiler (4.6) for which it is supposed to work.
Improvements since previous rc are bug fixes.
It would be very nice if you report me that you could build it.
If a MELT plugin build fails, give as much information as possible. (Maybe
using gdb for backtracing).
Please also give the output of the command gcc-4.6 -v for the gcc you are
building.
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} ***
Bug 44149.
Lectoribus Salutem, With the current Bugzilla I do not know how to indicate that I think this bug (44149) has been solved. I tried it with GCC trunk, revision 172608, in the following way (see files attached with the bug report): #!/bin/sh /usr/snp/bin/gfortran -c -flto -O2 -fwhole-program bkfconv.f90 ar rv x.a bkfconv.o /usr/snp/bin/gfortran -fuse-linker-plugin -flto -O2 -fwhole-program b.f x.a where /usr/snp is the location of revision 172608. It didn't fail anymore. BTW, does the build process of GCC honor $TMPDIR - I had a melt-down of a build due to the fact that my /tmp partition only had 850 Mb left. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
gcc-4.3-20110417 is now available
Snapshot gcc-4.3-20110417 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110417/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 172617 You'll find: gcc-4.3-20110417.tar.bz2 Complete GCC (includes all of below) MD5=42958fb97792c18eb43d33dc790040b2 SHA1=d2dcad75d26394412807ffe8e9f201c9613187fa gcc-core-4.3-20110417.tar.bz2C front end and core compiler MD5=da5608201ff12987ba2ae640281639fb SHA1=1fd018f7b727be79241e7a9bfada585bf2941d21 gcc-ada-4.3-20110417.tar.bz2 Ada front end and runtime MD5=c94fbd304ca6a876709fb0a0f1666751 SHA1=842fbcb226d846fb3dd4f44baf972628be863434 gcc-fortran-4.3-20110417.tar.bz2 Fortran front end and runtime MD5=232a52c326a5bc1d3baf897fd39e0351 SHA1=74cc8938e793c4f9bf70946e757cbb910264693d gcc-g++-4.3-20110417.tar.bz2 C++ front end and runtime MD5=8dc1dc3dc0bf278bfb504b8f8edb6c56 SHA1=0a90f187bbd28b5d1970aff639089528bad3bb33 gcc-go-4.3-20110417.tar.bz2 Go front end and runtime MD5=536b91aa57298245f4aa76cb306ab522 SHA1=2583474488ef1eba959e2bbeee1ca0e58557cbf3 gcc-java-4.3-20110417.tar.bz2Java front end and runtime MD5=8d94b2f1a4a1a8e9a8a4a4765ea17de9 SHA1=91cc3129da7630edeffdacbb416df7b4284baf81 gcc-objc-4.3-20110417.tar.bz2Objective-C front end and runtime MD5=69cb9124b362aa1bdb84f7317016a010 SHA1=8840c4f7fcf668cfb1c4dce5b9f171011ac45a9c gcc-testsuite-4.3-20110417.tar.bz2 The GCC testsuite MD5=140e8545696e5266a9f2a1708d5fe7f6 SHA1=7592fd6db1facfeb873205e65450ba8d664f1262 Diffs from 4.3-20110410 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Bug 44149.
On 04/17/2011 05:24 PM, Toon Moene wrote: BTW, does the build process of GCC honor $TMPDIR - I had a melt-down of a build due to the fact that my /tmp partition only had 850 Mb left. Well, it seems to. Unfortunately, I do not have the time (between two runs of HIRLAM) to wait for a --with-build-config=bootstrap-lto bootstrap. Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
[google] Merge google/integration -> google/main
Merge google/integration into google/main at rev 172609. Tested on x86_64. Diego.
Function pointer question
Hello, I was wondering if someone could answer a question regarding the feasibility (this is not a request for changes to GCC) of constant function pointer inlining. This obviously would require a compiler to do an N-depth analysis of pointer assignments to confirm that the value could not change (constant all the way back the address' origin). My question is; theoretically is this possible? (I'm obviously not a compiler programmer) Thank you, Aaron
[google] google/main -> google/gcc-4_6 merge
Merged google/main into google/gcc-4_6 up to rev 172617. Tested on x86_64. Diego.
Re: Function pointer question
Aaron Abassi writes:
> I was wondering if someone could answer a question regarding the
> feasibility (this is not a request for changes to GCC) of constant
> function pointer inlining. This obviously would require a compiler to
> do an N-depth analysis of pointer assignments to confirm that the
> value could not change (constant all the way back the address'
> origin).
>
> My question is; theoretically is this possible? (I'm obviously not a
> compiler programmer)
Assuming I understand you correctly (it always helps to provide a code
example): yes, it is feasible.
gcc already does it in some cases. E.g.:
inline int f(int i) { return i; }
int g(int (*pfn)(int), int i) {
return (*pfn)(i);
}
int h(int i) {
return g(f, i);
}
When compiled with -O2, f will be inlined into h.
Ian
Function pointer inlining
Hello, I was wondering if someone could answer a question regarding the feasibility (this is not a request for changes to GCC) of constant function pointer inlining through a structure. This obviously would require a compiler to do an N-depth analysis of pointer assignments to confirm that the value could not change (constant all the way back the address' origin). My question is; theoretically is this possible? (I'm obviously not a compiler programmer) Thank you, Aaron PS: This is a revised version of my question, I should have mentioned through a structure in my original post.
