Re: clang and FSF's strategy
On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote: > The fact that these non-free tools are not based on gcc are a > testament to how proprietary software developers cannot plug into gcc, > and how clang is fostering non-free software. What does it matter whether clang fosters non-free software if clang *also* fosters free software? Indeed, non-free software inspires a lot of free software, anyway. Apparently, gcc isn't fostering much of anything, except for a desire to replace it with llvm/clang. Where there is the least friction, there is the most freedom.
Re: clang and FSF's strategy
Michael Witten writes: > On Wed, Jan 22, 2014 at 2:33 PM, Jordi Gutiérrez Hermoso wrote: > >> The fact that these non-free tools are not based on gcc are a >> testament to how proprietary software developers cannot plug into gcc, >> and how clang is fostering non-free software. > > What does it matter whether clang fosters non-free software if clang *also* > fosters free software? Indeed, non-free software inspires a lot of free > software, anyway. > > Apparently, gcc isn't fostering much of anything, except for a desire to > replace it with llvm/clang. > > Where there is the least friction, there is the most freedom. And you can save a lot of money on street construction if everybody just drives off-road. Simple solutions for the win. The GNU project did not get where it is by accident. If you take a look at "prisoner's dilemma" tournaments, by far the most successful strategy invariably is "tit for tat" and slight variations. The unmodified strategy will _never_ beat an opponent in any single battle, and it still emerges as the winner in many tournaments. At any rate, if you want to bash the strategies of the GNU project, these lists are the wrong place to go. Try doing it on the Clang list though I am skeptical that they do not have better things to do as well. -- David Kastrup
Re: clang and FSF's strategy
Hi David, > At any rate, if you want to bash the strategies of the GNU project, these lists are the wrong place to go. Try doing it on the Clang list though I am skeptical that they do not have better things to do as well. the Clang list is for technical rather than political discussion, as you guessed. I unfortunately don't have any helpful suggestions for where Michael could best continue this discussion, but I'm pretty sure it's not the clang mailing list. Best wishes, Duncan.
Re: -Wformat-security warnings generated in gcc build
"Joseph S. Myers" a écrit:
> On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
>
>> Unfortunately, I am not clear on how to check for format specifiers in
>> string.
>> Should I do it manually by checking the format string for specifiers
>> and call abort if found a no-argument specifier,
>> or is there a better way to do it ?
>
> I'll leave it to Dodji as diagnostics maintainer to advise on the best way
> to implement error_at_no_args.
Thanks for the heads-up, Joseph.
Assuming we want to do something more than just segfaulting if
error_at_no_args is given a format specifier that needs an argument, I
think the function pretty-print.c:pp_format is the place where the
core of the change has to be done. Basically, that function walks the
format string and expands format specifiers.
Thus, in that function, if a format specifier needs an argument (that
is, each time we try to access text->args_ptr) but we are in a context
where we want to accept only no-argument specifiers, we can call abort
or internal_error with a meaningful error message.
I guess we can assume that we know that we are in a
oo-argument-specifier context if text->args_ptr is NULL in pp_format()
That text->args_ptr is actually the va_ap that you (Prathamesh) set to
NULL when you did:
void
error_at_no_args (location_t loc, const char *gmsgid)
{
diagnostic_info diagnostic;
diagnostic_set_info (&diagnostic, gmsgid, NULL, loc, DK_ERROR);
^
|
here: __|
report_diagnostic (&diagnostic);
}
And then, just keep the error_at_no_args() implementation like what
you did already.
Also, you'd need to modify cp/error.c:cp_printer in a similar way, to
issue an internal_error each time we try to access a null test->args_ptr.
But then, I guess some people might argue that we could as well let
the code as is and just segfault on accessing a NULL test->args_ptr.
I would personally lean towards aborting with a meaningful error
message, but I'd like to hear what others think about this.
I hope this helps.
--
Dodji
Re: clang and FSF's strategy
On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote: > the... list is for technical rather than political discussion That's just it; that's the whole point. The *political* aspects are dictating the *technical* aspects. So... like it or not, that makes this list exactly the right place to have this discussion.
Re: clang and FSF's strategy
On 23/01/14 12:42, Michael Witten wrote: On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote: the... list is for technical rather than political discussion That's just it; that's the whole point. The *political* aspects are dictating the *technical* aspects. Not for clang they aren't, so please leave the clang mailing list out of it. Best wishes, Duncan. So... like it or not, that makes this list exactly the right place to have this discussion.
Re: clang and FSF's strategy
> The *political* aspects are dictating the *technical* aspects. Perhaps. > So... like it or not, that makes this list exactly the right place to > have this discussion. No because the *people* that decide the political and technical aspects are different and this list is for the latter, not the former.
Re: -Wformat-security warnings generated in gcc build
On Thu, Jan 23, 2014 at 12:32:34PM +0100, Dodji Seketeli wrote:
> "Joseph S. Myers" a écrit:
>
> > On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
> >
> >> Unfortunately, I am not clear on how to check for format specifiers in
> >> string.
> >> Should I do it manually by checking the format string for specifiers
> >> and call abort if found a no-argument specifier,
> >> or is there a better way to do it ?
> >
> > I'll leave it to Dodji as diagnostics maintainer to advise on the best way
> > to implement error_at_no_args.
>
> Thanks for the heads-up, Joseph.
>
> Assuming we want to do something more than just segfaulting if
> error_at_no_args is given a format specifier that needs an argument, I
> think the function pretty-print.c:pp_format is the place where the
> core of the change has to be done. Basically, that function walks the
> format string and expands format specifiers.
>
> Thus, in that function, if a format specifier needs an argument (that
> is, each time we try to access text->args_ptr) but we are in a context
> where we want to accept only no-argument specifiers, we can call abort
> or internal_error with a meaningful error message.
>
> I guess we can assume that we know that we are in a
> oo-argument-specifier context if text->args_ptr is NULL in pp_format()
> That text->args_ptr is actually the va_ap that you (Prathamesh) set to
> NULL when you did:
>
> void
> error_at_no_args (location_t loc, const char *gmsgid)
> {
> diagnostic_info diagnostic;
> diagnostic_set_info (&diagnostic, gmsgid, NULL, loc, DK_ERROR);
>
>^
> |
> here: __|
>
> report_diagnostic (&diagnostic);
> }
>
>
> And then, just keep the error_at_no_args() implementation like what
> you did already.
>
> Also, you'd need to modify cp/error.c:cp_printer in a similar way, to
> issue an internal_error each time we try to access a null test->args_ptr.
>
> But then, I guess some people might argue that we could as well let
> the code as is and just segfault on accessing a NULL test->args_ptr.
> I would personally lean towards aborting with a meaningful error
> message, but I'd like to hear what others think about this.
It seems like this is prime teritory for an assert, and then documenting
the API to be if you use format specifiers then you must pass args as
well. Considering that both makes it easy to see what went wrong, and
doesn't trade performance to get most of what you get with
internal_error()
Trev
>
> I hope this helps.
>
> --
> Dodji
Re: -Wformat-security warnings generated in gcc build
On Thu, Jan 23, 2014 at 5:02 PM, Dodji Seketeli wrote:
> "Joseph S. Myers" a écrit:
>
>> On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
>>
>>> Unfortunately, I am not clear on how to check for format specifiers in
>>> string.
>>> Should I do it manually by checking the format string for specifiers
>>> and call abort if found a no-argument specifier,
>>> or is there a better way to do it ?
>>
>> I'll leave it to Dodji as diagnostics maintainer to advise on the best way
>> to implement error_at_no_args.
>
> Thanks for the heads-up, Joseph.
>
> Assuming we want to do something more than just segfaulting if
> error_at_no_args is given a format specifier that needs an argument, I
> think the function pretty-print.c:pp_format is the place where the
> core of the change has to be done. Basically, that function walks the
> format string and expands format specifiers.
>
> Thus, in that function, if a format specifier needs an argument (that
> is, each time we try to access text->args_ptr) but we are in a context
> where we want to accept only no-argument specifiers, we can call abort
> or internal_error with a meaningful error message.
>
> I guess we can assume that we know that we are in a
> oo-argument-specifier context if text->args_ptr is NULL in pp_format()
> That text->args_ptr is actually the va_ap that you (Prathamesh) set to
> NULL when you did:
>
> void
> error_at_no_args (location_t loc, const char *gmsgid)
> {
> diagnostic_info diagnostic;
> diagnostic_set_info (&diagnostic, gmsgid, NULL, loc, DK_ERROR);
>
> ^
> |
> here: __|
>
> report_diagnostic (&diagnostic);
> }
>
>
> And then, just keep the error_at_no_args() implementation like what
> you did already.
Shall it be correct then to replace calls to error() and friends,
taking only format string with no-argument specifiers
to error_at_no_args() ? (similarly we shall need warning_at_no_args,
pedwarn_no_args, etc.)
>
> Also, you'd need to modify cp/error.c:cp_printer in a similar way, to
> issue an internal_error each time we try to access a null test->args_ptr.
Shall check for text->args_ptr be required in each case label of
argument specifier in pp_format()
and client-specific functions like cp_printer() ?
eg:
case 'c':
gcc_assert (text->args_ptr);
pp_character (pp, va_arg (*text->args_ptr, int));
break;
>
> But then, I guess some people might argue that we could as well let
> the code as is and just segfault on accessing a NULL test->args_ptr.
> I would personally lean towards aborting with a meaningful error
> message, but I'd like to hear what others think about this.
>
> I hope this helps.
>
> --
> Dodji
Re: -Wformat-security warnings generated in gcc build
Prathamesh Kulkarni writes: > > Shall it be correct then to replace calls to error() and friends, > taking only format string with no-argument specifiers > to error_at_no_args() ? (similarly we shall need warning_at_no_args, > pedwarn_no_args, etc.) I would guess so, yes. >> >> Also, you'd need to modify cp/error.c:cp_printer in a similar way, to >> issue an internal_error each time we try to access a null test->args_ptr. > > Shall check for text->args_ptr be required in each case label of > argument specifier in pp_format() > and client-specific functions like cp_printer() ? Yes, I think so. Maybe you can make that a bit more maintainable by creating a macro like those used to access text->args_ptr in cp_printer, e.g: #define next_int va_arg (*text->args_ptr, int) In that macro, make the check for text->args_ptr before accessing it, and then use that macro to access text->args_ptr through the function. -- Dodji
Re: -Wformat-security warnings generated in gcc build
On Thu, Jan 23, 2014 at 8:24 PM, Dodji Seketeli wrote:
> Prathamesh Kulkarni writes:
>
>>
>> Shall it be correct then to replace calls to error() and friends,
>> taking only format string with no-argument specifiers
>> to error_at_no_args() ? (similarly we shall need warning_at_no_args,
>> pedwarn_no_args, etc.)
>
> I would guess so, yes.
>
>>>
>>> Also, you'd need to modify cp/error.c:cp_printer in a similar way, to
>>> issue an internal_error each time we try to access a null test->args_ptr.
>>
>> Shall check for text->args_ptr be required in each case label of
>> argument specifier in pp_format()
>> and client-specific functions like cp_printer() ?
>
> Yes, I think so. Maybe you can make that a bit more maintainable by
> creating a macro like those used to access text->args_ptr in cp_printer,
> e.g:
>
> #define next_int va_arg (*text->args_ptr, int)
>
> In that macro, make the check for text->args_ptr before accessing it,
> and then use that macro to access text->args_ptr through the function.
>
I was going through diagnostic.c, it appears that many functions in
(error(), error_at(), warning(), etc.) share common code (mostly
contains call to diagnostic_set_info() followed by call to
report_diagnostic()), which I guess can be re-written in terms of
emit_diagnostic(), however since it's variadic that's not possible. I
wrote a v_emit_diagnostic() function, that takes same arguments as
emit_diagnostic(), with additional va_list * at end (va_list * instead
of va_list, so I could pass NULL for error_no_args() and friends). Is
it correct to write these other functions (emit_diagnostic(), error(),
inform(), etc.) in terms of v_emit_diagnostic() ?
> --
> Dodji
Index: diagnostic.c
===
--- diagnostic.c (revision 206867)
+++ diagnostic.c (working copy)
@@ -884,29 +884,38 @@ diagnostic_append_note (diagnostic_conte
va_end (ap);
}
-bool
-emit_diagnostic (diagnostic_t kind, location_t location, int opt,
- const char *gmsgid, ...)
+static bool
+v_emit_diagnostic (diagnostic_t kind, location_t location, int opt, const char *gmsgid, va_list *ap_p)
{
diagnostic_info diagnostic;
- va_list ap;
bool ret;
-
- va_start (ap, gmsgid);
+
if (kind == DK_PERMERROR)
{
- diagnostic_set_info (&diagnostic, gmsgid, &ap, location,
+ diagnostic_set_info (&diagnostic, gmsgid, ap_p, location,
permissive_error_kind (global_dc));
diagnostic.option_index = permissive_error_option (global_dc);
}
else {
- diagnostic_set_info (&diagnostic, gmsgid, &ap, location, kind);
+ diagnostic_set_info (&diagnostic, gmsgid, ap_p, location, kind);
if (kind == DK_WARNING || kind == DK_PEDWARN)
diagnostic.option_index = opt;
}
ret = report_diagnostic (&diagnostic);
- va_end (ap);
+ return ret;
+}
+
+bool
+emit_diagnostic (diagnostic_t kind, location_t location, int opt,
+ const char *gmsgid, ...)
+{
+ va_list ap;
+ bool ret;
+
+ va_start (ap, gmsgid);
+ ret = v_emit_diagnostic (kind, location, opt, gmsgid, &ap);
+ va_end (ap);
return ret;
}
@@ -915,12 +924,10 @@ emit_diagnostic (diagnostic_t kind, loca
void
inform (location_t location, const char *gmsgid, ...)
{
- diagnostic_info diagnostic;
va_list ap;
va_start (ap, gmsgid);
- diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_NOTE);
- report_diagnostic (&diagnostic);
+ v_emit_diagnostic (DK_NOTE, location, 0, gmsgid, &ap);
va_end (ap);
}
@@ -947,15 +954,11 @@ inform_n (location_t location, int n, co
bool
warning (int opt, const char *gmsgid, ...)
{
- diagnostic_info diagnostic;
va_list ap;
bool ret;
va_start (ap, gmsgid);
- diagnostic_set_info (&diagnostic, gmsgid, &ap, input_location, DK_WARNING);
- diagnostic.option_index = opt;
-
- ret = report_diagnostic (&diagnostic);
+ ret = v_emit_diagnostic (DK_WARNING, input_location, opt, gmsgid, &ap);
va_end (ap);
return ret;
}
@@ -967,14 +970,11 @@ warning (int opt, const char *gmsgid, ..
bool
warning_at (location_t location, int opt, const char *gmsgid, ...)
{
- diagnostic_info diagnostic;
va_list ap;
bool ret;
va_start (ap, gmsgid);
- diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_WARNING);
- diagnostic.option_index = opt;
- ret = report_diagnostic (&diagnostic);
+ ret = emit_diagnostic (DK_WARNING, location, opt, gmsgid, &ap);
va_end (ap);
return ret;
}
@@ -995,14 +995,11 @@ warning_at (location_t location, int opt
bool
pedwarn (location_t location, int opt, const char *gmsgid, ...)
{
- diagnostic_info diagnostic;
va_list ap;
bool ret;
va_start (ap, gmsgid);
- diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_PEDWARN);
- diagnostic.option_index = opt;
- ret = report_diagnostic (&diagnostic);
+ ret = v_emit_diagnostic (DK_PEDWARN, location, opt, gmsgid, &ap);
va_end (ap);
return ret;
}
@@ -1017,15 +1014,11 @@ pedwarn (location_t locatio
ICE in trunk due to MEM with address in vector mode
Hello, I have found a strange case of an ICE due to a MEM with an address with vector mode. The ICE looks like: baaclc_block.c: In function 'fn2': baaclc_block.c:22:1: internal compiler error: in trunc_int_for_mode, at explow.c:56 } ^ 0x64d050 trunc_int_for_mode(long, machine_mode) /home/pmatos/work/fp_gcc-master/gcc/explow.c:56 0x637148 gen_int_mode(long, machine_mode) /home/pmatos/work/fp_gcc-master/gcc/emit-rtl.c:422 0x64d61a plus_constant(machine_mode, rtx_def*, long) /home/pmatos/work/fp_gcc-master/gcc/explow.c:190 0x63b3e1 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long) /home/pmatos/work/fp_gcc-master/gcc/emit-rtl.c:2088 0x98f05b simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int) /home/pmatos/work/fp_gcc-master/gcc/simplify-rtx.c:6061 0x98f381 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned int) /home/pmatos/work/fp_gcc-master/gcc/simplify-rtx.c:6123 0xf546ab propagate_rtx_1 /home/pmatos/work/fp_gcc-master/gcc/fwprop.c:565 0xf54c6c propagate_rtx /home/pmatos/work/fp_gcc-master/gcc/fwprop.c:730 0xf56628 forward_propagate_and_simplify /home/pmatos/work/fp_gcc-master/gcc/fwprop.c:1392 0xf568f4 forward_propagate_into /home/pmatos/work/fp_gcc-master/gcc/fwprop.c:1465 0xf56b8d fwprop /home/pmatos/work/fp_gcc-master/gcc/fwprop.c:1550 0xf56c30 execute /home/pmatos/work/fp_gcc-master/gcc/fwprop.c:1586 I cannot reproduce it with my host backend... however, I can try to explain what's happening. fwprop is calling propagate_rtx with rtxs of the form: X: (subreg:DI (reg/v:V4SI 93 [ v4wspecExp ]) 8 mode: DImode old_rtx: (reg/v:V4SI 93 [ v4wspecExp ]) new_rtx: (mem:V4SI (plus:V4SI (vec_concat:V4SI (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0])) (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0]))) (reg:V4SI 92 [ D.2926 ])) [0 S16 A6 This will go through simplify_subreg that upon seeing a memory where the address is not mode dependent will call adjust_address_1 with adjust_address argument enabled and it will call plus_constant to adjust the address, however plus_constant won't find any constants in the address and will simply fallback to: x = gen_rtx_PLUS (mode, x, gen_int_mode (c, mode)); gen_int_mode (8, V4SI) will call trunc_int_for_mode with 8 and V4SI which will ICE because trunc_int_for_mode doesn't handle ICE. I suggest the following patch to simplify-rtx.c: diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c index 04af01e..b01211f5 100755 --- a/gcc/simplify-rtx.c +++ b/gcc/simplify-rtx.c @@ -6057,7 +6057,11 @@ simplify_subreg (enum machine_mode outermode, rtx op, have instruction to move the whole thing. */ && (! MEM_VOLATILE_P (op) || ! have_insn_for (SET, innermode)) - && GET_MODE_SIZE (outermode) <= GET_MODE_SIZE (GET_MODE (op))) + && GET_MODE_SIZE (outermode) <= GET_MODE_SIZE (GET_MODE (op)) + && !VECTOR_MODE_P (GET_MODE (XEXP (op, 0 return adjust_address_nv (op, outermode, byte); /* Handle complex values represented as CONCAT Comments? Paulo Matos
Re: Enable -Wreturn-type by default ?
On Wed, 22 Jan 2014, Sylvestre Ledru wrote: > Actually, I wonder if -Wmissing-return should not be included by default ... I don't think that's appropriate for C; control reaching the end of a function is quite likely to mean simply that the user is writing C90 / C99 code without annotations for noreturn functions (so control can't actually reach the end of the function but GCC can't tell that). -- Joseph S. Myers jos...@codesourcery.com
Re: clang and FSF's strategy
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The fact that these non-free tools are not based on gcc are a > testament to how proprietary software developers cannot plug into gcc, > and how clang is fostering non-free software. What does it matter whether clang fosters non-free software if clang *also* fosters free software? Non-free software is an injustice. Our goal is to eliminate that injustice, to give computer users freedom. Developing free software part of what we do to achieve this goal. When any program fosters non-free software, that works directly against the overall goal. Copyleft is our method of making sure that our free software does not generate nonfree competitors which consist of our code plus something else that is off limits to us. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.
Re: clang vs free software
(Redirected to the proper lists, excluding emacs-devel.) Helmut Eller : > > If nobody bothers with even > > considering the question, it would appear that it is not all that > > important... > > Maybe nobody bothers because using clang is easier than to fight with > FSF policies. Which is pretty close if not identical to my original point. The clang people aren't just a technical challenge to GCC, they're a philosophical/political one to the FSF as well. They are explicitly reacting, and positioning themselves publicly against, what they consider FSF over-control. The clearest possible statement of this is in Chandler Carruth's talk "Clang: Defending C++ from Murphy's Million Monkeys" (all over YouTube) in which he explains "why we set out to build another C++ compiler" by beginning with this question posted to the gcc list: "is there are reason for not making the [GCC] front ends dynamic libraries which could be linked by any program that wants to parse source code?" Carruth then quotes RMS: "One of our main goals for GCC is to prevent any parts of it from being used together with non-free software. Thus, we have deliberately avoided many things that might possibly have the effect of facilitating such usage..." Carruth then says, exasperation very obvious in his voice, "This is *not* a *useful answer*!" (about 3:42 in the video). Thus, the clang project. They want to build IDEs and other tools that share the compiler's code. GCC policy won't let them do that. Ergo, GCC must be kicked aside. The clang developers are demonstrating that they have the capacity to make good on this threat. clang is not a toy or a laboratory demonstration; it is a real, production-quality compiler with some significant advantages over GCC. Much more useful error messages is one; a newer generation of optimization leading to smaller, tighter code is another; and much faster compilation is yet another. The "Clang vs Other Open Source Compilers" page admits that "GCC supports more targets than LLVM" and "GCC supports languages that clang does not aim to", but these are not stable advantages given the technical strength of LLVM and the large amount of developer commitment clang now has. I'm not pointing out these facts to argue with the FSF's past decisions, but to ask "What are you going to do now?" More of the same will not serve. GCC is in near-term danger of losing its dominance in open-source C development; I would say the danger is imminent if not that people are innately conservative about major changes to their toolchains. The other shoe will drop when a major Linux distribution ships with clang as its default compiler; I could easily see this happening before the end of 2015, followed by a cascade of me-too defections. To keep its #1 spot, GCC needs to out-improve and out-compete clang. And not just on the technical level, either. "Using clang is easier than to fight with FSF policies" indeed. Unless that changes, GCC's future is as a legacy tool, a backwater that developers are exiting as fast as is practical. As I've said before, I don't personally care who wins; either tool will serve my needs. I would prefer to see both flourish and compete with each other. But that's not where things are heading unless GCC ups its game. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: clang vs free software
On 23 January 2014 17:49, Eric S. Raymond wrote: > (Redirected to the proper lists, excluding emacs-devel.) Why do you think the gcc list is the proper place? > The clang people aren't just a technical challenge to GCC, they're a > philosophical/political one to the FSF as well. They are explicitly > reacting, and positioning themselves publicly against, what they > consider FSF over-control. The company that started Clang doesn't like the GPL, of course they position themselves against its philosophy. I'm not sure why you think that means GCC should follow. Are we supposed to be surprised that a proprietary code vendor finds the GPL prevents them doing certain things? Isn't that the point? > Carruth then says, exasperation very obvious in his voice, "This is *not* > a *useful answer*!" (about 3:42 in the video). Thus, the clang project. I'm not sure your version of history is accurate. Google didn't start the project. > They > want to build IDEs and other tools that share the compiler's code. GCC > policy won't let them do that. Ergo, GCC must be kicked aside. Good for them, why do you think the gcc list is the proper place to tell this story? > The clang developers are demonstrating that they have the capacity to make > good on this threat. clang is not a toy or a laboratory demonstration; it > is a real, production-quality compiler with some significant advantages over > GCC. Much more useful error messages is one; a newer generation of > optimization leading to smaller, tighter code is another; and much faster > compilation is yet another. Have you done a real comparison of error messages from the latest releases? Have you measured how much faster Clang compiles once you crank up the optimisation to the level that real programs use? If you're just going to parrot the usual outdated claims please do it somewhere else, we've heard them before. > I'm not pointing out these facts to argue with the FSF's past decisions, > but to ask "What are you going to do now?" Why do you think the gcc list is the proper place to ask questions of the FSF?
Re: clang and FSF's strategy
On Tue, 21 Jan 2014, Alexandre Oliva wrote: > On Jan 21, 2014, e...@thyrsus.com (Eric S. Raymond) wrote: > > > I think it is time to question whether the anti-plugins policy is > > still the best way to accomplish this. > > Err... Excuse me, but what anti-plugins policy are you talking about? Indeed. There are people working right now on improvements to modularity in GCC, elimination of global state, and support for use of GCC in a JIT library, led by Andrew MacLeod and David Malcolm. Contributions to those sorts of efforts (and to the plugin interface) are more useful than rhetoric. No policy objections are being made to these patches, it's simply a matter of the work involved. If people want suggestions that don't conflict with what Andrew and David are working on, a couple of suggestions: * We have about 700 target macros (my script lists 697 right now, but there are likely some false positives, and maybe false negatives), all of which should move to the hooks mechanism to enable multiple targets to be supported in a single compiler binary, and to get other benefits such as not having the build of GCC fail with warnings seen only for some targets because of differences in the target macro definitions. I expect a large proportion of these (not used in #if or in code built for the target, etc.) could be converted to hooks using some form of script-based automatic refactoring, possibly with manual fine-tuning of the resulting patches. * Andrew MacLeod's plans for improving static typing are I think largely about the middle end - there is plenty of scope for improving static typing of datastructures used in the front ends, and cleanly separating them from the language-independent compiler as far as possible. -- Joseph S. Myers jos...@codesourcery.com
Re: clang vs free software
On Thu, Jan 23, 2014 at 12:49 PM, Eric S. Raymond wrote: >> Maybe nobody bothers because using clang is easier than to fight with >> FSF policies. > > Which is pretty close if not identical to my original point. Your original point came across as a complaint that GCC does not support plugins because of some FSF policy, despite GCC supporting plugins because of the Runtime Exception that I championed. > The clearest possible statement of this is in Chandler Carruth's talk > "Clang: Defending C++ from Murphy's Million Monkeys" (all over > YouTube) in which he explains "why we set out to build another C++ > compiler" by beginning with this question posted to the gcc list: "is > there are reason for not making the [GCC] front ends dynamic > libraries which could be linked by any program that wants to parse > source code?" GCC is working toward re-factoring its code base toward a more compositional approach for "toolification". One can look at presentations from the recent GNU Cauldron 2013 for discussion of the topic. David Malcolm also has created patches for the GCC backend to be used as a JIT. The assertions that FSF policy prevents technical development and innovation simply is not true. Clang/LLVM has technical advantages and GCC has technical advantages. > More of the same will not serve. GCC is in near-term danger of losing > its dominance in open-source C development; I would say the danger is > imminent if not that people are innately conservative about major changes > to their toolchains. The other shoe will drop when a major Linux distribution > ships with clang as its default compiler; I could easily see this happening > before the end of 2015, followed by a cascade of me-too defections. Your comments presume that the choice is because of technical merit or philosophy impeding technical development. The issue for companies is control: which compiler allows them better access / control over the toolchain control point of the ecosystem and which allows them to create a walled garden to improve their margins and their business model. If developers and engineers want to cherry-pick technical anecdotes that support the business decision, it makes it easier for the company to implement its policy, but it does not change the direction of the business decision. - David
Re: clang vs free software
On Thu, Jan 23, 2014 at 6:49 PM, Eric S. Raymond wrote: > (Redirected to the proper lists, excluding emacs-devel.) This is not the proper list. "gcc@ is a ... list for general development discussions about GCC." (xf http://gcc.gnu.org/lists.html). Most of this pointless discussion has nothing to do with GCC development. But there's so much BS in this one e-mail that I can't resist reacting in equal non-nonsensical fashion... ;-) > GCC > policy won't let them do that. Ergo, GCC must be kicked aside. Same "logic": I can't use my dish washer to fly to the moon, ergo it must be kicked aside. > The clang developers are demonstrating that they have the capacity to make > good on this threat. I don't feel threatened. Do you? > clang is not a toy or a laboratory demonstration; it > is a real, production-quality compiler with some significant advantages over > GCC. Much more useful error messages is one; a newer generation of > optimization leading to smaller, tighter code is another; and much faster > compilation is yet another. You've of course all fact checked this? Have you checked *for yourself* that clang produces smaller, tighter code? What newer generation of optimizations does LLVM have that you confirmed GCC does not have? Or are you just propagating the clang marketing slogans? (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a better-supported point of view.) > GCC is in near-term danger of losing > its dominance in open-source C development; There's an indisputable statement, if not to say "fact"! Oh, wait... > I would say the danger is > imminent if not that people are innately conservative about major changes > to their toolchains. The other shoe will drop when a major Linux distribution > ships with clang as its default compiler; I could easily see this happening > before the end of 2015, followed by a cascade of me-too defections. Ah, the major Linux distro builders are going for clang! That explains why Redhat and Suse still work so hard to improve GCC and other GNU tool chain software! Oh, wait again... > To keep its #1 spot, GCC needs to out-improve and out-compete clang. Yes! Let's aim for the #1 spot and rule the universe! That's a stated goal for GCC, after all, isn't it? Oh, hmm, it isn't. Your entire rant seems to be based on nothing more than marketing statements that you present as facts, and an unbalanced deduction of irrational conclusions from there. It's a waste of bandwidth, if you ask me... Ciao! Steven
Re: Don't shoot the messenger
On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote: > I have not run direct checks on the quality of the optimized code, but > reports from others that it is improved seem plausible in light of > the fact that GCC's optimization technology is two decades older in > origin. Yay, another "fact". You must have missed the almost complete rewrite of GCC's optimization framework that was merged in 2004 and that's been continuously improved since than: http://gcc.gnu.org/projects/tree-ssa/ Really. Do your homework. Ciao! Steven
checking GPL compatibility in MELT meta-plugin
Hello All, [GCC list, MELT group, and David Malcolm -python plugin- and Diego Novillo -plugin enthusiast & maintainer] Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software enthusiast and I like a lot the GPLv3 As you know, GCC has some technical devices to invite plugin developers to make GPL compliant plugins. http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html This is done thru the plugin_is_GPL_compatible symbol. Of course, some dishonest person could technically have & distribute a proprietary GCC plugin defining that symbol (IANAL, but I believe it won't be accepted in court, even if technically feasible). MELT http://gcc-melt.org/ is a domain specific language (GPLv3 licensed and FSF copyrighted, since implemented in the MELT branch of GCC and the MELT plugin for GCC) to extend GCC and I (Basile) am the main author of MELT. I believe that MELT should have a technical device to invite people to make GPL compliant extensions in MELT. It is implemented by a runtime melt-runtime.cc & melt-runtime.h and by a bootstrapped MELT translator coded in MELT (files melt/warmelt*.melt) and also distributed in generated C++ form (files melt/generated/warmelt*.cc) MELT is a lisp-y language, and is generally distributed as a plugin for GCC. http://gcc-melt.org/download.html ; MELT is a meta-programmed system: MELT code is translated to C++ code, and that is translated to *.so which is dlopen-ed by the MELT runtime; the MELT translator is coded in MELT. MELT is (like D.Malcolm's Python plugin) a "meta"-plugin, in the sense that it enables other code (for MELT, in MELT lisp-y dialect, for the Python plugin, in Python) to be "injected" or "glued" into GCC ... MELT is GPLv3 and I (Basile) try hard to favor (when technically possible) GPL software (but I do know it is *not* a technical issue at first). Let me explain a bit: First, when the MELT plugin is built and installed, most of the source code is installed also, and MELT won't run without it (the MELT runtime contains some code in melt-runtime.cc to enforce that). Typically, MELT is installed under $(gcc -print-file-name=plugin) which contains (in addition of the files installed by GCC, e.g. by the gcc-4.8-plugin-dev of a Debian/Sid distribution) a directory melt-sources/ which contains all the source files in MELT (i.e. all *.melt files like warmelt-macro.melt etc... ) and the corresponding generated files in C++ (i.e. warmel-macro*.cc). Some code in the MELT runtime is checking that these files are accessible (in that sense MELT is more cautious than many other software: you need most of MELT source code to run MELT successfully!) but the checks are not perfect. I would very much like MELT extensions to have, if possible, a GPLv3 compatible license (AFAIK, there are not many MELT extensions today ). So I devised a device to "help" that: a MELT extension should use the case-insensitive MODULE_IS_GPL_COMPATIBLE macro somewhere in the *.melt source code. I'm using myself inside MELT, for example in warmelt-macro.melt file: ;; This MELT module is GPL compatible since it is GPLv3+ licensed. (module_is_gpl_compatible "GPLv3+") The argument to module_is_gpl_compatible can be any constant string. By human convention only that string explains a bit why the given module or extension is GPL compatible. when this macro is processed by the MELT translator (itself coded in MELT) the generated C++ file contains : MELT_EXTERN const char melt_module_is_gpl_compatible[]; const char melt_module_is_gpl_compatible[]= "warmelt-macro: GPLv3+"; where MELT_EXTERN is simply a C++ macro from melt-runtime.h : #define MELT_EXTERN extern "C" If the module_is_gpl_compatible macro is not used in the MELT source code of some extension, a warning and a notice happens; in that case (lines 2102 and following of file melt/warmelt-outobj.melt ...) I have: (warning_at () "MELT module $1 does not claim GPL compatibility using MODULE_IS_GPL_COMPATIBLE macro" omodnam) (inform_at () "See http://www.gnu.org/licenses/gcc-exception-3.1.en.html";) However, the MELT extension does become translated to C++ code. The C++ code itself may have the melt_module_is_gpl_compatible symbol. If it is missing, the MELT runtime complains (file melt-runtime.cc near line 9628) if (!MELTDESCR_OPTIONAL(melt_module_is_gpl_compatible)) warning (0, "MELT module %s does not claim to be GPL compatible", MELTDESCR_REQUIRED (melt_modulename)); Notice that MELT is very often generating C++ code and dlopening it. This is the common way for MELT to function & run. In particular, it may emit temporary C++ code, notably when simply evaluating a MELT expression, or for the "findgimple" mode of MELT - see middle of http://gcc-melt.org/tutousemelt.html for an explanation and compile and dlopen that code. There is no reason for that temporary C++ code to be GPL (it is temporary and is deleted when MELT finishes, and the source is just
Don't shoot the messenger
Some people have replied to me doubting that clang has the advantages I listed (better error messages, faster compilation, superior optimization). I maintain a C project called GPSD which, though not above medium size, is for various reasons a pretty good compiler-quality stress test. I found an optimizer bug in GCC 3.x with it a few years back. Though I normally build and test with GCC, I occasionally switch to clang as a portability check. I also routinely use scan-build, a clang-based auditing tool, for static code checking. I am therefore in position to certify that the claims of better error messages and faster compilation are by no means mere hype or marketing. They are obviously, visibly true even under the relatively light use I have made of the tool. I have not run direct checks on the quality of the optimized code, but reports from others that it is improved seem plausible in light of the fact that GCC's optimization technology is two decades older in origin. Don't shoot the messenger. I didn't create the clang problem, I'm only reporting it in an attempt to shake up your assumptions and concentrate your minds on how to make GCC more competitive. You can, of course, choose to ignore or dismiss what I say. I have a strong suspicion that such head-in-the-sand behavior is what the clang developers are expecting from this crew, and that is exactly why they think they can displace GCC wthout having to say they they intend to do so. -- http://www.catb.org/~esr/";>Eric S. Raymond "Both oligarch and tyrant mistrust the people, and therefore deprive them of arms." --Aristotle
Re: Don't shoot the messenger
Steven Bosscher : > On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote: > > I have not run direct checks on the quality of the optimized code, but > > reports from others that it is improved seem plausible in light of > > the fact that GCC's optimization technology is two decades older in > > origin. > > Yay, another "fact". > > You must have missed the almost complete rewrite of GCC's optimization > framework that was merged in 2004 and that's been continuously > improved since than: http://gcc.gnu.org/projects/tree-ssa/ > > Really. Do your homework. > > Ciao! > Steven And another bullet whizzes by my head. Really, attempts to shoot the messenger *won't help*. By ignoring the areas where clang *does* have a clear advantage, *right now*, you are displaying the exact head-in-the-sand attitude that is most likely to concede the high ground to clang. That outcome wouldn't be a problem for me. It would hurt the FSF's prestige pretty badly, though. It's not really my job to care about that, but I thought someone here would. Perhaps I was wrong. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Don't shoot the messenger
On 23 January 2014 21:58, Eric S. Raymond wrote: > Steven Bosscher : >> On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote: >> > I have not run direct checks on the quality of the optimized code, but >> > reports from others that it is improved seem plausible in light of >> > the fact that GCC's optimization technology is two decades older in >> > origin. >> >> Yay, another "fact". >> >> You must have missed the almost complete rewrite of GCC's optimization >> framework that was merged in 2004 and that's been continuously >> improved since than: http://gcc.gnu.org/projects/tree-ssa/ >> >> Really. Do your homework. >> >> Ciao! >> Steven > > And another bullet whizzes by my head. > > Really, attempts to shoot the messenger *won't help*. Then stop trying to "help" us, please. > By ignoring the > areas where clang *does* have a clear advantage, *right now*, you are > displaying the exact head-in-the-sand attitude that is most likely to > concede the high ground to clang. It's not about having our head-in-the-sand and not wanting to hear the message. You seem to think you're doing us a favour by telling us something we need to hear. We've heard it. It's not a new message. You can stop telling us now, thanks. > That outcome wouldn't be a problem for me. In that case you can stop trying to pass on the message now. We've heard it. > It would hurt the FSF's > prestige pretty badly, though. It's not really my job to care about that, > but I thought someone here would. Perhaps I was wrong. I know you think you're trying to help, but you're just yet another person standing outside the tent pissing in, thinking you're helping us win a war with Clang. But there is no war. There's room for two high-quality open source compilers. They will distinguish themselves in different ways, one of which is licensing. Now please, stop trying to help.
Re: checking GPL compatibility in MELT meta-plugin
On Thu, 2014-01-23 at 22:28 +0100, Basile Starynkevitch wrote: > Hello All, [GCC list, MELT group, and David Malcolm -python plugin- and > Diego Novillo -plugin enthusiast & maintainer] > > Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software > enthusiast and I like a lot the GPLv3 > > As you know, GCC has some technical devices to invite plugin developers > to make GPL compliant plugins. > http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html > > This is done thru the plugin_is_GPL_compatible symbol. Of course, some > dishonest person could technically have & distribute a proprietary GCC > plugin defining that symbol (IANAL, but I believe it won't be accepted > in court, even if technically feasible). [...] > So my concrete questions to the GCC community are: > > Do meta-plugins like MELT (& probably Python plugin) should be concerned > about having some device to check compatibility with GPL licensing? I > believe that yes... (David Malcolm: what is your feeling on this? How do > you deal with that concern inside your Python plugin?) [I am also not a lawyer, and I don't speak for Red Hat in this] The Python plugin contains the symbol "plugin_is_GPL_compatible", and is, as far as I know, GPL compatible. The source code declares itself to be under the GPLv3 with the "(at your option) any later version" clause. However it doesn't make any technical attempts to enforce that the code running within it is license-compatible. FWIW, I am skeptical of the ability of a computer to correctly (I) determine which licenses are applicable on any given code and (II) interpret these licenses. Hence I believe that any such attempt to enforce licensing would be both (a) doomed to have both false positives and false negatives, and (b) be irritating for the end-user, for only marginal benefit. (My 2 cents; hope it's helpful) Dave
gcc-4.8-20140123 is now available
Snapshot gcc-4.8-20140123 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140123/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 207012 You'll find: gcc-4.8-20140123.tar.bz2 Complete GCC MD5=c337ea303c09689fb45e12cdabdf400f SHA1=73d1b2494f52e6b29e3907433d3e3d556f2b5ecb Diffs from 4.8-20140116 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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: clang vs free software
On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote: > (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a > better-supported point of view.) Unrelated to this thread, it would be great for this web page to get updated. You may find it to be "a better-supported point of view", but it is also comparing against clang 3.2, which is from the end of 2012, and a lot has changed since then. Modern clang versions have its autovectorizor on by default (like GCC's) and generate much better code in general. http://www.phoronix.com/ has done some benchmarks across a wider range of code than just spec (which is notoriously "hacked" by compiler developers) and Clang generates better code (and faster) than GCC in many cases. -Chris
Re: clang vs free software
On Thu, Jan 23, 2014 at 2:56 PM, Chris Lattner wrote: > On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote: >> (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a >> better-supported point of view.) > > Unrelated to this thread, it would be great for this web page to get updated. > You may find it to be "a better-supported point of view", but it is also > comparing against clang 3.2, which is from the end of 2012, and a lot has > changed since then. > > Modern clang versions have its autovectorizor on by default (like GCC's) and > generate much better code in general. Correction -- unlike LLVM, autovectorizer is not turned on by default at O2 for GCC yet. David > http://www.phoronix.com/ has done some benchmarks across a wider range of > code than just spec (which is notoriously "hacked" by compiler developers) > and Clang generates better code (and faster) than GCC in many cases. > > -Chris
Re: clang vs free software
On 23 January 2014 22:56, Chris Lattner wrote: > > Unrelated to this thread, it would be great for this web page to get updated. > You may find it to be "a better-supported point of view", but it is also > comparing against clang 3.2, which is from the end of 2012, and a lot has > changed since then. Like a lot has changed since the GCC 4.2 version used in http://clang.llvm.org/diagnostics.html :-) (I'm glad the page acknowledges it uses that version now, thanks to whoever did that!)
Re: Don't shoot the messenger
Guys, I have resisted entering into this argument up until now. All I can do here is share my experience with technical decisions that have been made in GCC. I am the maintainer of GNUstep (http://www.gnustep.org/) and the principal author of the Gorm (Interface Builder) (http://www.gnustep.org/experience/Gorm.html) application as well as many other parts of GNUstep. GNUstep, being an implementation of Cocoa, requires an up to date Objective-C compiler, something that, sadly, GCC lacks. About 3 years ago it was necessary to have an Objective-C header parser in Gorm so that it could read classes and enter them into it's library for use when building the GUI for an application. I attempted to use GCC's implementation, but was unable to because GCC was apparently, purposefully, not modularized such that it was possible to take advantage of the parser as a separate library. I ended up writing my own which, while educational, should not have been necessary. Whether the decision was made politically or not, it held back progress in my project and delayed me from adding important functionality to free software. One other point I must make is in regards to clang's Objective-C support vs. that of GCC. GCC regards Objective-C as a second class language and has done so for some time. Objective-C, according to recent statistics has surpassed C++ in the number of developers using it (see this link http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c-in-tiobe-index.html). Clang has, in my experience, at least the above two advantages over GCC. My project is a free software project, but, yet, we are already starting to shift towards using Clang as our primary compiler for the above two reasons among others. It will not surprise me if I see more projects go the same way. I can't emphasize enough how important it is to see change in GCC not just for my project's sake, but for the whole of free software. Is it enough to "win" based on philosophical grounds, but lose on technical ones? And if GCC loses on technical grounds aren't you, in effect, losing the war since fewer people will end up using your stuff since it doesn't do what they need or want? I don't believe that making technical decisions on the basis of political ends really wins anything. A message earlier in this same thread bears out that many technical decisions on GCC were, in fact, made for political reasons and that GCC should carefully consider which ones should be rescinded. Sincerely, Gregory Casamento (Sorry for the repost, I didn’t know whether or not it was delivered as gmail sent it in HTML format which the list rejected) On Jan 23, 2014, at 5:22 PM, Jonathan Wakely wrote: > On 23 January 2014 21:58, Eric S. Raymond wrote: >> Steven Bosscher : >>> On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote: I have not run direct checks on the quality of the optimized code, but reports from others that it is improved seem plausible in light of the fact that GCC's optimization technology is two decades older in origin. >>> >>> Yay, another "fact". >>> >>> You must have missed the almost complete rewrite of GCC's optimization >>> framework that was merged in 2004 and that's been continuously >>> improved since than: http://gcc.gnu.org/projects/tree-ssa/ >>> >>> Really. Do your homework. >>> >>> Ciao! >>> Steven >> >> And another bullet whizzes by my head. >> >> Really, attempts to shoot the messenger *won't help*. > > Then stop trying to "help" us, please. > >> By ignoring the >> areas where clang *does* have a clear advantage, *right now*, you are >> displaying the exact head-in-the-sand attitude that is most likely to >> concede the high ground to clang. > > It's not about having our head-in-the-sand and not wanting to hear the > message. > > You seem to think you're doing us a favour by telling us something we > need to hear. > > We've heard it. It's not a new message. You can stop telling us now, thanks. > >> That outcome wouldn't be a problem for me. > > In that case you can stop trying to pass on the message now. We've heard it. > >> It would hurt the FSF's >> prestige pretty badly, though. It's not really my job to care about that, >> but I thought someone here would. Perhaps I was wrong. > > I know you think you're trying to help, but you're just yet another > person standing outside the tent pissing in, thinking you're helping > us win a war with Clang. But there is no war. > > There's room for two high-quality open source compilers. They will > distinguish themselves in different ways, one of which is licensing. > > Now please, stop trying to help.
Re: clang vs free software
On 01/24/2014 12:12 AM, Jonathan Wakely wrote: On 23 January 2014 22:56, Chris Lattner wrote: Unrelated to this thread, it would be great for this web page to get updated. You may find it to be "a better-supported point of view", but it is also comparing against clang 3.2, which is from the end of 2012, and a lot has changed since then. Like a lot has changed since the GCC 4.2 version used in http://clang.llvm.org/diagnostics.html :-) (I'm glad the page acknowledges it uses that version now, thanks to whoever did that!) Ask them about the Fortran performance. Cray, Inc. doesn't have any problem to include gfortran with their latest supercomputing offerings as one of the three supported compilers (their own, Intel's, and GNU). ECMWF [1] just bought one and is installing it. :-) [1] http://blogs.wsj.com/metropolis/2012/10/24/weather-journal-storm-could-make-next-week-a-mess/ -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Don't shoot the messenger
> One other point I must make is in regards to clang's Objective-C support vs. > that of GCC. GCC regards Objective-C as a second class language and has > done so for some time. Objective-C, according to recent statistics has > surpassed C++ in the number of developers using it (see this link > http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c > -in-tiobe-index.html). I think that neither GCC nor any other compilers can reasonably compete with clang when it comes to Objective-C given that clang is effectively the reference implementation of the language through the connection with Apple. > Clang has, in my experience, at least the above two advantages over GCC. My > project is a free software project, but, yet, we are already starting to > shift towards using Clang as our primary compiler for the above two reasons > among others. It will not surprise me if I see more projects go the same > way. Your case (implementation of Cocoa + Objective-C parser) is very specific though so generalizing from it alone seems a bit fast. > Is it enough to "win" based on philosophical grounds, but lose on technical > ones? And if GCC loses on technical grounds aren't you, in effect, losing > the war since fewer people will end up using your stuff since it doesn't do > what they need or want? I don't believe that making technical decisions on > the basis of political ends really wins anything. A message earlier in > this same thread bears out that many technical decisions on GCC were, in > fact, made for political reasons and that GCC should carefully consider > which ones should be rescinded. Why do you think that there is a war? It's at most a competition between projects with a different focus and different strengths. -- Eric Botcazou
Re: Don't shoot the messenger
Eric, On Jan 23, 2014, at 7:00 PM, Eric Botcazou wrote: >> One other point I must make is in regards to clang's Objective-C support vs. >> that of GCC. GCC regards Objective-C as a second class language and has >> done so for some time. Objective-C, according to recent statistics has >> surpassed C++ in the number of developers using it (see this link >> http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c >> -in-tiobe-index.html). > > I think that neither GCC nor any other compilers can reasonably compete with > clang when it comes to Objective-C given that clang is effectively the > reference implementation of the language through the connection with Apple. Granted, however, at the very least GCC should consciously ramp up it’s support for Objective-C. Currently the Objective-C implementation in GCC is woefully out of date as it doesn’t include basic support for ARC. >> Clang has, in my experience, at least the above two advantages over GCC. My >> project is a free software project, but, yet, we are already starting to >> shift towards using Clang as our primary compiler for the above two reasons >> among others. It will not surprise me if I see more projects go the same >> way. > > Your case (implementation of Cocoa + Objective-C parser) is very specific > though so generalizing from it alone seems a bit fast. I’m not so sure about that. My point was that GCC in general is not built in a modular fashion. This is a shortcoming, no matter how specific, that clang doesn’t have. The ability to use the compiler’s parser in applications outside of the compiler is an extremely powerful advantage that clang offers and is used in multiple places in clang’s own suite of software. The static analyzer uses the parser. On Mac OS X Xcode uses the parser to provide contextual feedback to the user while editing the source code and also uses it to colorize the source for easy reading. So, yes, while I’m giving a very specific example what I’m referring to is an advantage. What I can say is that something so trivial which I learned in my first course in Computer Science course at the University of Maryland where I went to school nearly 20 years ago should be reflected in GCC, yet it is not. I found this surprising at the time I attempted to create the parser and I still do today. >> Is it enough to "win" based on philosophical grounds, but lose on technical >> ones? And if GCC loses on technical grounds aren't you, in effect, losing >> the war since fewer people will end up using your stuff since it doesn't do >> what they need or want? I don't believe that making technical decisions on >> the basis of political ends really wins anything. A message earlier in >> this same thread bears out that many technical decisions on GCC were, in >> fact, made for political reasons and that GCC should carefully consider >> which ones should be rescinded. > > Why do you think that there is a war? It's at most a competition between > projects with a different focus and different strengths. I wasn’t referring to a war between clang and gcc. I was referring to the war that the FSF openly has with proprietary software. GCC’s policies were specifically designed to prevent proprietary software from leveraging it, as stated by RMS and other people on this list. I believe this was done because of the position of GCC at the time as the only free software compiler of any reasonable usability. That situation has now changed and GCC can no longer rely on it’s position and be assured that it will be the most commonly used compiler on systems which promote Free Software. I don’t believe these policies made sense then and I don’t believe they make sense now, especially given clang’s growing prominence. I believe it is better to compete on functionality and make certain people want to use GCC because it offers more features and better features than clang, not because of any political agenda. > -- > Eric Botcazou Gregory Casamento
Re: Don't shoot the messenger
On 24 January 2014 01:02, Gregory Casamento wrote: > > Granted, however, at the very least GCC should consciously ramp up it’s > support for Objective-C. Currently the Objective-C implementation in GCC is > woefully out of date as it doesn’t include basic support for ARC. That's easy to say but where are the resources to do that meant to come from?
Re: checking GPL compatibility in MELT meta-plugin
On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch wrote: > > Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software > enthusiast and I like a lot the GPLv3 > > As you know, GCC has some technical devices to invite plugin developers > to make GPL compliant plugins. > http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html > > This is done thru the plugin_is_GPL_compatible symbol. Of course, some > dishonest person could technically have & distribute a proprietary GCC > plugin defining that symbol (IANAL, but I believe it won't be accepted > in court, even if technically feasible). The plugin_is_GPL_compatible symbol is implemented by GCC and may serve as an indication of intent by plugin developers. But it does not by itself indicate whether a plugin may be used. The rules for plugins are spelled out in the GCC Runtime Library Exception (http://www.gnu.org/licenses/gcc-exception-3.1.html). A plugin that follows those rules adds no restrictions to the generated code. A plugin that does not follow those rules does add restrictions to the generated code. This is true whether or not the plugin does anything with the plugin_is_GPL_compatible symbol. > Do meta-plugins like MELT (& probably Python plugin) should be concerned > about having some device to check compatibility with GPL licensing? I > believe that yes... (David Malcolm: what is your feeling on this? How do > you deal with that concern inside your Python plugin?) I think it would be reasonable for you to use something like plugin_is_GPL_compatible. > Can I just leave a warning, not an error, when the MELT macro > module_is_gpl_compatible is not used in some user-provided *.melt code? If you are going to use it, then use it. Make it an error. > Are my warning messages good enough; should I speak of "claim to be GPL > compatible" in them, or should it be something else, e.g. "assert to be > GPL compatible" or "promise to be GPL compatible", or "is GPL > compatible" [which cannot be technically checked, only legally!]; please > recall that English is not my native language! So any better suggestions > are welcome! Hard to give an opinion on an incomplete phrase, but copying the error message in gcc/plugin.c ought to be fine. > Is it ok or good to give the > http://www.gnu.org/licenses/gcc-exception-3.1.en.html URL in a notice > message? Yes, I think that is a good idea. Hope this helps. Ian
Re: clang vs free software
Sorry, I forgot that pdf file is not permitted. Therefore I am resending my email without it. On 1/23/2014, 5:56 PM, Chris Lattner wrote: On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote: (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a better-supported point of view.) Unrelated to this thread, it would be great for this web page to get updated. You may find it to be "a better-supported point of view", but it is also comparing against clang 3.2, which is from the end of 2012, and a lot has changed since then. Modern clang versions have its autovectorizor on by default (like GCC's) and generate much better code in general. http://www.phoronix.com/ has done some benchmarks across a wider range of code than just spec (which is notoriously "hacked" by compiler developers) and Clang generates better code (and faster) than GCC in many cases. -Chris I am going to do this when gcc4.9 is released. I have data for gcc4.8 and 3.3 but I never published them. Here is an excerpt from my slides about the compiler release comparison: -- SPEC2000 Setup o Intel Haswell 3.4Ghz (i5-4670) p Common opts: -mtune=corei7 -march=i686 o peak: o LLVM: -O3 o GCC: -Ofast -fno-fast-math o LTO: o LLVM: -O4 o GCC: -Ofast -fno-fast-math -flto -fwhole-program o 32-bit: additionally -mpc64 o Only 4 SPECFP2000 (C) tests as LLVM has no Fortran FE SPEC2000 Results SPECInt LLVM-3.2LLVM-3.3 GCC-4.7 GCC-4.8 32-bit peak 3302 (0.0%) 3305 (+0.06%) 3525 (+6.7%) 3543 (+7.3%) 32-bit LTO 3592 (0.0%) 3596 (+0.06%) 3704 (+3.1%) 3740 (+4.2%) 64-bit peak 3537 (0.0%) 3517 (-0.57%) 3692 (+4.4%) 3724 (+5.4%) 64-bit LTO 3787 (0.0%) 3789 (+0.05%) 3806 (+0.5%) 3846 (+1.6%) SPECFP LLVM-3.2LLVM-3.3 GCC-4.7 GCC-4.8 32-bit peak 3583 (0.0%) 3580 (-0.08%) 4888 (+36%) 4985 (+39%) 32-bit LTO 3661 (0.0%) 3668 (+0.19%) 4878 (+33%) 5011 (+37%) 64-bit peak 5468 (0.0%) 5431 (-0.68%) 5799 (+6%) 5917 (+8.2%) 64-bit LTO 5659 (0.0%) 5659 (0.0%) 5881 (+3.9%) 6005 (+6.1%) Conclusions o LLVM 3.2 -> 3.3: No progress, even small 64-bit peak degradation (0.6%) o GCC4.7-> 4.8: Steady progress (1%-4%) o Still LLVM is dangerously close to GCC on some tests (1.6% on 64-bit LTO SPECInt) I also already have some comparison data for the trunk and llvm 3.4 but I don't want to publish it here as the trunk is not a release. As for Phoronix, so far I saw several pitfalls in their testing methodology: o Micro-benchmarking. E.g. favorite benchmark Scimark2 contains a few tests with only one small hot loop, like LU-factorization where most benchmark time is spent in 2-lines loop. It means that the worse results for GCC can be easily fixed as Jakub Jelinek recently improved Scimark SOR by 42% by a small patch: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01986.html o Comparing LLVM and GCC on Fortran benchmarks. LLVM has no fortran FE and just quietly call system GCC. So comparison of LLVM and GCC on Fortran benchmarks means comparison of system GCC and a given GCC. o IMHO, the data in articles lack credability may be because a wrong setup (by me or by phoronix). E.g. I tried to reproduce Scimark results for GCC4.8 and LLVM3.3 from his article "LLVM Clang 3.4 Already Has Some Performance Changes": http://www.phoronix.com/scan.php?page=article&item=llvm_clang34_first&num=2 Phoronix used i7-4770K for this. I used the closest machine I found i5-4670 (with switched turbo mode off). The important difference is 0.1Ghz in frequency (3.5Ghz vs. 3.4 Ghz). I got GCC Scimark (-large) composite score close to the article when I used -O and still on my machine the composite score was 20% higher than the article reports although the article says that -O3 -march=core-avx were used. o Phoronix articles about LLVM and GCC usually contains a lot of negative emotions about GCC and positive ones about LLVM. Such bias to LLVM is suspicious at least for me and make me feel Phoronix as just LLVM marketing machine. Still I like that LLVM did a good progress in generated code performance, it makes GCC people working on optimizations (including me) to justify the importance of their work. In overall, competition is a good thing for LLVM and GCC as it stimulates compiler developing in faster pace. One time it was GCC vs Open64. Next time it would be GCC and something else or LLVM and something else. Who knows.
Re: Don't shoot the messenger
On Thu, Jan 23, 2014 at 5:02 PM, Gregory Casamento wrote: > > Granted, however, at the very least GCC should consciously ramp up it’s > support for Objective-C. Currently the Objective-C implementation in GCC is > woefully out of date as it doesn’t include basic support for ARC. I would like to see that happen, but we must be realistic. GCC development is driven in part by volunteers and in part by company contributions. There is only one large company that is interested in Objective C: Apple. Apple has chosen to use clang/LLVM and reject GCC, ostensibly for licensing reasons (although personally speaking I have to say that those arguments have not made sense to me for some time). It follows that all work on Objective C support in GCC will be done by volunteers. Most people who use Objective C naturally use clang/LLVM; after all, it is free, and it works well. So the volunteer pool for Objective C in GCC is relatively small. It is basically those people who want or need to use Objective C and prefer to use GCC, or GPL software in general. There aren't very many of those people. They've actually done a good job in maintaining GCC's Objective C frontend. But while I would like to see significant additions to the frontend like ARC support, I would hesitate on planning to see it occur. To the extent that clang/LLVM and GCC are fighting, which is not really the case, then I think it makes sense for GCC to focus on its strengths, not its weaknesses. Objective C is not a strength. I'm not sure it makes sense for the GCC project to encourage its limited volunteer resources to work on it. Sorry for being blunt, but that is how I see it. Ian
Re: checking GPL compatibility in MELT meta-plugin
On Thu, 2014-01-23 at 17:42 -0800, Ian Lance Taylor wrote: > On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch > wrote: > > > > Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software > > enthusiast and I like a lot the GPLv3 > > > > As you know, GCC has some technical devices to invite plugin developers > > to make GPL compliant plugins. > > http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html > > > > This is done thru the plugin_is_GPL_compatible symbol. Of course, some > > dishonest person could technically have & distribute a proprietary GCC > > plugin defining that symbol (IANAL, but I believe it won't be accepted > > in court, even if technically feasible). > > The plugin_is_GPL_compatible symbol is implemented by GCC and may > serve as an indication of intent by plugin developers. But it does > not by itself indicate whether a plugin may be used. The rules for > plugins are spelled out in the GCC Runtime Library Exception > (http://www.gnu.org/licenses/gcc-exception-3.1.html). A plugin that > follows those rules adds no restrictions to the generated code. A > plugin that does not follow those rules does add restrictions to the > generated code. This is true whether or not the plugin does anything > with the plugin_is_GPL_compatible symbol. In addition, and this might perhaps be more true for some future MELT extensions than for other plugins, a plugin could be used for code checking purposes (i.e. as a super-lint). In that view, one compile his/her application with some MELT extension -or some other plugin- for heuristic static analysis purposes - and won't distribute code so compiled, but only distribute code compiled without any plugin (or MELT extension). Probably http://clang-analyzer.llvm.org/ is used this way also. And also http://frama-c.com (developed by my colleagues from CEA, LIST) which is a LGPL static analyzer separate from any compiler. BTW, this is probably also the case (for proprietary software compiled with plain GCC) regarding the debugging -g flag: I imagine that it is more used by developers than on the finally released or distributed binary... I understand that http://www.gnu.org/licenses/gcc-exception-3.1.en.html is only relevant for distribution (i.e. propagation or conveying, in terms of GPLv3) of [binary] software compiled with GCC (If the compiled binary is discarded or only internally used, does it apply?) > > > > Do meta-plugins like MELT (& probably Python plugin) should be concerned > > about having some device to check compatibility with GPL licensing? I > > believe that yes... (David Malcolm: what is your feeling on this? How do > > you deal with that concern inside your Python plugin?) > > I think it would be reasonable for you to use something like > plugin_is_GPL_compatible. > > > > Can I just leave a warning, not an error, when the MELT macro > > module_is_gpl_compatible is not used in some user-provided *.melt code? > > If you are going to use it, then use it. Make it an error. The reason I was using a warning not an error is that MELT could perhaps in the future be used for static analysis of code (as or with -g), but that in that scenario the real released executable would very probably be compiled without MELT (and without -g) - and perhaps even by an older version of GCC! But I could make it an error if you wish. I just believe it should stay a warning > > > > Are my warning messages good enough; should I speak of "claim to be GPL > > compatible" in them, or should it be something else, e.g. "assert to be > > GPL compatible" or "promise to be GPL compatible", or "is GPL > > compatible" [which cannot be technically checked, only legally!]; please > > recall that English is not my native language! So any better suggestions > > are welcome! > > Hard to give an opinion on an incomplete phrase, but copying the error > message in gcc/plugin.c ought to be fine. Here are the precise messages for a given example. Assume you translate an hypothetical your-foo.melt extension into your-foo.so module and that file your-foo.melt does not use the MODULE_IS_GPL_COMPATIBLE macro to claim GPL compatibility: You'll first translate that your-foo.melt extension into a binary MELT module using something like [see http://gcc-melt.org/tutousemelt.html for details] gcc -fplugin=melt -fplugin-arg-melt-mode=translatetomodule \ -fplugin-arg-melt-arg=your-foo.melt \ -c emptyfile.c -o /dev/null During this translation you'll get messages from warmelt-outobj.melt: warning: MELT module your-foo does not claim GPL compatibility using MODULE_IS_GPL_COMPATIBLE macro notice: see http://www.gnu.org/licenses/gcc-exception-3.1.en.html and MELT would have produced a your-foo.so MELT binary module. Later on, (perhaps a week after) you'll use that module to analyze (or perhaps even optimize - which is against the GCC runtime exception if you distribute the so compiled binary) some other-bar.cc fil
Re: clang vs free software
On Thu, Jan 23, 2014 at 11:52:00PM -0500, Vladimir Makarov wrote: > o IMHO, the data in articles lack credability may be because a wrong > setup (by me or by phoronix). E.g. I tried to reproduce Scimark > results for GCC4.8 and LLVM3.3 from his article "LLVM Clang 3.4 > Already Has Some Performance Changes": > > http://www.phoronix.com/scan.php?page=article&item=llvm_clang34_first&num=2 > > Phoronix used i7-4770K for this. I used the closest machine I found > i5-4670 (with switched turbo mode off). The important difference is > 0.1Ghz in frequency (3.5Ghz vs. 3.4 Ghz). I got GCC Scimark > (-large) composite score close to the article when I used -O and > still on my machine the composite score was 20% higher than the > article reports although the article says that -O3 -march=core-avx > were used. Yeah, that is my experience too, e.g. on http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=3 Phoronix claims the LU benchmark improved 80% with LLVM 3.4 and ahead of GCC, but I couldn't reproduce anything close to that, while LLVM 3.4 slightly improved compared to LLVM 3.3, it was still comparable to GCC 4.8 and behind GCC 4.9. All that matters in the benchmark is a single loop though: for (jj=j+1; jj
