Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > If gcc supports plugins, then all we've eliminated is the need to
> > > plug that code into passes.c. But that is the easiest part of the
> > > job. Adding plugins is not going to require us to support a stable
> I have a different fear: that gcc will become increasing irrelevant,
> as more and more new programmers learn to work on alternative free
> compilers instead. That is neutral with regard to freedom, but it
> will tend to lose the many years of experience which have been put
> into gcc. In my vi
Andrew Haley <[EMAIL PROTECTED]> writes:
> > Most new gcc back-ends are private, so I don't buy that part of the
> > argument. And in any case nobody is talking about plug-ins for gcc
> > backends. We're talking about plugins at the tree/GIMPLE level.
>
> Yeah, I know. I'm thinking about pr
Thanks to Jim Wilson's help, I eliminated a non-standard file,
/usr/bin/true, which was interfering with gcc scripts.
Now everything is fine with gcc building.
-Tom
Tom Browder
Niceville, Florida
USA
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > Most new gcc back-ends are private, so I don't buy that part of the
> > > argument. And in any case nobody is talking about plug-ins for gcc
> > > backends. We're talking about plugins at the tree/GIMPLE level.
Ian Lance Taylor wrote:
But as you know, most gcc ports are never contributed anyhow.
Naively, I didn't know that!
I thought most ports were contributed, but some rejected because of code
quality, lack of reviewers, etc
But does these ports are published elsewhere, in the spirit of GPL,
On Fri, Nov 16, 2007 at 12:02:44PM -0500, Richard Kenner wrote:
> As was said before, the difficultly in people working with GCC is
> primarily lack of adequate documentation. Creating a "plugin" interface
> is certainly much more fun than writing documentation, but doesn't help
> this issue nearl
Hello,
I have recently reported GCC bug #34030
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34030)
As it might have been fixed in 4.2.3, and as my concern is primarily for
the 4.1.1 branch (we don't want to upgrade now), I am ready to fix it in
my own sources.
However, I am not familiar wi
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
David Edelsohn
Sent: 16 November 2007 16:58
To: Andrew Haley
Cc: Ian Lance Taylor; Richard Kenner; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; gcc@gcc.gnu.org
Subject: Re: Progress on GCC plugi
On Fri, Nov 16, 2007 at 12:05:06AM +0100, Michael_fogel wrote:
> tcp_in.c:1133: internal compiler error: in gen_reg_rtx, at emit-rtl.c:771
> Please submit a full bug report,
This means you're calling gen_reg_rtx() when you're not allowed to.
Olders version of GCC had a life1 pass, after which c
Hi,
On Nov 16, 2007 12:16 PM, Alexander Lamaison <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
> > Several projects will survive the initial prototyping stages and become
> > techniques we can apply in industrial settings. We want to attract
> > that. Plus we want to attract the grad student
Andrew Haley wrote:
Well, that's where we differ. I don't at all understand how adding
plugins won't make it very much easier. It seems obvious to me that
if there is a reasonably well-defined plugin architecture it will be
vastly easier to export data from gcc's front-ends to a proprietary
co
On Fri, Nov 16, 2007 at 06:13:32PM +0100, Bernd Schmidt wrote:
> I must admit I don't understand the upside. I've always thought of
> plugins as something proprietary programs need because their source
> isn't open.
On the contrary, many successful free programs have plugins.
Consider Emacs. Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Diego Novillo wrote:
> Before plug-ins: put your gimple-to-myIR converter in passes.c
> After plug-ins: dlopen gimple-to-myIR.so
>
> Both represent the same effort. Both require your converter to be kept
> up-to-date with GCC's ever shifting ABI/API
Diego Novillo wrote:
> Richard Kenner wrote:
>
> > I don't see that. Why is it that much harder to link in with GCC
> than doing
> > it as a plugin?
>
> Limited time and steep learning curves. Typically, researchers are
> interested in rapid-prototyping to keep the paper mill going. Plug-ins
Andrew Haley wrote:
Well, that's where we differ. I don't at all understand how adding
plugins won't make it very much easier. It seems obvious to me that
if there is a reasonably well-defined plugin architecture it will be
vastly easier to export data from gcc's front-ends to a proprietary
co
On 16 November 2007 10:56, Li Wang wrote:
> Dave Korn 写道:
>>
>> Various CPU backends (but IIRC not i386) implement a "naked" function
>> attribute, which suppresses function epilogue and prologue generation. You
>> could implement something like that.
>>
> It seems to be what I want. Could y
* Ian Lance Taylor <[EMAIL PROTECTED]> [2007-11-16 07:49]:
> But as you know, most gcc ports are never contributed anyhow. Ports
> that people hire Red Hat to do are contributed, but I can easily
> count six gcc ports I've seen myself that were never contributed.
Can you list those six ports? Ha
Bernd Schmidt wrote:
I must admit I don't understand the upside. I've always thought of
plugins as something proprietary programs need because their source
isn't open.
On the contrary, the plug-in model is used in several large and complex
open source projects (firefox, thunderbird, gimp, li
Bernd Schmidt wrote:
Ian Lance Taylor wrote:
I think it's quite important for gcc's long-term health to permit and
even encourage academic researchers and students to use it. And I see
plugins as directly supporting that goal. Note that I don't see any
problem with requiring (or attempting to
On 16 November 2007 17:25, Richard Kenner wrote:
> If I want to test some piece of code in the compiler, I don't have to
> bootstrap with or without plugins (unless I need to for testing purposes).
> The only difference is how I link, which seems a completely trivial
> distinction to me.
That s
Andrew Haley <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > > Most new gcc back-ends are private, so I don't buy that part of the
> > > > argument. And in any case nobody is talking about plug-ins for gcc
> > > > backends. W
Andrew Haley wrote:
>
> But as you know, most gcc ports are never contributed anyhow.
Sure, but they are still free software: if the compiler gets
distributed, so does its source code. Of couse, assigning copyright
to FSF is nice, but freedom is much more important.
Oh I fully understand t
On Fri, Nov 16, 2007 at 06:15:50PM +0100, Basile STARYNKEVITCH wrote:
> I even don't believe that competitor proprietary compilers are much more
> documented than GCC.
Depends. Vendors of compiler front ends (those sold for extension by
others) provide very good documentation, much better than a
Ian Lance Taylor wrote:
I have a different fear: that gcc will become increasing irrelevant,
as more and more new programmers learn to work on alternative free
compilers instead. That is neutral with regard to freedom, but it
will tend to lose the many years of experience which have been put
in
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > > Most new gcc back-ends are private, so I don't buy that part of the
> > > > > argument. And in any case nobody is talking
Richard Kenner wrote:
As was said before, the difficultly in people working with GCC is
primarily lack of adequate documentation.
I am not sure of that.
GCC is a huge piece of software. This is the major difficulty: grasping
a 3MLOC software whose source is available, rather well commented
On 16 November 2007 00:01, Jim Wilson wrote:
> Michael_fogel wrote:
>> (ior:SI (subreg:SI (mem/s:QI (reg/f:SI 1250) [0
>> .flags+0 S1 A32]) 0)
>
> See register_operand and general_operand in recog.c. (SUBREG (MEM)) is
> accepted by register_operand if INSN_SCHEDULING is not defined, for
> Diego Novillo writes:
Diego> I'm not sure if it's intended, but I don't think it's desirable. The
Diego> information needed to do LTO optimizations should be independent from
Diego> the debugging information.
Diego> We could have a --strip-lto option for strip, but I don't think
Diego>
> Andrew Haley writes:
>> I have a different fear: that gcc will become increasing
>> irrelevant, as more and more new programmers learn to work on
>> alternative free compilers instead. That is neutral with regard to
>> freedom, but it will tend to lose the many years of experience
>> which
Hi,
On Nov 16, 2007 6:45 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Richard Kenner wrote:
> > As was said before, the difficultly in people working with GCC is
> > primarily lack of adequate documentation. Creating a "plugin" interface
> > is certainly much more fun than writing documentation
> ">" == Dep, Khushil (GE Money) <[EMAIL PROTECTED]> writes:
>> I believe efforts to clarify and expand documentation is much more
>> likely to entice new researchers and developers rather than a
>> plugin system which no doubt would be poorly documented!
This idea comes up a lot.
I'm sympat
On Fri, Nov 16, 2007 at 07:29:12PM +0100, [EMAIL PROTECTED] wrote:
> I hope we aren't thinking about keeping things difficult for
> everybody simply because everybody includes some people who
> may want to take advantage of GCC in a proprietary way. In
> the long term, this only benefits the folks
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Ian Lance Taylor <[EMAIL PROTECTED]> [2007-11-16 07:49]:
> > But as you know, most gcc ports are never contributed anyhow. Ports
> > that people hire Red Hat to do are contributed, but I can easily
> > count six gcc ports I've seen myself that were
On Fri, Nov 16, 2007 at 09:54:25PM +0300, [EMAIL PROTECTED] wrote:
> I have an invention which makes possible to brake through the barriers of
> common software development.
Nothing new here: add a level of indirection (or use C++ virtual
functions), and dynamically load code. In the Ptolemy proj
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > But as you know, most gcc ports are never contributed anyhow.
>
> Naively, I didn't know that!
> I thought most ports were contributed, but some rejected because of
> code quality, lack of reviewers, etc
>
> But d
Dear Sirs.
In respect of your time I will straight to the matter.
It is absolutely obvious that in today's world in order to be on the top it
is required to be innovative. Without that you can not brake through the
competitors. It is just impossible.
I have an invention which makes possible to
Joe Buck wrote:
> RMS believes that people who extend GCC, hoping to take their
extensions
> proprietary, and then finding that they can't, will then just decide
to
> contribute the code, if it is useful, since otherwise they can't
> distribute and have to support it by themselves forever, or else
On 16 November 2007 05:56, Li Wang wrote:
> As you said, the coprocessor has no ABI to describe a stack and a
> function interface, then inline applies. But how could I inline 'main'?
> And I am sorry for I misuse the word 'elf assembly', what exactly I mean
> by that is how to omit the section or
Much as I hate prolonging a probably-pointless discussion...
I hope we aren't thinking about keeping things difficult for
everybody simply because everybody includes some people who
may want to take advantage of GCC in a proprietary way. In
the long term, this only benefits the folks you'd be tryi
Richard Kenner wrote:
I have a different fear: that gcc will become increasing irrelevant,
as more and more new programmers learn to work on alternative free
compilers instead. That is neutral with regard to freedom, but it
will tend to lose the many years of experience which have been put
into
William Maddox wrote:
It appears that portions of the LTO information are emitted in the usual
debugging sections, rather, information that would already be present there
is shared. This is great for reducing the size of object files that
contain both
LTO info and debugging info, but means that
Quoting Martin Jambor <[EMAIL PROTECTED]>:
So as far as attracting new programmers, researchers and inexperienced
students in particular is concerned, I think that effort that
implementing plugins would take would be much better spent on keeping
documentation up to date, possibly impr
Ian Lance Taylor wrote:
> I think it's quite important for gcc's long-term health to permit and
> even encourage academic researchers and students to use it. And I see
> plugins as directly supporting that goal. Note that I don't see any
> problem with requiring (or attempting to require) that a
Dave Korn 写道:
On 16 November 2007 05:56, Li Wang wrote:
As you said, the coprocessor has no ABI to describe a stack and a
function interface, then inline applies. But how could I inline 'main'?
And I am sorry for I misuse the word 'elf assembly', what exactly I mean
by that is how to omit th
On 11/15/07, Rob Quill <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was wondering if anyone could help me make sense of the
> more_specialized_fn() function in pt.c (line 13281).
>
> Specifically, I am trying to understand what each of the are:
>
> tree decl1 = DECL_TEMPLATE_RESULT (pat1);
This is the
> I must admit I don't understand the upside. I've always thought of
> plugins as something proprietary programs need because their source
> isn't open.
>
> In my view, plugins will bitrot quickly as GCC's interface changes; and
> they won't even help with the learning curve - does anyone believe
On Fri, Nov 16, 2007 at 03:03:15PM -0500, Diego Novillo wrote:
> I'm not sure if it's intended, but I don't think it's desirable. The
> information needed to do LTO optimizations should be independent from the
> debugging information.
FWIW, I disagree - not least because this makes GCC much mor
Daniel Jacobowitz wrote:
> On Fri, Nov 16, 2007 at 03:03:15PM -0500, Diego Novillo wrote:
>> I'm not sure if it's intended, but I don't think it's desirable. The
>> information needed to do LTO optimizations should be independent from the
>> debugging information.
>
> FWIW, I disagree - not lea
Dave Korn wrote:
First places to look would be GO_IF_LEGITIMATE_ADDRESS and
REG_OK_FOR_BASE_P, wouldn't they? Particularly in conjunction with
REG_OK_STRICT.
This could be a REG_OK_STRICT issue, but it isn't the usual case of
accepting an unallocated pseudo in reload, as we have a SUBREG ME
Sharing beteen the debug info and the LTO info is a very a good thing, and
I feel that we should not adopt a solution that breaks that. I'd really rather
leave 'strip --strip-debug' broken than bloat up the object files. The sort of
solution I would favor would be to make 'strip' smarter so that
Mark Mitchell wrote:
That seems reasonable to me. The transparent_union trick (copying the
fields, along with making a new TYPE_MAIN_VARIANT) might work, but even
there you have to worry about making sure you a different type_info
object, how do you mangle the name, etc. You're also likely to g
Thomas Koenig wrote:
On Thu, 2007-11-15 at 17:42 -0800, Jim Wilson wrote:
Thomas Koenig wrote:
build/genmodes -h > tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
Your problem is that you accidentally ran ../gcc/gcc/configure instead
of ../gcc/configure. However, why it fails
On Friday 16 November 2007, Dave Korn wrote:
> On 16 November 2007 05:56, Li Wang wrote:
> > As you said, the coprocessor has no ABI to describe a stack and a
> > function interface, then inline applies. But how could I inline 'main'?
> > And I am sorry for I misuse the word 'elf assembly', what ex
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage.
...if you try to use U as an argument type to a function with C++ linkage.
Jason
Snapshot gcc-4.3-20071116 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071116/
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/trunk
> "Bernd" == Bernd Schmidt <[EMAIL PROTECTED]> writes:
Bernd> I must admit I don't understand the upside. I've always thought of
Bernd> plugins as something proprietary programs need because their source
Bernd> isn't open.
Everybody explained about the existing free software that has plugins
Hello,
The amount of duplicate work done on RTL is sometimes really amazing,
especially since the merge of the dataflow branch. Some of the people
who have worked on the dataflow branch had hoped that other developers
would help with the follow-up actions to actually *use* all the
information tha
On Nov 16, 2007 11:43 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Hello,
>
> The amount of duplicate work done on RTL is sometimes really amazing,
> especially since the merge of the dataflow branch. Some of the people
> who have worked on the dataflow branch had hoped that other developers
>
On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
Initially, float could simply use double and cast the result.
For double->float the results will remain correctly rounded.
Yes, very probably, but this needs to be proven for each supported
function, due to the double rounding problem (this ma
"Dep, Khushil (GE Money)" <[EMAIL PROTECTED]> writes:
| I'm not sure that a plugin system will encourage more research and
| development. Anyone who even contemplates getting into the this field
| isn't going to be someone who is easily disuaded by challenges and
| obstacles.
I beg to disagree --
Geert Bosch wrote:
>
> On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
>
>>> Initially, float could simply use double and cast the result.
>>> For double->float the results will remain correctly rounded.
>>
>> Yes, very probably, but this needs to be proven for each supported
>> function, due t
62 matches
Mail list logo
