Re: Progress on GCC plugins ?
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 > > > tree interface or anything along those lines; if it did, I would > > > oppose that. > > > > Ahh. I don't know about that: once we have a plugin > > infrastructure, we have to document it and there will be pressure to > > stabilize it. I don't believe that an unstable plugin architecture > > has any viability at all. > > I disagree. In fact, if creating a plugin architecture comes with a > requirement to make a stable structure for trees, then I'm opposed to > it. That would hurt us far more than it would help. This is not a > slippery slope. > > An unstable plugin architecture is still very useful for our users. > Correct installation of a patched gcc is an awkward affair that many > people get wrong. Correct installation of a plugin requires no more > than a command line option. Plugins make it easy for people to share > their gcc extensions across projects or across university departments. Even if the interafce changes continuously? Maybe. I find it hard to believe, but we'll just have to agree to differ. > > > So this seems to me to be a very weak argument against plugins. > > > Adding plugins does not make it noticeably easier to integrate gcc's > > > frontend with a proprietary compiler. And adding plugins would not > > > change the issue of whether such a combination violated the GPL. > > > > > > Do you disagree with this assessment? > > > > I think there is a real possibility that, had we had such a plugin > > interface years ago, some of the gcc back-ends and optimization work > > we have would never have been paid for by some companies, and so gcc > > would be a worse compiler. > > 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 proprietary compilers (not just back-ends, optimization passes) bolted on to a gcc front-end to get Linux compatibility. > And, frankly, very few people are paying for general new gcc > optimizations. As far as I know, the only people doing so are > companies like IBM and Red Hat, and they would contribute their > changes anyhow. Do you have any examples in mind? ISTR that at least part of if-conversion was paid for, but I can't remember how much of what I know is confidential and how much is just plain wrong. > When I was in the business of convincing people to pay for gcc > work, I had a laundry list of general gcc improvements to sell. I > was never able to get a dime except for target specific > improvements. A plugin architecture would not make any difference > to that kind of work. No, but it might mean that entire gcc ports go away, as people who already have in-house compilers use them with a gcc front-end for Linux ports, rather than funding gcc ports. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Progress on GCC plugins ?
> 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 view, if we can't even get ourselves together to > permit something as simple as plugins with an unstable API, then we > deserve to lose. 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 nearly as much. Moreover, writing documentation is not a potential legal threat while plugins are. To me, that argues strongly against plugins and in favor of much more documentation.
Re: Progress on GCC plugins ?
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 proprietary compilers (not just > back-ends, optimization passes) bolted on to a gcc front-end to get > Linux compatibility. As we've discussed previously, we are already seeing that without plugins: GCCfss. Sun took gcc's frontend and attached it to their proprietary backend. So in my view introducing plugins will not make a substantive difference here. > > When I was in the business of convincing people to pay for gcc > > work, I had a laundry list of general gcc improvements to sell. I > > was never able to get a dime except for target specific > > improvements. A plugin architecture would not make any difference > > to that kind of work. > > No, but it might mean that entire gcc ports go away, as people who > already have in-house compilers use them with a gcc front-end for > Linux ports, rather than funding gcc ports. 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. So again I don't see a substantive difference here. Ian
Re: Build Failure for gcc-4.3-20071109 [SOLVED]
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
Re: Progress on GCC plugins ?
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. > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > back-ends, optimization passes) bolted on to a gcc front-end to get > > Linux compatibility. > > As we've discussed previously, we are already seeing that without > plugins: GCCfss. Sun took gcc's frontend and attached it to their > proprietary backend. So in my view introducing plugins will not make > a substantive difference here. Well, yeah, but no-one ever said it wouldn't be possible without plugins. > > > When I was in the business of convincing people to pay for gcc > > > work, I had a laundry list of general gcc improvements to sell. I > > > was never able to get a dime except for target specific > > > improvements. A plugin architecture would not make any difference > > > to that kind of work. > > > > No, but it might mean that entire gcc ports go away, as people who > > already have in-house compilers use them with a gcc front-end for > > Linux ports, rather than funding gcc ports. > > 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. > 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. > So again I don't see a substantive difference here. I guess it depends on what you mean by "substantive". As I said, I suspect that if it were easier to decouple the gcc front-end from the back-end and to maintain the resulting compiler, there would be fewer free compilers. And no, neither of us can prove it without doing the experiment. I insist, however, that when it comes to a change that potentially reduces freedom, the burden of proof -- or at least of evidence -- is on those wanting to make the change. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Progress on GCC plugins ?
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, or
are there distributed in a fully proprietary & binary only way (hence
violating the GPL)?
> 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. So again
I don't see a substantive difference here.
Regarding GCC plugins, and in contrast to some, I still view them as a
big progress (avoiding a make bootstrap is already significant). In
particular, a GCC plugin machinery permit quicker experimentation of new
stuff, and also would perhaps permit inclusion of some specialized code
(like static analysis) which won't fit in the trunk easily. Of course it
is bound by the GPL and should be GPL.
There is one (minor, & insignificant in my opinion) argument against
dynamic plugins: they require a dynamic loading machinery (typically the
libdl, dlopen or equivalent libtldl) which in principle could be
unavailable on some bizarre hosts (but I don't know of anymore such
host) In other words, they require additional features than the
theoretical plain C ANSI compiler.
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 mines, sont seulement les miennes} ***
Re: Progress on GCC plugins ?
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 nearly as much. Moreover, writing documentation is not a > potential legal threat while plugins are. To me, that argues strongly > against plugins and in favor of much more documentation. More documentation: a good thing. Contributions welcome. Plugins a potential legal threat: you must be using "legal threat" in some strange way I don't understand, but I don't see them as a threat at all. In any case, the two issues are orthogonal.
ICE in in compare_values_warnv, at tree-vrp.c:701
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 with the involved compiler passes, so any advice on where to search would help me. Given the fact that it is generic (I reproduced it on several targets), and that removing the (void*) cast in the sample code, I suppose it has to do with early lowering phases that incorrectly propagate (or not) the type of comparison operands. Thanks for your suggestions, Christophe.
RE: Progress on GCC plugins ?
-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 plugins ? --snip-- -> The concern is not a first-order effect, but a second-order effect. GCC will improve more and faster if more developers are involved. ->Plug-ins will encourage more research and development of GCC -- more features and benefits. An improved GCC will attract more users. --snip-- 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. Anyone new to a system looks for clear concise documentation - something which the opensource world can lack! 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! My 2c - have a good weekend all! -Khush.
Re: own target: combine emits invalid RTL
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 calling gen_reg_rtx()
was forbidden. Use the debugger to find out why gen_reg_rtx() is being
called when it shouldn't (no_new_pseudos).
> but after the combine pass one instruction is deleted and combined with
> the second:
>
> (note 2058 2053 2059 144 NOTE_INSN_DELETED)
>
> (insn 2059 2058 2060 144 (set (reg:SI 1256)
> (ior:SI (subreg:SI (mem/s:QI (reg/f:SI 1250) [0
> .flags+0 S1 A32]) 0)
> (const_int 2 [0x2]))) 18 {iorsi3_internal1}
> (insn_list:REG_DEP_TRUE 2053 (nil))
> (nil))
>
> This instruction is invalid and there is no pattern for a match.
It matches the "iorsi3_internal1" pattern.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
Re: Progress on GCC plugins ?
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 students that did the research > > and graduate with a favourable attitude towards using GCC in their > > future career. > > As a research student who spent 6 months working on an improvement to GCC, I > agree with all of Diego's remarks. Out of the 6 months, 4 were spent > learning the GCC internals and fighting the GCC build process, 1 was spent > writing up leaving 1 month of actual productive research. While not all of > this would be solved by a plugin system (a lot was down to documentation) it > would have significantly increased the amount of time I had to make useful > contributions. I have started looking into GCC slightly more than a year ago, since then I have successfully finished thesis on interprocedural optimizations which was largely a research project. I am still essentially a newcomer, yet I completely disagree. When I think what a plugin framework would help me with, I cannot think of anything significant. It would have saved me modifying passes.c which was not really an issue. Everything else would be as complicated as it was or even more. 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 improving it (hey, Alexander, what were your problems, someone might answer them on Wiki for others!) and, in particular, staying as friendly and forgiving community as you are (especially on IRC anyway :-). IMHO 4 months of learning how to work with GCC internals seems to be completely reasonable time for me. Compilers are complex and GCC is no toy. (And plugins won't help with this, will they?) Of course, I understand there might be other and perhaps more important uses of plugins. Martin
Re: Progress on GCC plugins ?
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
compiler. It is entirely beyond my understanding why this isn't also
obvious to you.
I beg to disagree. Exporting GCC data outside makes practical sense if
the data is somehow stable (e.g. from one version of GCC to the next).
But a plugin mechanism does not require any stability of any sort. And
the current internal representations are not (in my view) stable (and
this is good, I am not criticizing GCC here) in the same sense that the
accepted languages & GCC options are stable.
For example, the "simple" plugin mechanism many people have implicitly
in mind is just: something give you the ability to call a dlsymed
function inside a dlopened plugin as a pass in a defined (& fixed)
position in passes.c. I tend to believe it is not that difficult to
implement (it seems to me that the issue is to get it accepted in the
trunk). However, this does not guaranty at all that all the internal
representation (e.g. the tree.h and other header files) is stable.
In other words, such a plugin yourplugin.so (which you coded for future
gcc-4.4.3) might be usable from gcc 4.4.3 but not from gcc 4.4.5, and
probably not from gcc-4.5 and certainly not from gcc-5.x
I'm probably naive, but I think that there are enough incentives (both
technical compatibility as above, also legal requirements per GPL, and
community & ethical standards of free software at large) that the author
of the plugin has interest to publish his source under GPL together with
the yourplugin.so file.
So a well defined plugin architecture does not mean any stability of
internal representations (in their binary detail) or of the many GIMPLE
transformations
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 mines, sont seulement les miennes} ***
Re: Progress on GCC plugins ?
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. The user can extend the editor using a Turing-complete extension language (elisp), and commands in the extension language have the same status as native commands in C. Consider Firefox. Again, there are vast numbers of useful extensions. They allow users to customize the tool in ways that the core developers wouldn't necessarily want to support. > 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 for a > second you won't have to understand compiler internals to write a plugin? A poorly-designed plugin architecture would rot quickly. A well-designed architecture would require maintainance, but not as much work to keep up (Firefox plugins often require changes to keep up with new versions).
Re: Progress on GCC plugins ?
-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. They represent the same effort for somebody writing a plugin pass. They do *not* represent the same effort for a Mozilla hacker who just wants to compile Mozilla with the extra static-checking pass enabled. The fact that they can use a stock GCC (and potentially a precompiled plugin specific to their GCC version) is a huge advantage. Note that we're talking about analysis passes that would never be appropriate for integration with GCC directly: e.g. "statically enforce that the internal typedef PRBool is only ever 0 or 1" or "statically enforce that pointers to subclasses of MMgc::GCObject allocated on the heap are only written through this particular writebarrier pattern"... so arguments about whether we want the code to be integrated into GCC itself are irrelevant. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPdQkSSwGp5sTYNkRAjbiAKCPnFBPN4wXswT35dSx3gpyZv+DWACg3L8X 0ntugTV0nMoJoMTXa1yX+FE= =V32a -END PGP SIGNATURE-
RE: Progress on GCC plugins ?
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 > offers a simple method for avoiding the latencies of repeated bootstrap > cycles. > > 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 students that did the research > and graduate with a favourable attitude towards using GCC in their > future career. As a research student who spent 6 months working on an improvement to GCC, I agree with all of Diego's remarks. Out of the 6 months, 4 were spent learning the GCC internals and fighting the GCC build process, 1 was spent writing up leaving 1 month of actual productive research. While not all of this would be solved by a plugin system (a lot was down to documentation) it would have significantly increased the amount of time I had to make useful contributions. I fully understand that this can seems strange to people who know GCC like the back of their hand, but to a newcomer it is a huge task just to write a single useful line of code. I'm sure many give up before ever reaching that point. Alex Lamaison Imperial College London
Re: Progress on GCC plugins ?
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 compiler. It is entirely beyond my understanding why this isn't also obvious to you. Because it is not at all easier. It already is *trivial*. 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.
RE: How to let GCC produce flat assembly
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 you please give more clues? Which > backend and where I can find that "naked" function attribute, thanks. Lots of the embedded cpu backends implement it, see e.g. arm, avr, c4x, h8300 (calls it 'OS_Task'), mcore, spu. cheers, DaveK -- Can't think of a witty .sigline today
Re: Progress on GCC plugins ?
* 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? Has anyone tried to talk to those people to get them to contribute? -- Martin Michlmayr http://www.cyrius.com/
Re: Progress on GCC plugins ?
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, linux kernel, etc). It's precisely the complexity reduction features that make plug-ins so attractive. For us this means attracting more developers, which in turn means bigger potential for attracting long-time contributors, which helps with the long-term survival of GCC. 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 for a second you won't have to understand compiler internals to write a plugin? Of course not. But with a plug-in framework you get to interact with exactly the set of components important for your work, you don't have to deal with the whole compiler and its internal build machinery. Diego.
Re: Progress on GCC plugins ?
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 require) that any plugin be
covered by the GPL.
So from my perspective the downside of plugins is very small, and the
upside is very large.
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.
No. Many firefox plugins and linux kernel plugins (called modules) are
opensource!
Every GCC plugin has to be open source (because GCC is GPL) because it
has to be GPL!
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 for a
second you won't have to understand compiler internals to write a plugin?
Plugin will help to experiment, and a major point of a plugin is that it
can be removed or disabled without impacting GCC major ability to
compile stuff (it might only decrease performance, additional
functionalities, .. if removed).
Plugins should make daily work on GCC easier: you don't have to
bootstrap everything! And you could release it (with its source code)
even if it is incomplete, because it can be very easily disabled.
And plugins could even be dynamically produced (shameless ad for my
paper & work).
The main point of a plugin is that it could be removed easily! Much
harder for anything else.
Just hacking GCC for making a feature which can be robustly disabled is
a significant work! Plugins get you that for free... And it is essential
for every kind of "experimental" or "additional" features! You really
want it to be easy to remove!
--
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 mines, sont seulement les miennes} ***
RE: Progress on GCC plugins ?
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 seems, on the face of it, a specious argument. It's only true because you have already in the past bootstrapped the compiler and kept the build directory lying around. Saying "I don't have to bootstrap because I've already done it" doesn't justify your claim that it's no easier or harder for new developers (who haven't got $objdir kicking around already). cheers, DaveK -- Can't think of a witty .sigline today
Re: Progress on GCC plugins ?
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. We're talking about plugins at the tree/GIMPLE level. > > > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > > back-ends, optimization passes) bolted on to a gcc front-end to get > > > Linux compatibility. > > > > As we've discussed previously, we are already seeing that without > > plugins: GCCfss. Sun took gcc's frontend and attached it to their > > proprietary backend. So in my view introducing plugins will not make > > a substantive difference here. > > Well, yeah, but no-one ever said it wouldn't be possible without > plugins. I'm sorry, I've lost the sense of the argument here. I thought you were arguing that plugins would make this more likely. I'm saying that it's already happening, and that it's not noticeably easier with plugins. So can you repeat your point? > > > > When I was in the business of convincing people to pay for gcc > > > > work, I had a laundry list of general gcc improvements to sell. I > > > > was never able to get a dime except for target specific > > > > improvements. A plugin architecture would not make any difference > > > > to that kind of work. > > > > > > No, but it might mean that entire gcc ports go away, as people who > > > already have in-house compilers use them with a gcc front-end for > > > Linux ports, rather than funding gcc ports. > > > > 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. If I follow this, it seems that you are saying that if we have plugins, some people will choose to use them to get a gcc frontend for a proprietary compiler rather than doing a gcc port. I'm sorry, I don't buy this at all. Again, people can already do this, and adding plugins does not make it substantially easier. > > 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. > > > So again I don't see a substantive difference here. > > I guess it depends on what you mean by "substantive". As I said, I > suspect that if it were easier to decouple the gcc front-end from the > back-end and to maintain the resulting compiler, there would be fewer > free compilers. And no, neither of us can prove it without doing the > experiment. I insist, however, that when it comes to a change that > potentially reduces freedom, the burden of proof -- or at least of > evidence -- is on those wanting to make the change. I'm very sorry to hear you take that position. I think you are letting an unlikely fear sacrifice a clear benefit. 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 view, if we can't even get ourselves together to permit something as simple as plugins with an unstable API, then we deserve to lose. Ian
Re: Progress on GCC plugins ?
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 that now. So most GCC ports are GPL-ed but outside
FSF source tree. Hence, a plugin machinery (including for backends)
would make this easier!
I also expressed (orally) the concern (at previous GCC summit, Ottawa
july 2007) that getting the copyright assignment signed is a lot of work
in some organizations and I would hope that the FSF might consider
making it easier (I don't know exactly how, as a non lawyer I would
dream of simple GPLed contributions, with the copyright owner giving the
FSF the right to sue on its behalf, ...) but apparently it is not a
concern.
I still believe that GCC needs more developers, and attracting them
could be a concern.
--
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 mines, sont seulement les miennes} ***
Re: Progress on GCC plugins ?
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 any that GCC has; this is necessary since they are sold to be extended by the buyer. I won't name names because it's inappropriate to plug proprietary software on this list.
Re: Progress on GCC plugins ?
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 into gcc. In my view, if we can't even get ourselves together to permit something as simple as plugins with an unstable API, then we deserve to lose. That's precisely my concern. Diego.
Re: Progress on GCC plugins ?
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 about plug-ins for gcc > > > > > backends. We're talking about plugins at the tree/GIMPLE level. > > > > > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > > > back-ends, optimization passes) bolted on to a gcc front-end to get > > > > Linux compatibility. > > > > > > As we've discussed previously, we are already seeing that without > > > plugins: GCCfss. Sun took gcc's frontend and attached it to their > > > proprietary backend. So in my view introducing plugins will not make > > > a substantive difference here. > > > > Well, yeah, but no-one ever said it wouldn't be possible without > > plugins. > > I'm sorry, I've lost the sense of the argument here. I thought you > were arguing that plugins would make this more likely. I'm saying > that it's already happening, and that it's not noticeably easier > with plugins. So can you repeat your point? Ah, OK. I think that it will be noticeably easier with plugins. If the plugin architecture really doesn't make it easier, my point falls. > > > > > When I was in the business of convincing people to pay for gcc > > > > > work, I had a laundry list of general gcc improvements to sell. I > > > > > was never able to get a dime except for target specific > > > > > improvements. A plugin architecture would not make any difference > > > > > to that kind of work. > > > > > > > > No, but it might mean that entire gcc ports go away, as people who > > > > already have in-house compilers use them with a gcc front-end for > > > > Linux ports, rather than funding gcc ports. > > > > > > 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. > > If I follow this, it seems that you are saying that if we have > plugins, some people will choose to use them to get a gcc frontend > for a proprietary compiler rather than doing a gcc port. I'm > sorry, I don't buy this at all. Again, people can already do this, > and adding plugins does not make it substantially easier. 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 compiler. It is entirely beyond my understanding why this isn't also obvious to you. > > > 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. > > > > > So again I don't see a substantive difference here. > > > > I guess it depends on what you mean by "substantive". As I said, > > I suspect that if it were easier to decouple the gcc front-end > > from the back-end and to maintain the resulting compiler, there > > would be fewer free compilers. And no, neither of us can prove > > it without doing the experiment. I insist, however, that when it > > comes to a change that potentially reduces freedom, the burden of > > proof -- or at least of evidence -- is on those wanting to make > > the change. > > I'm very sorry to hear you take that position. I think you are > letting an unlikely fear sacrifice a clear benefit. > > 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 view, if we can't even get > ourselves together to permit something as simple as plugins with an > unstable API, then we deserve to lose. OK. Well, that's your view. I don't believe that the presence or absence of plugins will make one iota of differebce to mainstream use of gcc. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Progress on GCC plugins ?
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, with
some documentation (I agree it could be better; feel free to add it at
least on the wiki).
Compare this to the Linux kernel (which I do not know in detail). While
it might be more documented in the source tree, it is certainly more
documented outside (there are several good books on kernel internals;
I'm not sure that equivalent books for GCC exist, and I would spend 50
euros -of my own money- for such a book if it existed).
And still, diving and contributing to the Linux kernel and/or to GCC is
really hard (I admit I don't know what is harder, and probably nobody
knows both software in the same details!).
The biggest barrier to working on GCC is a learning & working effort
barrier. I don't think documentation would help a lot (and maintaining
it is a nightmare).
I am not sure (I really don't know) if more documentation on GCC exist,
even inside companies with teams of a dozen of talented GCC
contributors. I don't believe (maybe I am wrong) that for instance IBM
or Google or AMD (or any company with several GCC developers full time)
have a lot of (maybe proprietary) internal documentation on GCC.
I even don't believe that competitor proprietary compilers are much more
documented than GCC.
GCC is an incredibly complex software (because any similar compiler has
to be complex and huge).
PS. My mentor on GCC has been Sebastian Pop. I'll never thank him enough!
--
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 mines, sont seulement les miennes} ***
RE: own target: combine emits invalid RTL
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 > historical reasons. This is something that should be fixed some day. > > INSN_SCHEDULING is defined if you have any of the instruction scheduling > related patterns in your md file. If this is a new port, and you > haven't tried to add instruction scheduling support, then > INSN_SCHEDULING won't be defined yet. > > Anyways, this means that the RTL is correct, and we expect reload to fix > it. The error from gen_reg_rtx implies that reload is failing, perhaps > because of a bug in your port that doesn't handle (SUBREG (MEM)) correctly. > > There are other legitimate cases where (SUBREG (MEM)) can occur during > reload, when you have a subreg of an pseudo that did not get allocated > to a hard register for instance, so even if register_operand and > general_operand are changed, you still need to find and fix the bug in > your port. 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. cheers, DaveK -- Can't think of a witty .sigline today
Re: [LTO] LTO breaks if debug info is stripped from object files
> 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> --strip-debug should remove LTO data. Having LTO dwarf information dependent on debugging section may not be great, but is the alternative better? If we place the lto dwarf info in another section, should debuggers also look there? Or should we duplicate info in both .debug and .lto, which bloats the file? Or should binutils look for .to and not strip .debug or warn about stripping .debug affecting LTO? David
Re: Progress on GCC plugins ?
> 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 have been put into gcc. In my view, if we can't even get >> ourselves together to permit something as simple as plugins with an >> unstable API, then we deserve to lose. Andrew> OK. Well, that's your view. I don't believe that the presence or Andrew> absence of plugins will make one iota of differebce to mainstream use Andrew> of gcc. The concern is not a first-order effect, but a second-order effect. GCC will improve more and faster if more developers are involved. Plug-ins will encourage more research and development of GCC -- more features and benefits. An improved GCC will attract more users. In my experience, most users prefer GCC because it is free, generates code with "good-enough" performance, supports many architectures and languages, defines a uniform C language, and is distributed with an "open source-compatible" license. I do not believe that the GPL or the Free Software Foundation's goals are near the top of the reasons for most users. If developers and users find that another free compiler satisfies those requirements better, I suspect developers and users would start migrating away. As Ian said, that ultimately would not hurt software freedom; it might hurt Free Software, and it definitely would hurt the GNU Project and the Free Software Foundation. David
Re: Progress on GCC plugins ?
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, but doesn't help > > this issue nearly as much. Moreover, writing documentation is not a > > potential legal threat while plugins are. To me, that argues strongly > > against plugins and in favor of much more documentation. > > No, this argument is fallacious. Plug-ins and poor documentation are > not, and should not be related. Poor documentation is an orthogonal > problem which ALSO needs to be addressed. I brought up the documentation in this debate so let me clarify what I meant. I simply wanted to tell that you cannot expect that plugins are going to make life easier for newcomers. If that is your goal, you have to do something else. On the contrary, I have acknowledged there might be other and very beneficial reasons for having such a framework like the static analysis tools which I know nothing about. The conclusion is that the arguments in favor of plugins should concentrate on these technical advantages rather than on research. Such arguments, if explained a bit more thoroughly, might indeed be very interesting to hear (read). Finally, I also do not think plugins would all of a sudden allow anyone to hijack the compiler more easily than it is possible today. Martin
Re: Progress on GCC plugins ?
> ">" == 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 sympathetic to it -- it would have been really useful to me, a couple years ago, if GCC had had better documentation. However, the two things are not tradeable. It isn't as if we are deciding what to do with limited manpower. GCC as a project basically cannot do that. Rather, we're deciding what changes to accept. There are existing patches to add plugins, and, presumably, the interest and manpower to polish and maintain them. Sadly, there aren't ready patches to radically upgrade the documentation. It doesn't make sense to reject plugin patches on the basis that documentation would be preferable. I find it unlikely that this will cause more documentation to be written. Instead, I think the likely effect is that GCC will lose some potential developers. Tom
Re: Progress on GCC plugins ?
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 you'd be trying > to exclude. 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 they have to risk legal problems. And he has some evidence that this sometimes happens (C++, Objective-C, many contributed back ends). So the intent isn't to prevent certain people from using it, but to have those people contribute the changes back even if that isn't their preference. Now that's fine as far as it goes, but when it becomes a defense of an opaque, non-extendable architecture we have a problem.
Re: Progress on GCC plugins ?
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 never contributed. > > Can you list those six ports? Has anyone tried to talk to those > people to get them to contribute? C2 Microsystems Jazz C2 Microsystems ENE Cray X-2 Cradle Technologies DSE A processor from a Japanese company which I have forgotten, maybe Toshiba and, OK, I thought I had seen six but now I can only remember five There are also routinely messages on gcc-help referring to private ports which I have not seen myself. The truth is, there is no real advantage to anybody for these ports to be contributed. They often have machine specific changes to the machine independent parts of gcc, which would have to be managed somehow. These are not popular processors. Nobody outside the manufacturer has the knowledge or interest to maintain the backends. We've seen plenty of cases where a backend was contributed and then dropped a couple of years later. These would just be more of the same. Ian
Re: FW: matrix linking
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 project (http://ptolemy.eecs.berkeley.edu/) we were doing that in 1990: we could define new classes and load them into a running application, without restarting.
Re: Progress on GCC plugins ?
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 does these ports are published elsewhere, in the spirit of GPL, or > are there distributed in a fully proprietary & binary only way (hence > violating the GPL)? Fallacy of the excluded middle. I'm not aware of anybody who violates the GPL when distributing gcc. But the GPL permits private distribution: if you give people both the binaries and the sources, you have satisfied the requirements of the GPL. That is what happens with private gcc ports: the companies distribute the modified compiler to their customers, but not to the public at large. Under the terms of the GPL, their customers are of course free to distribute the compiler to anybody they choose. In practice, they don't bother; why should they? > There is one (minor, & insignificant in my opinion) argument against > dynamic plugins: they require a dynamic loading machinery (typically > the libdl, dlopen or equivalent libtldl) which in principle could be > unavailable on some bizarre hosts (but I don't know of anymore such > host) In other words, they require additional features than the > theoretical plain C ANSI compiler. Yes. But in practice they can work on GNU/Linux, all Unix systems, Windows, and MacOS, so I don't think this is a major concern. Ian
FW: matrix linking
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 brake through the barriers of common software development. Videlicet, the invention makes possible to change the business logic of the application right on the fly, without any restarting of the application. And this is tread safe operation, so it means you do not need to suspend the (multi-threaded) application even. Just use your imagination in order to understand what opportunities it gives. It is the same as comparing server and the desktop PC. I have made a patch to GCC compiler and have got some results, please find the details of the innovation here: http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking. I would have been kindly appreciated of your comments on the subject. In case of questions do no hesitate to ask. Yours sincerely, George.
RE: Progress on GCC plugins ?
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 they have > to risk legal problems. And he has some evidence that this sometimes > happens (C++, Objective-C, many contributed back ends). So the intent > isn't to prevent certain people from using it, but to have those people > contribute the changes back even if that isn't their preference. > > Now that's fine as far as it goes, but when it becomes a defense > of an opaque, non-extendable architecture we have a problem. Agreed. It can also make it harder to contribute changes back, thus possibly precluding some contributions. -Jerry
RE: How to let GCC produce flat assembly
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 any other informations helps > linker to organize a executable from the cc1 output. In a word, codes > something like the following is what I want, If possible to let cc1 > produce such assembly? Thanks. > > movl$2, -4(%ebp) > movl$2, -8(%ebp) > movl-8(%ebp), %eax > addl-4(%ebp), %eax 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. cheers, DaveK -- Can't think of a witty .sigline today
RE: Progress on GCC plugins ?
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 trying to exclude. Think about it. You have nothing to fear from people writing trivial add-ons (if they're useful, they'll be duplicated in open source; if not, they'll fade away). The only people you might need to worry about would be those writing significant new compiler designs/enhancements using GCC as a starting point (and possibly trying to get past the GPL by avoiding direct linking/etc.). Yet as has already been pointed out, they already can do this by creating their own interface to plug into. If they use a standard interface (since the code base would favor this), it would be easier to replace their plug-ins with open-source alternatives later. -Jerry
Re: Progress on GCC plugins ?
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 gcc. In my view, if we can't even get ourselves together to permit something as simple as plugins with an unstable API, then we deserve to lose. 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 nearly as much. Moreover, writing documentation is not a potential legal threat while plugins are. To me, that argues strongly against plugins and in favor of much more documentation. No, this argument is fallacious. Plug-ins and poor documentation are not, and should not be related. Poor documentation is an orthogonal problem which ALSO needs to be addressed. The existence of a plug-in framework with bad/no documentation does not make working with GCC any easier. Diego.
Re: [LTO] LTO breaks if debug info is stripped from object files
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 LTO breaks if 'strip --strip-debug' has been run on object files submitted to it as input. Is this intended or desirable behavior? 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. We could have a --strip-lto option for strip, but I don't think --strip-debug should remove LTO data. Mark, Kenny, your thoughts? Diego.
Re: Progress on GCC plugins ?
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 improving it (hey, Alexander, what were your problems, someone might answer them on Wiki for others!) and, in particular, staying as friendly and forgiving community as you are (especially on IRC anyway :-). I certainly agree with this! The same effort spent on documentation rather than on a plugin system would, imho, give greater value. But, as there seems to be a willingness to work on plugins in contrast to the willingness to document, I am supporting progress wherever it is on offer. The project is over and eventually I solved the problems through sweat and tears. I have the solutions scribbled down somewhere and eventually I mean to put the up on the web somewhere to save others the same pain.
Re: Progress on GCC plugins ?
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 any plugin be > covered by the GPL. > > So from my perspective the downside of plugins is very small, and the > upside is very large. 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 for a second you won't have to understand compiler internals to write a plugin? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: How to let GCC produce flat assembly
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 the section or any other informations helps linker to organize a executable from the cc1 output. In a word, codes something like the following is what I want, If possible to let cc1 produce such assembly? Thanks. movl$2, -4(%ebp) movl$2, -8(%ebp) movl-8(%ebp), %eax addl-4(%ebp), %eax 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 you please give more clues? Which backend and where I can find that "naked" function attribute, thanks. cheers, DaveK Regards, Li Wang
Re: Help understanding overloaded templates
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 actual FUNCTION_DECL node that represents the function template. It's just like another other (non-template) FUNCTION_DECL, except that it's associated with a template and will use some of the template parameters in its definition and declaration. > tree targs1 = make_tree_vec (DECL_NTPARMS (pat1)); DECL_NTPARMS is the number of template parameters, so we're just making a vector that long. > tree tparms1 = DECL_INNERMOST_TEMPLATE_PARMS (pat1); For member templates, this pulls out just the innermost template parameters. > tree args1 = TYPE_ARG_TYPES (TREE_TYPE (decl1)); This is the list of function parameter types. e.g., in a function template template void f(T*, int, float); this would be a TREE_LIST containing the types T*,, int, and float. > and how the function is supposed to deal with variadic functions in > terms of these. That is to say, if a function is variadic, how is that > represented in these data structures? By "variadic" I assume you mean C-style variadic functions, e.g., template void f(T x, ...); and not the C++0x variadic templates. The presence of an ellipsis is indicated by the last node in the TREE_LIST being void_list_node; if there is no ellipsis, the last parameter's TREE_CHAIN will simply be NULL_TREE. - Doug
Re: Progress on GCC plugins ?
> 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 for a > second you won't have to understand compiler internals to write a plugin? I agree. I don't understand the upside either, for the same reasons. 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.
Re: [LTO] LTO breaks if debug info is stripped from object files
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 more sensitive to the correctness of its debugging output! -- Daniel Jacobowitz CodeSourcery
Re: [LTO] LTO breaks if debug info is stripped from object files
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 least because this makes GCC much more sensitive > to the correctness of its debugging output! Right. In these discussions about DWARF-for-LTO, it's important to remember several things that went into the design. Some of these things have changed, and so maybe things about DWARF-for-LTO should change too, but they're still relevant for perspective. Here are three of the goals: 1. One goal was a compiler-independent (or, at least, GCC-version-independent) representation. We gave up on that for function-body representations, but the original LTO design (as circulated back in late 2005) had us designing a compiler-independent representation of expressions, too, with the goal of enabling non-LTO uses (such as IDEs, code-analysis tools, etc.). 2. Another goal was not to make .o files larger by duplicating the debug information for LTO. LTO needs names and types of functions; so does DWARF. 3. Finally, we felt DWARF was already designed for some combination of compactness and ability to skip about in the representation (rather than having to un-serialize everything to get any information) so it seemed a plausible representation format. 4. As Daniel says, a secondary goal was to improve GCC's debug information by making its correctness imperative for LTO. If all we care about is performance, that might not matter much -- but as per recent discussions on this list, many users care a lot about debugging information and the debugging experience, so improving debug information quality seems beneficial. For example, capturing GNU attributes in debug information for LTO will also debuggers and other tools that peer at debug information to have a more accurate view of the program. If we decide that we want to put the LTO declarative information in a separate section, we might well be able to do better than DWARF. I don't feel like we know enough yet to do that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: own target: combine emits invalid RTL
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 MEM here. Probably there is code in the backend that assumes SUBREG can only contain a REG, which is incorrect. SUBREG can also contain a MEM. You need to check to make sure. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [LTO] LTO breaks if debug info is stripped from object files
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 it preserved the part of the debug info that LTO needed. Ideally, we would segregate the data so that the portions of the debug info of interest to LTO could be easily identified or its location compactly described so that 'strip' doesn't actually have to know much about LTO. I don't understand the current usage of DWARF by LTO well enough, however, to know whether this is feasible. --Bill
Re: Attributes on structs
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 get
messages like "can't convert X to X" because one of them has an attribute.
Yep. That sort of thing seems reasonable for C, but not for C++, and so
my inclination would be to disallow it for both.
Incidentally, while poking at this I noticed that build_duplicate_type
has been broken since the gomp merge; it just returns the same type. I
would be inclined to just reject transparent_union as well, but it seems
that existing practice is to write
typedef union { ... } U __attribute ((transparent_union));
which modifies the typedef copy of the union rather than the original
type. That is, if build_duplicate_type were doing its job.
I'm not sure what to do about this. I'm reluctant to break the existing
code that does this (such as the glibc stdlib.h). Perhaps just passing
the attribute through to the original type is appropriate for this case,
but seems wrong for
union U2_ { ... };
typedef union U_ U2 __attribute ((transparent_union));
and I'm not sure how to distinguish the two in the compiler. Of course,
we could just pass it through in all cases and tell people who want to
use both the original union and its transparent variant that they're
crazy and need to write another union.
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. Perhaps that's why
build_duplicate_type got broken.
Jason
Re: bootstrap failure with rev 130208
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 this way has me baffled. I can easily reproduce it though. The rule to build genmodes by the way is build/gen%$(build_exeext): build/gen%.o $(BUILD_LIBDEPS) $(CC_FOR_BUILD) $(BUILD_CFLAGS) $(BUILD_LDFLAGS) -o $@ \ $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS) This is some GNU make magic. For some reason, make finds this rule if gcc is correctly configured, but can't find it if gcc is incorrectly configured. I looked at make -d output; I didn't find it helpful. For some reason the search order for matching patterns is different, but I see no clue why. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: How to let GCC produce flat assembly
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 exactly I mean > > by that is how to omit the section or any other informations helps > > linker to organize a executable from the cc1 output. In a word, codes > > something like the following is what I want, If possible to let cc1 > > produce such assembly? Thanks. > > > > movl$2, -4(%ebp) > > movl$2, -8(%ebp) > > movl-8(%ebp), %eax > > addl-4(%ebp), %eax > > 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. __attribute__((naked)) isn't useful in that way. A side-effect of suppressing supressing the function prologue/epiloge is that you effectively can't use C in that function. The compiler will still generate references to the stack frame if it feels like it. This will fail fairly rapidly as you've suppressed the code to create that stack frame. IMHO gcc isn't really suited to this kind of absurdly small machine implementing a crippled subset of C. C (and most of the other langages gcc supports) pretty much assume a machine will a stack. Note that this doesn't mean your CPU has to have dedicated stack hardware. Most RISC architectures don't have any specific support for this, we just pick a register, and by convention use that as the stack pointer. If there isn't a ABI for your target, to get to design one. Paul
Re: Attributes on structs
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
gcc-4.3-20071116 is now available
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 revision 130245 You'll find: gcc-4.3-20071116.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20071116.tar.bz2 C front end and core compiler gcc-ada-4.3-20071116.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20071116.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20071116.tar.bz2 C++ front end and runtime gcc-java-4.3-20071116.tar.bz2 Java front end and runtime gcc-objc-4.3-20071116.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20071116.tar.bz2The GCC testsuite Diffs from 4.3-20071109 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: Progress on GCC plugins ?
> "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. But, I thought I'd mention a few use cases for plugins. The biggest benefit of a plugin system is that you can add things to the compiler without requiring all your users to build their own compiler. E.g., Mozilla developers have said before (even earlier in this thread) that they would like to be able to run Mozilla-specific analysis passes over their code, say before checkin. Probably this consists of a bunch of warning checks that are suitable for Mozilla but not suitable for inclusion in GCC. With a plugin system they have the option of providing "Mozilla GCC plugin for Fedora 9", or whatever, and avoiding the mess of "to build Mozilla first you have to build GCC with patch X". Bernd> In my view, plugins will bitrot quickly as GCC's interface Bernd> changes; and they won't even help with the learning curve - Bernd> does anyone believe for a second you won't have to understand Bernd> compiler internals to write a plugin? Plugins are about deployment, not development. They don't make writing the code much simpler. That is why we can argue that the risk they pose is small: they don't make it significantly simpler to make a proprietary GCC. Tom
Limits of stage3 changes
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 that, for example, the df-scan problem collects. My favorite example of this lack of follow-through is gcse.c. It computes reg-def chains and monotonic insn IDs. Guess what df-scan provides? Attached is an example of the cleanups I would have liked to see during stage 2 of GCC 4.3. The patch is not finished, but it gives you an idea of what is possible. The patch avoids computation of redundant information by making gcse use the df-scan information, instead of computing everything for itself. In theory, this saves memory and it reduces the number of passes over all RTX'en in memory. So, if finished, this should give compile time improvements and a slightly smaller memory footprint. Question is, whether this kind of rather large changes is acceptable for stage 3 or not. Me, I call it a "regression fix" if it reduces compile time. But I will not work on it now (or ask help from others) if it is a priori not acceptable for stage 3. Thus, thoughts please! :-) (FWIW I have almost complete rewrites of half the passes in gcse.c, and the attached patch is a kind-of back port of the ideas from my new implementations...) Gr. Steven * gcse.c (uid_cuid, max_uid, INSN_CUID, max_cuid, struct reg_set, reg_set_table, REG_SET_TABLE_SLOP, reg_set_in_block, alloc_reg_set_mem, free_reg_set_mem, record_one_set, record_set_info, compute_set, grealloc): Remove. (recompute_all_luids): New function. (gcse_main): Don't compute sets, and don't do related memory allocations/free-ing. If something changed before the end of the pass, update LUIDs using recompute_all_luids. (alloc_gcse_mem): Don't compute LUIDs. Don't allocate reg_set memory. (free_gcse_mem): Don't free it either. (oprs_unchanged_p, load_killed_in_block, record_last_reg_set_info): Use the df insn LUIDs. (load_killed_in_block): Likewise. (compute_hash_table_work): Don't compute reg_set_in_block. (compute_transp): Use DF_REG_DEF_CHAINs. (local_cprop_pass): Don't use compute_sets and related functions. (one_cprop_pass, pre_gcse, one_pre_gcse_pass, one_code_hoisting_pass): Use get_max_uid() instead of max_cuid. (insert_insn_end_basic_block, pre_insert_copy_insn, update_ld_motion_stores): Don't try to keep reg_set tables up to date. (pre_insert_copies): Use df insn LUIDs. (reg_set_info): Don't use extra bitmap argument. (compute_store_table): Don't compute reg_set_in_block. Use DF scan information to compute regs_set_in_block. (free_store_memory, store_motion): Don't nullify reg_set_in_block. (bypass_jumps): Don't use compute_sets and friends. Index: gcse.c === *** gcse.c (revision 130236) --- gcse.c (working copy) *** along with GCC; see the file COPYING3. *** 27,36 - a store to the same address as a load does not kill the load if the source of the store is also the destination of the load. Handling this allows more load motion, particularly out of loops. -- ability to realloc sbitmap vectors would allow one initial computation - of reg_set_in_block with only subsequent additions, rather than - recomputing it for each pass - */ /* References searched while implementing this. --- 27,32 *** static struct hash_table expr_hash_table *** 362,431 /* Copy propagation hash table. */ static struct hash_table set_hash_table; - /* Mapping of uids to cuids. -Only real insns get cuids. */ - static int *uid_cuid; - - /* Highest UID in UID_CUID. */ - static int max_uid; - - /* Get the cuid of an insn. */ - #ifdef ENABLE_CHECKING - #define INSN_CUID(INSN) \ - (gcc_assert (INSN_UID (INSN) <= max_uid), uid_cuid[INSN_UID (INSN)]) - #else - #define INSN_CUID(INSN) (uid_cuid[INSN_UID (INSN)]) - #endif - - /* Number of cuids. */ - static int max_cuid; - /* Maximum register number in function prior to doing gcse + 1. Registers created during this pass have regno >= max_gcse_regno. This is named with "gcse" to not collide with global of same name. */ static unsigned int max_gcse_regno; - /* Table of registers that are modified. - -For each register, each element is a list of places where the pseudo-reg -is set. - -For simplicity, GCSE is done on sets of pseudo-regs only. PRE GCSE only -requires knowledge of which blocks kill which regs [and thus could use -a bitmap instead of the lists `reg_set_table' uses]. - -`reg_set_table' and could be turned into an array of bitmaps (num-bbs x -num-regs) [however perhaps it may be useful to keep the data as is]. One -advantage of recording things this way is that `reg_set_table' is fairly -sparse with r
Re: Limits of stage3 changes
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 > would help with the follow-up actions to actually *use* all the > information that, for example, the df-scan problem collects. > > My favorite example of this lack of follow-through is gcse.c. It > computes reg-def chains and monotonic insn IDs. Guess what df-scan > provides? > > Attached is an example of the cleanups I would have liked to see > during stage 2 of GCC 4.3. The patch is not finished, but it gives > you an idea of what is possible. The patch avoids computation of > redundant information by making gcse use the df-scan information, > instead of computing everything for itself. In theory, this saves > memory and it reduces the number of passes over all RTX'en in memory. > So, if finished, this should give compile time improvements and a > slightly smaller memory footprint. > > Question is, whether this kind of rather large changes is acceptable > for stage 3 or not. Me, I call it a "regression fix" if it reduces > compile time. But I will not work on it now (or ask help from others) > if it is a priori not acceptable for stage 3. > > Thus, thoughts please! :-) I think we should be able to rely on DF enough to make mostly mechanical changes like this ok for stage3. I don't know where we are in terms of compile-time compared to 4.2 or 4.1, but certainly if you go back further compile-time is always a "regression". Thanks, Richard.
Re: Using crlibm as the default math library in GCC sources
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 may take some time for functions like pow). If a real number is rounded to the nearest number in a binary floating point format with 2*p+1 bits and that result rounded again to a p-bit float, the result is the same as if the original value was rounded to a p-bit float directly. -Geert PS. Sorry, dont' have a reference to a proof handy at the moment.
Re: Progress on GCC plugins ?
"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 -- speaking from experience. The issue isn't `obstacle'; from my perspective, it is that of time and energy sunk into `mere re-invention of pointless wheels with no research result'. I had no trouble getting students up to spead on well-structured plugable proprietary compiler within weeks. However, the same experience on GCC has proven much less impressive results. Consequently, we have been making more progress working with proprietary compiler than with GCC -- something I find myself embarrasing :-( -- Gaby
Re: Using crlibm as the default math library in GCC sources
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 to the double rounding problem (this may take some time >> for functions like pow). > > If a real number is rounded to the nearest number in a binary floating > point format with 2*p+1 bits and that result rounded again to > a p-bit float, the result is the same as if the original value was > rounded to a p-bit float directly. > > -Geert > > PS. Sorry, dont' have a reference to a proof handy at the moment. In particular, when using x87 code to implement float, it makes no difference for a single floating point operation followed by a store whether 32- 53- or 64-bit precision mode is active. The double rounding problem becomes a big issue when substituting 64-bit precision mode for double operations; hence the policy of Microsoft and certain BSD variants of setting 53-bit precision mode.
