Re: RFH - Testing targets for the switch to C++
Hello Diego, what is with targets that only use cross compilers like RTEMS? I think there is no need for a bootstrap? -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RFC: -Wall by default
2012/4/11 Ian Lance Taylor : > Andrew Haley writes: > >> On 04/05/2012 01:28 PM, Michael Veksler wrote: >> >>> As for specific warnings, I hate that the the code (a&&b || c&&d), >>> which did not cause a warning on older gcc version now gives a >>> warning. I would not want it on by default since it forces users to >>> write too many parentheses in ((a&&b)||(c&&d)) which makes the >>> expression less readable. What next? Warn about (a*b+c*d) ? I would >>> hate to write ((a*b)+(c*d)). >>> >>> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less >>> clear and deserves a warning, but: & vs. | ; && vs. || ; are at >>> least as common as * vs. + that programmers ought to know them. >> >> Absolutely so, yes. I'd consider this a bug in gcc, just as if it >> warned for arithmetic. > > This one is an interesting case, since there are strong arguments on > both sides. > > I enabled the C++ warning about the precedence of && and || (it's been > in C for many years). It found real bugs in real code, bugs that had > existed for years. I've got a radically different experience here, real bugs were introduced while trying to remove this warning, and as far as I can tell, I've never found any bugs involving precedence of && and || -- in the code I'm working on --, whose precedence is really well known from everyone. In the real life, things are not as simple as (a && b) || ( c && d), some checks usually lie over more than five lines. This warning applied to such checks are really a pain to remove. We shall definitely have an option to remove this very warning, without getting rid of the whole sets of usefull warnings embedded in -Wparentheses. -- Fabien
Re: Switching to C++ by default in 4.8
On Wed, Apr 11, 2012 at 10:24 AM, Lawrence Crowl wrote: > On 4/10/12, Jakub Jelinek wrote: >> That when stepping through code in the debugger you keep >> enterring/exiting these one liner inlines, most of them really >> should be at least by default considered just as normal statements >> (e.g. glibc heavily uses artificial attribute for those, still >> gdb doesn't hide those by default). > > You do want to step into those inline functions, except when you do. > In the short term, we can make the debugger behave as though they did > not exist. In the longer term, we really want debugging tools that > help C++ programmers. One way to get there is to use C++ ourselves. > >> > The above is just quickly cooked up examples. A carefully >> > designed C++ based API can be self documenting and make the >> > client code very readable. It is hard to believe that there is >> > no room for improvement in GCC. >> >> Do you have examples? E.g. I haven't touched gold, because, >> while it is a new C++ codebase, looks completely unreadable to >> me, similarly libdw C++ stuff. A carefully designed C based API >> can be self documenting and make the code very readable as well, >> often more so. > > If you just look at any decently sized code base, it'll look pretty > much unreadable. The question is how quickly can someone who learns > the base vocabulary can produce reasonable modifications. > > There are many places where C++ can help substantially. For example: > > () The C++ postfix member function call syntax means that following > a chain of attributes is a linear read of the expression. With C > function call syntax, you need to read the expression inside out. > > () C++ has both overloaded functions and member functions, so you can > use the same verb to talk about several different kinds of objects. > With C function names, we have to invent a new function name for > each type. Such names are longer and burden both the author and > the reader of the code. > > () Standard C++ idioms enable mashing program components with ease. > The C++ standard library is based on mixing and matching algorithms > and data structures, via the common idiom of iterators. > > () The overloadable operator new means that memory can be > _implicitly_ allocated in the right place. > > () Constructors and destructors reduce the number of places in the > code where you need to do explicit memory management. Without garbage > collection, leaks are less frequent. With garbage collection, you > have much less active garbage, and can run longer between collection > runs. Indeed, a conservative collector would be sufficient. > > () Constructors and destructors also neatly handle actions that > must occur in pairs. The classic example is mutex lock and unlock. > Within GCC, timevar operations need to happen in pairs. > > () Class hierarchies (even without virtual functions) can directly > represent type relationships, which means that a debugger dump of > a C++ type has little unnecessary information, as opposed to the > present union of structs approach with GCC trees. > > () Class hierarchies also mean that programmers can distinguish > in the pointer types that a function needs a decl parameter, > without having to say 'all trees' versus 'a very specific tree'. > The static type checking avoids run-time bugs. > > I have written compilers in both C and C++. I much prefer the > latter. > What you said sounds correct(mostly) for me. But I think the big benefit of C++ (or any other modern language that support OO design) is that C++ is more consistent with modern software engineering practice : high cohesion and low coupling. C++ allow you to write excellent code more easily than C. Actually, you don't need to write C++ code to use C++. I think you compiler guys should know very well how each line of C++ code is translated to C code, just as C programmers normally know very well how each line of C code is translated to assembly code. So, using which language is not a big deal. It is all about the methodology, the style. You can think in C++, imaging the classes, objects in mind, and use your brain to translate this "in-brain" code to C++ or C code, whatever you like. The reason why GCC's code is very hard to hack is not simple. In part, this is because GCC use a very old, extremely hard to understand build system. In part, this is because GCC developer are more focused on fixing bugs or adding new features, rather than re-factoring GCC's code itself. For example, for a .c file that have 15 years old, people tend to fix its bugs to make it more and more ugly, rather to rewrite it. But I think the big reason is that, GCC tend to have extremely large .c files, which is typical > 6000 LOC. If you look at LLVM, there are rarely source code files that is > 2000 LOC. Typical LLVM source code files have 1000~2000 LOC. Just separating a source code file of 6000 LOC to several small files or file sections of 1000 LOC can improve the cod
Re: RFC: -Wall by default
On 4/12/2012 4:55 AM, Fabien Chêne wrote: I've got a radically different experience here, real bugs were introduced while trying to remove this warning, and as far as I can tell, I've never found any bugs involving precedence of&& and || -- in the code I'm working on --, whose precedence is really well known from everyone. You simply can't make a claim on behalf of everyone like this, and it's very easy to prove you wrong, i personally know many competent programmers who do NOT know this rule. In the real life, things are not as simple as (a&& b) || ( c&& d), some checks usually lie over more than five lines. This warning applied to such checks are really a pain to remove. a) complex conditionals over five lines are a bit of a menace anyway, but ones that rely on knowing this precedence rule are a true menace if you ask me. b) it should be trivial to remove this warning, as it is a simple automatic refactoring that should be easily done with a tool (most certainly the automatic refactoring available in GPS for GNAT would take care of this, if it needed to, which it does not, since in Ada parentheses are required in such cases (the designers of Ada most certainly disagreed with you that everyone knows this warning). We shall definitely have an option to remove this very warning, without getting rid of the whole sets of usefull warnings embedded in -Wparentheses. Yes, that seems a perfectly reasonable proposition. In GNAT there is a very general mechanism to suppress any specific warning (pragma Warnings (Off, string), where string matches the text of the message you want to suppress)) as well as a long list of specific warnings switches, similar to what we have in GNU C.
Re: RFC: -Wall by default
Robert Dewar writes: >> I've got a radically different experience here, real bugs were >> introduced while trying to remove this warning, and as far as I can >> tell, I've never found any bugs involving precedence of&& and || -- >> in the code I'm working on --, whose precedence is really well known >> from everyone. > > You simply can't make a claim on behalf of everyone like this, and it's > very easy to prove you wrong, i personally know many competent > programmers who do NOT know this rule. ... and it's quite possible that such bugs resulting from adding parentheses means that the programmer "fixing" the code didn't actually know the right precedence! I think the relative precedence of * and + can be safely termed "very well known", but in the case of && and ||, it's not so clear... -miles -- Brain, n. An apparatus with which we think we think.
Re: RFC: -Wall by default
On 4/12/2012 5:55 AM, Miles Bader wrote: ... and it's quite possible that such bugs resulting from adding parentheses means that the programmer "fixing" the code didn't actually know the right precedence! or that the layout (which is what in practice we should rely on to make things clear with or without the parentheses) was sloppy or plain incorrect. I think the relative precedence of * and + can be safely termed "very well known", but in the case of&& and ||, it's not so clear... indeed
Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On 11 April 2012 19:41, Pedro Alves wrote:
> On 04/11/2012 07:26 PM, Jonathan Wakely wrote:
>
>> GCC's diagnostics have got a lot better recently.
>>
>> The http://clang.llvm.org/diagnostics.html page compares clang's
>> diagnostics to GCC 4.2, which was outdated long before that page was
>> written.
>>
>> It doesn't help GCC's cause when people keep repeating that outdated info :-)
>
>
> Spelling out the obvious, IWBVN if someone from the gcc camp did a
> similar comparison using a current gcc. Is there such a page somewhere?
Manu has filed lots of bugs in bugzilla with specific comparisons of
GCC's diagnostics to Clang's.
I'll start a page on the GCC wiki but I hope others will add to it.
The people asking to see results should be the ones doing the
comparisons really ;-)
For now, the first example on the clang page now shows GCC is better,
because it warns about *both* missing arguments, while Clang only gets
one (even in the unreleased 3.1 version from svn)
$ gcc-4.7 -fsyntax-only -Wformat format-strings.c
format-strings.c: In function 'f':
format-strings.c:4:5: warning: field precision specifier '.*' expects
a matching 'int' argument [-Wformat]
format-strings.c:4:5: warning: format '%d' expects a matching 'int'
argument [-Wformat]
$ clang-3.1 -fsyntax-only format-strings.c
format-strings.c:4:15: warning: '.*' specified field precision is
missing a matching 'int' argument
printf("%.*d");
~~^~
1 warning generated.
Using this source:
#include
void f() {
printf("%.*d");
}
And the last example on the page now gives:
$ g++-4.7 tsc.cc
tsc.cc:2:10: error: expected ';' after class definition
tsc.cc:6:1: error: expected ';' after struct definition
$ clang++-3.1 tsc.cc
tsc.cc:2:11: error: expected ';' after class
class a {}
^
;
tsc.cc:6:2: error: expected ';' after struct
}
^
;
2 errors generated.
Which was using this source:
template
class a {}
class temp {};
a b;
struct b {
}
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On 04/12/2012 11:01 AM, Jonathan Wakely wrote: > Manu has filed lots of bugs in bugzilla with specific comparisons of > GCC's diagnostics to Clang's. > > I'll start a page on the GCC wiki but I hope others will add to it. > The people asking to see results should be the ones doing the > comparisons really ;-) Excellent, thank you! -- Pedro Alves
[PATCH] Add StarPU on extensions.html
Hello, As suggested by Gerald Pfeifer. Thanks, Ludo’. --- extensions.html.~1.51.~ 2011-09-28 01:45:17.0 +0200 +++ extensions.html 2012-04-12 12:11:09.0 +0200 @@ -26,6 +26,19 @@ maintainers, not our mailing lists. to ease development of GCC plugin-like extensions. +http://runtime.bordeaux.inria.fr/StarPU/";>StarPU + +StarPU is a GCC extension and run-time support library for hybrid + CPU/GPU task programming. Its GCC plug-in allows programmers to + annotate C code to describe tasks and their implementations. Each + task may have one or more implementations, such as CPU implementations + or implementations written in OpenCL. + + + StarPU’s support library schedules tasks over the available CPU cores + and GPUs, and is also responsible for scheduling any data transfers + between main memory and GPUs. + http://pdp10.nocrew.org/gcc/";>PDP-10 port This is an experimental port of GCC to the DEC PDP-10 architecture.
Re: RFC: -Wall by default
On 11/04/2012 09:50, Vincent Lefevre wrote: > On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: >> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: >>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote: >>> Maybe -Wstandard isn't the best name though, as "standard" usually means something quite specific for compilers, and the warning switch wouldn't have anything to do with standards conformance. >>> -Wdefault >>> >>> might be better >> except if people want warnings about "defaults" in C++11 (which can mean >> lot of things). > > How about a warning level? > > -W0: no warnings (equivalent to -w) > -W1: default > -W2: equivalent to the current -Wall > -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. cheers, DaveK
Re: RFC: -Wall by default
2012/4/12 Robert Dewar : > On 4/12/2012 4:55 AM, Fabien Chêne wrote: > >> I've got a radically different experience here, real bugs were >> introduced while trying to remove this warning, and as far as I can >> tell, I've never found any bugs involving precedence of&& and || -- >> >> in the code I'm working on --, whose precedence is really well known >> from everyone. > > > You simply can't make a claim on behalf of everyone like this, and it's > very easy to prove you wrong, i personally know many competent programmers > who do NOT know this rule. I should have said: from everyone with whom I work. I'm not claiming that this warning is useless for everybody, I'm basically saying that it is often a nuisance/risk to convert existing code to bypass this warning. > In the real life, things are not as simple as (a&& b) >> >> || ( c&& d), some checks usually lie over more than five lines. This >> >> warning applied to such checks are really a pain to remove. > > a) complex conditionals over five lines are a bit of a menace > anyway, I agree, they are actually a menace, and I do not want to touch them without a good reason. Adding parentheses does not improve readability, nor does it solves bugs in my own experience. Anyway, precedence rules have to be known in order to remove the warning. > but ones that rely on knowing this precedence rule are > a true menace if you ask me. G++ has not warned about this for decades, so whether or not people assuming basic precedence rules to be known are a menace, code that does not make precedence explicit, is quite common and we have to cope with it. And hopefully I'd rather not fix it everywhere. > b) it should be trivial to remove this warning, as it is a simple > automatic refactoring that should be easily done with a tool (most > certainly the automatic refactoring available in GPS for GNAT would > take care of this, if it needed to, which it does not, since in Ada > parentheses are required in such cases (the designers of Ada most > certainly disagreed with you that everyone knows this warning). If you are aware of a simple tool that do that for C++, I am all ears ... But I'd rather have a new option to disable it ;-) -- Fabien
Re: Switching to C++ by default in 4.8
On Thu, Apr 12, 2012 at 11:28 AM, Chiheng Xu wrote: > > The reason why GCC's code is very hard to hack is not simple. In part, > this is because GCC use a very old, extremely hard to understand build > system. In part, this is because GCC developer are more focused on > fixing bugs or adding new features, rather than re-factoring GCC's > code itself. For example, for a .c file that have 15 years old, > people tend to fix its bugs to make it more and more ugly, rather to > rewrite it. > > But I think the big reason is that, GCC tend to have extremely large > .c files, which is typical > 6000 LOC. If you look at LLVM, there are > rarely source code files that is > 2000 LOC. Typical LLVM source code > files have 1000~2000 LOC. Just separating a source code file of 6000 > LOC to several small files or file sections of 1000 LOC can improve > the code significantly. Why has this not been done before ? GCC > developers are reluctant to re-factoring their code may be the reason. > And, as the .c file grows, it become even harder to re-factor. > Thinking in C++ can help you write smaller, easier to understand, > easier to maintain code(C or C++), which have high cohesion and low > coupling. > > And I think the file names of GCC's source can also be changed more > friendly to newbies, using some notion of FQN(fully qualified name) > may be good. I think one of the reasons is a tools deficiency - at least subversion (which we use) is not able to track code motion, so if you dig in the revision history you will need more intermediate steps, but more important, rely on 2nd level information (like the ChangeLog entry) to tell where a function was moved from. Still some refactoring happens (I think mostly trying to remove APIs is important). But yes, I think we never renamed files ... I suppose when we start moving things into sub-directories that would be a good time to re-think names. At least subversion can handle file-renames just fine ;) Yes, files are too big - but splitting them is not easy unless you can figure out a hierarchy that you can expose. The largest file is dwarf2out.c with 22825 lines, but the average is more like 2000 (just looking at gcc/*.c files). There are only 23 files bigger than 6000 lines (out of 356), so the situation is not as bad as you paint it. But yes, looking at filenames hardly tells you about its contents anymore. Richard.
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On Thu, Apr 12, 2012 at 12:01 PM, Jonathan Wakely wrote:
> On 11 April 2012 19:41, Pedro Alves wrote:
>> On 04/11/2012 07:26 PM, Jonathan Wakely wrote:
>>
>>> GCC's diagnostics have got a lot better recently.
>>>
>>> The http://clang.llvm.org/diagnostics.html page compares clang's
>>> diagnostics to GCC 4.2, which was outdated long before that page was
>>> written.
>>>
>>> It doesn't help GCC's cause when people keep repeating that outdated info
>>> :-)
>>
>>
>> Spelling out the obvious, IWBVN if someone from the gcc camp did a
>> similar comparison using a current gcc. Is there such a page somewhere?
>
> Manu has filed lots of bugs in bugzilla with specific comparisons of
> GCC's diagnostics to Clang's.
>
> I'll start a page on the GCC wiki but I hope others will add to it.
> The people asking to see results should be the ones doing the
> comparisons really ;-)
>
> For now, the first example on the clang page now shows GCC is better,
> because it warns about *both* missing arguments, while Clang only gets
> one (even in the unreleased 3.1 version from svn)
>
> $ gcc-4.7 -fsyntax-only -Wformat format-strings.c
> format-strings.c: In function 'f':
> format-strings.c:4:5: warning: field precision specifier '.*' expects
> a matching 'int' argument [-Wformat]
> format-strings.c:4:5: warning: format '%d' expects a matching 'int'
> argument [-Wformat]
>
> $ clang-3.1 -fsyntax-only format-strings.c
> format-strings.c:4:15: warning: '.*' specified field precision is
> missing a matching 'int' argument
> printf("%.*d");
> ~~^~
> 1 warning generated.
>
> Using this source:
>
>
> #include
>
> void f() {
> printf("%.*d");
> }
>
>
> And the last example on the page now gives:
>
> $ g++-4.7 tsc.cc
> tsc.cc:2:10: error: expected ';' after class definition
> tsc.cc:6:1: error: expected ';' after struct definition
> $ clang++-3.1 tsc.cc
> tsc.cc:2:11: error: expected ';' after class
> class a {}
> ^
> ;
> tsc.cc:6:2: error: expected ';' after struct
> }
> ^
> ;
> 2 errors generated.
>
> Which was using this source:
>
> template
> class a {}
> class temp {};
> a b;
> struct b {
> }
And since yesterday GCC shows
t.C:2:10: error: expected ';' after class definition
class a {}
^
t.C:6:1: error: expected ';' after struct definition
}
^
as we now enabled -fdiagnostics-show-caret by default.
Richard.
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On 12 April 2012 11:35, Richard Guenther wrote:
> And since yesterday GCC shows
>
> t.C:2:10: error: expected ';' after class definition
> class a {}
> ^
> t.C:6:1: error: expected ';' after struct definition
> }
> ^
>
> as we now enabled -fdiagnostics-show-caret by default.
Yep :-)
Because of that I plan to show results for both 4.7 and 4.8 on the
wiki page, but I only have the 4.8-20120408 snapshot to hand right now
so did those first tests with 4.7.0
Two more examples, then I'll save it for a wiki page instead of the
mailing list:
A missing "typename" keyword is a very common, very easy to make
mistake when using C++ templates. It isn't usually obvious what the
problem is, so it's exactly where compilers could help, but both get
zero marks here:
$ cat missing-typename.cc
template void f(T::type) { }
struct A { };
void g()
{
A a;
f(a);
}
$ g++-4.7 missing-typename.cc
missing-typename.cc:1:33: error: variable or field 'f' declared void
missing-typename.cc: In function 'void g()':
missing-typename.cc:8:5: error: 'f' was not declared in this scope
missing-typename.cc:8:8: error: expected primary-expression before '>' token
$ clang++-3.1 missing-typename.cc
missing-typename.cc:1:24: error: variable 'f' declared as a template
template void f(T::type) { }
~ ^
missing-typename.cc:1:34: error: expected ';' at end of declaration
template void f(T::type) { }
^
;
missing-typename.cc:1:35: error: expected unqualified-id
template void f(T::type) { }
^
missing-typename.cc:7:5: error: use of undeclared identifier 'A'
A a;
^
missing-typename.cc:8:5: error: use of undeclared identifier 'f'
f(a);
^
missing-typename.cc:8:7: error: use of undeclared identifier 'A'
f(a);
^
missing-typename.cc:8:10: error: use of undeclared identifier 'a'
f(a);
^
7 errors generated.
Clang's carets and range highlighting don't help in the slightest, and
the poor error recovery that means "A" is reported as unidentified
doesn't help either.
If you add the missing typename then G++ does better:
$ cat deduce.cc
template void f(typename T::type) { }
struct A { };
void g()
{
A a;
f(a);
}
$ g++-4.7 deduce.cc
deduce.cc: In function 'void g()':
deduce.cc:8:11: error: no matching function for call to 'f(A&)'
deduce.cc:8:11: note: candidate is:
deduce.cc:1:24: note: template void f(typename T::type)
deduce.cc:1:24: note: template argument deduction/substitution failed:
deduce.cc: In substitution of 'template void f(typename
T::type) [with T = A]':
deduce.cc:8:11: required from here
deduce.cc:1:24: error: no type named 'type' in 'struct A'
$ clang++-3.1 deduce.cc
deduce.cc:8:5: error: no matching function for call to 'f'
f(a);
^~~~
deduce.cc:1:24: note: candidate template ignored: substitution failure
[with T = A]
template void f(typename T::type) { }
^
1 error generated.
Compare "no type named 'type' in 'struct A'" with "substitution failure"
Re: RFC: -Wall by default
On 04/12/2012 10:46 AM, Robert Dewar wrote: > On 4/12/2012 4:55 AM, Fabien Chêne wrote: > >> I've got a radically different experience here, real bugs were >> introduced while trying to remove this warning, and as far as I can >> tell, I've never found any bugs involving precedence of&& and || -- >> in the code I'm working on --, whose precedence is really well known >> from everyone. > > You simply can't make a claim on behalf of everyone like this, and it's > very easy to prove you wrong, i personally know many competent > programmers who do NOT know this rule. I realize that I am in danger of using the No True Scotsman argument, but I think I'd have to question the "competent" assertion. It's rather like saying you know many competent carpenters who don't know how to use a biscuit joiner: while they may be decent carpenters, you'd have to ask how much carpentry they'd actually done. I would also suggest that a competent programmer would know what they don't know; when reading code they'd look it up, when writing code they'd insert parentheses for clarity. Andrew. http://en.wikipedia.org/wiki/No_true_scotsman
Re: RFH - Testing targets for the switch to C++
On 4/12/12 3:11 AM, Sebastian Huber wrote: Hello Diego, what is with targets that only use cross compilers like RTEMS? I think there is no need for a bootstrap? No. I'm mostly interested in the stage 0 compiler used in those targets. I want to decide what we should recommend as a minimum g++ version and/or vendor compiler version. Thanks. Diego.
Re: RFC: -Wall by default
On 4/12/12 6:23 AM, Dave Korn wrote: On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: How about a warning level? -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. Indeed. Diego.
Re: RFC: -Wall by default
On 4/12/2012 6:44 AM, Andrew Haley wrote: I would also suggest that a competent programmer would know what they don't know; when reading code they'd look it up, when writing code they'd insert parentheses for clarity. Yes, of course I 100% agree with that. But then by your definition code that does not have the "parentheses for clarity" is written by incompetent programmers, and it seems reasonable to have a warning that warns them of this incompetence :-)
Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)
Hi,
(Sorry for the delay.)
I suppose the proposed API doesn’t cover all the needs of your Python
bindings and their applications, does it? How do you plan to export the
GIMPLE and tree.h APIs?
Regarding iterators, there are things like:
GCC_IMPLEMENT_PUBLIC_API(bool)
gcc_cfg_for_each_block(gcc_cfg cfg,
bool (*cb)(gcc_cfg_block block, void *user_data),
void *user_data)
{
int i;
for (i = 0; i < cfg.inner->x_n_basic_blocks; i++) {
Instead of the callback API, could the details of the containers be
exposed a little more, like:
/* Return the number of basic blocks in CFG. */
unsigned int gcc_cfg_block_count (gcc_cfg cfg);
/* Return a pointer to the array of basic blocks in CFG. */
gcc_cfg_block *gcc_cfg_blocks (gcc_cfg cfg);
That would allow higher-level language bindings to provide idiomatic
ways to iterate over basic blocks, such as (lazy) list iterators.
WDYT?
Thanks,
Ludo’.
Re: RFC: -Wall by default
On 04/12/2012 02:03 PM, Robert Dewar wrote: > On 4/12/2012 6:44 AM, Andrew Haley wrote: > >> I would also suggest that a competent programmer would know what they >> don't know; when reading code they'd look it up, when writing code >> they'd insert parentheses for clarity. > > Yes, of course I 100% agree with that. But then by your definition > code that does not have the "parentheses for clarity" is written by > incompetent programmers, and it seems reasonable to have a warning > that warns them of this incompetence :-) Sorry for the confusion: I intended to write >> I would also suggest that your competent programmer would know what >> they don't know; when reading code they'd look it up, when writing >> code they'd insert parentheses for clarity. Using two different definitions of "competent programmer" without clarification makes me an incompetent writer, I suppose. :-) Andrew.
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 5:23 AM, Dave Korn wrote: > On 11/04/2012 09:50, Vincent Lefevre wrote: >> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: >>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: On 4/9/2012 1:36 PM, Jonathan Wakely wrote: > Maybe -Wstandard isn't the best name though, as "standard" usually > means something quite specific for compilers, and the warning switch > wouldn't have anything to do with standards conformance. -Wdefault might be better >>> except if people want warnings about "defaults" in C++11 (which can mean >>> lot of things). >> >> How about a warning level? >> >> -W0: no warnings (equivalent to -w) >> -W1: default >> -W2: equivalent to the current -Wall >> -W3: equivalent to the current -Wall -Wextra > > I like this suggestion a lot. > me, very not. :-( -- Gaby
Re: RFC: -Wall by default
On 4/12/2012 9:30 AM, Andrew Haley wrote: Sorry for the confusion: I intended to write I would also suggest that your competent programmer would know what they don't know; when reading code they'd look it up, when writing code they'd insert parentheses for clarity. Using two different definitions of "competent programmer" without clarification makes me an incompetent writer, I suppose. :-) Andrew. The correct thing to write definitely does NOT depend on the competence or otherwise of the writer. If putting in parentheses adds to clarity, then everyone should do it since you are writing code for other people to read, not yourself.
Re: RFC: -Wall by default
On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote: -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. Me too! I also like short switches, but gcc mostly favors long hard-to-type not-necessarily-easy-to-remember switch names.
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar wrote: > On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote: > -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra >>> >>> >>> I like this suggestion a lot. > > > Me too! > > I also like short switches, but gcc mostly favors long > hard-to-type not-necessarily-easy-to-remember switch > names. People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. Geodelization is great for machines, hardly so as human interface. -- Gaby
Re: RFC: -Wall by default
On 12/04/2012 15:43, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar wrote: >> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote: >> > -W0: no warnings (equivalent to -w) > -W1: default > -W2: equivalent to the current -Wall > -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. >> >> Me too! >> >> I also like short switches, but gcc mostly favors long >> hard-to-type not-necessarily-easy-to-remember switch >> names. > > People easily associates some ordering to numbers (usually > the greater the better or in this case the worse) which > creates another set of confusion. What's the problem? The greater the number, the more warnings you get. Simple. > Geodelization is great > for machines, hardly so as human interface. I don't think the incompleteness theorem is remotely relevant here. cheers, DaveK
Re: RFC: -Wall by default
On 04/12/2012 03:36 PM, Robert Dewar wrote: > On 4/12/2012 9:30 AM, Andrew Haley wrote: > I would also suggest that your competent programmer would know what they don't know; when reading code they'd look it up, when writing code they'd insert parentheses for clarity. >> >> Using two different definitions of "competent programmer" without >> clarification makes me an incompetent writer, I suppose. :-) > > The correct thing to write definitely does NOT depend on the > competence or otherwise of the writer. If putting in > parentheses adds to clarity, then everyone should do it > since you are writing code for other people to read, > not yourself. Certainly, everything that adds to clarity (and has no runtime costs!) is desirable. But adding parentheses may not add to clarity if doing so also obfuscates the code. There is a cost to the reader due to a blizzard of syntactically redundant parentheses; if there weren't, we wouldn't bother with operator precedence. Ultimately, it's a matter of taste and experience. I'm going to find it hard to write for people who don't know the relative precedence of & and | . Andrew.
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn wrote: > On 12/04/2012 15:43, Gabriel Dos Reis wrote: >> On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar wrote: >>> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote: >>> >> -W0: no warnings (equivalent to -w) >> -W1: default >> -W2: equivalent to the current -Wall >> -W3: equivalent to the current -Wall -Wextra > > I like this suggestion a lot. >>> >>> Me too! >>> >>> I also like short switches, but gcc mostly favors long >>> hard-to-type not-necessarily-easy-to-remember switch >>> names. >> >> People easily associates some ordering to numbers (usually >> the greater the better or in this case the worse) which >> creates another set of confusion. > > What's the problem? The greater the number, the more warnings you get. > Simple. Not necessarily. By contrast, -Wname suggest switch warning you could expect. Note also that "short" does not need to be a number. > >> Geodelization is great >> for machines, hardly so as human interface. > > I don't think the incompleteness theorem is remotely relevant here. It is the process, not the end end result. > > cheers, > DaveK > >
Re: RFC: -Wall by default
On 12/04/2012 15:55, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn wrote: >> On 12/04/2012 15:43, Gabriel Dos Reis wrote: >>> People easily associates some ordering to numbers (usually >>> the greater the better or in this case the worse) which >>> creates another set of confusion. >> What's the problem? The greater the number, the more warnings you get. >> Simple. > > Not necessarily. Your argument makes no sense. You said that there was a problem because people will expect numbered -W options to be ordinal. But they *are* ordinal. So people's expectations will be correct. You haven't said anything about where the problem is yet, you've just asserted that there will be one without demonstration or evidence, so again I ask: What's the problem? It works just fine for -O, users understand and are happy with that, why shouldn't it work just as well for -W? cheers, DaveK
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn wrote: > On 12/04/2012 15:55, Gabriel Dos Reis wrote: >> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn >> wrote: >>> On 12/04/2012 15:43, Gabriel Dos Reis wrote: > People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. > >>> What's the problem? The greater the number, the more warnings you get. >>> Simple. >> >> Not necessarily. > > Your argument makes no sense. Do you think that assertion makes sens when no evidence is provided to support it? > You said that there was a problem because > people will expect numbered -W options to be ordinal. What is nonsensical there? > But they *are* ordinal. Now? What is the order? > So people's expectations will be correct. You haven't said anything about > where the problem is yet, you've just asserted that there will be one without > demonstration or evidence, so again I ask: What's the problem? You said the greater the number the more warnings you get, but you did not show that would happen, so you have not shown that would necessarily happen. What is nonsensical there? > > It works just fine for -O, Exactly what happens with -O? -On does not necessarily generate faster or better code when n is higher. In fact, -Os is a perfect example of a short name that is NOT a number. > users understand and are happy with that, why > shouldn't it work just as well for -W? > > cheers, > DaveK >
Re: RFC: -Wall by default
On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote: What is nonsensical there? But they *are* ordinal. Now? What is the order? less warnings to more warnings, what could be more ordered than that! It works just fine for -O, Exactly what happens with -O? -On does not necessarily generate faster or better code when n is higher. -On means more optimizations for higher n, simple enough? In fact, -Os is a perfect example of a short name that is NOT a number. right, because -Os lies outside the more optimizations for higher values rule. I agree with Dave Korn, I do not understand your objection. I would understand an objection of the general kind that you prefer mnemonic names to numbers, but that ultimately is just that a preference, nothing more. You seem on the contrary to be trying to make a substantive argument against the digit scheme, but I can't understand it.
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 10:16 AM, Robert Dewar wrote: > On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote: > >> What is nonsensical there? >> >>> But they *are* ordinal. >> >> >> Now? What is the order? > > > less warnings to more warnings, what could be more > ordered than that! What exactly do you put in -Wn to make it give *more* warning? I can think of a reduced number of switch that would give you more warning on a specific program without them being terribly useful. > > >>> It works just fine for -O, >> >> >> Exactly what happens with -O? -On does not necessarily >> generate faster or better code when n is higher. > > -On means more optimizations for higher n, simple enough? like the traditional -O2 vs. -O3? > >> >> In fact, -Os is a perfect example of a short name that is NOT >> a number. > > right, because -Os lies outside the more optimizations for > higher values rule. because -Os says it optimizes for size, the expectation is clear. -O3 does not necessarily give better optimization than -O2. > I agree with Dave Korn, I do not understand your objection. I am objecting to the perceived benefits of the scheme and the false dubious analogy with -O. > > I would understand an objection of the general kind that you > prefer mnemonic names to numbers, but that ultimately is just > that a preference, nothing more. I would not be surprise if any contrary opinion to your preference isn't a preference :-) > You seem on the contrary to > be trying to make a substantive argument against the digit > scheme, but I can't understand it. I am puzzled by this.
Re: RFC: -Wall by default
On 12/04/2012 16:06, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn > wrote: >> On 12/04/2012 15:55, Gabriel Dos Reis wrote: >>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn >>> wrote: On 12/04/2012 15:43, Gabriel Dos Reis wrote: > People easily associates some ordering to numbers (usually > the greater the better or in this case the worse) which > creates another set of confusion. What's the problem? The greater the number, the more warnings you get. Simple. >>> Not necessarily. >> Your argument makes no sense. > > Do you think that assertion makes sens when no evidence is > provided to support it? My assertion was backed up by the sentences immediately after it, you can't just take it out of context and expect it to stand by yourself. Here's the evidence coming up right now: >> You said that there was a problem because >> people will expect numbered -W options to be ordinal. > > What is nonsensical there? Well stop interrupting and let me finish! The very next sentence points out what is nonsensical about your statement: >> But they *are* ordinal. > > Now? What is the order? Zero, then one, then two, then three. Are we having a language difficulty here? You can't really be asking me what the ordinal sequence of the integers is. >> So people's expectations will be correct. You haven't said anything about >> where the problem is yet, you've just asserted that there will be one without >> demonstration or evidence, so again I ask: What's the problem? > > You said the greater the number the more warnings you get, but you did not > show that would happen, so you have not shown that would necessarily happen. > What is nonsensical there? You appear to have forgotten what we're talking about, so let me remind you: > -W0: no warnings (equivalent to -w) > -W1: default > -W2: equivalent to the current -Wall > -W3: equivalent to the current -Wall -Wextra There will be more warnings the greater the number because that is how it was defined to work. The "default" will be the suggestion we've been discussing so far, i.e. effectively -Wall with a few of the less useful warnings removed. >> It works just fine for -O, > > Exactly what happens with -O? -On does not necessarily > generate faster or better code when n is higher. Exactly, just like how it would be with warnings. -On when n is higher uses more optimisations, some of which may be problematic - we're warned that -O3 may be unstable, and similarly -W3 may turn on warnings that are more of a hinderance than a help. cheers, DaveK
Re: RFC: -Wall by default
On 4/12/2012 10:48 AM, Andrew Haley wrote: Certainly, everything that adds to clarity (and has no runtime costs!) is desirable. But adding parentheses may not add to clarity if doing so also obfuscates the code. There is a cost to the reader due to a blizzard of syntactically redundant parentheses; if there weren't, we wouldn't bother with operator precedence. Well I think blizzard is overblown. Ada requires these parentheses and I never heard of anyone complaining of blizzards :-) Ultimately, it's a matter of taste and experience. I'm going to find it hard to write for people who don't know the relative precedence of & and | . Well it's always a problem for programmers who know too much to write code that can easily be read by everyone, in Ada we take the position that readability is paramount, and we really don't care if programmers find it harder to write readable code :-) Andrew.
Re: RFC: -Wall by default
On 4/12/2012 11:23 AM, Gabriel Dos Reis wrote: less warnings to more warnings, what could be more ordered than that! What exactly do you put in -Wn to make it give *more* warning? I can think of a reduced number of switch that would give you more warning on a specific program without them being terribly useful. It's JUST like the optimization case, you use a higher number to get more optimization. Yes, there may be cases where this hurts (we have seen cases where -O3 is slower than -O2 due to cache effects) For warnings you put a higher number to get more warnings. Yes, you may find that you get too many warnings and they are not useful. Remedy: reduce the number after -W :-) -On means more optimizations for higher n, simple enough? like the traditional -O2 vs. -O3? Right, -O3 does more optimziations than -O2. Of course there might be cases where this doesn't help. I bet if you look hard enough you will find cases where -O1 code is slower than -O0. For -O, we do not guarantee that a higher number means faster code, just that more optimizations are applied. for -W, we do not guarantee that a higher number means a more useful set of warnings, just more of them.
Re: RFC: -Wall by default
On 4/12/2012 10:48 AM, Andrew Haley wrote: Ultimately, it's a matter of taste and experience. I'm going to find it hard to write for people who don't know the relative precedence of & and | . There are probably some programmers who completely know ALL the operator precedence rules in C. There are probably some subset of those who feel free to write code that takes full advantage of these rules. I would hate to read code written by such people :-)
Re: RFH - Testing targets for the switch to C++
On 04/12/2012 02:32 PM, Diego Novillo wrote: On 4/12/12 3:11 AM, Sebastian Huber wrote: Hello Diego, what is with targets that only use cross compilers like RTEMS? I think there is no need for a bootstrap? No. I'm mostly interested in the stage 0 compiler used in those targets. I want to decide what we should recommend as a minimum g++ version and/or vendor compiler version. The *-rtems4* toolchains I supply for RTEMS currently are hosted on CentOS5+6, openSUSE 11.3+12.1, Fedora 15+16+17, mingw32 and cygwin, using these OSes' native toolchains. Other folks have reported to build these toolchains under different *BSDs and MacOSX variants. That said, in my understanding, the rtems targets entries on your table do not make much sense, because the limiting factor is the host-OS. From my list above, the oldest native compiler being in use are Cygwin's GCC-3.4.4 and CentOS5's gcc-4.1.2. Ralf
Re: RFC: -Wall by default
On 12 April 2012 16:33, Robert Dewar wrote: > > For warnings you put a higher number to get more warnings. Yes, > you may find that you get too many warnings and they are not > useful. Remedy: reduce the number after -W :-) It would even allow -Winf for the sometimes-requested-but-probably-not-actually-useful -Wreally-really-all that turns on *all* possible warnings. Or -Wover9000.
RE: FW: is "syslimits.h" likely to change?
Thank you Ian, hopefully I will be compatible then for a long time, as Larry Wall would say "at least until the heat death of the Universe". I can't "ignore it" :) My build system cannot handle "include_next" - it cannot handle the situation where you are finding a header file in one -I directory, and later when you are trying to find it again, you ignore that directory and find it in a subsequent -I directory. The system is extremely fast, like a sports car than will only go on asphalt (standard C and a GCC-like compiler). >I recommend that you simply ignore it in your build system.
Re: RFC: -Wall by default
On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote: > because -Os says it optimizes for size, the expectation is clear. > -O3 does not necessarily give better optimization than -O2. No, but it does mean that GCC turns on more optimization options. "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options. " Just like -W3 wouldn't necessarily generate more warnings on your code than -W1, perhaps because your code is already "clean" enough. It would simply be documented as: "-W3: Warn yet more. -W3 turns on all warnings specified by -W2 and also ...". I'll also note the parallel with -glevel, not just -O. So, 'gcc -glevel -Wlevel -Olevel' feels quite natural to me. -- Pedro Alves
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 10:24 AM, Dave Korn wrote: > On 12/04/2012 16:06, Gabriel Dos Reis wrote: >> On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn >> wrote: >>> On 12/04/2012 15:55, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn wrote: > On 12/04/2012 15:43, Gabriel Dos Reis wrote: >> People easily associates some ordering to numbers (usually >> the greater the better or in this case the worse) which >> creates another set of confusion. > What's the problem? The greater the number, the more warnings you get. > Simple. Not necessarily. >>> Your argument makes no sense. >> >> Do you think that assertion makes sens when no evidence is >> provided to support it? > > My assertion was backed up by the sentences immediately after it, you can't > just take it out of context and expect it to stand by yourself. Here's the > evidence coming up right now: > >>> You said that there was a problem because >>> people will expect numbered -W options to be ordinal. >> >> What is nonsensical there? > > Well stop interrupting and let me finish! The very next sentence points out > what is nonsensical about your statement: > >>> But they *are* ordinal. >> >> Now? What is the order? > > Zero, then one, then two, then three. Are we having a language difficulty > here? You can't really be asking me what the ordinal sequence of the > integers is. I keep talking about useful *warnings*, you keep talking about *numbers*. > >>> So people's expectations will be correct. You haven't said anything about >>> where the problem is yet, you've just asserted that there will be one >>> without >>> demonstration or evidence, so again I ask: What's the problem? >> >> You said the greater the number the more warnings you get, but you did not >> show that would happen, so you have not shown that would necessarily happen. >> What is nonsensical there? > > You appear to have forgotten what we're talking about, so let me remind you: I did not forget about it, if you had a doubt. >> -W0: no warnings (equivalent to -w) >> -W1: default >> -W2: equivalent to the current -Wall >> -W3: equivalent to the current -Wall -Wextra I have given up on touching -Wall in any menaingful way (either turning it on by default or moving warnings out of it, e.g. -Wununsed). Other useful warnings are left out of this scheme > > There will be more warnings the greater the number because that is how it > was defined to work. The "default" will be the suggestion we've been > discussing so far, i.e. effectively -Wall with a few of the less useful > warnings removed. > >>> It works just fine for -O, >> >> Exactly what happens with -O? -On does not necessarily >> generate faster or better code when n is higher. > > Exactly, just like how it would be with warnings. If you agree with that, then that is even more reason I am not convinced by the scheme. I would rather see a scheme that gives more useful warnings than just cranking up warnings, just any warning to get higher number. I suspect that is the real issue, not language issue. > -On when n is higher uses > more optimisations, some of which may be problematic - we're warned that -O3 > may be unstable, and similarly -W3 may turn on warnings that are more of a > hinderance than a help. yes, I am unkeen on repeating that. > > cheers, > DaveK > >
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 10:38 AM, Jonathan Wakely wrote: > On 12 April 2012 16:33, Robert Dewar wrote: >> >> For warnings you put a higher number to get more warnings. Yes, >> you may find that you get too many warnings and they are not >> useful. Remedy: reduce the number after -W :-) > > It would even allow -Winf for the > sometimes-requested-but-probably-not-actually-useful > -Wreally-really-all that turns on *all* possible warnings. Or > -Wover9000. Do we have bugzilla entry for that? -- Gaby
Re: Switching to C++ by default in 4.8
Hi, Basile Starynkevitch skribis: > My feeling is that the plugin ability of GCC should help academia to work > more on (that > is, "inside") GCC, to only to use GCC. Yes, except that, on one hand, they have a library stack with stable APIs, and on the other, an otherwise quite stable API that GCC hackers say “should not be used” by plug-ins. This, together with LLVM being in fashion, tends to push “academia” away from GCC, I think. Thanks, Ludo’.
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 10:43 AM, Pedro Alves wrote: > On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote: > >> because -Os says it optimizes for size, the expectation is clear. >> -O3 does not necessarily give better optimization than -O2. > > > No, but it does mean that GCC turns on more optimization options. > > "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also > turns on the -finline-functions, > -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, > -ftree-vectorize and -fipa-cp-clone options. " I think we have perverted the meaning of "optimize yet more", and optimize yet more does not yield better/faster code :-) Yes, I understand the transformations; that does not justify for the awkward user-interface. > > Just like -W3 wouldn't necessarily generate more warnings on > your code than -W1, perhaps because your code is > already "clean" enough. It would simply be documented as: > > "-W3: Warn yet more. -W3 turns on all warnings specified by -W2 and also > ...". > > I'll also note the parallel with -glevel, not just -O. > > So, 'gcc -glevel -Wlevel -Olevel' feels quite natural to me. > > -- > Pedro Alves
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 10:49 AM, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 10:38 AM, Jonathan Wakely > wrote: >> On 12 April 2012 16:33, Robert Dewar wrote: >>> >>> For warnings you put a higher number to get more warnings. Yes, >>> you may find that you get too many warnings and they are not >>> useful. Remedy: reduce the number after -W :-) >> >> It would even allow -Winf for the >> sometimes-requested-but-probably-not-actually-useful >> -Wreally-really-all that turns on *all* possible warnings. Or >> -Wover9000. > > Do we have bugzilla entry for that? > -- Gaby I forgot the remark about -Wover9000: for many GCC users (that I eye-witnessed), not only -On is supposed to optimize more, but n can go beyond 99 and it will give you better code than 9 or 3. One can argue they should be reading the manual, but that is the whole point: many of them don't read the manual; they look at a switch name and draw inference from there. There is little ambiguity left by -Wreally-all-of-them-damn-it :-)
Re: RFC: -Wall by default
On 04/12/2012 04:52 PM, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 10:43 AM, Pedro Alves wrote: >> On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote: >> >>> because -Os says it optimizes for size, the expectation is clear. >>> -O3 does not necessarily give better optimization than -O2. >> >> >> No, but it does mean that GCC turns on more optimization options. >> >> "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also >> turns on the -finline-functions, >> -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, >> -ftree-vectorize and -fipa-cp-clone options. " > > I think we have perverted the meaning of "optimize yet more", and optimize > yet more does not yield better/faster code :-) Sure, so that phrase in the documentation could be improved/replaced, or even removed. The rest of the paragraph looks quite clear enough. > Yes, I understand the transformations; that does not justify for the awkward > user-interface. So stop thinking in terms of -O, if it helps. Maybe think in terms of -glevel? "Request debugging information and also use level to specify how much information. The default level is 2." or just consider it on its own merits: -W0 no warning options enabled. -W1, more warning options enabled than -W0. -W2, more warning options enabled than -W1. -WN, more warning options enabled than -WN-1. I fail to see why is that awkward? -- Pedro Alves
Ann: MELT plugin release 0.9.5 for GCC 4.6 & 4.7
Hello All
It is my pleasure to announce the MELT plugin release 0.9.5 for GCC 4.6 & 4.7
MELT is a high-level domain specific language to extend GCC (the Gnu Compiler
Collection).
See http://gcc-melt.org/ for more.
The MELT plugin 0.9.5 (for GCC 4.6 & 4.7) is available from
http://gcc-melt.org/melt-0.9.5-plugin-for-gcc-4.6-or-4.7.tar.gz
it is a gzipped tar archive of 4502575 bytes and md5sum
b5a0ea2a022b4283120c50dbd6eff93d
MELT is free software (GPLv3+ licensed, FSF copyrighted).
NEWS for 0.9.5 MELT plugin for GCC 4.6 & 4.7
[[April 12th 2012]]
Language improvements
=
Alternative infix syntax is abandoned (it was never implemented)
Accept $(sub sepxr) in macro-string and $[seq sepxr]
Runtime improvements
Handle SIGIO Unix signals with asynchronous input channels
(experimental feature)
Can be compiled by C++ (since GCC 4.7 often is)
All the values are translated to melt_ptr_t variables, not void*
ones.
Library improvements
Much more matchers, and much more generated documentation, to interface to
GCC internal stuff in xtramelt-ana-base.melt
###
Comments, patches, bug reports, feature requests, suggestions, improvements are
welcome on
gcc-m...@googlegroups.com (or on gcc@gcc.gnu.org if subject contains [MELT])
Thanks to Alexandre Lissy for last minute bug reports.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: RFH - Testing targets for the switch to C++
On 4/12/12 11:34 AM, Ralf Corsepius wrote: The *-rtems4* toolchains I supply for RTEMS currently are hosted on CentOS5+6, openSUSE 11.3+12.1, Fedora 15+16+17, mingw32 and cygwin, using these OSes' native toolchains. Other folks have reported to build these toolchains under different *BSDs and MacOSX variants. That said, in my understanding, the rtems targets entries on your table do not make much sense, because the limiting factor is the host-OS. From my list above, the oldest native compiler being in use are Cygwin's GCC-3.4.4 and CentOS5's gcc-4.1.2. Thanks. I've coalesced the rtems entries into one and added this data in the notes. Diego.
Re: RFC: -Wall by default
Robert Dewar escreveu: > On 4/12/2012 10:48 AM, Andrew Haley wrote: > >> Ultimately, it's a matter of taste and experience. I'm going to find >> it hard to write for people who don't know the relative precedence of >> & and | . > > There are probably some programmers who completely know ALL the operator > precedence rules in C. There are probably some subset of those who feel > free to write code that takes full advantage of these rules. I would > hate to read code written by such people :-) I know the different precedences (well I some/most times get confused with the order of some because I almost always use parenthesis). I prefer to think of && and || with same, left to right precedence. There are people that require (a)?(b):(c) to be in parenthesis because they find the precedence rules confusing. And there are all the extra parenthesis added to avoid surprises after macro expansion, but people usually do not read macro expansions :-) Paulo
RE: GSoC proposal: Provide optimizations feedback through post-compilation messages
Quite lengthy but very interesting mail! It took me a while to formulate a proper reply :) > Feedback can be scarce, but don't let that stop you from submitting a > proposal. > Either way, can you keep me informed about any progress? I might wish to help > though that would probably be later in the cycle (got a lot queued up for > the comming months). Submitted :) The reviews are not too positive yet, my biggest efforts go into making my plan clear. If any progress, help will be very appreciable indeed. > Great that's exactly what I'm aiming at:) It's not just presenting the > results of static analysis in real-time, as I actually dislike most > kinds of it like finding memory leaks, to me that seems like an attempt > to make the computer do what it's really bad at (understanding the > code). I just want to give the programmer the fullest picture of the > situation but at the same time make it so it doesn't become noise that > interferes. More or less you can say the goal is "To provide feedback > that allows the user to extend his understanding of the program". That > mostly means giving access to all the information that can be > unambiguously concluded from the code by the computer. To what degree > we carry it and how much the compiler is involved is only a question of > practicality and performance. I quite agree for the most part, still there is a subtle nuance on which I want to argue: Do we really help the programmer by offering all the valuable information that is possible to infer? Ten years from now, would he/she be a better programmer if we had not let him/her strive to simulate the program in mind, or code a portion in assembly and finally learn about machine architecture? My point is to avoid creating an interface that "assists" of "helps" the programmer, as he/she might become dependent on it. This is just helping in the short term, and the only person who ever learns something is the one who actually creates the compiler. If a statement could sum my view, it would be that "the user improves through his/her use of the interface" (here the feedback messages). How does it make a difference in practice? I want to minimize the information given :) The reason I want to introduce feedback messages is that this particular information (the inner workings of compilers) is very hard to find in practice. I want to give a slight help to put the user on the rails, nothing more. > Perfect! However, how to do that so that it actually works seems a bit > complex. The first (practically unsolvable) issue is what actually > constitutes better code, as given two pieces one may be faster in some > cirtumstances while the other in different. But as I understand that's > not really what we're trying to tell the user, rather we want him to > explore for himself what's possible and what are the results and why > they are the way they are? I'm guessing this will unfortunately (or > fortunately) require him to actually see and undestand the intermediate > code, see how it changes after different optimizations, and see the > output assembly. Personally I really need/want that;) Though my end > target is a bit more to "broaden" the abstraction when programming > (both up and down), so not to just show what's happening with the code > but also allow the programmer to interact with it on that lower level. > LLVM seems like the perfect fit for that but I've got some gripes with > it, and that is still far away in the future. Excellent! Letting the user explore by himself sounds great, and seing the output assembly/IR besides is indeed a must. I like the idea that compilation is a cooperation between programmer and machine (as far as the programmer is inclined to help of course). It would also be nice to see compilation be split at Value range propagation, as one could verify it is properly computed, before proceeding into optimizations. > Unfortunately I only saw 36m of it as it broke and seeking doesn't work > on vimeo for me, so I'll watch the rest later. To me it touches on some > of the right issues/concepts but in slightly the wrong way, and it > completely ignores some issues. Agreed. (Only the first half of the video is relevant for the programming prototype) Thibault
Wiki slowness
Why does saving/editing a page on the GCC wiki take several minutes to reload the page? Opening the page in a new tab shows the changes have been saved, but the page still keeps loading. Is there some kind of re-indexing going on which is incredibly inefficient? Or does the moinmoinwiki code simply not close the TCP connection or something silly like that?
Re: Wiki slowness
On 12 April 2012 19:53, Jonathan Wakely wrote: > Why does saving/editing a page on the GCC wiki take several minutes to > reload the page? By several I mean in excess of ten minutes where my browser is still spinning saying the page is loading! > Opening the page in a new tab shows the changes have been saved, but > the page still keeps loading. Is there some kind of re-indexing going > on which is incredibly inefficient? Or does the moinmoinwiki code > simply not close the TCP connection or something silly like that?
Re: Wiki slowness
On 4/12/12 3:00 PM, Jonathan Wakely wrote: On 12 April 2012 19:53, Jonathan Wakely wrote: Why does saving/editing a page on the GCC wiki take several minutes to reload the page? By several I mean in excess of ten minutes where my browser is still spinning saying the page is loading! Yes. I've noticed this for a long time now. I never really bothered figuring out why. My trick is to cancel the transfer and click 'save' again. It then comes back with the message 'you already saved this page!'. Which I ignore. Diego.
Re: Switching to C++ by default in 4.8
> "Diego" == Diego Novillo writes: Diego> Tom, I'm thinking of that patch on black listing functions. There was Diego> also the idea of a command that would only step in the outermost Diego> function call of an expression. That patch went in. The new command is called "skip". I don't think anybody has worked on stepping into just the outermost function call of an expression. Tom
Re: Switching to C++ by default in 4.8
On 4/12/12 3:40 PM, Tom Tromey wrote: "Diego" == Diego Novillo writes: Diego> Tom, I'm thinking of that patch on black listing functions. There was Diego> also the idea of a command that would only step in the outermost Diego> function call of an expression. That patch went in. The new command is called "skip". Nice! What version of gdb has this support? I don't think anybody has worked on stepping into just the outermost function call of an expression. I think we can workaround most issues with 'skip'. Thanks. Diego.
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On 12 April 2012 11:41, Jonathan Wakely wrote: > Two more examples, then I'll save it for a wiki page instead of the > mailing list: And here it is: http://gcc.gnu.org/wiki/ClangDiagnosticsComparison
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On Thu, Apr 12, 2012 at 2:43 PM, Jonathan Wakely wrote: > On 12 April 2012 11:41, Jonathan Wakely wrote: >> Two more examples, then I'll save it for a wiki page instead of the >> mailing list: > > And here it is: > > http://gcc.gnu.org/wiki/ClangDiagnosticsComparison Thanks; this is useful. -- Gaby
Re: Switching to C++ by default in 4.8
> "Diego" == Diego Novillo writes: Diego> Nice! What version of gdb has this support? 7.4. Tom
Re: RFC: -Wall by default
On 12/04/2012 17:03, Gabriel Dos Reis wrote: > There is > little ambiguity left by -Wreally-all-of-them-damn-it :-) Actually, no, as anyone could tell you who before they discovered version control used to have lots of files lying around called "foo.final.c", "foo.final.reallyfinal.c", "foo.final.updated.reallyfinalthistime.c", and so on; in other words, I think that after a few years have passed, we would find that we've been persuaded to add -Wreally-really-all-of-them-damn-it, -Wreally-really-all-no-actually-all-including-everything, and -Wreally-really-all-of-them-damn-it-no-i-really-did-mean-all-of-them-even-including-the-really-unexpected-ones. There's nothing more ambiguous than saying that something is final in a world where perfection is never achieved. That's why software has monotonically increasing version numbers, instead of just one that means "this is done now". cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 16:47, Gabriel Dos Reis wrote: > I keep talking about useful *warnings*, you keep talking about *numbers*. No you don't. You said: >>> People easily associates some ordering to numbers (usually >>> the greater the better or in this case the worse) which >>> creates another set of confusion. That is talking about numbers. I'm not going to bother reading the rest of your email, you're just being argumentative and misunderstanding on purpose. DaveK.
Re: RFC: -Wall by default
On 12 April 2012 16:49, Gabriel Dos Reis wrote: >> It would even allow -Winf for the >> sometimes-requested-but-probably-not-actually-useful >> -Wreally-really-all that turns on *all* possible warnings. Or >> -Wover9000. > > Do we have bugzilla entry for that? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and its dup. I thought I remembered another one with a subject like "-Wall isn't" but I can't find it now.
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
Thanks for preparing the wiki page. I have looked at the examples from
this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf
with trunk gcc. In some cases, gcc's warning matches that of clang but
in majority of cases, gcc either emits no warnings or worse ones. The
warnings in the comments are from clang. One possible advantage of
clang is that adding new warnings is relatively easier.
Another side note. This slide mentioned two things: 1) thread-safety
static check; 2) compiler based dynamic check. The first one was first
introduced in a gcc branch but never made into the mainline, but now
it is getting into Clang. 2) Gcc work on dynamic check was also done
partially, but not made into trunk either.
Gcc command line option: -fsyntax-only -Wall -std=c++11
thanks,
David
Example 1: Gcc produces nothing even with -Warray-bounds
int foo() {
int arr[100];
// ...
return arr[100];
}
/*
array.cpp:4:10: warning: array index 100 is past the end of the array
(which contains 100 elements) [-Warray-bounds]
return arr[100];
^ ~~~
array.cpp:2:3: note: array 'arr' declared here
int arr[100];
^
1 warning generated.
*/
Example 2: gcc produces nothing even with -Warray-bounds
constexpr int arr_size = 42;
constexpr int N = 44;
void f(int);
int test() {
int arr[arr_size];
// ...
f(arr[N]);
// ...
if (N < arr_size) return arr[N];
return 0;
}
/*
deadcode.cpp:7:5: warning: array index 44 is past the end of the array
(which contains 42 elements) [-Warray-bounds]
f(arr[N]);
^ ~
deadcode.cpp:5:3: note: array 'arr' declared here
int arr[arr_size];
^
1 warning generated.
*/
Example 3: nothing from gcc:
---
#include
struct S { int a, b, c; float vec[16]; };
void test(S *s) {
// ...
memset(s, 0, sizeof(s));
// ...
}
/*
memset.cpp:5:23: warning: argument to 'sizeof' in 'memset' call is the
same expression as the destination; did you mean to dereference it? [-
Wsizeof-pointer-memaccess]
memset(s, 0, sizeof(s));
~^
1 warning generated.
*/
Example 4: Nothing from gcc:
static const long long
DiskCacheSize = 8 << 30; // 8 Gigs
/*
overflow.cpp:1:42: warning: signed shift result (0x2) requires 35
bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
static const long long DiskCacheSize = 8 << 30; // 8 Gigs
~ ^ ~~
1 warning generated.
*/
Example 5: More suggestions from clang --> suggesting changing = to ==
-
void foo();
void bar();
void test(int i) {
// ...
if (i = 42) foo();
else bar();
}
/*
parentheses1.cpp:5:9: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
if (i = 42) foo();
~~^~~~
parentheses1.cpp:5:9: note: place parentheses around the assignment to
silence this warning
if (i = 42) foo();
^
( )
parentheses1.cpp:5:9: note: use '==' to turn this assignment into an
equality comparison
if (i = 42) foo();
^
==
1 warning generated.
*/
Example 6: Nothing from gcc
---
int get();
void test() {
int i = get();
// ...
if ((i == get())) {
// ...
}
}
/*
parentheses2.cpp:5:10: warning: equality comparison with extraneous
parentheses [-Wparentheses-equality]
if ((i == get())) {
~~^~~~
parentheses2.cpp:5:10: note: remove extraneous parentheses around the
comparison to silence this warning
if ((i == get())) {
~ ^ ~
parentheses2.cpp:5:10: note: use '=' to turn this equality comparison
into an assignment
if ((i == get())) {
^~
=
1 warning generated.
*/
Example 7: Nothing from gcc
int test(bool b, int x, int y) {
return 42 + b ? x : y;
}
/*
parentheses4.cpp:2:17: warning: operator '?:' has lower precedence than
'+'; '+' will be evaluated first [-Wparentheses]
return 42 + b ? x : y;
~~ ^
parentheses4.cpp:2:17: note: place parentheses around the '+' expression
to silence this warning
return 42 + b ? x : y;
^
( )
parentheses4.cpp:2:17: note: place parentheses around the '?:' expression
to evaluate it first
return 42 + b ? x : y;
^
()
1 warning generated.
*/
Example 8: No useful suggestions for corrections from gcc:
-
struct BaseType {};
struct DerivedType : public BaseType {
static int base_type;
DerivedType() : basetype() {}
};
/*
typo1.cpp:4:19: error: initializer 'basetype' doe
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 3:56 PM, Dave Korn wrote: > On 12/04/2012 17:03, Gabriel Dos Reis wrote: >> There is >> little ambiguity left by -Wreally-all-of-them-damn-it :-) > > Actually, no, as anyone could tell you who before they discovered version > control used to have lots of files lying around called "foo.final.c", > "foo.final.reallyfinal.c", "foo.final.updated.reallyfinalthistime.c", and so > on; in other words, I think that after a few years have passed, we would find > that we've been persuaded to add -Wreally-really-all-of-them-damn-it, > -Wreally-really-all-no-actually-all-including-everything, and > -Wreally-really-all-of-them-damn-it-no-i-really-did-mean-all-of-them-even-including-the-really-unexpected-ones. But we are no longer in the era that forms the basis of your analogy :-) > > There's nothing more ambiguous than saying that something is final in a > world where perfection is never achieved. That's why software has > monotonically increasing version numbers, instead of just one that means "this > is done now". As I observed earlier, Geodelization is great for machines. -- Gaby
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote: > On 12/04/2012 16:47, Gabriel Dos Reis wrote: > >> I keep talking about useful *warnings*, you keep talking about *numbers*. > > No you don't. You said: > People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. > > That is talking about numbers. And you were complaining about your comments being taken out of context? > I'm not going to bother reading the rest of > your email, you're just being argumentative and misunderstanding on purpose. > > DaveK. >
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 4:30 PM, Jonathan Wakely wrote: > On 12 April 2012 16:49, Gabriel Dos Reis wrote: >>> It would even allow -Winf for the >>> sometimes-requested-but-probably-not-actually-useful >>> -Wreally-really-all that turns on *all* possible warnings. Or >>> -Wover9000. >> >> Do we have bugzilla entry for that? > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and its dup. > > I thought I remembered another one with a subject like "-Wall isn't" > but I can't find it now. Thank you, -- Gaby
Re: RFC: -Wall by default
On 4/12/2012 5:35 PM, Gabriel Dos Reis wrote: There's nothing more ambiguous than saying that something is final in a world where perfection is never achieved. That's why software has monotonically increasing version numbers, instead of just one that means "this is done now". As I observed earlier, Geodelization is great for machines. You observed this before, but it was nonsense then and nonsense now, this has nothing to do with incompleteness! -- Gaby
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 4:38 PM, Robert Dewar wrote: > On 4/12/2012 5:35 PM, Gabriel Dos Reis wrote: > >>> There's nothing more ambiguous than saying that something is final in a >>> world where perfection is never achieved. That's why software has >>> monotonically increasing version numbers, instead of just one that means >>> "this >>> is done now". >> >> >> As I observed earlier, Geodelization is great for machines. > > > You observed this before, but it was nonsense then It isn't non-sense just because you decide so or you don't like the observation. > and > nonsense now, this has nothing to do with incompleteness! >> >> >> -- Gaby > >
Re: RFC: -Wall by default
On 4/12/2012 5:40 PM, Gabriel Dos Reis wrote: It isn't non-sense just because you decide so or you don't like the observation. and nonsense now, this has nothing to do with incompleteness! I think you don't know what incompleteness is about, yes, it is nonsense, because no one can make any sense out of it except you and you refuse to elaborate or explain beyond just repeating the observation. Feel free to explain. -- Gaby
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 4:42 PM, Robert Dewar wrote: > On 4/12/2012 5:40 PM, Gabriel Dos Reis wrote: > >> It isn't non-sense just because you decide so or you don't like the >> observation. >> >>> and >>> nonsense now, this has nothing to do with incompleteness! > > > I think you don't know what incompleteness is about, yes, it is Do not allow yourself to be easily confused by misunderstanding of Geodelization, a *process* of assigning numbers to entities http://demonstrations.wolfram.com/Goedelization/ http://en.wikipedia.org/wiki/Turing%27s_proof and make statement only in terms of those numbers and the incompleteness theorems themselves, lest you might give the impression that you do not know what you are talking about and all you need as evidence of target of your message is to look in mirror. -- Gaby > nonsense, because no one can make any sense out of it except you > and you refuse to elaborate or explain beyond just repeating > the observation. Feel free to explain. -- Gaby >>> >>> >>> >
Re: Updated GCC vs Clang diagnostics
Hi Jonathan, I think the wiki page is a great idea! Thanks for doing this. I am planning to open PRs for all the issues where GCC is worse. I think it would be nice to have even more examples where GCC is better. Examples where GCC is worse can be added to http://gcc.gnu.org/wiki/Better_Diagnostics About automatic macro expansion, actually Clang does not expand macros, they simply track macro locations. GCC can do this right now with -ftrack-macro-expansion, which hopefully will be enabled by default in GCC 4.8 thanks to Dodji's work. And I have a very simple patch that shows the caret for those macro expansions, so the output is the same (except colors and ranges). Then, there are three obvious differences between GCC's and Clang's diagnostics shown int that page: color, ranges and fix-it hints. * The diagnostics support to print a range given two locations is trivial to implement. However, modifying the location machinery so it tracks ranges seems much more complex (and deciding which range to choose in each diagnostic is a lot of work, because there are a lot of diagnostics). * Implementing color is trivial and there are reference implementations in GNU grep and GNU make. It would be much more reliable than parsing the output of GCC. Specially with caret diagnostics. * Fix-it hints would also be quite trivial to implement, but it would be a lot of work to decide which diagnostics should use it, and how. Of course, the major question is: Are the decision makers in GCC interested on any of this? Would some reviewer reject patches implementing them? Are there any conditions attached to the implementation that would be good to know beforehand? Cheers, Manuel.
Re: RFC: -Wall by default
End of thread for me, remove me from the reply lists, thanks discussion is going nowhere, at this stage my vote is for no change whatever in the way warnings are handled.
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On 12 April 2012 22:32, Xinliang David Li wrote: > Thanks for preparing the wiki page. I have looked at the examples from > this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf > with trunk gcc. In some cases, gcc's warning matches that of clang but > in majority of cases, gcc either emits no warnings or worse ones. The > warnings in the comments are from clang. One possible advantage of > clang is that adding new warnings is relatively easier. Noone will add them to GCC unless someone requests them. You're in the process of creating bugzilla reports for those issues, right?
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
yes .. thanks, David On Thu, Apr 12, 2012 at 2:51 PM, Jonathan Wakely wrote: > On 12 April 2012 22:32, Xinliang David Li wrote: >> Thanks for preparing the wiki page. I have looked at the examples from >> this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf >> with trunk gcc. In some cases, gcc's warning matches that of clang but >> in majority of cases, gcc either emits no warnings or worse ones. The >> warnings in the comments are from clang. One possible advantage of >> clang is that adding new warnings is relatively easier. > > Noone will add them to GCC unless someone requests them. You're in > the process of creating bugzilla reports for those issues, right?
Re: Updated GCC vs Clang diagnostics
On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez wrote: > Hi Jonathan, >[] > Of course, the major question is: Are the decision makers in GCC > interested on any of this? > > Would some reviewer reject patches implementing them? I suspect decisions will be based on the implementations themselves. > Are there any conditions attached to the implementation that would be > good to know beforehand? The devils are in the details. -- Gaby
Re: Updated GCC vs Clang diagnostics
On 12 April 2012 23:54, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez > wrote: >> Hi Jonathan, >>[] >> Of course, the major question is: Are the decision makers in GCC >> interested on any of this? >> >> Would some reviewer reject patches implementing them? > > I suspect decisions will be based on the implementations themselves. > So given your ideal implementation, if the user-visible result was exactly like the one in Clang, will you be happy with any of the three things: ranges, color and fix-it hints? Or you will prefer to never have some of them or to have them disabled by default? Or to have them, but in a different (user-visible) manner? Cheers, Manuel.
Re: Updated GCC vs Clang diagnostics
On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez wrote: > On 12 April 2012 23:54, Gabriel Dos Reis > wrote: >> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez >> wrote: >>> Hi Jonathan, >>>[] >>> Of course, the major question is: Are the decision makers in GCC >>> interested on any of this? >>> >>> Would some reviewer reject patches implementing them? >> >> I suspect decisions will be based on the implementations themselves. >> > > So given your ideal implementation, if the user-visible result was > exactly like the one in Clang, will you be happy with any of the three > things: ranges, color and fix-it hints? My ideal isn't to replicate Clang :-) I would like us to set a standard that Clang would have to follow :-) There are several things that need to be considered. The three items above are choices in the toolset. Ideally, I would like to have a mechanism where the output could be configured (through a command line switch, etc) that allows for example IDEs (not just GNU Emacs) to hook into databases of advices, standard definitions, etc. Even for our own testsuites, this might be useful instead of the current one-dimensional char sequence oriented diagnostic testing. > > Or you will prefer to never have some of them or to have them disabled > by default? > > Or to have them, but in a different (user-visible) manner? I suspect to some degree this is closer to I would like to see, but again, I would prefer to make a judgment based on an implementation. -- Gaby
Re: Updated GCC vs Clang diagnostics
On 4/12/12, Manuel López-Ibáñez wrote: > So given your ideal implementation, if the user-visible result > was exactly like the one in Clang, will you be happy with any of > the three things: ranges, color and fix-it hints? There are many issues with color. Does your reader have any color deficiencies? Does your software address them? Does the system software render colors well? Is color contrast sufficient? Is greyscale contrast sufficient? Color is low on my list of desirables. > Or you will prefer to never have some of them or to have them > disabled by default? The first thing I do is turn off colors in /bin/ls because there are actually too few readable color combinations to be very usable. So, I want to have the ability to turn warning colors off. > Or to have them, but in a different (user-visible) manner? This question is hard to answer because I don't know all manners. -- Lawrence Crowl
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On 12 April 2012 22:53, Xinliang David Li wrote: > yes .. Excellent, thanks, and thanks for the link to the pdf, I hadn't seen it before and GCC does do pretty poorly with those examples. > thanks, > > David > > On Thu, Apr 12, 2012 at 2:51 PM, Jonathan Wakely > wrote: >> On 12 April 2012 22:32, Xinliang David Li wrote: >>> Thanks for preparing the wiki page. I have looked at the examples from >>> this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf >>> with trunk gcc. In some cases, gcc's warning matches that of clang but >>> in majority of cases, gcc either emits no warnings or worse ones. The >>> warnings in the comments are from clang. One possible advantage of >>> clang is that adding new warnings is relatively easier. >> >> Noone will add them to GCC unless someone requests them. You're in >> the process of creating bugzilla reports for those issues, right?
Re: Updated GCC vs Clang diagnostics [Was: Switching to C++ by default in 4.8]
On Thu, Apr 12, 2012 at 3:28 PM, Jonathan Wakely wrote: > On 12 April 2012 22:53, Xinliang David Li wrote: >> yes .. > > Excellent, thanks, and thanks for the link to the pdf, I hadn't seen > it before and GCC does do pretty poorly with those examples. The talk was given pretty recently .. David > > >> thanks, >> >> David >> >> On Thu, Apr 12, 2012 at 2:51 PM, Jonathan Wakely >> wrote: >>> On 12 April 2012 22:32, Xinliang David Li wrote: Thanks for preparing the wiki page. I have looked at the examples from this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf with trunk gcc. In some cases, gcc's warning matches that of clang but in majority of cases, gcc either emits no warnings or worse ones. The warnings in the comments are from clang. One possible advantage of clang is that adding new warnings is relatively easier. >>> >>> Noone will add them to GCC unless someone requests them. You're in >>> the process of creating bugzilla reports for those issues, right?
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 00:17, Gabriel Dos Reis wrote: > On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez > wrote: >> On 12 April 2012 23:54, Gabriel Dos Reis >> wrote: >>> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez >>> wrote: Hi Jonathan, [] Of course, the major question is: Are the decision makers in GCC interested on any of this? Would some reviewer reject patches implementing them? >>> >>> I suspect decisions will be based on the implementations themselves. >>> >> >> So given your ideal implementation, if the user-visible result was >> exactly like the one in Clang, will you be happy with any of the three >> things: ranges, color and fix-it hints? > > My ideal isn't to replicate Clang :-) > > I would like us to set a standard that Clang would have to follow :-) > There are several things that need to be considered. > The three items above are choices in the toolset. Ideally, I would > like to have a mechanism where the output could be configured > (through a command line switch, etc) that allows for example IDEs > (not just GNU Emacs) to hook into databases of advices, standard > definitions, etc. Even for our own testsuites, this might be useful > instead of the current one-dimensional char sequence > oriented diagnostic testing. That sounds nice. Are you working on this on a branch? I hope you manage to finish it for GCC 4.8. I would like to have color output. And since nobody is paying me to do this work, I'd rather work on what I would like to have. The question is whether this is something that GCC wants to have. If the answer is NO, that is fine, I will have more free time. If the answer is yes but the implementation has to autodetect low contrast settings / read colors from a configuration file / allow users to input colors in their own language, then thanks but no thanks, I'll choose my free time. If it is ok that the implementation works like grep's, then I may try to find some free time to give it a try, since the probability that some new contributor will implement it instead of just using Clang gets closer to zero as time goes by. Cheers, Manuel.
gcc-4.5-20120412 is now available
Snapshot gcc-4.5-20120412 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120412/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 186398 You'll find: gcc-4.5-20120412.tar.bz2 Complete GCC MD5=4b72cd056f646bf29c075e095ca48847 SHA1=40c3e8acd9d5a781735061a57fd4109e2d6e68fd Diffs from 4.5-20120405 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: Switch statement case range
I was wondering if anyone had a response to this? No one responded on- or off-list, which was both surprising and confusing. Thanks! :-) Best regards, Rick C. Hodgin --- On Sun, 4/8/12, Rick Hodgin wrote: > From: Rick Hodgin > > ...I think [GCC] is, without a doubt, the best GNU > project in history. > > Has there ever been any talk of nominating Richard Stallman > for the Nobel Peace Prize (seriously)? > > Best regards, > Rick C. Hodgin
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 12:42:19AM +0200, Manuel López-Ibáñez wrote: > I would like to have color output. And since nobody is paying me to do > this work, I'd rather work on what I would like to have. The question > is whether this is something that GCC wants to have. > > If the answer is NO, that is fine, I will have more free time. I'm not interested in color output, and would turn it off if it were implemented (the escape sequences would just mess things up when capturing compiler output in log files). Clang is much smarter about identifying what the user probably meant when the issue is a typo, or "." instead of "->" or vice versa. Getting GCC to do at least as well in this area is a much better use of developers' time than presenting a cascade of unintelligible messages resulting from template expansion in full color. That said, you're free to work on what interests you.
Re: Updated GCC vs Clang diagnostics
On 13 April 2012 03:40, Joe Buck wrote: > On Fri, Apr 13, 2012 at 12:42:19AM +0200, Manuel López-Ibáñez wrote: >> I would like to have color output. And since nobody is paying me to do >> this work, I'd rather work on what I would like to have. The question >> is whether this is something that GCC wants to have. >> >> If the answer is NO, that is fine, I will have more free time. > > I'm not interested in color output, and would turn it off if it were > implemented (the escape sequences would just mess things up when capturing > compiler output in log files). My proposal is to follow grep, that is, --color=[never|auto|always]. With auto, color would only be printed when isatty() is true. The default could be auto, or never if some people are very much against it. > Clang is much smarter about identifying what the user probably meant when > the issue is a typo, or "." instead of "->" or vice versa. Getting GCC to > do at least as well in this area is a much better use of developers' time > than presenting a cascade of unintelligible messages resulting from > template expansion in full color. > > That said, you're free to work on what interests you. Yes, there is plenty of things that could be fixed in GCC. And I have fixed my fair share of bugs that don't actually affect me at all, for free, on my free time. I find the color output of Clang just beautiful and, in my opinion, color support in GCC would make it a bit more beautiful and attract new users, so it is a much better use of developer's time than fixing yet another obscure diagnostic issue that only triggers with a careful ad-hoc example. That said, I do really think you are free to work on what interests you, so I hope to see your patches fixing diagnostics issues soon. Cheers, Manuel.
Re: Updated GCC vs Clang diagnostics
On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez wrote: > I find the color output of Clang just beautiful and, in my opinion, > color support in GCC would make it a bit more beautiful and attract > new users, so it is a much better use of developer's time than fixing > yet another obscure diagnostic issue that only triggers with a careful > ad-hoc example. That said, I do really think you are free to work on > what interests you, so I hope to see your patches fixing diagnostics > issues soon. Is this the kind of protracted passive-aggressive opinion you were looking for? -- Gaby
[no subject]
здаровчик, красавчик.)) uhusnarirw.pochtamt.ruКузичка_Кашканова моё имя там...!!) если есть желание познакомиться поближе...
Re: Updated GCC vs Clang diagnostics
Lawrence Crowl writes: > On 4/12/12, Manuel López-Ibáñez wrote: >> So given your ideal implementation, if the user-visible result >> was exactly like the one in Clang, will you be happy with any of >> the three things: ranges, color and fix-it hints? > > There are many issues with color. Does your reader have any > color deficiencies? Does your software address them? Does the > system software render colors well? Is color contrast sufficient? > Is greyscale contrast sufficient? Color is low on my list of > desirables. It would be terrible if an error message could not be understood without color. But nobody is suggesting that. The question at hand is whether color can be used to enhance an error message that can be understood without color. For example, whether color can be added to current error messages without any other changes. I personally think it would be an excellent idea. Even clang's C++ error messages can be long. A simple use of color is an excellent way to draw the eye to the more important parts of the message. If the color is not available, then it doesn't help, but the error message can be understood without it. Ian
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 12:11 AM, Ian Lance Taylor wrote:
> I personally think it would be an excellent idea. Even clang's C++
> error messages can be long. A simple use of color is an excellent way
> to draw the eye to the more important parts of the message. If the
> color is not available, then it doesn't help, but the error message can
> be understood without it.
I would expect that an implementation in this direction would transform
error ("there is no operator %E with arguments %T and %T", foo, bar, baz)
into an internal IL rich enough to represent formatting directives
(and "2D" representation) independent of the actual rendering device's
capabilities.
It would then be up to each output device to display the diagnostics based on
their own characteristics (color or not, caret or not, pointing the cursor back
to the source file or not). And indeed, it would be really terrible idea if the
intelligibility of a diagnostic -requires- colors.
-- Gaby
Re: Updated GCC vs Clang diagnostics
On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote: > Lawrence Crowl writes: > > > On 4/12/12, Manuel López-Ibáñez wrote: > >> So given your ideal implementation, if the user-visible result > >> was exactly like the one in Clang, will you be happy with any of > >> the three things: ranges, color and fix-it hints? > > > > There are many issues with color. Does your reader have any > > color deficiencies? Does your software address them? Does the > > system software render colors well? Is color contrast sufficient? > > Is greyscale contrast sufficient? Color is low on my list of > > desirables. > > It would be terrible if an error message could not be understood without > color. But nobody is suggesting that. > > The question at hand is whether color can be used to enhance an error > message that can be understood without color. For example, whether > color can be added to current error messages without any other changes. > > I personally think it would be an excellent idea. Even clang's C++ > error messages can be long. A simple use of color is an excellent way > to draw the eye to the more important parts of the message. If the > color is not available, then it doesn't help, but the error message can > be understood without it. Yeah, I second this. As Manuel said, we should have an option to select never/auto/always coloring, colors must be just visual enhancements of the diagnostics that even when colors are disabled gives all the info that is needed (highlight error/warning/note diagnostic kind keywords, keywords in the source, perhaps types, whatever), we should limit to a very small set of colors, because not so many colors are actually very readable and perhaps make the color sets configurable somehow (things might be different if people use normally black characters on white background or white characters on black background, grep has GREP_COLORS env var here, ls LS_COLORS). Jakub
Re: RFC: -Wall by default
On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewar wrote: > End of thread for me, remove me from the reply lists, thanks > discussion is going nowhere, at this stage my vote is for > no change whatever in the way warnings are handled. I was asked "wassup with Robert?". All I can say s that it is a decade-old relationship :-) -- Gaby
Re: Updated GCC vs Clang diagnostics
On Fri, Apr 13, 2012 at 1:03 AM, Jakub Jelinek wrote: > we should limit to a very small > set of colors, because not so many colors are actually very readable and > perhaps make the color sets configurable somehow (things might be different > if people use normally black characters on white background or white > characters on black background, grep has GREP_COLORS env var here, ls > LS_COLORS). I would certainly expect the set of used colors to be small and configurable. Ideally, when mapped to a bicolor rendering with bold and/or underlying they should convey the same visual information. -- Gaby
