Re: Copy assignments for non scalar types
On Tue, 13 Apr 2010, Sebastian Pop wrote:
> On Tue, Apr 13, 2010 at 13:14, Sebastian Pop wrote:
> > Hi,
> >
> > While working on the tree-if-conv.c, I realized that the copy
> > of the contents of a non scalar variable are not correctly done.
> > The copy assignment triggers this error:
> >
> > error: virtual SSA name for non-VOP decl
> > while verifying SSA_NAME _ifc_.2005_46 in statement
> > # .MEM_394 = VDEF <.MEM_475>
> > _ifc_.2005_46 = ops[j_457];
> >
> > The array reference looks like this:
> >
> > > type > sizes-gimplified asm_written type_0 BLK
> >
> > For scalar types, the code that creates the copy is working correctly:
> >
> > /* Create a new temp variable of type TYPE. Add GIMPLE_ASSIGN to assign EXP
> > to the new variable. */
> >
> > static gimple
> > ifc_temp_var (tree type, tree exp)
> > {
> > const char *name = "_ifc_";
> > tree var, new_name;
> > gimple stmt;
> >
> > /* Create new temporary variable. */
> > var = create_tmp_var (type, name);
> > add_referenced_var (var);
> >
> > /* Build new statement to assign EXP to new variable. */
> > stmt = gimple_build_assign (var, exp);
> >
> > /* Get SSA name for the new variable and set make new statement
> > its definition statement. */
> > new_name = make_ssa_name (var, stmt);
> > gimple_assign_set_lhs (stmt, new_name);
> > SSA_NAME_DEF_STMT (new_name) = stmt;
> > update_stmt (stmt);
> >
> > return stmt;
> > }
> >
> > What is missing in this function to make it handle non scalar types?
> >
>
> At least this is missing (but it is not enough, so I am still looking for
> a solution):
>
> if (gimple_referenced_vars (cfun))
> {
> add_referenced_var (t);
> mark_sym_for_renaming (t);
> }
>
> from tree-dfa.c:
>
> /* Build a temporary. Make sure and register it to be renamed. */
>
> tree
> make_rename_temp (tree type, const char *prefix)
> {
> tree t = create_tmp_var (type, prefix);
>
> if (TREE_CODE (TREE_TYPE (t)) == COMPLEX_TYPE
> || TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
> DECL_GIMPLE_REG_P (t) = 1;
>
> if (gimple_referenced_vars (cfun))
> {
> add_referenced_var (t);
> mark_sym_for_renaming (t);
> }
>
> return t;
> }
>
> I will replace the call to create_tmp_var with make_rename_temp.
No. make_rename_temp should go away. Please.
Btw, you can't make an SSA name of aggregate type.
Richard.
Re: vectorization, scheduling and aliasing
On Wed, Apr 14, 2010 at 8:48 AM, roy rosen wrote:
> Hi All,
>
> I have implemented some vectorization features in my gcc port.
>
> In the generated code for this function I can see a scheduling problem:
>
> int xxx(int* __restrict__ a, int* __restrict__ b)
> {
> int __restrict__ i;
> for (i = 0; i < 8; i++)
> {
> a[i] = b[i];
> }
> return 0;
> }
>
> from asmcons:
>
> (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
> (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load}
> (nil))
>
> (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
> (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
> (nil)))
>
> (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
> (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
> (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
> (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
> (nil)))
>
> (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
> (const_int 8 [0x8])) [2 S8 A64])
> (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
> (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
> (nil
>
> from sched1 - dependecies list:
> --- Region Dependences --- b 3 bb 0
> ;; insn code bb dep prio cost reservation
> ;; -- --- ---
> ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
> ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
> ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
> ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
> ;; 58 101 3 4 1 1 (3_slots+pcu) :
>
> As you can see, insn 19 is dependant on 18.
> I think that this should not happen since the arrays has __restrict__.
> It might have something to do with aliasing.
>
> Are you aware of any kind of problems regarding aliasing and vectors?
> Can you think of anything else that might be wrong in my code that
> leads gcc to think that there is a dependency between insn 18 and 19?
It completely depends on the GCC version you are using. The
MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
they are not existant. Try recent trunk which should work fine.
Richard.
> Thanks, Roy.
>
Re: Copy assignments for non scalar types
On Wed, Apr 14, 2010 at 04:40, Richard Guenther wrote: > No. make_rename_temp should go away. Please. I don't disagree, in principle (less code is always good). What is wrong with it? Diego.
GCC 4.5.0 Status Report (2010-04-14)
Status == The GCC 4.5.0 release has been created and the branch is now open for regression and documentation fixes again. The release will be annonced once the upload to ftp.gnu.org finished and the mirrors had a chance to catch up. Quality Data Priority # Change from Last Report --- --- P10 P2 90 + 9 P3 10 + 6 --- --- Total 100 + 15 Previous Report === http://gcc.gnu.org/ml/gcc/2010-03/msg00477.html The next status report will be sent by Jakub. -- Richard Guenther Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: Copy assignments for non scalar types
On Wed, 14 Apr 2010, Diego Novillo wrote: > On Wed, Apr 14, 2010 at 04:40, Richard Guenther wrote: > > > No. make_rename_temp should go away. Please. > > I don't disagree, in principle (less code is always good). What is > wrong with it? It asks the SSA renamer to put your new variables into SSA form. It's very simple to do that manually (at least if no PHIs are involved), so better do that. Richard.
Re: Copy assignments for non scalar types
Hi, On Wed, Apr 14, 2010 at 01:31:05PM +0200, Richard Guenther wrote: > On Wed, 14 Apr 2010, Diego Novillo wrote: > > > On Wed, Apr 14, 2010 at 04:40, Richard Guenther wrote: > > > > > No. make_rename_temp should go away. Please. > > > > I don't disagree, in principle (less code is always good). What is > > wrong with it? > > It asks the SSA renamer to put your new variables into SSA form. > It's very simple to do that manually (at least if no PHIs are > involved), so better do that. > The problem of using create_tmp_var directly is that the following pattern is now bound to creep up at quite many places: tmp = create_tmp_var (TREE_TYPE (adj->base), "blah"); if (TREE_CODE (TREE_TYPE (tmp)) == COMPLEX_TYPE || TREE_CODE (TREE_TYPE (tmp)) == VECTOR_TYPE) DECL_GIMPLE_REG_P (tmp) = 1; Perhaps we should have something like create_gimple_reg_tmp_var that would do this? If so, I'll be happy to add it. Martin
Re: Copy assignments for non scalar types
On Wed, Apr 14, 2010 at 07:31, Richard Guenther wrote: > It asks the SSA renamer to put your new variables into SSA form. > It's very simple to do that manually (at least if no PHIs are > involved), so better do that. But then we'd have lots of duplicate code fragments all doing the same thing. Isn't it better to have a single self-contained helper to do that for us? Diego.
Re: Copy assignments for non scalar types
On Wed, Apr 14, 2010 at 1:44 PM, Martin Jambor wrote: > Hi, > > On Wed, Apr 14, 2010 at 01:31:05PM +0200, Richard Guenther wrote: >> On Wed, 14 Apr 2010, Diego Novillo wrote: >> >> > On Wed, Apr 14, 2010 at 04:40, Richard Guenther wrote: >> > >> > > No. make_rename_temp should go away. Please. >> > >> > I don't disagree, in principle (less code is always good). What is >> > wrong with it? >> >> It asks the SSA renamer to put your new variables into SSA form. >> It's very simple to do that manually (at least if no PHIs are >> involved), so better do that. >> > > The problem of using create_tmp_var directly is that the following > pattern is now bound to creep up at quite many places: > > tmp = create_tmp_var (TREE_TYPE (adj->base), "blah"); > if (TREE_CODE (TREE_TYPE (tmp)) == COMPLEX_TYPE > || TREE_CODE (TREE_TYPE (tmp)) == VECTOR_TYPE) > DECL_GIMPLE_REG_P (tmp) = 1; > > Perhaps we should have something like create_gimple_reg_tmp_var that > would do this? If so, I'll be happy to add it. Yes. I suggest create_tmp_reg as a name for that (simply add a wrapper around create_tmp_var). Richard. > Martin >
Re: RFC: c++ diagnostics
This may be of interest to KDE developers. So adding them to the CC list. Manuel. On 5 April 2010 17:20, Benjamin Kosnik wrote: > > Hello all! > > I've put up a short diagnostics comparison between gcc, icc, and > clang. It is my plan to update this with major revisions to individual > compilers. > > Included are most of the outstanding bugzilla requests with the > "diagnostic" keyword. However, I am looking for help! Please send me > code samples that frustrate, obfuscate, and annoy. > > In particular, I am looking for template instantiation issues such as > c++/41884, but hopefully something in a deliciously small snippet. No > doubt other C++ hackers have particular annoyances. > > I'm also looking for guidance on how to rank the priority of these > issues. Is there some way to tell what the biggest annoyance is? > > http://people.redhat.com/bkoz/diagnostics/diagnostics.html > > best, > benjamin >
Viewvc perms problem ?
Looking at the GCC viewvc, for example: http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/ All the graphics and style information are missing, for me at any rate. Inspecting my browser's transactions shows that it's getting an HTTP 403 (Forbidden) error for everything under http://gcc.gnu.org/viewvc-static/. Some kind of accident with the unix perms or htaccess maybe? cheers, DaveK
Re: dragonegg in FSF gcc?
On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote: > Hi Steven, > >> FWIW, this sounds great and all... but I haven't actually seen any >> comparisons of GCC vs. LLVM with DragonEgg. A search with Google >> doesn't give me any results. >> >> Can you point out some postings where people actually made a >> comparison between GCC and LLVM with DragonEgg? > > I gave some comparisons in my talk at the 2009 LLVM developers meeting. > See the links at the bottom of http://dragonegg.llvm.org/ > > Since then I've been working on completeness and correctness, and didn't > do any additional benchmarking yet. I don't know if anyone else did any > benchmarking. If so they didn't inform me. Duncan, It would be interesting to know what the Sqlite3 -O3/-O2 benchmarks show for llvm 2.7. I benchmarked about a 14% improvement in the Polyhedron 2005 benchmarks over a 13 month period of llvm development. Perhaps the current numbers look a bit better. Jack > > Ciao, > > Duncan.
Re: dragonegg in FSF gcc?
On 04/14/2010 03:36 PM, Jack Howarth wrote: On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote: Hi Steven, FWIW, this sounds great and all... but I haven't actually seen any comparisons of GCC vs. LLVM with DragonEgg. A search with Google doesn't give me any results. Can you point out some postings where people actually made a comparison between GCC and LLVM with DragonEgg? I gave some comparisons in my talk at the 2009 LLVM developers meeting. See the links at the bottom of http://dragonegg.llvm.org/ Since then I've been working on completeness and correctness, and didn't do any additional benchmarking yet. I don't know if anyone else did any benchmarking. If so they didn't inform me. Duncan, It would be interesting to know what the Sqlite3 -O3/-O2 benchmarks show for llvm 2.7. I benchmarked about a 14% improvement in the Polyhedron 2005 benchmarks over a 13 month period of llvm development. Perhaps the current numbers look a bit better. This kind of summarizes where the interest for dragonegg lies. :-P Paolo ps: look at smiley before clicking "reply"
Re: Viewvc perms problem ?
Hi - > Looking at the GCC viewvc, for example: > http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/ > > All the graphics and style information are missing [...] This was an unintended consequence of a viewvc rpm update. It's fixed now. - FChE
RE: dragonegg in FSF gcc?
Hi Diego, I agree with what you said. As a researcher I started using GCC instead of Open64 in 2005 after I saw some steps towards modularity when pass manager has been introduced since it was really simplifying my life when working on iterative/collective compilation. We have been also trying to propose further modularization/API-zation using plugins and interactive compilation interface to provide more abstractions to GCC but the acceptance was far too slow (6+ years). Up to now, LLVM is quite behind in terms of optimizations, but it's modularity simplifies adding new optimization, instrumentation and analysis passes among other things. I still use or plan to GCC for many reasons but I also use LLVM and I see some of my colleagues moving from GCC to LLVM mainly due to modularity and simplicity-of-use reasons. I still sometimes hear comments that GCC shouldn't be driven at all by the needs of researchers but lots of advanced optimizations actually came from academic research, so I think this can be a bit short-sighted. If GCC will not move towards modularization and clean APIs (by the way, I am not saying that it's easy), it doesn't mean that it will disappear, but it will change the role and will have to catch up. So, I think having 2 good open-source compilers and a healthy competition is not bad ;) ... We also heard many similar comments from our colleagues at GROW'09 and GROW'10 workshops... Cheers, Grigori -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Diego Novillo Sent: Tuesday, April 13, 2010 11:06 PM To: Steven Bosscher Cc: Jack Howarth; Paolo Bonzini; Dave Korn; Manuel López-Ibáñez; Duncan Sands; gcc@gcc.gnu.org Subject: Re: dragonegg in FSF gcc? On Tue, Apr 13, 2010 at 16:51, Steven Bosscher wrote: > You say you see benefits for both compilers. What benefits do you see > for GCC then, if I may ask? And what can GCC take from LLVM? (And I > mean the FSF GCC, long term.) This is an honest question, because I > personally really don't see any benefit for GCC. If comparisons between the two compilers are easy to make, then it's easy to determine what one compiler is doing better than the other and do the necessary port. In terms of internal structure, LLVM is more modular, which simplifies maintenance (e.g., the automatic bug finder, unit tests). The various components of the pipeline have better separation and stronger APIs. GCC has been slowly moving in that direction, but it still have ways to go. LLVM has already proven that organizing the compiler that way is advantageous (additionally, other research compilers were structured similarly: Sage++, SUIF), so emulating that structure sounds like a reasonable approach. Another example where GCC may want to operate with LLVM is in JIT compilation. Clearly, LLVM has made a significant investment in this area. If GCC were to generate LLVM IR, it could just use all the JIT machinery without having to replicate it. There may be other things GCC could take advantage of. OTOH, GCC has optimizer and codegen features that LLVM may want to incorporate. I don't have specific examples, since I am not very familiar with LLVM. Diego.
Re: Viewvc perms problem ?
On 14/04/2010 14:59, Frank Ch. Eigler wrote: > Hi - > >> Looking at the GCC viewvc, for example: >> http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/ >> >> All the graphics and style information are missing [...] > > This was an unintended consequence of a viewvc rpm update. > It's fixed now. Works fine here now; thanks Frank! cheers, DaveK
RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Hi all, Dorit and I just got an anonymous ;) feedback about GCC vs LLVM following our email about GROW'10 panel questions so we are just forwarding it here (non-edited): The reasons I have seen for using llvm/clang are basically two-fold: gcc is too slow and too complicated. (This is true even for a company with significant in-house gcc expertise.) The C language parser for llvm (clang) is far faster than the gcc equivalent, easier to modify, and easier to build into a separate library. Speed is a major decision for choosing clang/llvm, as OpenCL needs to be complied on the fly. The llvm infrastructure is also far easier to manipulate and modify than gcc. This is particularly important as implementing OpenCL means building complier backends to generate Nvidia's PTX or AMD's IL, adding specific vector extensions, and supporting various language intrinsics. I don't know how much of an issue the licensing issues may be. These issues, plus significant corporate backing, appear to be really driving llvm in the OpenCL area. My impression is that for gcc to be competitive it will have to offer both comparable compilation speed and dramatically better code optimizations. Even then, I'm not sure if the difficulty of working with it will be considered a good tradeoff for most companies. Cheers, Grigori -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Dorit Nuzman Sent: Sunday, April 11, 2010 2:54 PM To: gcc@gcc.gnu.org Subject: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) Dear all, We would like to share notes from the lively panel discussion at GROW'10 (GCC Research Opportunities Workshop) that took place at the end of January in Pisa, Italy (alongside the HiPEAC conference). The main topic of the discussion was: How to make GCC more attractive to researchers, and how GCC can benefit from researchers? Here is the list of major points and wishes raised by participants: * Need to encourage cleanup/infrastructure work on GCC and provide stable/flexible/extensible APIs (the question is how to encourage such infrastructure work...?) * Encourage people to work on infrastructure and full implementation that actually works: Lobby for high quality conferences to reserve a quota of the accepted papers to papers that focus on *implementation* work (and start with HiPEAC!) * Follow up to the above: Encourage research that actually works: Lobby for conferences to favor research work that is tested on a realistic environment (e.g. pass all of SPECcpu...), and that is reproducible. Then GCC and the community could immediately benefit from the results and not wait for many years before someone decides to reproduce/redo research ideas in GCC. * Get statistics on percentage of papers/projects that use compilers other than GCC, and ask them why... (By the way, why was OpenCL implemented only on LLVM and not on GCC?) * Open up GCC to be used as a library by other tools, so that other tools could use its analysis facilities. For example, having alias analysis as an API rather than a pass that needs to be applied and then collect information. Allow developers/tools access those functions outside GCC (should be a high-level API). * Follow up to the above: Need to come up with a common API / standardization / common levels of abstractions. Decide on how to coordinate efforts and find commonalities. * Need a simple pass manager that can list all available passes and allow any scheduling (providing dependency information). * Make more visible/accessible guides for building/extending GCC. * Better advertize Google Summer of Code, and provide more mentoring. * Send feedback on which plugin events are desired to add to next releases of GCC. * GCC tries to auto-parallelize the programs it compiles. Will GCC itself be made more multi-threaded and run faster in a multi-core environment...? We've collected these and other comments/suggestions before/at/after the workshop, on the GROW'10 wiki page: http://cTuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Panel_Questions We hope these notes would help improve GCC and its appeal/usability for researches (or at least raise more discussion!) Yours, Grigori Fursin and Dorit Nuzman (GROW'10 organizers)
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Hi, You know, I'm getting pretty fed up with all this LLVM advocacy on a GCC list. It's distracting and counter-productive. It is not as if anything mentioned in this feedback is new and not already known here on the GCC list. Repeating the long list of known problems won't help GCC. Can we now please return to discussions about GCC here? Please? Ciao! Steven On Wed, Apr 14, 2010 at 4:23 PM, Grigori Fursin wrote: > Hi all, > > Dorit and I just got an anonymous ;) feedback about GCC vs LLVM following > our email about GROW'10 panel questions so we are just forwarding it here > (non-edited): > > The reasons I have seen for using llvm/clang are basically two-fold: gcc is > too slow and too > complicated. (This is true even for a company with significant in-house gcc > expertise.) The C > language parser for llvm (clang) is far faster than the gcc equivalent, > easier to modify, and easier > to build into a separate library. Speed is a major decision for choosing > clang/llvm, as OpenCL needs > to be complied on the fly. The llvm infrastructure is also far easier to > manipulate and modify than > gcc. This is particularly important as implementing OpenCL means building > complier backends to > generate Nvidia's PTX or AMD's IL, adding specific vector extensions, and > supporting various > language intrinsics. I don't know how much of an issue the licensing issues > may be. These issues, > plus significant corporate backing, appear to be really driving llvm in the > OpenCL area. My > impression is that for gcc to be competitive it will have to offer both > comparable compilation speed > and dramatically better code optimizations. Even then, I'm not sure if the > difficulty of working > with it will be considered a good tradeoff for most companies. > > Cheers, > Grigori > > > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Dorit > Nuzman > Sent: Sunday, April 11, 2010 2:54 PM > To: gcc@gcc.gnu.org > Subject: Notes from the GROW'10 workshop panel (GCC research opportunities > workshop) > > > Dear all, > > We would like to share notes from the lively panel discussion at > GROW'10 (GCC Research Opportunities Workshop) that took place at the > end of January in Pisa, Italy (alongside the HiPEAC conference). > The main topic of the discussion was: > > How to make GCC more attractive to researchers, > and how GCC can benefit from researchers? > > Here is the list of major points and wishes raised by participants: > > * Need to encourage cleanup/infrastructure work on GCC and provide > stable/flexible/extensible APIs (the question is how to encourage such > infrastructure work...?) > > * Encourage people to work on infrastructure and full implementation > that actually works: Lobby for high quality conferences to reserve a quota > of the accepted papers to papers that focus on *implementation* work (and > start with HiPEAC!) > > * Follow up to the above: Encourage research that actually works: > Lobby for conferences to favor research work that is tested on a realistic > environment (e.g. pass all of SPECcpu...), and that is reproducible. > Then GCC and the community could immediately benefit from the results and > not wait for many years before someone decides to reproduce/redo research > ideas in GCC. > > * Get statistics on percentage of papers/projects that use compilers other > than GCC, and ask them why... (By the way, why was OpenCL implemented only > on LLVM and not on GCC?) > > * Open up GCC to be used as a library by other tools, so that other tools > could use its analysis facilities. For example, having alias analysis as an > API rather than a pass that needs to be applied and then collect > information. Allow developers/tools access those functions outside GCC > (should be a high-level API). > > * Follow up to the above: Need to come up with a common API / > standardization / common levels of abstractions. Decide on how to > coordinate efforts and find commonalities. > > * Need a simple pass manager that can list all available passes > and allow any scheduling (providing dependency information). > > * Make more visible/accessible guides for building/extending GCC. > > * Better advertize Google Summer of Code, and provide more mentoring. > > * Send feedback on which plugin events are desired to add to next releases > of GCC. > > * GCC tries to auto-parallelize the programs it compiles. Will GCC itself > be made more multi-threaded and run faster in a multi-core environment...? > > > We've collected these and other comments/suggestions before/at/after the > workshop, on the GROW'10 wiki page: > http://cTuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Panel_Questions > > > > We hope these notes would help improve GCC and its appeal/usability for > researches (or at least raise more discussion!) > > Yours, > Grigori Fursin and Dorit Nuzman > (GROW'10 organizers) > >
Update git mirror with proper branches?
Hi, The current git mirror has some strange branches, which don't exist in subversion. Those branches under branches/*/* are either not mirrored or mirrored with the first directory name. There is ix86 branch in git. But in subversion, there are atom/ avx/ gcc-4_1-branch/ gcc-4_2-branch/ gcc-4_3-branch/ gcc-4_4-branch/ under /branches/ix86. I think we should either mirror or branches or don't mirror branches with more than one `/' in branch name after /branches. Thanks. -- H.J.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On 14 April 2010 16:34, Steven Bosscher wrote: > Hi, > > You know, I'm getting pretty fed up with all this LLVM advocacy on a > GCC list. It's distracting and counter-productive. You cannot accuse Grigori/Dorit of Clang/LLVM advocacy. He is retransmitting other people's feedback on perceived GCC problems. I think knowing how many people are strongly unsatisfied with GCC can help to take some future decisions, like moving to C++. GCC is better than Clang/LLVM in many aspects but, like it or not, the opposite is also true, and we should learn from those aspects what we can, take what is good and drop what is bad. [1] Otherwise, as Ian said in another topic [2]: "I have a different fear: that gcc will become increasing irrelevant". Manuel. [1] A good example is the comparison of http://people.redhat.com/bkoz/diagnostics/diagnostics.html [2] http://gcc.gnu.org/ml/gcc/2007-11/msg00436.html PS: On the other hand, I think that modifying GCC to suit the purposes of dragonegg or LLVM is a *bad* idea. PS2: That GCC developers lose temper over this, also gives a negative image of GCC.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 5:18 PM, Manuel López-Ibáñez wrote: > On 14 April 2010 16:34, Steven Bosscher wrote: >> Hi, >> >> You know, I'm getting pretty fed up with all this LLVM advocacy on a >> GCC list. It's distracting and counter-productive. > > You cannot accuse Grigori/Dorit of Clang/LLVM advocacy. I did not mean to come across as accusing them. If I did, then I appologize for that. Ciao! Steven
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez wrote: > GCC is better than Clang/LLVM in many aspects but, like it or not, the > opposite is also true, and we should learn from those aspects what we > can, take what is good and drop what is bad. [1] Agreed. > Otherwise, as Ian said in another topic [2]: "I have a different fear: > that gcc will become increasing irrelevant". That's my impression, as well. It is true of just about every code base, if it cannot attract new developers, it stagnates and eventually whithers away. To attract new developers, GCC needs to modernize its internal structure. I have some thoughts on that, but progress has been slow, due mostly to resource constraints. Alternately, GCC could just content itself to being a legacy compiler with a dwindling user base. It won't happen tomorrow, but it may happen eventually. Diego.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Hi Manuel, PS: On the other hand, I think that modifying GCC to suit the purposes of dragonegg or LLVM is a *bad* idea. my policy has been to only propose GCC patches that are useful to GCC itself. Well, yesterday I broke this rule and posted a patch that was only of interest to dragonegg, but let's hope that this is the exception that proves the rule, as they say :) Ciao, Duncan.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: > On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez > wrote: > > Otherwise, as Ian said in another topic [2]: "I have a different fear: > > that gcc will become increasing irrelevant". > > That's my impression, as well. It is true of just about every code > base, if it cannot attract new developers, it stagnates and eventually > whithers away. > > To attract new developers, GCC needs to modernize its internal > structure. I have some thoughts on that, but progress has been slow, > due mostly to resource constraints. Would you mind expanding--even just a little bit--on what bits need modernizing? There's things like: http://gcc.gnu.org/wiki/Speedup_areas and perhaps: http://gcc.gnu.org/wiki/general_backend_cleanup But neither of those really touches the middle-end, which is where I presume the grousing vis-a-vis GCC vs. LLVM is really generated from. Or it's the front-end support. I don't know. I know there are ugly parts still remaining in GCC. But my experience (extending/parameterizing an LLVM optimization pass, writing/modifying GCC middle-end optimization passes, some GCC backend hacking) suggests that the complexity is similar. I think concrete "I tried X and it sucked" or "these are the areas of suckage" would be helpful. -Nathan
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 5:44 PM, Nathan Froyd wrote: > On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: >> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez >> wrote: >> > Otherwise, as Ian said in another topic [2]: "I have a different fear: >> > that gcc will become increasing irrelevant". >> >> That's my impression, as well. It is true of just about every code >> base, if it cannot attract new developers, it stagnates and eventually >> whithers away. >> >> To attract new developers, GCC needs to modernize its internal >> structure. I have some thoughts on that, but progress has been slow, >> due mostly to resource constraints. > > Would you mind expanding--even just a little bit--on what bits need > modernizing? There's things like: > > http://gcc.gnu.org/wiki/Speedup_areas > > and perhaps: > > http://gcc.gnu.org/wiki/general_backend_cleanup > > But neither of those really touches the middle-end, which is where I > presume the grousing vis-a-vis GCC vs. LLVM is really generated from. > Or it's the front-end support. I don't know. > > I know there are ugly parts still remaining in GCC. But my experience > (extending/parameterizing an LLVM optimization pass, writing/modifying > GCC middle-end optimization passes, some GCC backend hacking) suggests > that the complexity is similar. I think concrete "I tried X and it > sucked" or "these are the areas of suckage" would be helpful. I think we have made good progress with cleaning up the frontend - backend interface. Still there remains cleanups and enhancements to be done with the pass-manager and how it interacts with the cgraph code. Oh, and of course some high-level overview documentation just about that pieces are missing. Richard. > -Nathan >
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 11:44, Nathan Froyd wrote: > On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: >> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez >> wrote: >> > Otherwise, as Ian said in another topic [2]: "I have a different fear: >> > that gcc will become increasing irrelevant". >> >> That's my impression, as well. It is true of just about every code >> base, if it cannot attract new developers, it stagnates and eventually >> whithers away. >> >> To attract new developers, GCC needs to modernize its internal >> structure. I have some thoughts on that, but progress has been slow, >> due mostly to resource constraints. > > Would you mind expanding--even just a little bit--on what bits need > modernizing? Sure, I commented on this a bit on the dragonegg thread (things we'd like to borrow from LLVM). In general, I would like to continue the separation of the various modules in the pipeline. In particular: - Firm APIs: remove global state, add public interfaces. - Split up the gcc/ directory. Move major components into libraries (e.g, libgimple, librtl, libgeneric). - Make each library a standalone module, with separate testsuites. - Add unit tests for each library. - Make all the major IRs streamable so that do things like remove the current gty-based pch generation, or allow testing of individual passes. - Remove the macro-based back end configuration. Convert it to registered callbacks. Allow backends to be compiled into a separate library that can be loaded at runtime. The theme is modularization at the library level so that we can build/test these components separately. The driver could simply be dynamically linked to all of them. > http://gcc.gnu.org/wiki/Speedup_areas > > and perhaps: > > http://gcc.gnu.org/wiki/general_backend_cleanup Those too, yes. > I know there are ugly parts still remaining in GCC. But my experience > (extending/parameterizing an LLVM optimization pass, writing/modifying > GCC middle-end optimization passes, some GCC backend hacking) suggests > that the complexity is similar. I think concrete "I tried X and it > sucked" or "these are the areas of suckage" would be helpful. My ulterior motive for all this modularization is to extend Tom Tromey's incremental compiler. But I also think that it has other benefits, mostly in testing and maintenance. I've been collecting thoughts in this area for a few weeks. I will try to get it finished and publish it on the wiki. Hopefully, soon. Diego.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 5:57 PM, Diego Novillo wrote: > On Wed, Apr 14, 2010 at 11:44, Nathan Froyd wrote: >> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: >>> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez >>> wrote: >>> > Otherwise, as Ian said in another topic [2]: "I have a different fear: >>> > that gcc will become increasing irrelevant". >>> >>> That's my impression, as well. It is true of just about every code >>> base, if it cannot attract new developers, it stagnates and eventually >>> whithers away. >>> >>> To attract new developers, GCC needs to modernize its internal >>> structure. I have some thoughts on that, but progress has been slow, >>> due mostly to resource constraints. >> >> Would you mind expanding--even just a little bit--on what bits need >> modernizing? > > Sure, I commented on this a bit on the dragonegg thread (things we'd > like to borrow from LLVM). > > In general, I would like to continue the separation of the various > modules in the pipeline. In particular: > > - Firm APIs: remove global state, add public interfaces. > - Split up the gcc/ directory. Move major components into libraries > (e.g, libgimple, librtl, libgeneric). > - Make each library a standalone module, with separate testsuites. > - Add unit tests for each library. > - Make all the major IRs streamable so that do things like remove the > current gty-based pch generation, or allow testing of individual > passes. > - Remove the macro-based back end configuration. Convert it to > registered callbacks. Allow backends to be compiled into a separate > library that can be loaded at runtime. Yeah, but that's all pie-in-the-sky stuff. We first have to really properly separate the frontends from middle-end - like solve the debug info issue with LTO. Like drive the whole compilation by the pass manager, not jump into/outof it all the time. But yes, moving the C frontend to a subdirectory was planned for a long time. I'm not sure about the rest - too much modularization can hurt as much as bring benefit. There is lots of generic infrastructure stuff that lurks around in tree-ssa-*.c optimizers (like all the fold_gimple stuff in tree-ssa-ccp.c that I long wanted to move to a gimple-fold.c ...). > The theme is modularization at the library level so that we can > build/test these components separately. The driver could simply be > dynamically linked to all of them. Well, maybe nice to have, but not really the theme of GCC, and not the most important cleanup areas. Unit-testing is a major missing feature, but at least for optimizers we could easily implement a poor-mans solution using the C frontend, -O0 and single enabled passes (given a slightly more clever pass manager). Richard. > >> http://gcc.gnu.org/wiki/Speedup_areas >> >> and perhaps: >> >> http://gcc.gnu.org/wiki/general_backend_cleanup > > Those too, yes. > >> I know there are ugly parts still remaining in GCC. But my experience >> (extending/parameterizing an LLVM optimization pass, writing/modifying >> GCC middle-end optimization passes, some GCC backend hacking) suggests >> that the complexity is similar. I think concrete "I tried X and it >> sucked" or "these are the areas of suckage" would be helpful. > > My ulterior motive for all this modularization is to extend Tom > Tromey's incremental compiler. But I also think that it has other > benefits, mostly in testing and maintenance. > > I've been collecting thoughts in this area for a few weeks. I will > try to get it finished and publish it on the wiki. Hopefully, soon. > > > Diego. >
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Nathan Froyd wrote: On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: To attract new developers, GCC needs to modernize its internal structure. I have some thoughts on that, but progress has been slow, due mostly to resource constraints. Would you mind expanding--even just a little bit--on what bits need modernizing? There's things like: That's the wrong red herring :-) Diego is afraid that GCC can't attract new developers - and he subsequently blames it on its bad structure. I have seen this argument before. It is bandied about by the Weather Forecasting Project I'm a researcher for: "We can't interest the academic world to help us because our code is incomprehensible !" But, what happens is a combination of the following factors: 1. Academics have to plead to get our code and sign a contract never to use it for actual weather forecasting. 2. There is a well known US Weather Forecasting model (WRF, pronounce: WARF) that you can just download, comes with extensive documentation and an enormous user base, user support by users, etc., because of this. So my solution to the Weather Forecasting model development problem would be: Let academia use WRF, we read their publications and decide which ideas to implement in our own model (instead of running around like headless chickens claiming that no-one wants to work with our model). We have enough paid people (in 25-odd national weather services in Europe) to work on our model. Mutatis mutandis, the same goes for GCC: There might be too many hurdles to use GCC in academia. So what - the number of companies working on GCC have enough clout to employ the necessary base of engineers to keep GCC going (and, for an extra bonus - they do not have to invest in Fortran, because that's run by volunteers :-) Case closed. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
> "Richard" == Richard Guenther writes: Richard> I think we have made good progress with cleaning up the Richard> frontend - backend interface. FWIW, I can attest to this based on my experience on the incremental branch. Tom
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Nathan Froyd writes: > On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: > >> To attract new developers, GCC needs to modernize its internal >> structure. I have some thoughts on that, but progress has been slow, >> due mostly to resource constraints. > > Would you mind expanding--even just a little bit--on what bits need > modernizing? The tree/GIMPLE layer needs significantly better documentation, but is otherwise not too bad. Once you get to the RTL layer, there are too many undocumented inter-pass dependencies. The interface between the frontend and the middle-end is largely undocumented. Ian
On the use of abort() in the testsuite
I feel in my bones that this will probably have been discussed before ... but. On my platform of choice when abort() is called it tries to a) generate a coredump b) formats and saves a cute crashdump to allow non-expert users to forward failure info to application writers or the system vendor. This is quite consuming of system resources when running the gcc testsuite which is full of abort() calls. I queried darwin-dev about switching off (b) [although one is normally reluctant to do so - because it's actually pretty useful] however, this is non-trivial and not an option on a a day-today basis. Also the response to (a) was that doing a coredump is a POSIX- compliant response to abort(). (I obviously set ulimit to 0 for cores to work around this). So... I wonder what does abort() offer to the testsuite? that, for example, _exit(-(__LINE__)) ; doesn't? These days, running the testsuite way outweighs (> 2:1) building the compiler - so any possible ways to improve turn-round time on regtests would be cool. (of course, it's a lot of editing to do just to find out.. ) Iain
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Toon Moene wrote:
Mutatis mutandis, the same goes for GCC: There might be too many hurdles
to use GCC in academia.
This is probably true, however, the plugin ability of the just released
GCC 4.5 (or is it released tomorrow) helps probably significantly.
Academics (even people working in technological research institutes like
me) will probably be more able to practically contribute to GCC thru the
plugin interface. It brings two minor points: a somehow defined plugin
API (which is a sane "bottleneck" to the enormity of GCC code), and the
ability to practically publish code without transfering copyright to FSF
(in the previous situation, the only way to avoid that was to create a
specific GPLv3 fork of GCC; in practice it is too expensive in labor for
academia).
My point is that academics can quite easily contribute to GPL software,
but much harder obtain the necessary legal authorizations to transfer
copyright to FSF. My intuition is that if (in a different past & a
different world which did not happen) GCC was only GPLv2+ without the
FSF copyright requirement -exactly as Linux kernel is, things would have
been much different.
With the new plugin ability of GCC, I would believe that academics would
be a little happier to contribute to GCC, by coding plugins (or even
perhaps MELT extensions, which are plugins with a different API).
I know several French university employees (professors or lecturers =
"maitres de conférence" or interns or PhD students) who all can very
easily, without even asking officially any high-level suit at their
Univerisiy, publish some GPL code on their site and a paper in a
conference or journal, but for whom getting any kind of document signed
by their dean about transferring copyright to FSF is so painful that
they won't even try.
I would actually believe that the amount of code from academics in the
Linux kernel is bigger than the acedemic code in GCC, just because of
this copyright issue (which is soften by the plugin feature, assuming
people will publish & maintain plugin code).
Perhaps most of the GCC community don't care about getting more
academics contribute to GCC (in my opinion this is a mistake of the GCC
community; we should attract more academics).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Basile Starynkevitch wrote: Toon Moene wrote: Mutatis mutandis, the same goes for GCC: There might be too many hurdles to use GCC in academia. This is probably true, however, the plugin ability of the just released GCC 4.5 (or is it released tomorrow) helps probably significantly. My point is that academics can quite easily contribute to GPL software, but much harder obtain the necessary legal authorizations to transfer copyright to FSF. Nods -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Basile Starynkevitch wrote: Toon Moene wrote: Mutatis mutandis, the same goes for GCC: There might be too many hurdles to use GCC in academia. This is probably true, however, the plugin ability of the just released GCC 4.5 (or is it released tomorrow) helps probably significantly. My point is that academics can quite easily contribute to GPL software, but much harder obtain the necessary legal authorizations to transfer copyright to FSF. My answer was not as clear as necessary. My (earlier) argument was from the perspective of the providers of the code (GCC) - it did not take into account those who *want* to contribute to GCC, but have a hard time to convince their respective legal departments (whether in academia or the commercial world). In that case, a clear plugin interface (and accompanying documentation) can be instrumental in proving that an improvement "actually does the desired thing" and hence can be considered "the outcome of the academic research" (which then subsequently can be written up in a paper). Thanks for pointing that out. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: On the use of abort() in the testsuite
IainS writes: > So... I wonder what does abort() offer to the testsuite? > > that, for example, _exit(-(__LINE__)) ; > > doesn't? The testsuite can be run on embedded systems over serial ports, where is sometimes limited communication available. Each test has to give one of two responses: success or failure. Embedded systems do not reliably return the value passed to the exit function, and in any case it seemed to make sense to use two different functions for the two responses. So we picked exit(0) and abort(). All the tests are written that way (or at least that was the goal). Using two functions is flexible in a different way: it means that you can compile the testsuite with -Dabort=my_favorite_abort and link against your own library. So do that. You can do this with magic in site.exp, but don't ask me what that magic is because I no longer remember. Ian
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Basile Starynkevitch writes: > My point is that academics can quite easily contribute to GPL > software, but much harder obtain the necessary legal authorizations to > transfer copyright to FSF. My intuition is that if (in a different > past & a different world which did not happen) GCC was only GPLv2+ > without the FSF copyright requirement -exactly as Linux kernel is, > things would have been much different. That is likely true, but it's something that we really don't want to change. The FSF could and should make the copyright disclaimer much simpler--for example, you can do Google's copyright disclaimer on a web page (http://code.google.com/legal/individual-cla-v1.0.html). But avoiding the copyright disclaimer entirely is what permitted, e.g., the SCO debacle to occur. Ian
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Wed, Apr 14, 2010 at 09:49:08PM +0200, Basile Starynkevitch wrote: > Toon Moene wrote: >> >> Mutatis mutandis, the same goes for GCC: There might be too many >> hurdles to use GCC in academia. > > This is probably true, however, the plugin ability of the just released > GCC 4.5 (or is it released tomorrow) helps probably significantly. > > Academics (even people working in technological research institutes like > me) will probably be more able to practically contribute to GCC thru the > plugin interface. It brings two minor points: a somehow defined plugin > API (which is a sane "bottleneck" to the enormity of GCC code), and the > ability to practically publish code without transfering copyright to FSF > (in the previous situation, the only way to avoid that was to create a > specific GPLv3 fork of GCC; in practice it is too expensive in labor for > academia). I appreciate the point about the difficulty of copyright transference in an academic environment, having gone through such difficulties myself. But I think you are confusing "using GCC as a base for your research activities" and "getting the results of that research accepted upstream". I think plugins help in the first category insofar as they force GCC to clearly define interface boundaries. But they have little effect concerning the second category. Perhaps people will be able to make their code more widely available: the plugin interface will likely be relatively stable (I realize this is not guaranteed) and people can therefore release easily compilable packages. Before, you would be forced to distribute (and maintain!) patch files that may need significant changes from release to release. -Nathan
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On 14 April 2010 22:46, Ian Lance Taylor wrote: > Basile Starynkevitch writes: > >> My point is that academics can quite easily contribute to GPL >> software, but much harder obtain the necessary legal authorizations to >> transfer copyright to FSF. My intuition is that if (in a different >> past & a different world which did not happen) GCC was only GPLv2+ >> without the FSF copyright requirement -exactly as Linux kernel is, >> things would have been much different. > > That is likely true, but it's something that we really don't want to > change. The FSF could and should make the copyright disclaimer much > simpler--for example, you can do Google's copyright disclaimer on a > web page (http://code.google.com/legal/individual-cla-v1.0.html). But > avoiding the copyright disclaimer entirely is what permitted, e.g., > the SCO debacle to occur. Have you suggested this to the FSF with this specific example? The Google's disclaimer is in fact much more complex that the FSF's one I received, so doing it via web would be even simpler/easier. And in fact, GCC will be better served if the FSF produced a copyright disclaimer specific for GCC, because the first one I received was too vague and general for my university to accept, once it was made more specific, the university had no problem to sign it. Could not the Steering Committee ask the FSF to make some progress on this? Manuel.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Ian Lance Taylor wrote:
Basile Starynkevitch writes:
My point is that academics can quite easily contribute to GPL
software, but much harder obtain the necessary legal authorizations to
transfer copyright to FSF. My intuition is that if (in a different
past & a different world which did not happen) GCC was only GPLv2+
without the FSF copyright requirement -exactly as Linux kernel is,
things would have been much different.
That is likely true, but it's something that we really don't want to
change. The FSF could and should make the copyright disclaimer much
simpler--for example, you can do Google's copyright disclaimer on a
web page (http://code.google.com/legal/individual-cla-v1.0.html). But
avoiding the copyright disclaimer entirely is what permitted, e.g.,
the SCO debacle to occur.
From what I understood of the runtime exception of GCC, plugins should
be GPLv3 licensed but are not requested to be FSF copyrighted. Of course
such plugin code is not inside GCC FSF (I am expecting it would be
hosted elsewhere, e.g. on some university site; of course FSF owned
plugins -like MELT- are different).
From the point of view of an academic, that makes a significant
difference. And even if he/she want to push code inside GCC (and for
that he still will need the transfer to FSF, unless GCC changes a lot),
convincing his big boss to sign a paper is less terrible when you
actually have some code (in a plugin form) that really has some outside
interest. In that (optimistic) situation, the academic could spend some
of his time to get the legal papers signed.
Before the plugins, the academics could fork GCC (a huge non academic
task) and work on his fork (practically unlikely) or should take the
effort to get the legal papers signed before coding the first line of
code (very hard, and very discouraging).
A university (or research institute) boss in big suit [able to sign
legal papers] is probably more keen to sign a legal paper with the FSF
once some code -from his university- exist which attracts outside
interest, and not before.
And my personal preference on GCC licensing would be more a Linux-kernel
like GPL with copyright belonging to authors employee (I don't feel a
SCO like issue as a major threat today; it might have been ten years
ago). That is much easier to get than a copyright transfer to FSF.
And GCC is probably less threatened today by legal issues à la SCO than
by obesity, obsolescence, outside competition -eg LLVM- and perhaps even
less interest by industry for the low level languages (C, C++, Ada) GCC
is processing. Even in industry, scripting languages (or languages like
Java or C# which are not practically significant for GCC) have more
market share than a dozen years ago.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
