Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
> I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. They aren't really regressions from 4.6.0 but on SPARC/Solaris we have: FAIL: gcc.dg/vect/pr48377.c execution test (you know what I mean) FAIL: g++.dg/cpp0x/lambda/lambda-eh2.C execution test (PR c++/49260) and on SPARC64 we have an ACATS failure: FAIL: c94007a The ACATS failure is a reorg.c bug, for which I have a straightforward fix, but I think I should first ask if you're interested in it for 4.6.1 before wasting CPU cycles. ;-) -- Eric Botcazou
Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
On Tue, Jun 21, 2011 at 10:47:54AM +0200, Eric Botcazou wrote: > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux and i686-linux. Please test it and report any issues to > > bugzilla. > > They aren't really regressions from 4.6.0 but on SPARC/Solaris we have: > > FAIL: gcc.dg/vect/pr48377.c execution test (you know what I mean) For this a patch is awaiting review, but it is a testsuite only issue, so not a blocker. > FAIL: g++.dg/cpp0x/lambda/lambda-eh2.C execution test (PR c++/49260) > > and on SPARC64 we have an ACATS failure: > > FAIL: c94007a > > > The ACATS failure is a reorg.c bug, for which I have a straightforward fix, > but > I think I should first ask if you're interested in it for 4.6.1 before > wasting > CPU cycles. ;-) I guess it depends on how risky the patch is, while reorg.c affects only a few targets, they still include some primary targets. If it is not a regression from 4.6.0 and the fix isn't very obviously safe, it would probably be better to postpone it for 4.6.2 (though, I think CPU cycles wouldn't be wasted by preparing a fix for 4.6.2). Jakub
Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
> I guess it depends on how risky the patch is, while reorg.c affects only a > few targets, they still include some primary targets. If it is not a > regression from 4.6.0 and the fix isn't very obviously safe, it would > probably be better to postpone it for 4.6.2 (though, I think CPU cycles > wouldn't be wasted by preparing a fix for 4.6.2). I think it is as obviously safe as a reorg.c patch can be so I'm going to test it (on the branch) and post it afterward, but it will be your call of course. -- Eric Botcazou
Problem with array initialization
Not sue if this is the right place to report this problem.
The following doesn't compile for me.
-snip---
#include
const int const1 = 10;
const int const2 = 11;
int arr[] = {
const1,
const2
};
int main(void)
{
printf("consts %d %d \n", arr[0], arr[1]);
}
-snip---
$ gcc main.c
main2.c:7: error: initializer element is not constant
main2.c:7: error: (near initialization for ‘arr[0]’)
main2.c:9: error: initializer element is not constant
main2.c:9: error: (near initialization for ‘arr[1]’)
Where as the following works!
-snip---
#include
const int const1 = 10;
const int const2 = 11;
int main(void)
{
int arr[] = {
const1,
const2
};
printf("consts %d %d \n", arr[0], arr[1]);
}
-snip---
ARM RVCT compiler compiles both without any errors.
best regards,
Aneesh
Re: viewcvs: Python error
> File "/usr/lib/python2.3/site-packages/pygments/token.py", line 26, in > __init__ > self.subtypes = set() > NameError: global name 'set' is not defined set() appeared in python2.4 according to: http://docs.python.org/release/2.3.5/lib/built-in-funcs.html vs http://docs.python.org/release/2.4/lib/built-in-funcs.html So the fix may be to upgrade python on the host, and the cause may be that a new version of viewcvs has been installed which now use set() whereas the previous didn't... -- Vincent Legoll
Re: Problem with array initialization
On 21 June 2011 10:39, Aneesh V wrote:
> Not sue if this is the right place to report this problem.
It's not, as explained on the website.
As stated at http://gcc.gnu.org/lists.html for help using GCC you
should use the gcc-help list, or to report bugs see the "How to
report" link on the GCC homepage, which takes you to
http://gcc.gnu.org/bugs/
In this case there's no bug, so please take any follow up questions to
the gcc-help list, thanks.
> The following doesn't compile for me.
That's because it's not valid C.
A global variable such as arr has static storage duration and the C99
standard says
"All the expressions in an initializer for an object that has static
storage duration shall be
constant expressions or string literals."
The errors you got are correct because const1 and const2 are not
constant expressions.
In C++ the code is valid, because the initializer for arr can contain
non-constant expressions, and because const1 and const2 are constant
expressions anyway.
The code can be made valid C by replacing const1 and const2 like so:
enum { const1 = 10, const2 = 11 };
Re: LIBGCC2_FLAGS not used by libgcc2 configure?
"Paulo J. Matos" writes: > Which flag (like CFLAGS_FOR_BUILD) can I use that is passed in the > command line to compile the driver? CFLAGS. CFLAGS_FOR_BUILD is for code compiled for the build system. CFLAGS is for code compiled for the host system. CFLAGS_FOR_TARGET is for code compiled for the target system. The driver and the compiler as a whole run on the host system. The build system is used for tools which are run while building the compiler, such as genrecog. Ian
New GCC plugin: gcc-python-plugin
I've been working on a new plugin for GCC, which supports embedding
Python within GCC, exposing GCC's internal data structures as Python
objects and classes.
The plugin links against libpython, and (I hope) allows you to invoke
arbitrary Python scripts from inside a compile. My aim is to allow
people to write GCC "plugins" as Python scripts, and to make it much
easier to prototype new GCC features (Python is great for doing this
kind of thing).
The plugin is Free Software, licensed under the GPLv3 (or later).
The code can be seen here:
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=summary
and the website for the plugin is the Trac instance here:
https://fedorahosted.org/gcc-python-plugin/
The documentation is in the "docs" subdirectory (using sphinx). You can
see a pre-built HTML version of the docs here:
http://readthedocs.org/docs/gcc-python-plugin/en/latest/index.html
It's still at the "experimental proof-of-concept stage"; expect crashes
and tracebacks (I'm new to the insides of GCC, and I may have
misunderstood things. I'm entirely ignoring the garbage collector, and
I've also used a few entrypoints that aren't yet exposed in the plugin
headers).
It's already possible to use this to add additional compiler
errors/warnings, e.g. domain-specific checks, or static analysis.
One of my goals for this is to "teach" GCC about the common mistakes
people make when writing extensions for CPython [1], but it could be
used
- e.g. to teach GCC about GTK's reference-counting semantics,
- to check locking in the Linux kernel
- to check signal-safety in APIs, etc
- rapid prototyping
Other ideas include visualizations of code structure. There are handy
methods for plotting control flow graphs (using graphviz), showing the
source code interleaved with GCC's internal representation, such as the
one here:
http://readthedocs.org/docs/gcc-python-plugin/en/latest/cfg.html
It could also be used to build a more general static-analysis tool.
The CPython API checker has the beginnings of this:
Example output:
test.c: In function ‘leaky’:
test.c:21:10: error: leak of PyObject* reference acquired at call to
PyList_New at test.c:21 [-fpermissive]
test.c:22: taking False path at if (!list)
test.c:24: reaching here item = PyLong_FromLong(42);
test.c:27: taking True path at if (!item)
test.c:21: returning NULL
Numerous caveats right now (e.g. how I deal with loops is really
dubious). It's disabled for now within the source tree (I need to fix
my selftests to pass again...) It perhaps could be generalized to do
e.g. {malloc,FILE*, fd} leaks, array bounds checking, int overflow, etc,
but obviously that's a far bigger task.
So far, I'm just doing a limited form of "abstract interpretation" (or,
at least, based on my understanding of that term), dealing with explicit
finite prefixes of traces of execution, tracking abstract values (e.g.
NULL-ptr vs non-NULL-ptr) and stopping when the trace loops (which is
just an easy way to guarantee termination, not a good one, but for my
use-case is good enough, I hope. Plus it ought to make it easier to
generate highly-readable error messages).
Thanks to Red Hat for allowing me to devote a substantial chunk of
$DAYJOB to this over the last couple of months.
I hope this will be helpful to both the GCC and Python communities.
Dave
[1] see
http://readthedocs.org/docs/gcc-python-plugin/en/latest/cpychecker.html
and
https://fedoraproject.org/wiki/Features/StaticAnalysisOfCPythonExtensions
Re: New GCC plugin: gcc-python-plugin
On Tue, 21 Jun 2011 14:33:20 -0400
David Malcolm wrote:
> It's still at the "experimental proof-of-concept stage"; expect crashes
> and tracebacks (I'm new to the insides of GCC, and I may have
> misunderstood things. I'm entirely ignoring the garbage collector, and
> I've also used a few entrypoints that aren't yet exposed in the plugin
> headers).
>
> It's already possible to use this to add additional compiler
> errors/warnings, e.g. domain-specific checks, or static analysis.
>
> One of my goals for this is to "teach" GCC about the common mistakes
> people make when writing extensions for CPython [1], but it could be
> used
> - e.g. to teach GCC about GTK's reference-counting semantics,
> - to check locking in the Linux kernel
> - to check signal-safety in APIs, etc
> - rapid prototyping
>
For your information, MELT has the same goals, except that it does not
ignore the Gcc garbage collector (on the contrary, it is built above
it).
See http://gcc-melt.org/ for more, or download the MELT branch (or the
MELT plugin).
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} ***
Re: New GCC plugin: gcc-python-plugin
On Tue, 2011-06-21 at 21:02 +0200, Basile Starynkevitch wrote: > On Tue, 21 Jun 2011 14:33:20 -0400 > David Malcolm wrote: > > It's still at the "experimental proof-of-concept stage"; expect crashes > > and tracebacks (I'm new to the insides of GCC, and I may have > > misunderstood things. I'm entirely ignoring the garbage collector, and > > I've also used a few entrypoints that aren't yet exposed in the plugin > > headers). > > > > It's already possible to use this to add additional compiler > > errors/warnings, e.g. domain-specific checks, or static analysis. > > > > One of my goals for this is to "teach" GCC about the common mistakes > > people make when writing extensions for CPython [1], but it could be > > used > > - e.g. to teach GCC about GTK's reference-counting semantics, > > - to check locking in the Linux kernel > > - to check signal-safety in APIs, etc > > - rapid prototyping > > > > For your information, MELT has the same goals, except that it does not > ignore the Gcc garbage collector (on the contrary, it is built above > it). > See http://gcc-melt.org/ for more, or download the MELT branch (or the > MELT plugin). Thanks for the link. When I mentioned the garbage collector, I was merely trying to convey the early, buggy nature of my code. This is a bug that I need to fix, but not a fundamental design flaw (I hope!) I'm aware of MELT - as I understand it, it's a Lisp variant. Languages and runtimes are a sensitive topic. For myself, I'm very fond of Python and its syntax (and its community), and having that available for writing GCC extensions is very appealing to me. The CPython runtime may not be the fastest free software runtime, but it is flexible and easy to debug. Although I'm new to GCC development, I feel that the more languages that GCC can support for plugins and scripting, the better. There's already a JavaScript plugin, and I didn't want the Python fans to feel left out. [Plus I'm using this code to analyse python's .c code, so I selfishly hope that other python fans will want to help; by using python as the extension language I hope I'll be more likely to get more contributors]. Hope this makes sense Dave
PR 44149 can be considered fixed, as of 4.6.1
I seem to have royally screwed up my bugzilla account, in that I cannot even successfully change my password, hence this unusual request: PR lto/44149 can be considered solved as of 4.6.1. I just tried the test case with: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-10' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 20110526 (prerelease) (Debian 4.6.0-10) and $ ld -v GNU ld (GNU Binutils for Debian) 2.21.51.20110523 It worked as expected. Perhaps some kind soul with access to bugzilla can close this one. Thanks. -- 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
Re: PR 44149 can be considered fixed, as of 4.6.1
Toon, > Perhaps some kind soul with access to bugzilla can close this one. Done, Dominique
Re: New GCC plugin: gcc-python-plugin
On Tue, 21 Jun 2011 15:34:51 -0400
David Malcolm wrote:
> I'm aware of MELT - as I understand it, it's a Lisp variant.
Yes. However, I do have in the works an infix syntax of MELT called
MILT. But it would just be an infix/prefix syntax of exactly the same
language (more precisely, of a large subset of MELT). I mean that every
syntactic construct in MELT will have its infix/prefix equivalent (e.g.
MELT operations starting with + will be additive infix, etc..).
I don't think that MELT lispy syntax matters that much. For the few
users of MELT, the main issue is understand the details of GCC internal
representations (Gimple & Tree, notably), not MELT syntax. I'm sure
your Python hackers will have the same issue: understanding GCC details
is hard (much harder than learning how to code in Python or in MELT).
>
> Languages and runtimes are a sensitive topic. For myself, I'm very fond
> of Python and its syntax (and its community), and having that available
> for writing GCC extensions is very appealing to me. The CPython runtime
> may not be the fastest free software runtime, but it is flexible and
> easy to debug.
>
> Although I'm new to GCC development, I feel that the more languages that
> GCC can support for plugins and scripting, the better. There's already
> a JavaScript plugin, and I didn't want the Python fans to feel left out.
Agreed.
> [Plus I'm using this code to analyse python's .c code, so I selfishly
> hope that other python fans will want to help; by using python as the
> extension language I hope I'll be more likely to get more contributors].
I actually dreamed that some Python C binding guru would make a MELT
extension to analyze such things. Again, the issue is understanding GCC
internals (mostly Gimple & Tree representations), and being able to
specify a GCC pass doing such analysis. This also requires a deep
understanding of Python -> C binding rules.
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} ***
Re: New GCC plugin: gcc-python-plugin
On Tue, 21 Jun 2011 15:34:51 -0400
David Malcolm wrote:
> When I mentioned the garbage collector, I was merely trying to convey
> the early, buggy nature of my code. This is a bug that I need to fix,
> but not a fundamental design flaw (I hope!)
I would be very interested in understanding in details how you mix
Python reference counting garbage collector with Gcc GGC!
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: New GCC plugin: gcc-python-plugin
On Tue, 2011-06-21 at 22:30 +0200, Basile Starynkevitch wrote: > On Tue, 21 Jun 2011 15:34:51 -0400 > David Malcolm wrote: > > I'm aware of MELT - as I understand it, it's a Lisp variant. > > Yes. However, I do have in the works an infix syntax of MELT called > MILT. But it would just be an infix/prefix syntax of exactly the same > language (more precisely, of a large subset of MELT). I mean that every > syntactic construct in MELT will have its infix/prefix equivalent (e.g. > MELT operations starting with + will be additive infix, etc..). > > I don't think that MELT lispy syntax matters that much. For the few > users of MELT, the main issue is understand the details of GCC internal > representations (Gimple & Tree, notably), not MELT syntax. I'm sure > your Python hackers will have the same issue: understanding GCC details > is hard (much harder than learning how to code in Python or in MELT). FWIW, I think I disagree with some of the above. For me, one of the core "ideas" behind python is that syntax matters a great deal - code is read more times than it's written, so the readability of code to humans is important. Whether this is a good tradeoff, and the meaning of "readability" is a deeply personal thing, of course - Python is my favorite language, but others have different preferences. There's also a limit to how much "cognitive load" I can cope with at once: learning a new domain of types and objects is one thing, learning a new (to me) language and runtime at the same time adds to the burden. I know lots of handy tricks for debugging Python code, which is helpful to me when dealing with an unfamiliar problem domain (such as seeing GCC's insides for the first time). I certainly agree with you that understanding GCC's internals is a difficult hurdle for new contributors to overcome. I'm still on that journey... Currently I've documented my Python API from the perspective of the Python classes and objects. However, it just struck me that this could be improved by adding a description from the perspective of the source language - provide snippets of C/C++/etc code demonstrating an element of syntax, and show for each one what the resulting IR looks like as tree/gimple instances. I may do this for my Python plugin; maybe it's a good idea for the other plugins? (and perhaps for GCC's own devel docs?) [... snip (further language discussion) ...] > > [Plus I'm using this code to analyse python's .c code, so I selfishly > > hope that other python fans will want to help; by using python as the > > extension language I hope I'll be more likely to get more contributors]. > > I actually dreamed that some Python C binding guru would make a MELT > extension to analyze such things. Again, the issue is understanding GCC > internals (mostly Gimple & Tree representations), and being able to > specify a GCC pass doing such analysis. This also requires a deep > understanding of Python -> C binding rules. [FWIW, I'm a CPython committer, and I know the Python->C binding rules well (I hope!); but not to rehash all the above I greatly prefer to work in Python itself. (sorry)] Thanks for the feedback; I hope this is helpful Dave
gcc-4.4-20110621 is now available
Snapshot gcc-4.4-20110621 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110621/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 175276 You'll find: gcc-4.4-20110621.tar.bz2 Complete GCC MD5=f5d4f5cc7e28468ce343e8c27df5d84f SHA1=d9700ebb1c56ade17e727fbb0afd7a1808cae275 Diffs from 4.4-20110614 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: New GCC plugin: gcc-python-plugin
On Tue, 2011-06-21 at 22:31 +0200, Basile Starynkevitch wrote: > On Tue, 21 Jun 2011 15:34:51 -0400 > David Malcolm wrote: > > When I mentioned the garbage collector, I was merely trying to convey > > the early, buggy nature of my code. This is a bug that I need to fix, > > but not a fundamental design flaw (I hope!) > > > I would be very interested in understanding in details how you mix > Python reference counting garbage collector with Gcc GGC! I'm looking forward to figuring that out as well! :) I'm not yet familiar with the details of the gcc GC, but it appears that GTY() annotations are preprocessed to generate traversal code used by a mark-and-sweep algorithm. Python's own GC allows for classes to opt-in as reference-owners; instances of such classes get tracked within linked lists (one per generation of Python's GC). This is intended for use for tracking PyObject* references, but I may be able to piggy-back off of this - if I add the relevant flag to my wrapper classes then they get tracked in these linked lists. I can then register a callback to PLUGIN_GGC_MARKING that uses this to locate the subset of all PyObject* objects that wrap GCC objects. This could then mark all of the wrapped GCC objects referenced from Python. That way all of the Python wrapper objects can be found as roots within a GCC GC, and thus not have their wrapped GCC objects deleted "from under them" (traversing any refs they in turn keep alive, of course). (Or it could just explicitly keep track of all live Python wrapper objects, and walk them when PLUGIN_GGC_MARKING occurs, marking the wrapped GCC objects; not sure). I'm probably forgetting something important here though (e.g. what happens when Python's GC runs? Though so far I'm only wrapping GCC with Python, not the other way around, so I _think_ this isn't an issue) Hope this sounds sane Dave
Re: New GCC plugin: gcc-python-plugin
On Tue, 21 Jun 2011 17:51:52 -0400
David Malcolm wrote:
>
> FWIW, I think I disagree with some of the above. For me, one of the
> core "ideas" behind python is that syntax matters a great deal - code is
> read more times than it's written, so the readability of code to humans
> is important. Whether this is a good tradeoff, and the meaning of
> "readability" is a deeply personal thing, of course - Python is my
> favorite language, but others have different preferences.
FWIW, I love Ocaml.
Does Python provide pattern matching facilities (the last time I
checked, it didn't)? MELT does provide them (and pattern matching is
probably the most important feature of MELT). I don't call such a
difference a syntactical one (pattern matching is a deep, semantic, not
only syntactic, feature of a language).
Then, a Python binding to GCC will favor those applications which don't
need to match GCC things, while MELT favor those that do need to match
GCC things (like Gimple, Tree etc...). Obviously, that makes a
difference (more important than a lispy syntax or not).
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} ***
