Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 6, 2010 at 10:51 PM, Kai Ruottu wrote: > This seems to be defined in a header generated during the build > into the $BUILD/gcc : > > [r...@localhost gcc]# grep ggc_alloc_cleared_lang_type *.h > gtype-desc.h:#define ggc_alloc_cleared_lang_type_u() ((union lang_type_u > *)(ggc_internal_cleared_alloc_stat (sizeof (union lang_type_u) > MEM_STAT_INFO))) > > On CentOS 5.5/ia32 the build seemed to succeed for the > 'x86_64-linux-gnu' target, using gcc-4.1.2 as the host > and build compiler. Must check the Fedora 13/x86_64 > host with its gcc-4.4.4 too but I wouldn't expect any > change with it... > > So maybe the Gentoo distro has some problem... No, I've tried compiling gcc-4.6-20100911 on ubuntu 10.04, the same problem also happened; and I also found that macro was defined in a generated header file, in the gcc build directory; renq...@flyer-1-1:~/src/gcc-4.6-build$ grep -RsInw ggc_alloc_cleared_lang_type gcc/ gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_type) MEM_STAT_INFO))) this definition just doesn't accept any arguments, but inside gcc/c-decl.c:7028 and 7311: space = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); lt = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); both passes 1 argument, so the compiler report error, so the problem is how can you succeed compiling that? renq...@flyer-1-1:~/src/gcc-4.6-build$ (cd gcc/; gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6-20100911/gcc -I../../gcc-4.6-20100911/gcc/. -I../../gcc-4.6-20100911/gcc/../include -I../../gcc-4.6-20100911/gcc/../libcpp/include -I/opt/gektop/usr/include -I../../gcc-4.6-20100911/gcc/../libdecnumber -I../../gcc-4.6-20100911/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-4.6-20100911/gcc/c-decl.c) ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘grokdeclarator’: ../../gcc-4.6-20100911/gcc/c-decl.c:5536: warning: format not a string literal and no format arguments ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘grokparms’: ../../gcc-4.6-20100911/gcc/c-decl.c:6197: warning: format not a string literal and no format arguments ../../gcc-4.6-20100911/gcc/c-decl.c:7028:64: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘finish_struct’: ../../gcc-4.6-20100911/gcc/c-decl.c:7028: error: ‘ggc_alloc_cleared_lang_type’ undeclared (first use in this function) ../../gcc-4.6-20100911/gcc/c-decl.c:7028: error: (Each undeclared identifier is reported only once ../../gcc-4.6-20100911/gcc/c-decl.c:7028: error: for each function it appears in.) ../../gcc-4.6-20100911/gcc/c-decl.c:7311:62: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100911/gcc/c-decl.c: In function ‘finish_enum’: ../../gcc-4.6-20100911/gcc/c-decl.c:7311: error: ‘ggc_alloc_cleared_lang_type’ undeclared (first use in this function) Thanks,
Re: Merging Apple's Objective-C 2.0 compiler changes
On 09/10/2010 03:12 PM, Manuel López-Ibáñez wrote: On 10 September 2010 15:00, Steven Bosscher wrote: On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner wrote: Some strong way of addressing the concern that this could be used to make proprietary front-ends or proprietary back-ends using part of GCC! Why is this case different from the existing llvm-gcc? It's the question of what one means by "plug-in interface". If you view it as no different from the existing llvm-gcc, then you're basically saying we already HAVE a plug-in interface. So then what are we talking about? Obviously not about the same thing. llvm-gcc is GCC front ends with LLVM as a back end. The idea here is clang with GCC as a back end. They are equivalent in the sense that I would understand why GCC would allow the former but it would fight against the latter. Hmm, my impression was that GCC can mostly gain from clang-gcc, and only lose from llvm-gcc... Paolo
Re: Merging Apple's Objective-C 2.0 compiler changes
On 13 September 2010 12:30, Paolo Bonzini wrote: > On 09/10/2010 03:12 PM, Manuel López-Ibáńez wrote: >> >> On 10 September 2010 15:00, Steven Bosscher wrote: >>> >>> On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner >>> wrote: >> >> Some strong way of addressing the concern that this could be used to >> make >> proprietary front-ends or proprietary back-ends using part of GCC! > > Why is this case different from the existing llvm-gcc? It's the question of what one means by "plug-in interface". If you view it as no different from the existing llvm-gcc, then you're basically saying we already HAVE a plug-in interface. So then what are we talking about? >>> >>> Obviously not about the same thing. >>> >>> llvm-gcc is GCC front ends with LLVM as a back end. >>> >>> The idea here is clang with GCC as a back end. >> >> They are equivalent in the sense that I wouldn't understand why GCC would >> allow the former but it would fight against the latter. > > Hmm, my impression was that GCC can mostly gain from clang-gcc, and only > lose from llvm-gcc... What will be gained and what will be lost in your opinion? Cheers, Manuel.
Re: on how to compile gcc-4.6 correctly?
13.9.2010 10:39, Dennis, CHENG Renquan kirjoitti: So maybe the Gentoo distro has some problem... No, I've tried compiling gcc-4.6-20100911 on ubuntu 10.04, the same problem also happened; and I also found that macro was defined in a generated header file, in the gcc build directory; renq...@flyer-1-1:~/src/gcc-4.6-build$ grep -RsInw ggc_alloc_cleared_lang_type gcc/ gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_type) MEM_STAT_INFO))) In all stages during the native bootstrap this define was : gtype-desc.h:#define ggc_alloc_cleared_lang_type(SIZE) ((struct lang_type *)(ggc_internal_cleared_alloc_stat (SIZE MEM_STAT_INFO))) in Fedora 13 with the earlier gcc-4.6-20100904 snapshot... this definition just doesn't accept any arguments, but inside gcc/c-decl.c:7028 and 7311: space = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); lt = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); both passes 1 argument, so the compiler report error, so the problem is how can you succeed compiling that? My RedHat-based systems (CentOS, Fedora) will generate a different '#define' for this. Why the Gentoo and Ubuntu are working differently is hard to say... Ok, I can try also Ubuntu 10.04 so let's see what it does...
Re: on how to compile gcc-4.6 correctly?
> renq...@flyer-1-1:~/src/gcc-4.6-build$ grep -RsInw > ggc_alloc_cleared_lang_type gcc/ > gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct > lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct > lang_type) MEM_STAT_INFO))) > > this definition just doesn't accept any arguments, but inside I am the author of how these macros are generated, but somehow I have missed this thread initially. Could you send me off-list that gtype-desc.h file? Thanks, -- Laurynas
Re: How to parse a code snippet at front-end plugin
From: Basile Starynkevitch
Subject: Re: How to parse a code snippet at front-end plugin
Date: Sun, 12 Sep 2010 08:35:48 +0200
> On Sat, 11 Sep 2010 22:19:06 +0800 (CST)
> "Thinker K.F. Li" wrote:
>
>> Hi,
>>
>> I am try to make a plugin to analyze GIMPLE before genericize. It
>> will insert some code defined by user into the tree. I want the user
>> to specify the inserted code in C. For example,
>>
>> --
>> {
>> static int i=0;
>>
>> printf("Hello %d\n", i++);
>> }
>> --
>>
>> I try to find a way to make C language parser of GCC to compile it for
>> me, and I will insert the code into the tree created from the main
>> source. But, it seems provide only functions to parse a complete C
>> source file, and I try to push a buffer to the reader of libcpp. But,
>> it does not work.
>
> I am not sure that there exist enough plugin hooks to do that (I am not sure
> even if there are plugin hooks to front-ends in GCC). However, I do see some
> way to perhaps implement what you suggest even in 4.5
>
> First, don't think of your problem as adding C code. Think of it as adding
> Gimple stuff into some Gimple representation.
> (I believe it is a case of aspect oriented programming, see
> http://en.wikipedia.org/wiki/Aspect-oriented_programming for more). But you
> want the user to specify the added code, using the already accepted C syntax
> of GCC (i.e. without hacking GCC parser).
>
> So you could use attributes & pragmas or builtins for that purpose.
>
> First, your user define its code snipped to insert as a C function with a
> special attribute, e.g.
>
> void say_hello(void) __attribute__((added_chunk));
>
> void say_hello(void)
> {
> static int i;
> printf("Hello %d\n", i++);
> }
>
> Then, your user would mark with another attribute every function into which
> your chunk should be added, perhaps
>
> int some_complex_function(int a, void*b)
> __attribute((insert_chunk(say_hello)));
>
> Or perhaps have a pragram asking this to insert the chunk in every function
> whose name start with some_
>
> #pragma GCCMELT insert_chunk_prefix(say_hello, some_)
>
This is a good idea that user can define rules in a included file and
include it in C files. I will try it. Thanks for your suggestion!
> The point here is that with the tricks above, you don't have to change GCC
> parser! and you could implement that using a plugin coded in C (this is not
> so simple, you have to filter Gimple). Better yet, you could implement that
> using GCC MELT http://gcc.gnu.org/wiki/MELT which provides pattern matching
> facilities on Gimple to make such tasks much simpler.
>
> You still have to understand Gimple & Tree in detail and find a good position
> in the pass machinery to insert your new pass or passes.
>
> If you succeed in making such a plugin please tell us. I would be delighted
> if you coded it in MELT, as a MELT extension.
>
> Good luck.
Actually, I have done something in C. It includes stuffs to filter
Gimple and insert chunks into original Gimple representation. I am
very glad to know MELT. I will try it. Thanks!
Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 13, 2010 at 8:16 PM, Laurynas Biveinis wrote: > I am the author of how these macros are generated, but somehow I have > missed this thread initially. Could you send me off-list that > gtype-desc.h file? The problematic gtype-desc.h has been sent to Laurynas separately, I was compiling only the gcc-core-4.6-20100911.tar.bz2 tarball, because I only want a c compiler; I searched the macro ggc_alloc_cleared_lang_type through out the source and build directory, only one definition and two usage, with conflict arguments passing: ../path/to/gcc-build$ grep -RsInw ggc_alloc_cleared_lang_type ../gcc-4.6-20100911/ gcc/ ../gcc-4.6-20100911/gcc/c-decl.c:7027: space = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); ../gcc-4.6-20100911/gcc/c-decl.c:7310: lt = ggc_alloc_cleared_lang_type (sizeof (struct lang_type)); gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_type) MEM_STAT_INFO))) and in fact, I'm interested why this Kai Ruottu got a ggc_alloc_cleared_lang_type_u macro with 0 arguments in gtype-desc.h while my gtype-desc.h doesn't have that macro? I'm not sure he could get ggc_alloc_cleared_lang_type macro or not, so how can he succeed his compilation; On Mon, Sep 6, 2010 at 10:51 PM, Kai Ruottu wrote: > This seems to be defined in a header generated during the build > into the $BUILD/gcc : > > [r...@localhost gcc]# grep ggc_alloc_cleared_lang_type *.h > gtype-desc.h:#define ggc_alloc_cleared_lang_type_u() ((union lang_type_u > *)(ggc_internal_cleared_alloc_stat (sizeof (union lang_type_u) > MEM_STAT_INFO))) > > Thanks, > -- > Laurynas > -- Cheng, from Singapore
Re: on how to compile gcc-4.6 correctly?
2010/9/13 Dennis, CHENG Renquan : > On Mon, Sep 13, 2010 at 8:16 PM, Laurynas Biveinis > wrote: >> I am the author of how these macros are generated, but somehow I have >> missed this thread initially. Could you send me off-list that >> gtype-desc.h file? > > The problematic gtype-desc.h has been sent to Laurynas separately, I > was compiling only the gcc-core-4.6-20100911.tar.bz2 tarball, because > I only want a c compiler Thanks. I assume that you pass --enable-languages=c to configure? I will investigate this tomorrow and will get back to you. Regards, -- Laurynas
Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 13, 2010 at 9:32 PM, Laurynas Biveinis
wrote:
> Thanks. I assume that you pass --enable-languages=c to configure?
No, just a very simple configure and make command:
../path/to/gcc-4.6-build$ time { ../gcc-4.6-20100911/configure
--prefix=/usr --disable-nls --with-system-zlib && make --debug=b; } |&
tee build-log
Because the source code is uncompressed from gcc-core-4.6-..., it only
includes the c compiler, I leave the configure to figure out there is
only c compiler source code;
>
> I will investigate this tomorrow and will get back to you.
>
> Regards,
> --
> Laurynas
>
--
Cheng, from Singapore
Re: Merging Apple's Objective-C 2.0 compiler changes
On Mon, Sep 13, 2010 at 01:44:57PM +0200, Manuel López-Ibáñez wrote: > On 13 September 2010 12:30, Paolo Bonzini wrote: > > > > Hmm, my impression was that GCC can mostly gain from clang-gcc, and only > > lose from llvm-gcc... > > What will be gained and what will be lost in your opinion? > I assume that, by clang-gcc, Paolo meant adding plug-in support for a clang FE. It is unclear what is meant by llvm-gcc unless he really mean dragon-egg. Certainly llvm-gcc itself is a rather dead-end as there appears to be little appetite to attempt to update llvm-gcc to gcc 4.5 or later due to GPLv3. Perhaps the best approach would be to welcome both. While it can be clearly argued that dragon-egg is only a net gain for llvm, the reverse could be said for a clang FE plugin to FSF gcc. By supporting both approaches, both projects end up sharing and obtaining a net win for each. Jack > Cheers, > > Manuel.
Re: Merging Apple's Objective-C 2.0 compiler changes
On 13 September 2010 16:55, Jack Howarth wrote: > On Mon, Sep 13, 2010 at 01:44:57PM +0200, Manuel López-Ibáñez wrote: >> On 13 September 2010 12:30, Paolo Bonzini wrote: >> > >> > Hmm, my impression was that GCC can mostly gain from clang-gcc, and only >> > lose from llvm-gcc... >> >> What will be gained and what will be lost in your opinion? >> > > I assume that, by clang-gcc, Paolo meant adding plug-in support for > a clang FE. It is unclear what is meant by llvm-gcc unless he really mean > dragon-egg. Certainly llvm-gcc itself is a rather dead-end as there appears > to be little appetite to attempt to update llvm-gcc to gcc 4.5 or later > due to GPLv3. Perhaps the best approach would be to welcome both. While > it can be clearly argued that dragon-egg is only a net gain for llvm, > the reverse could be said for a clang FE plugin to FSF gcc. By supporting > both approaches, both projects end up sharing and obtaining a net win for > each. From a user-perspective, there are benefits on both clang->gcc and gcc->llvm. However, from what I know about the GCC project, I don't see yet how GCC developers can consider either more beneficial than the other. But I would be very interested on clarifying this issue, so anyone thinking about making clang->gcc possible can assess whether it is worth it. It seems Richard is supporting it, and that is a big vote in favour. I can guess why he is not similarly favourable to gcc->llvm, but then, others in the GCC project may be more favourable to gcc->llvm than to clang->gcc (depending what you are working on). So the question remains, would GCC accept patches to implement plugging clang to GCC? Cheers, Manuel.
Is this wrong optimization in cse1 pass?
Hello,
I am experimenting some cond_exec patterns to better support
predicate in our target. I came across the following optimization
done in cse1, and not sure if it is correct behaviour or my fault.
Basically, cse1 performs copy propagation for insn 12 and 16 based
on assignment in insn 10. However, there is a conditional assignment
of reg 86 in insn 11. Shouldn't GCC perform the optimization here?
Our port is based on latest 4.5 branch.
tst.c.149r.jump
(insn 10 9 11 2 tst.c:16 (set (reg/v:V2SI 86 [ c ])
(reg/v:V2SI 85 [ c ])) 190 {fp_movv2si} (nil))
(insn 11 10 12 2 tst.c:16 (cond_exec (ne (reg/v:PR 83 [ p ])
(const_int 0 [0x0]))
(set (reg/v:V2SI 86 [ c ])
(reg:V2SI 90))) 511 {fp_predv2si} (nil))
(insn 12 11 16 2 tst.c:16 (set (reg:V2SI 87 [ ])
(reg/v:V2SI 86 [ c ])) 190 {fp_movv2si} (nil))
(insn 16 12 19 2 tst.c:18 (set (reg/i:V2SI 8 r8)
(reg:V2SI 87 [ ])) 190 {fp_movv2si} (nil))
tst.c.152r.cse1
(insn 10 9 11 2 tst.c:16 (set (reg/v:V2SI 86 [ c ])
(reg/v:V2SI 85 [ c ])) 190 {fp_movv2si} (nil))
(insn 11 10 12 2 tst.c:16 (cond_exec (ne (reg/v:PR 83 [ p ])
(const_int 0 [0x0]))
(set (reg/v:V2SI 86 [ c ])
(reg:V2SI 90))) 511 {fp_predv2si} (nil))
(insn 12 11 16 2 tst.c:16 (set (reg:V2SI 87 [ ])
(reg/v:V2SI 85 [ c ])) 190 {fp_movv2si} (nil))
(insn 16 12 19 2 tst.c:18 (set (reg/i:V2SI 8 r8)
(reg/v:V2SI 85 [ c ])) 190 {fp_movv2si} (nil))
Cheers,
Bingfeng Mei
Re: Merging Apple's Objective-C 2.0 compiler changes
Manuel López-Ibáñez writes: > From a user-perspective, there are benefits on both clang->gcc and > gcc->llvm. However, from what I know about the GCC project, I don't > see yet how GCC developers can consider either more beneficial than > the other. It seems to me that at the present moment LLVM's frontends are better than GCC's, and GCC's backends are better than LLVM's. By this I mean specifically that LLVM's frontends generate better diagnostics, whereas GCC's backends generate code that has better runtime performance. (LLVM also appears to run faster, which is a good feature but not in my mind a determining one.) Therefore, I see a clear benefit to clang->gcc, but I do not see a clear benefit to gcc->llvm. This comment is of course entirely independent of the licensing issues. Ian
Re: Is this wrong optimization in cse1 pass?
"Bingfeng Mei" writes: > I am experimenting some cond_exec patterns to better support > predicate in our target. I came across the following optimization > done in cse1, and not sure if it is correct behaviour or my fault. > Basically, cse1 performs copy propagation for insn 12 and 16 based > on assignment in insn 10. However, there is a conditional assignment > of reg 86 in insn 11. Shouldn't GCC perform the optimization here? I don't think any of the current gcc ports expect to see a cond_exec before the ifcvt pass, which is where define_cond_exec is implemented. So, this sounds like a bug in combine which none of the current ports trigger. Ian
Re: Merging Apple's Objective-C 2.0 compiler changes
On 9/13/10 2:04 PM, Ian Lance Taylor wrote: Therefore, I see a clear benefit to clang->gcc, but I do not see a clear benefit to gcc->llvm. Suppose you have large Fortran applications, and want to accelerate parts of them on graphics processors. Several of the OpenCL implementations use LLVM for runtime code generation, so one could compile the application to LTO, and let it go through some expensive stages of the GCC optimizer, and have LLVM bitcode staged for final translation to the GPU ISA. In general, make the distinction between heavy ahead-of-time compilation and light just-in-time compilation along the lines of GCC and LLVM.
Re: Is this wrong optimization in cse1 pass?
On Mon, Sep 13, 2010 at 10:15 PM, Ian Lance Taylor wrote: > "Bingfeng Mei" writes: > >> I am experimenting some cond_exec patterns to better support >> predicate in our target. I came across the following optimization >> done in cse1, and not sure if it is correct behaviour or my fault. >> Basically, cse1 performs copy propagation for insn 12 and 16 based >> on assignment in insn 10. However, there is a conditional assignment >> of reg 86 in insn 11. Shouldn't GCC perform the optimization here? > > I don't think any of the current gcc ports expect to see a cond_exec > before the ifcvt pass, which is where define_cond_exec is implemented. > So, this sounds like a bug in combine which none of the current ports > trigger. No no no! Geez, I thought someone with your experience in GCC would know better :-P State of things: having COND_EXEC before reload is finished is just plain wrong. No code before reload expects to see COND_EXECs. This is why most posts with support conditional execution have define_insn_and_splits with if_then_else before the split and cond_exec after reload (or, after pass_split_after_reload). Only post-reload if-conversion, i.e. pass_if_after_reload, will try to predicate streams of insns. Passes before reload, including combine, know nothing about COND_EXEC and do not understand the dataflow involved. The reasons for this are historical: ia64 not as relevant as projected, funding stopped, few targets where cond_exec really matters, spilling of predicate registers hard, and so on. Ciao! Steven
Re: Merging Apple's Objective-C 2.0 compiler changes
On 13 September 2010 22:04, Ian Lance Taylor wrote: > Manuel López-Ibáñez writes: > >> From a user-perspective, there are benefits on both clang->gcc and >> gcc->llvm. However, from what I know about the GCC project, I don't >> see yet how GCC developers can consider either more beneficial than >> the other. > > It seems to me that at the present moment LLVM's frontends are better > than GCC's, and GCC's backends are better than LLVM's. By this I mean > specifically that LLVM's frontends generate better diagnostics, whereas > GCC's backends generate code that has better runtime performance. (LLVM > also appears to run faster, which is a good feature but not in my mind a > determining one.) Therefore, I see a clear benefit to clang->gcc, but I > do not see a clear benefit to gcc->llvm. This comment is of course > entirely independent of the licensing issues. I think you are again talking about user benefits. You don't see a (user) benefit in gcc->llvm because you perhaps do not use the features that LLVM has and GCC doesn't. But users of gcc->llvm surely see a large benefit if people have spent so much effort working on it, first as a patched gcc and now as a plugin. But I am talking about benefits to GCC. Do you see any benefit/downside on adding code to GCC to enable a plugin that implements clang->gcc? Cheers, Manuel.
Re: Merging Apple's Objective-C 2.0 compiler changes
Manuel López-Ibáñez writes: > On 13 September 2010 22:04, Ian Lance Taylor wrote: >> Manuel López-Ibáñez writes: >> >>> From a user-perspective, there are benefits on both clang->gcc and >>> gcc->llvm. However, from what I know about the GCC project, I don't >>> see yet how GCC developers can consider either more beneficial than >>> the other. >> >> It seems to me that at the present moment LLVM's frontends are better >> than GCC's, and GCC's backends are better than LLVM's. By this I mean >> specifically that LLVM's frontends generate better diagnostics, whereas >> GCC's backends generate code that has better runtime performance. (LLVM >> also appears to run faster, which is a good feature but not in my mind a >> determining one.) Therefore, I see a clear benefit to clang->gcc, but I >> do not see a clear benefit to gcc->llvm. This comment is of course >> entirely independent of the licensing issues. > > I think you are again talking about user benefits. I'm not sure I understand the distinction you are drawing. What is the difference between a benefit to users of gcc and a benefit to gcc itself? > You don't see a > (user) benefit in gcc->llvm because you perhaps do not use the > features that LLVM has and GCC doesn't. But users of gcc->llvm surely > see a large benefit if people have spent so much effort working on it, > first as a patched gcc and now as a plugin. I understand the benefit that existed before clang. And my general understanding is that clang C++ support is not yet complete, so there is a benefit there, but only a temporary one. I don't see a real benefit going forward. > But I am talking about benefits to GCC. Do you see any > benefit/downside on adding code to GCC to enable a plugin that > implements clang->gcc? Since for me benefits to users of gcc are pretty much the same as benefits to gcc, yes, I see a benefit. Ian
Re: Merging Apple's Objective-C 2.0 compiler changes
On Mon, Sep 13, 2010 at 11:32 PM, Manuel López-Ibáñez wrote: > I think you are again talking about user benefits. You don't see a > (user) benefit in gcc->llvm because you perhaps do not use the > features that LLVM has and GCC doesn't. But users of gcc->llvm surely > see a large benefit if people have spent so much effort working on it, > first as a patched gcc and now as a plugin. And then replacing it. What's your point? Ciao! Steven
Re: Merging Apple's Objective-C 2.0 compiler changes
On 13 September 2010 23:41, Ian Lance Taylor wrote: > Manuel López-Ibáñez writes: > >> On 13 September 2010 22:04, Ian Lance Taylor wrote: >>> Manuel López-Ibáñez writes: >>> From a user-perspective, there are benefits on both clang->gcc and gcc->llvm. However, from what I know about the GCC project, I don't see yet how GCC developers can consider either more beneficial than the other. >>> >>> It seems to me that at the present moment LLVM's frontends are better >>> than GCC's, and GCC's backends are better than LLVM's. By this I mean >>> specifically that LLVM's frontends generate better diagnostics, whereas >>> GCC's backends generate code that has better runtime performance. (LLVM >>> also appears to run faster, which is a good feature but not in my mind a >>> determining one.) Therefore, I see a clear benefit to clang->gcc, but I >>> do not see a clear benefit to gcc->llvm. This comment is of course >>> entirely independent of the licensing issues. >> >> I think you are again talking about user benefits. > > I'm not sure I understand the distinction you are drawing. What is the > difference between a benefit to users of gcc and a benefit to gcc > itself? > >> You don't see a >> (user) benefit in gcc->llvm because you perhaps do not use the >> features that LLVM has and GCC doesn't. But users of gcc->llvm surely >> see a large benefit if people have spent so much effort working on it, >> first as a patched gcc and now as a plugin. > > I understand the benefit that existed before clang. And my general > understanding is that clang C++ support is not yet complete, so there is > a benefit there, but only a temporary one. I don't see a real benefit > going forward. Access to all the other GCC front-ends that the LLVM project has not (yet) reimplemented? Someone provided above a real user-case for gcc->llvm involving Fortran. I don't think dragon-egg development is stalled at all. >> But I am talking about benefits to GCC. Do you see any >> benefit/downside on adding code to GCC to enable a plugin that >> implements clang->gcc? > > Since for me benefits to users of gcc are pretty much the same as > benefits to gcc, yes, I see a benefit. By that rule, it is clearly beneficial for some gcc users to compile Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg is beneficial to GCC. Anyway, I don't see anyone implementing clang->gcc soon, but it is good to know it would be welcome. Thanks for answering, Manuel.
Re: Merging Apple's Objective-C 2.0 compiler changes
On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez wrote: >> I understand the benefit that existed before clang. And my general >> understanding is that clang C++ support is not yet complete, so there is >> a benefit there, but only a temporary one. I don't see a real benefit >> going forward. > > Access to all the other GCC front-ends that the LLVM project has not > (yet) reimplemented? Someone provided above a real user-case for > gcc->llvm involving Fortran. I don't think dragon-egg development is > stalled at all. And some (including yours truly) consider this little more than theft. Especially since there is GCC-bashing on the one side, and taking the bits they like on the other. >> Since for me benefits to users of gcc are pretty much the same as >> benefits to gcc, yes, I see a benefit. > > By that rule, it is clearly beneficial for some gcc users to compile > Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg > is beneficial to GCC. No it "is" not, you "think it is", i.e. opinion. Again, I don't share that opinion at all, because this means there is less motivation for developers to add OpenCL to GCC itself. Anyway, we're waaay off-topic here from the original question about improving ObjC in GCC. Ciao! Steven
Re: Merging Apple's Objective-C 2.0 compiler changes
Manuel López-Ibáñez writes: > By that rule, it is clearly beneficial for some gcc users to compile > Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg > is beneficial to GCC. That's pretty special purpose, though. Not something I would personally recommend that gcc developers work on. Ian
Re: Merging Apple's Objective-C 2.0 compiler changes
On 14 September 2010 00:16, Steven Bosscher wrote: > On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez > wrote: >>> I understand the benefit that existed before clang. And my general >>> understanding is that clang C++ support is not yet complete, so there is >>> a benefit there, but only a temporary one. I don't see a real benefit >>> going forward. >> >> Access to all the other GCC front-ends that the LLVM project has not >> (yet) reimplemented? Someone provided above a real user-case for >> gcc->llvm involving Fortran. I don't think dragon-egg development is >> stalled at all. > > And some (including yours truly) consider this little more than theft. > Especially since there is GCC-bashing on the one side, and taking the > bits they like on the other. > > >>> Since for me benefits to users of gcc are pretty much the same as >>> benefits to gcc, yes, I see a benefit. >> >> By that rule, it is clearly beneficial for some gcc users to compile >> Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg >> is beneficial to GCC. > > No it "is" not, you "think it is", i.e. opinion. Again, I don't share > that opinion at all, because this means there is less motivation for > developers to add OpenCL to GCC itself. In the same sense that adding clang->gcc means that there is less motivation for developers to improve the current C/C++ FEs. So I guess you are against this as well. But then, just a few mails above, you are the one who proposed adding clang to gcc in the first place. Sorry, it seems a contradiction to me and I cannot get my head around it. > Anyway, we're waaay off-topic here from the original question > about improving ObjC in GCC. Well, the discussion is whether it makes sense to replace the ObjC FE with clang directly. I would say you disagree, but then you proposed it. I am ambivalent since my understanding is that replacing parts of GCC is bad. But then Richard and Ian surprised me by being in favour because it would benefit gcc users. I am just trying to make sense of it. Cheers, Manuel.
Re: Merging Apple's Objective-C 2.0 compiler changes
Manuel López-Ibáñez writes: > In the same sense that adding clang->gcc means that there is less > motivation for developers to improve the current C/C++ FEs. From the perspective of gcc, I think the goal of clang->gcc would be to replace the current frontends entirely. Ian
Re: Merging Apple's Objective-C 2.0 compiler changes
On Tue, Sep 14, 2010 at 12:30 AM, Manuel López-Ibáñez wrote: > On 14 September 2010 00:16, Steven Bosscher wrote: >> On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez >> wrote: I understand the benefit that existed before clang. And my general understanding is that clang C++ support is not yet complete, so there is a benefit there, but only a temporary one. I don't see a real benefit going forward. >>> >>> Access to all the other GCC front-ends that the LLVM project has not >>> (yet) reimplemented? Someone provided above a real user-case for >>> gcc->llvm involving Fortran. I don't think dragon-egg development is >>> stalled at all. >> >> And some (including yours truly) consider this little more than theft. >> Especially since there is GCC-bashing on the one side, and taking the >> bits they like on the other. >> >> Since for me benefits to users of gcc are pretty much the same as benefits to gcc, yes, I see a benefit. >>> >>> By that rule, it is clearly beneficial for some gcc users to compile >>> Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg >>> is beneficial to GCC. >> >> No it "is" not, you "think it is", i.e. opinion. Again, I don't share >> that opinion at all, because this means there is less motivation for >> developers to add OpenCL to GCC itself. > > In the same sense that adding clang->gcc means that there is less > motivation for developers to improve the current C/C++ FEs. So I guess > you are against this as well. But then, just a few mails above, you > are the one who proposed adding clang to gcc in the first place. > Sorry, it seems a contradiction to me and I cannot get my head around > it. So perhaps your guess is not right? You're using sophisms: First you "guess" what my goals are, and then you go on to show apparent contradictions. But actually, I think it may be the right thing for GCC to replace the front ends altogether with clang. Note: Maybe. There are clear advantages and disadvantages, and only time (and experimenting) will tell whether it will actually happen or not. Trying it with ObjC and ObjC++ first would be an interesting feasibility study. I personally do not believe that there is much value in maintaining GNU ObjC/ObjC++. The community of users is small and there are barely enough maintainers to sustain these front ends. In GCC, these languages will probably always be less important than C/C++, but in clang they are 1st class citizens. So what I meant to say in those "few mails above" is that time spent on plugging clang into gcc may be worth more than trying to forward-port about a decade of ObjC development from the Apple/NEXT compilers and runtimes to GCC. Ciao! Steven
