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. Wh
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
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
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
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 de
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 sub
Toon,
> Perhaps some kind soul with access to bugzilla can close this one.
Done,
Dominique
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_WRA
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 en
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 entrypo
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
pe
"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 t
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 home
> 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/li
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
> 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
> wo
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:
>
>
> 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++
18 matches
Mail list logo
