Re: RFC: -Wall by default
Can someone summarize what the most useful warnings people are expecting that -Wall would bring? I suspect not all of -Wall would actually be welcome/a good idea by default, and we might be looking for a better compromise where most warnings are enabled by default, but not "all". In particular, I'm not convinced that -Wuninitialized should be enabled by default, precisely because this warning does generate a good bunch of false positives. So to me it's not black or white, and considering -Wall as a single entity is not the right way to address these user complains IMO. Arno
Re: RFC: -Wall by default
Miles Bader writes: > For instance, how about adding -Wall to the default options now, and > then re-evaluate the issue based on any complaints that come in from > people using snapshots? That's hardly a perfect method, as the sort > of people who run compiler snapshots are maybe not entirely > representative, but at least it's better data than one gets by simply > sitting around and pontificating... I guess it's pretty obvious, but I meant to say "... and then later re-evaluate the issue before the next release ...". -miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 11:11 PM, Miles Bader wrote: > For instance, how about adding -Wall to the default options now, and > then re-evaluate the issue based on any complaints that come in from > people using snapshots? I believe this would offer far more evidence for/against the notion of the change being bold and/or inconvenient to users. -- Gaby
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 8:27 PM, Robert Dewar wrote: > On 4/4/2012 6:42 PM, Gabriel Dos Reis wrote: >> >> On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar wrote: >>> >>> On 4/4/2012 2:34 PM, Dominique Dhumieres wrote: >>> IMO only the warnings in C that are likely errors should be the default as it is in gfortran (don't ask for examples of such warnings for C, I am quasi-illiterate). >>> >>> >>> >>> That's also the default philosophy in GNAT, >> >> >> In which case you should NOT be objecting to the proposal :-) > > > -Wall is roughtly equivalent to -gnatwa in the GNAT front end, > and this is definitely NOT on by default. If you run GNAT in > default mode, there are virtually no false positives, since > the only warnings on by default are the kind of warnings that > say "if you execute this statement, your program will go wrong" like calling a function with non-void return type whose definition ails to return value. -- Gaby
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar wrote: > On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote: > >> Again, this proposal does not come out of a whim. > > > But it does seem to come out of a few anecdotal requests > for a change, It does appear very disturbing that you would dismiss repeated requests on the basis that they are anecdotal without offering evidence. What is more, we seem to have implemented a feature that makes it even more intimidating for potential users to fill out such requests. > and you always have to be careful in considering > such input, because of course people who agree with the status > quo do not write in complaining. I do see evidence to the contrary to that claim, starting with this very thread AND the bugzilla database that we seem to have designed to intimidate future requesters. > I see no evidence that a > majority of users are in favor of this change. This strikes me as a way to a self-fullfilling prophecy. > By the way, to me a much more significant issue is the default > optimization level. Gcc code quality is plain horrible at -O0, > often MUCH worse that competitive compilers with default > optimization (most compilers do much more than -O0 by default). One cannot seriously argue for "do what it is told" and at the same time complain about default level of optimization :-) Furthermore, the problem you see with the default level of optimization is not in conflict with default level of diagnostics. I am approaching the issue from the point of view of diagnostics maintainer; if you want to raise the default level of optimization you should feel free to make a proposal. > We have run into people running benchmarks where they were > specifically prohibited from using other than the default > options, and gcc fared badly in such comparisons. That is no argument against diagnostic level by default. In fact, it appears to support the claim that many users run the compiler without options -- and the argument of -Wall being short to remember is evenless potent since -O is even shorter to remember. > > So we have wondered from time to time whether -O1 should > be the default, but the debugger is not well behaved at > -O1, and it's too much of a change I am afraid. Again, that isn't an argument against more useful diagnostic level by default. -- Gaby
Re: RFC: -Wall by default
Robert Dewar writes: > We have run into people running benchmarks where they were > specifically prohibited from using other than the default > options, and gcc fared badly in such comparisons. Yeah, there was the silly "benchmark" at phoronix where they came to the conclusion that tcc was a better compiler than gcc because it generated faster programs when run without any options... [*] Phoronix is well known for completely clueless benchmarking practices, but ... unfortunately some people actually seem to pay attention to what they say. -miles -- Innards, n. pl. The stomach, heart, soul, and other bowels.
Re: RFC: -Wall by default
domi...@lps.ens.fr (Dominique Dhumieres) writes: > PS -Wall is a simple enough option to be remembered by all users who > need it As is -Wno-all, of course. > (if they don't use it, they don't want it). That isn't necessarily the case. In my experience, there seem to be a lot of developers who simply don't think much about the issue to the point of adding warning options, but who are not really averse to _heeding_ warnings that the compiler emits by default. It's kind of hard to say where the right balance lies given gcc's disparate user community, but ... one way to find out is try... :] For instance, how about adding -Wall to the default options now, and then re-evaluate the issue based on any complaints that come in from people using snapshots? That's hardly a perfect method, as the sort of people who run compiler snapshots are maybe not entirely representative, but at least it's better data than one gets by simply sitting around and pontificating... -Miles -- Ocean, n. A body of water covering seven-tenths of a world designed for Man - who has no gills.
Re: RFC: -Wall by default
On 4/4/2012 6:42 PM, Gabriel Dos Reis wrote: On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar wrote: On 4/4/2012 2:34 PM, Dominique Dhumieres wrote: IMO only the warnings in C that are likely errors should be the default as it is in gfortran (don't ask for examples of such warnings for C, I am quasi-illiterate). That's also the default philosophy in GNAT, In which case you should NOT be objecting to the proposal :-) -Wall is roughtly equivalent to -gnatwa in the GNAT front end, and this is definitely NOT on by default. If you run GNAT in default mode, there are virtually no false positives, since the only warnings on by default are the kind of warnings that say "if you execute this statement, your program will go wrong" there never should be false positives at all in the default mode IMO (well hardly ever :-) Dominique PS -Wall is a simple enough option to be remembered by all users who need it (if they don't use it, they don't want it).
Re: RFC: -Wall by default
On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote: Again, this proposal does not come out of a whim. But it does seem to come out of a few anecdotal requests for a change, and you always have to be careful in considering such input, because of course people who agree with the status quo do not write in complaining. I see no evidence that a majority of users are in favor of this change. By the way, to me a much more significant issue is the default optimization level. Gcc code quality is plain horrible at -O0, often MUCH worse that competitive compilers with default optimization (most compilers do much more than -O0 by default). We have run into people running benchmarks where they were specifically prohibited from using other than the default options, and gcc fared badly in such comparisons. So we have wondered from time to time whether -O1 should be the default, but the debugger is not well behaved at -O1, and it's too much of a change I am afraid.
Re: question about the constraint modifier '+'
Handong Ye writes:
> Hi, I'm new in gcc, and maybe misunderstand the constraint modifier '+'.
> As the internal document says, '+' means an inout parameter. In my
> mind, it means the instruction both reads and writes the pseudo
> register.
>
> Assuming I have a pattern like:
>
> (define_insn "lssu"
>[(set (match_operand:m1 0 ...)
>(unspec:m1 [ (match_operand:SI 1 "register_operand" "+r")
> (match_operand:SI 2 ...)] UNSPEC_XXX))]
>
> and I have a sequence of code like
>
> (insn 1 (set (reg:SI 100) (...)))
> ...
> (insn 10 ... (set (reg:m1 200) (unspec:m1 [(reg:SI 100) (...)]
> UNSPEC_XXX)) 33 {lssu} (nil))
> ...
> (insn 30 ... (set (reg:SI 300) (reg:SI 100)
>
> Can I expect that pseudo reg 100 in insn 30 has the new value written
> by insn 10?
>
> My experiments show that this is not true, and pseudo reg 100 in insn
> 30 still takes the value in insn 1.
> Or maybe something else is wrong in our porting ?
Constraints, like +r, are only used by the register allocator and reload
and friends. They do not mean anything to the RTL optimizers. You
should write your RTL to explicitly set values that are changed.
Ian
question about the constraint modifier '+'
Hi, I'm new in gcc, and maybe misunderstand the constraint modifier '+'.
As the internal document says, '+' means an inout parameter. In my
mind, it means the instruction both reads and writes the pseudo
register.
Assuming I have a pattern like:
(define_insn "lssu"
[(set (match_operand:m1 0 ...)
(unspec:m1 [ (match_operand:SI 1 "register_operand" "+r")
(match_operand:SI 2 ...)] UNSPEC_XXX))]
and I have a sequence of code like
(insn 1 (set (reg:SI 100) (...)))
...
(insn 10 ... (set (reg:m1 200) (unspec:m1 [(reg:SI 100) (...)]
UNSPEC_XXX)) 33 {lssu} (nil))
...
(insn 30 ... (set (reg:SI 300) (reg:SI 100)
Can I expect that pseudo reg 100 in insn 30 has the new value written
by insn 10?
My experiments show that this is not true, and pseudo reg 100 in insn
30 still takes the value in insn 1.
Or maybe something else is wrong in our porting ?
--
Thanks.
Handong
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 5:56 PM, Eric Botcazou wrote: >> The trouble is that most users find it an annoyance and don't >> remember. And they ask: if it is so simple, why isn't it included by >> default? > > Huh? -Wall is supposed to be simple to remember, but its implementation and > effects are of course not simple at all. From developer perspective, we think that -Wall is so simple to remember, because in fact, we are used to handle so many complex things that this one five letter is nothing. However, users aren't as sophisticated as we would like them to (I am not being condescending.) The way we have to approach this is how can we satisfy persistent demands and still remain competitive. Again, this proposal does not come out of a whim. -- Gaby
Re: RFC: -Wall by default
> The trouble is that most users find it an annoyance and don't > remember. And they ask: if it is so simple, why isn't it included by > default? Huh? -Wall is supposed to be simple to remember, but its implementation and effects are of course not simple at all. -- Eric Botcazou
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar wrote: > On 4/4/2012 2:34 PM, Dominique Dhumieres wrote: > >> IMO only the warnings in C that are likely errors should be the default as >> it is in gfortran (don't ask for examples of such warnings for C, I am >> quasi-illiterate). > > > That's also the default philosophy in GNAT, In which case you should NOT be objecting to the proposal :-) > there never should be false > positives at all in the default mode IMO (well hardly ever :-) > >> >> >> Dominique >> >> PS -Wall is a simple enough option to be remembered by all users who need >> it (if they don't use it, they don't want it). > >
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 1:34 PM, Dominique Dhumieres wrote: >> >> We do have regular requests for this, so it is not just out of thin >> >> air. >> > >> > Perhaps, but I think that changing the default like this is far too >> > invasive. ?GCC should do what it's told, if a user asks for warnings, >> > give them, if they don't, then don't. >> >> It is hard to define "what it is told" means -- we are already in gray >> zone. >> >> > I suspect changing the default like this will generate a flood of >> > complaints. >> >> Really? Such as what? > > At least me!-(how many "regular requests" compared to the number of gcc > users?). well, you can have a look at our bugzilla database, and look for -Wall for example and follow the discussions there. >> If we get floods of complaints, that can only that -Wall too many >> false positives; >> but I don't think it does. We have been careful over the years to >> watch for that effect. > > [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.c | wc -l > 1060 > [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.h | wc -l > 21 > > Doesn't that count as "false positives"? I said "too many false positive". I did not say "no false positive". What you would be more informative is the ratio of functions with that attribute over the number of function definitions. > IMO only the warnings in C that are likely errors should be the default as I can leave with that. However, here is the thing: We put in -Wall the warnings that are likely errors. I suspect if we find something in -Wall that are not likely errors, then that is an engineering bug from our part and we should fix it. > it is in gfortran (don't ask for examples of such warnings for C, I am > quasi-illiterate). > > > Dominique > > PS -Wall is a simple enough option to be remembered by all users who need > it (if they don't use it, they don't want it). The trouble is that most users find it an annoyance and don't remember. And they ask: if it is so simple, why isn't it included by default? This particular request came out of long discussions with people frustrated by the way GCC behaves compared to competitors.
RE: [GCC Steering Committee] Android sub-port reviewer
Maxim Kuvyrkov wrote:
> I encourage you to submit the MIPS Android patches to
> gcc-patches@. And, as long as your changes preserve the
> status quo of mips-*-* being big-endian by default and
> mipsel-*-* being little-endian by default, there should be no
> major obstacles to merge those in.
>
For now, two MIPS changes in gnu-user.h and unwind-dw2-fde-dip.c can be
posted for comment.
(I didn't tested this patch, though.)
After starting to build toolchains for Android with Bionic, we may find new
files to
patch. Ex: Comment out getpagesize() for bionic.
Any comment? Thanks a lot!
Regards,
Chao-ying
Index: gcc/gcc/config/mips/gnu-user.h
===
--- gcc.orig/gcc/config/mips/gnu-user.h 2012-04-03 17:39:50.0 -0700
+++ gcc/gcc/config/mips/gnu-user.h 2012-04-04 14:31:50.804236000 -0700
@@ -45,8 +45,8 @@ along with GCC; see the file COPYING3.
/* A standard GNU/Linux mapping. On most targets, it is included in
CC1_SPEC itself by config/linux.h, but mips.h overrides CC1_SPEC
and provides this hook instead. */
-#undef SUBTARGET_CC1_SPEC
-#define SUBTARGET_CC1_SPEC "%{profile:-p}"
+#undef GNU_USER_SUBTARGET_CC1_SPEC
+#define GNU_USER_SUBTARGET_CC1_SPEC "%{profile:-p}"
/* -G is incompatible with -KPIC which is the default, so only allow objects
in the small data section if the user explicitly asks for it. */
@@ -54,8 +54,8 @@ along with GCC; see the file COPYING3.
#define MIPS_DEFAULT_GVALUE 0
/* Borrowed from sparc/linux.h */
-#undef LINK_SPEC
-#define LINK_SPEC \
+#undef GNU_USER_TARGET_LINK_SPEC
+#define GNU_USER_TARGET_LINK_SPEC \
"%(endian_spec) \
%{shared:-shared} \
%{!shared: \
@@ -89,8 +89,8 @@ along with GCC; see the file COPYING3.
#undef ASM_OUTPUT_REG_PUSH
#undef ASM_OUTPUT_REG_POP
-#undef LIB_SPEC
-#define LIB_SPEC "\
+#undef GNU_USER_TARGET_LIB_SPEC
+#define GNU_USER_TARGET_LIB_SPEC "\
%{pthread:-lpthread} \
%{shared:-lc} \
%{!shared: \
@@ -133,7 +133,34 @@ extern const char *host_detect_local_cpu
LINUX_DRIVER_SELF_SPECS
/* Similar to standard Linux, but adding -ffast-math support. */
-#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
+#undef GNU_USER_TARGET_ENDFILE_SPEC
+#define GNN_USER_TARGET_ENDFILE_SPEC \
"%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+
+#undef LINK_SPEC
+#define LINK_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
+ GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
+
+#undef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC \
+ LINUX_OR_ANDROID_CC (GNU_USER_SUBTARGET_CC1_SPEC,\
+ GNU_USER_SUBTARGET_CC1_SPEC " " ANDROID_CC1_SPEC)
+
+#undef CC1PLUS_SPEC
+#define CC1PLUS_SPEC \
+ LINUX_OR_ANDROID_CC ("", ANDROID_CC1PLUS_SPEC)
+
+#undef LIB_SPEC
+#define LIB_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
+ GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC)
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, ANDROID_STARTFILE_SPEC)
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_ENDFILE_SPEC, ANDROID_ENDFILE_SPEC)
Index: gcc/libgcc/unwind-dw2-fde-dip.c
===
--- gcc.orig/libgcc/unwind-dw2-fde-dip.c2012-04-03 17:07:28.0
-0700
+++ gcc/libgcc/unwind-dw2-fde-dip.c 2012-04-04 14:51:01.338074000 -0700
@@ -48,8 +48,9 @@
#include "gthr.h"
#if !defined(inhibit_libc) && defined(HAVE_LD_EH_FRAME_HDR) \
-&& (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \
- || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG)))
+&& ((defined(__BIONIC__) && (defined(mips) || defined(__mips__))) \
+|| (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \
+ || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG
# define USE_PT_GNU_EH_FRAME
#endif
RFC: X32 TLS specification
Hi, X32 support has been checked into Linux kernel v3.4-rc1. I started submitting x32 glibc and GDB patches. I added TLS specification to x32 psABI: https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0&d=1 I am planning to submit x32 extension to x86-64 psABI soon if there are no major issues. Thanks. -- H.J.
Re: RFC: -Wall by default
On 4/4/2012 2:34 PM, Dominique Dhumieres wrote: IMO only the warnings in C that are likely errors should be the default as it is in gfortran (don't ask for examples of such warnings for C, I am quasi-illiterate). That's also the default philosophy in GNAT, there never should be false positives at all in the default mode IMO (well hardly ever :-) Dominique PS -Wall is a simple enough option to be remembered by all users who need it (if they don't use it, they don't want it).
Re: RFC: -Wall by default
On 4/4/2012 2:02 PM, Gabriel Dos Reis wrote: The interesting thing about -Wall is that it is pretty safe, for the most part, in terms of false positives. And, for the record, I find lots of false positives, the front end of GNAT has a lot of junk initialiations marked "keep back end quiet". -- Gaby
Re: RFC: -Wall by default
Sometimes, we have to be brave to challenge tradition. The world around us is moving and we definitely want GCC to remain competitive. It is hard to define what "it's told" means without tripping over. The interesting thing about -Wall is that it is pretty safe, for the most part, in terms of false positives. Well I find it too big a change to make, if people want warnings, it really is not that hard to ask for them! -- Gaby
Re: GSoC proposal: Provide optimizations feedback through post-compilation messages
On Mon, 2 Apr 2012 19:57:20 + Thibault Raffaillac wrote: > Bump! > > Let me renew my interest in contributing through GSoC with post-compilation > feedback (This was not an early april joke). Do you think it could lead to an > acceptable GSoC proposal? (mentor interested?) 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). > @Tomasz: > On the interaction side I totally agree that communication between compiler > and > programmer is scarce (and there is room for improvement). Focusing too soon on > the editor would overlook the vast users needs though, as: > _ some users do not use an IDE (and will kindly refuse); > _ some users do not need more communication, as they already know what GCC can > and cannot do; > _ some users do not want more communication, as they have other business to > focus on; Sure, I'm one of the people who don't use an IDE as it causes more issues than it solves for me. This isn't meant for everyone the same way anything else isn't, it just can't;p Still looking at it, other languages, different IDEs, I'd say my way of tackling the issues is more usable and useful than most other, and could easily see wider adoption. Btw my experience is mostly in low-level kernel/driver programming, 2/3d graphics, games. > I think the editor being split from the compiler is good thing. There still > exist tools to expose static analysis data from the compiler (and choose the > editor to visualize it with), but fundamentally they are assisting him/her > rather than helping him/her improve. Instead of gathering loads of data on the > optimizations/analysis performed, and filtering it for visualization by the > user, we could relate the optimization technique used so that the user truly > knows what GCC is capable of (instead of guessing by observation). 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. > My proposal is thus not to be confused with a static analysis visualization: > the programmer learns what techniques are implemented in GCC (or in compilers > in general), how to write code that is more easily compiled, and can further > browse the Intwawaernet for detailed theory on the techniques involved. 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. > The point on the possible-optimizations-which-could-be-enabled-if-specific- > -constraint-is-lifted is particularly interesting, but is also extremely risky > if the compiler makes a stupid remark on a constraint which can "obviously" > (for the programmer) not be lifted. If ever, I would introduce it with a LOT > of > care. Yes and no. First of all I don't necessarily mean for the compiler/editor to suggest anything to the programmer, rather if the programmer asks just say what's physically possible, and not what's right, since if the compiler could do that it would just perform the optimization. Furthermore the situation with my source code is that I can probably make all this in such a form that it is actually usable and useful which seems to me close to impossible with normal languages. I can also with almost no effort store within the source
Re: RFC: -Wall by default
On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote: > Really? Such as what? Such as "I wrote a perfectly legal C program, and gcc spewed out a ton of messages." Andrew.
Re: RFC: -Wall by default
> >> We do have regular requests for this, so it is not just out of thin > >> air. > > > > Perhaps, but I think that changing the default like this is far too > > invasive. ?GCC should do what it's told, if a user asks for warnings, > > give them, if they don't, then don't. > > It is hard to define "what it is told" means -- we are already in gray > zone. > > > I suspect changing the default like this will generate a flood of > > complaints. > > Really? Such as what? At least me!-(how many "regular requests" compared to the number of gcc users?). > If we get floods of complaints, that can only that -Wall too many > false positives; > but I don't think it does. We have been careful over the years to > watch for that effect. [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.c | wc -l 1060 [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.h | wc -l 21 Doesn't that count as "false positives"? While -Wunused can help to spot some "copy&paste" errors, most of the time the warning just reflects some harmless sloppyness. IMO only the warnings in C that are likely errors should be the default as it is in gfortran (don't ask for examples of such warnings for C, I am quasi-illiterate). Dominique PS -Wall is a simple enough option to be remembered by all users who need it (if they don't use it, they don't want it).
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 1:06 PM, Jeff Law wrote: > On 04/04/2012 12:04 PM, Gabriel Dos Reis wrote: >> >> On Wed, Apr 4, 2012 at 10:17 AM, Jeff Law wrote: >>> >>> On 04/04/2012 08:56 AM, Ian Lance Taylor wrote: Andrew Haley writes: > On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: >> >> >> For GCC-4.8, I would like to turn on -Wall by default. >> Comments? > > > > Umm, should this really happen at exactly the same time as C++ > by default? I assume that Gaby is talking about making -Wall the default for users of GCC. >>> >>> >>> If so, that seems awful presumptuous to me. >> >> >> We do have regular requests for this, so it is not just out of thin air. > > Perhaps, but I think that changing the default like this is far too > invasive. GCC should do what it's told, if a user asks for warnings, give > them, if they don't, then don't. It is hard to define "what it is told" means -- we are already in gray zone. > I suspect changing the default like this will generate a flood of complaints. Really? Such as what? If we get floods of complaints, that can only that -Wall too many false positives; but I don't think it does. We have been careful over the years to watch for that effect. > > jeff
Re: RFC: -Wall by default
On 04/04/2012 12:04 PM, Gabriel Dos Reis wrote: On Wed, Apr 4, 2012 at 10:17 AM, Jeff Law wrote: On 04/04/2012 08:56 AM, Ian Lance Taylor wrote: Andrew Haleywrites: On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by default. Comments? Umm, should this really happen at exactly the same time as C++ by default? I assume that Gaby is talking about making -Wall the default for users of GCC. If so, that seems awful presumptuous to me. We do have regular requests for this, so it is not just out of thin air. Perhaps, but I think that changing the default like this is far too invasive. GCC should do what it's told, if a user asks for warnings, give them, if they don't, then don't. I suspect changing the default like this will generate a flood of complaints. jeff
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 10:17 AM, Jeff Law wrote: > On 04/04/2012 08:56 AM, Ian Lance Taylor wrote: >> >> Andrew Haley writes: >> >>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by default. Comments? >>> >>> >>> Umm, should this really happen at exactly the same time as C++ >>> by default? >> >> >> I assume that Gaby is talking about making -Wall the default for users >> of GCC. > > If so, that seems awful presumptuous to me. We do have regular requests for this, so it is not just out of thin air. -- Gaby
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 10:07 AM, Andrew Haley wrote: > On 04/04/2012 03:56 PM, Ian Lance Taylor wrote: >> Andrew Haley writes: >> >>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by default. Comments? >>> >>> Umm, should this really happen at exactly the same time as C++ >>> by default? >> >> I assume that Gaby is talking about making -Wall the default for users >> of GCC. > > Oh, wow. Really? That's a big change. Time to be brave, I guess, > but I very much like the idea of a gcc that does just what it's told; > making -Wall the default is a big break with tradition. Sometimes, we have to be brave to challenge tradition. The world around us is moving and we definitely want GCC to remain competitive. It is hard to define what "it's told" means without tripping over. The interesting thing about -Wall is that it is pretty safe, for the most part, in terms of false positives. -- Gaby
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 9:56 AM, Ian Lance Taylor wrote: > Andrew Haley writes: > >> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: >>> For GCC-4.8, I would like to turn on -Wall by default. >>> Comments? >> >> Umm, should this really happen at exactly the same time as C++ >> by default? > > I assume that Gaby is talking about making -Wall the default for users > of GCC. Exactly. Our bugzilla databases has lot of requests in this spirit. My personal opinion is that we are doing ourselves a disservice by ignoring them. It is high time. -- Gaby
Re: Switching to C++ by default in 4.8
On 4/4/12, Richard Guenther wrote: > On Apr 4, 2012 Bernd Schmidt wrote: > > On 04/04/2012 11:06 AM, Richard Guenther wrote: > > > So - I'll veto the switch unless I see 1) and 2). 1) and 2) > > > can be combined by transitioning vec.h to a C++ template class, > > > with proper GC support. (not sure that I can veto anything > > > - heh) > > > > I don't think I can veto anything, but I'll go on the record > > again saying that I don't think this entire plan is a good > > idea. Write a new project in C++? Absolutely. Convert a large > > existing one to a different language? A huge waste of time that > > will distract us for years from actual user-visible changes. > > I agree for the idea of converting all of GCC to C++ (whatever > that means). I disagree for the part making the internal > infrastructure easier to use, understand and maintain. Which > means targeting mostly isolated sub-systems, like vec.h (and > other various containers), double-int.[ch] (and other various > way of representing and working with constants). Making tree > or gimple a C++ class with inheritance and whatever is indeed > a huge waste of time and existing developer ressources (that, > if only because they have to adapt and maintain two completely > different code-bases over some time). Trees are presently a significant problem in that many static errors become dynamic errors, which entails more debugging. > I expect the GCC core to maintain written in C, compiled by C++. Converting VECs to C++ vectors vector would provide significant code clarity benefits. The files in which that is done would necessarily be C++ only. > > I also find debugging C++ in gdb somewhat more annoying than > > debugging plain C, and at the moment I always go back to a > > stage1 compiler. > > Indeed - I'd be worried if my debugging efficiency decreases by > more than 5%. If the number of debugging sessions was reduced by the same amount, the result would be a net wash. -- Lawrence Crowl
Re: RFC: -Wall by default
On 04/04/2012 08:56 AM, Ian Lance Taylor wrote: Andrew Haley writes: On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by default. Comments? Umm, should this really happen at exactly the same time as C++ by default? I assume that Gaby is talking about making -Wall the default for users of GCC. If so, that seems awful presumptuous to me. jeff
Re: RFC: -Wall by default
Andrew Haley writes: > On 04/04/2012 03:56 PM, Ian Lance Taylor wrote: >> Andrew Haley writes: >> >>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by default. Comments? >>> >>> Umm, should this really happen at exactly the same time as C++ >>> by default? >> >> I assume that Gaby is talking about making -Wall the default for users >> of GCC. > > Oh, wow. Really? That's a big change. Time to be brave, I guess, > but I very much like the idea of a gcc that does just what it's told; > making -Wall the default is a big break with tradition. Yes, that would be a big change. But we already use -Wall when building GCC itself, so that would not be a change at all. Ian
Re: RFC: -Wall by default
On 04/04/2012 03:56 PM, Ian Lance Taylor wrote: > Andrew Haley writes: > >> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: >>> For GCC-4.8, I would like to turn on -Wall by default. >>> Comments? >> >> Umm, should this really happen at exactly the same time as C++ >> by default? > > I assume that Gaby is talking about making -Wall the default for users > of GCC. Oh, wow. Really? That's a big change. Time to be brave, I guess, but I very much like the idea of a gcc that does just what it's told; making -Wall the default is a big break with tradition. Andrew.
Re: Switching to C++ by default in 4.8
On 4/4/12 8:04 AM, Richard Guenther wrote: I agree for the idea of converting all of GCC to C++ (whatever that means). Right. The conversion that does happen, can be gradual. One other big advantage I see in this effort, is the transition to commonly used programming idioms and patterns. This will lower barriers of entry to new developers, which is crucial to the long term survival of the project. I've heard many new developers (experienced compiler developers even) express frustration at the obtuse and obscure patterns they find in GCC. I disagree for the part making the internal infrastructure easier to use, understand and maintain. Which means targeting mostly isolated sub-systems, like vec.h (and other various containers), double-int.[ch] (and other various way of representing and working with constants). Making tree or gimple a C++ class with inheritance and whatever is indeed a huge waste of time and existing developer ressources (that, if only because they have to adapt and maintain two completely different code-bases over some time). I expect the GCC core to maintain written in C, compiled by C++. I'm not sure about that long term, but I agree that this will likely be true for several releases. We want to be careful, of course. Particularly with the core sub-systems. I also find debugging C++ in gdb somewhat more annoying than debugging plain C, and at the moment I always go back to a stage1 compiler. Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. We should take this opportunity to help improve gdb by filing bugs. Diego.
Re: RFC: -Wall by default
Andrew Haley writes: > On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: >> For GCC-4.8, I would like to turn on -Wall by default. >> Comments? > > Umm, should this really happen at exactly the same time as C++ > by default? I assume that Gaby is talking about making -Wall the default for users of GCC. The C++ issue does not affect users of GCC at all. It only affects people who build GCC. Ian
Re: Switching to C++ by default in 4.8
On Apr 4, 2012, at 4:37 PM, Gabriel Dos Reis wrote: > On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold wrote: > >> For Alpha, gas crashes during libstdc++ build. From initial investigation, >> this looks manageable. But Alpha object format is quite old, and has no >> support for comdat (but weak symbols should work). > > I believe weak symbols should suffice, if the object file does not have > comdat. That's also my understanding from reading various gcc pieces. But these features (aliases and weak) was never well-tested in the Alpha VMS case. Tristan.
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 4:45 PM, Richard Guenther wrote: > On Wed, Apr 4, 2012 at 4:12 PM, Tom Tromey wrote: >>> "Richard" == Richard Guenther writes: >> >> Richard> Oh, and did we address all the annoyances of debugging gcc when it's >> Richard> compiled by a C++ compiler? ... >> >> If you mean gdb problems, please file bugs. > > I think I filed the most annoying one already, passing cut&pasted addresses > to inferior calls and gdb doing funny overload resolution on the pointer > types. > Not sure what its status is. Seems unfixed: http://sourceware.org/bugzilla/show_bug.cgi?id=13356 > Richard. > >> Tom
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 4:12 PM, Tom Tromey wrote: >> "Richard" == Richard Guenther writes: > > Richard> Oh, and did we address all the annoyances of debugging gcc when it's > Richard> compiled by a C++ compiler? ... > > If you mean gdb problems, please file bugs. I think I filed the most annoying one already, passing cut&pasted addresses to inferior calls and gdb doing funny overload resolution on the pointer types. Not sure what its status is. Richard. > Tom
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold wrote: > For Alpha, gas crashes during libstdc++ build. From initial investigation, > this looks manageable. But Alpha object format is quite old, and has no > support for comdat (but weak symbols should work). I believe weak symbols should suffice, if the object file does not have comdat. -- Gaby
Re: Switching to C++ by default in 4.8
> "Richard" == Richard Guenther writes: Richard> Oh, and did we address all the annoyances of debugging gcc when it's Richard> compiled by a C++ compiler? ... If you mean gdb problems, please file bugs. Tom
Re: Switching to C++ by default in 4.8
On Apr 4, 2012, at 3:12 PM, Ian Lance Taylor wrote: > Tristan Gingold writes: > >> On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote: >> >>> >>> We would like to start the process to make GCC 4.8 build in C++ mode by >>> default. >>> >>> The mechanics of the change are simple enough. I volunteer to test >>> changing the default on all primary targets (assuming I can get them from >>> the GCC build farm). >> >> Is it already possible to build stage1 with c++ ? > > Yes. There are two relevant configure options: --enable-build-with-cxx Ah thanks, I missed this option. > and --enable-build-poststage1-with-cxx. Currently the first defaults to > no and the second defaults to yes. The change in question would be > making the first default to yes. > > >> The VMS targets are not yet ready with build in C++ mode. This target >> is somewhat special because it can be built only with a cross-compiler >> (we don't support regular 3 stages native builds because there is no >> complete and working well enough UNIX emulation tools). >> >> I started to build g++ (and gfortran) for ia64 and alpha VMS in order >> to prepare this transition, but having a soft path would be better to >> me. > > Sounds like you would need to have a C++ cross-compiler for VMS. What > are the issues with making that work? For ia64, g++ is working on simple examples (and for the testsuite). But building gcc will be a better test. For Alpha, gas crashes during libstdc++ build. From initial investigation, this looks manageable. But Alpha object format is quite old, and has no support for comdat (but weak symbols should work). I only have worked on g++ for Alpha for a few days. Tristan.
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On Sat, 31 Mar 2012, Stefano Lattarini wrote: > Note there's nothing I'm planning to do, nor I should do, in this regard: > the two setups described above are both already supported by the current > automake implementation (but the last one is not encouraged, even though > it makes perfect sense in some *rare* situations). I was just pointing > out that you have to choose one of these setups -- so, if you want to > distribute info files, you must accept to have them build in the srcdir. The approach used in GCC, for example in the libquadmath directory, is a --enable-generated-files-in-srcdir configure option that is used when building a release tarball - so normally the files go in the build directory, but a special configuration is used to put them in the source directory only when building releases. (This does not involve the "cygnus" option.) I think support for that seems more generically useful (and it makes sense to me for automake to look at features used in other packages' configure/build systems, that aren't inherently specific to those packages, and try to provide generic versions of them). The Binutils/GDB release tarball building process is substantially different and I'm not familiar with it. -- Joseph S. Myers jos...@codesourcery.com
Re: Switching to C++ by default in 4.8
Tristan Gingold writes: > On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote: > >> >> We would like to start the process to make GCC 4.8 build in C++ mode by >> default. >> >> The mechanics of the change are simple enough. I volunteer to test changing >> the default on all primary targets (assuming I can get them from the GCC >> build farm). > > Is it already possible to build stage1 with c++ ? Yes. There are two relevant configure options: --enable-build-with-cxx and --enable-build-poststage1-with-cxx. Currently the first defaults to no and the second defaults to yes. The change in question would be making the first default to yes. > The VMS targets are not yet ready with build in C++ mode. This target > is somewhat special because it can be built only with a cross-compiler > (we don't support regular 3 stages native builds because there is no > complete and working well enough UNIX emulation tools). > > I started to build g++ (and gfortran) for ia64 and alpha VMS in order > to prepare this transition, but having a soft path would be better to > me. Sounds like you would need to have a C++ cross-compiler for VMS. What are the issues with making that work? Ian
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 7:19 AM, Richard Guenther wrote: > On Wed, Apr 4, 2012 at 2:14 PM, Andrew Haley wrote: >> On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote: >>> On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley wrote: On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: > For GCC-4.8, I would like to turn on -Wall by default. > Comments? Umm, should this really happen at exactly the same time as C++ by default? >>> >>> I consider it a separate issue. >>> >>> -Wall is a primary a service to GCC users (which GCC is already >>> using internally.) >>> >>> Switching to compile with C++ compiler is an internal >>> compiler infrastructure issue that should be independent >>> of the services we provide to the broader C++ community. >> >> It's certainly a separate issue, but the set of C++ warnings is >> very different, and to avoid unnecessary chaos it might be good >> to stage the changes. > > We already use -Wall for both the stage1 C and the stage2+ C++ compiles. > Only stage2+ use -Werror though. Exactly. I am suggesting to turn on -Werror by default. -- Gaby
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 2:14 PM, Andrew Haley wrote: > On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote: >> On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley wrote: >>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by default. Comments? >>> >>> Umm, should this really happen at exactly the same time as C++ >>> by default? >> >> I consider it a separate issue. >> >> -Wall is a primary a service to GCC users (which GCC is already >> using internally.) >> >> Switching to compile with C++ compiler is an internal >> compiler infrastructure issue that should be independent >> of the services we provide to the broader C++ community. > > It's certainly a separate issue, but the set of C++ warnings is > very different, and to avoid unnecessary chaos it might be good > to stage the changes. We already use -Wall for both the stage1 C and the stage2+ C++ compiles. Only stage2+ use -Werror though. Richard. > Andrew.
Re: RFC: -Wall by default
On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote: > On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley wrote: >> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: >>> For GCC-4.8, I would like to turn on -Wall by default. >>> Comments? >> >> Umm, should this really happen at exactly the same time as C++ >> by default? > > I consider it a separate issue. > > -Wall is a primary a service to GCC users (which GCC is already > using internally.) > > Switching to compile with C++ compiler is an internal > compiler infrastructure issue that should be independent > of the services we provide to the broader C++ community. It's certainly a separate issue, but the set of C++ warnings is very different, and to avoid unnecessary chaos it might be good to stage the changes. Andrew.
Re: RFC: -Wall by default
On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley wrote: > On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: >> For GCC-4.8, I would like to turn on -Wall by default. >> Comments? > > Umm, should this really happen at exactly the same time as C++ > by default? I consider it a separate issue. -Wall is a primary a service to GCC users (which GCC is already using internally.) Switching to compile with C++ compiler is an internal compiler infrastructure issue that should be independent of the services we provide to the broader C++ community. -- Gaby
Re: RFC: -Wall by default
On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: > For GCC-4.8, I would like to turn on -Wall by default. > Comments? Umm, should this really happen at exactly the same time as C++ by default? Andrew.
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt wrote: > On 04/04/2012 11:06 AM, Richard Guenther wrote: >> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined >> by transitioning vec.h to a C++ template class, with proper GC support. >> (not sure that I can veto anything - heh) > > I don't think I can veto anything, but I'll go on the record again > saying that I don't think this entire plan is a good idea. Write a new > project in C++? Absolutely. Convert a large existing one to a different > language? A huge waste of time that will distract us for years from > actual user-visible changes. I agree for the idea of converting all of GCC to C++ (whatever that means). I disagree for the part making the internal infrastructure easier to use, understand and maintain. Which means targeting mostly isolated sub-systems, like vec.h (and other various containers), double-int.[ch] (and other various way of representing and working with constants). Making tree or gimple a C++ class with inheritance and whatever is indeed a huge waste of time and existing developer ressources (that, if only because they have to adapt and maintain two completely different code-bases over some time). I expect the GCC core to maintain written in C, compiled by C++. > I also find debugging C++ in gdb somewhat more annoying than debugging > plain C, and at the moment I always go back to a stage1 compiler. Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. Richard.
Re: Switching to C++ by default in 4.8
On 04/04/2012 11:06 AM, Richard Guenther wrote: > So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined > by transitioning vec.h to a C++ template class, with proper GC support. > (not sure that I can veto anything - heh) I don't think I can veto anything, but I'll go on the record again saying that I don't think this entire plan is a good idea. Write a new project in C++? Absolutely. Convert a large existing one to a different language? A huge waste of time that will distract us for years from actual user-visible changes. I also find debugging C++ in gdb somewhat more annoying than debugging plain C, and at the moment I always go back to a stage1 compiler. Bernd
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 1:20 PM, Diego Novillo wrote: > On 4/4/12 5:06 AM, Richard Guenther wrote: > >> Btw, I think we should only start forcing C++ when 1) there is a >> branch/patch out >> that shows benefit from using C++. I previously mentioned that I'd like >> to see >> 2) a patch that _properly_ wraps a C++ class for consumption by our >> garbage >> collector (thus, not a hack that works for a specific case but >> infrastructure >> that we think will work for _all_ cases, including libstdc++ container >> use). > > > My idea was to start with something like converting VEC() which would > require dealing with GC. > > I did not intend to make the conversion and the switch as a single > operation, however. Seemed like too much to change in a single patch. > > >> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be >> combined >> by transitioning vec.h to a C++ template class, with proper GC support. >> (not sure that I can veto anything - heh) I think vec.h is the canonical example of something that we agree on that using C++ is an improvement and a case where we have to get GC support right. If you say the changes doing GC "right" and transforming vec.h are too big to be done together, then well. You only know if you did things right if you have both the "new" GC and a user (vec.h in C++). So yes, maybe too big for a patch but not too big for a branch (where you could merge the GC infrastructure changes separately from the vec.h change). But both need to be developed together. Oh, and did we address all the annoyances of debugging gcc when it's compiled by a C++ compiler? ... Richard. > Well, none of us can, really. Except maybe RMs in the context of release > branches. > > > Diego.
Re: RFC: -Wall by default
An idea whose time has come. --- On Wed, 4/4/12, Gabriel Dos Reis wrote: > For GCC-4.8, I would like to turn on -Wall by default. > Comments?
Re: Switching to C++ by default in 4.8
On 4/3/12 9:13 PM, David Edelsohn wrote: I appreciate the motivation, but this may cause major problems on non-GNU/Linux platforms. Testing on all primary targets is not enough. I can test on other targets, as well. What targets do you have in mind? If I don't have access to them, I'll need volunteers to test my patch. Diego.
Re: Switching to C++ by default in 4.8
On 4/4/12 5:06 AM, Richard Guenther wrote: Btw, I think we should only start forcing C++ when 1) there is a branch/patch out that shows benefit from using C++. I previously mentioned that I'd like to see 2) a patch that _properly_ wraps a C++ class for consumption by our garbage collector (thus, not a hack that works for a specific case but infrastructure that we think will work for _all_ cases, including libstdc++ container use). My idea was to start with something like converting VEC() which would require dealing with GC. I did not intend to make the conversion and the switch as a single operation, however. Seemed like too much to change in a single patch. So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined by transitioning vec.h to a C++ template class, with proper GC support. (not sure that I can veto anything - heh) Well, none of us can, really. Except maybe RMs in the context of release branches. Diego.
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 11:59 AM, Richard Guenther
wrote:
> On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis
> wrote:
>> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
>> wrote:
>>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
>>> wrote:
On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn wrote:
> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo wrote:
>>
>> We would like to start the process to make GCC 4.8 build in C++ mode by
>> default.
>>
>> The mechanics of the change are simple enough. I volunteer to test
>> changing
>> the default on all primary targets (assuming I can get them from the GCC
>> build farm).
>
> I appreciate the motivation, but this may cause major problems on
> non-GNU/Linux platforms. Testing on all primary targets is not
> enough.
>
> Do you expect GCC to be able to bootstrap starting from a vendor C++
> compiler or will this require G++?
I would expect that we use C++03, and any C++ compiler.
>>>
>>> Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we
>>> build with GCC to
>>> avoid creep in of GNU features.
>>
>> Fully agreed.
>>
>>> Btw, I think we should only start forcing C++ when 1) there is a
>>> branch/patch out
>>> that shows benefit from using C++. I previously mentioned that I'd like to
>>> see
>>> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage
>>> collector (thus, not a hack that works for a specific case but
>>> infrastructure
>>> that we think will work for _all_ cases, including libstdc++ container use).
>>
>> I was actually thinking starting with abstractions that do not interact
>> directly
>> with the memory manager, because I would like us to get our feet wet
>> before doing the full plunge. Such a work would be confined to a part of
>> the compiler (say the C++ front-end). Any particular reason you would
>> like to start
>> with the garbage collector which touches just about anything?
>
> Because the garbage collector is the thing that will block reasonable use
> of C++ if we cannot get it working. And because of the fear that if we
> don't show how to do it _right_ first then people will start inventing a
> dozent
> different ways of making it work for a special case.
>
> Note that I don't think it will touch everything. I remember we discussed how
> to do it and basically settled on something like
>
> template
> struct gc_mark {
> static void mark (T *) {}
> }
>
> and specializations that actually do something meaningful.
>
> which we can provide specializations for all existing types walked by
> gengtype trivially. This would provide a way to support GCing objects
> whose types are not "supported" by gengtype - gengtype would simply
> emit gc_mark::mark () calls which are trivially optimized away
> if there is nothing to mark.
>
> That said - somebody would need to prototype that, and VEC is a good
> candidate I think because it's used both with GC and non-GC memory.
This will, of course, be also a challenge for various non-GCC host C++
compilers ;) (let's hope they get this part of templates right ... thus,
let's avoid the need to do partial specialization at least).
> Richard.
>
>> -- Gaby
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis
wrote:
> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
> wrote:
>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
>> wrote:
>>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn wrote:
On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo wrote:
>
> We would like to start the process to make GCC 4.8 build in C++ mode by
> default.
>
> The mechanics of the change are simple enough. I volunteer to test
> changing
> the default on all primary targets (assuming I can get them from the GCC
> build farm).
I appreciate the motivation, but this may cause major problems on
non-GNU/Linux platforms. Testing on all primary targets is not
enough.
Do you expect GCC to be able to bootstrap starting from a vendor C++
compiler or will this require G++?
>>>
>>> I would expect that we use C++03, and any C++ compiler.
>>
>> Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we
>> build with GCC to
>> avoid creep in of GNU features.
>
> Fully agreed.
>
>> Btw, I think we should only start forcing C++ when 1) there is a
>> branch/patch out
>> that shows benefit from using C++. I previously mentioned that I'd like to
>> see
>> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage
>> collector (thus, not a hack that works for a specific case but infrastructure
>> that we think will work for _all_ cases, including libstdc++ container use).
>
> I was actually thinking starting with abstractions that do not interact
> directly
> with the memory manager, because I would like us to get our feet wet
> before doing the full plunge. Such a work would be confined to a part of
> the compiler (say the C++ front-end). Any particular reason you would
> like to start
> with the garbage collector which touches just about anything?
Because the garbage collector is the thing that will block reasonable use
of C++ if we cannot get it working. And because of the fear that if we
don't show how to do it _right_ first then people will start inventing a dozent
different ways of making it work for a special case.
Note that I don't think it will touch everything. I remember we discussed how
to do it and basically settled on something like
template
struct gc_mark {
static void mark (T *) {}
}
and specializations that actually do something meaningful.
which we can provide specializations for all existing types walked by
gengtype trivially. This would provide a way to support GCing objects
whose types are not "supported" by gengtype - gengtype would simply
emit gc_mark::mark () calls which are trivially optimized away
if there is nothing to mark.
That said - somebody would need to prototype that, and VEC is a good
candidate I think because it's used both with GC and non-GC memory.
Richard.
> -- Gaby
RFC: -Wall by default
Hi, For GCC-4.8, I would like to turn on -Wall by default. Comments? -- Gaby
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther wrote: > On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis > wrote: >> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn wrote: >>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo wrote: We would like to start the process to make GCC 4.8 build in C++ mode by default. The mechanics of the change are simple enough. I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm). >>> >>> I appreciate the motivation, but this may cause major problems on >>> non-GNU/Linux platforms. Testing on all primary targets is not >>> enough. >>> >>> Do you expect GCC to be able to bootstrap starting from a vendor C++ >>> compiler or will this require G++? >> >> I would expect that we use C++03, and any C++ compiler. > > Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we > build with GCC to > avoid creep in of GNU features. Fully agreed. > Btw, I think we should only start forcing C++ when 1) there is a > branch/patch out > that shows benefit from using C++. I previously mentioned that I'd like to > see > 2) a patch that _properly_ wraps a C++ class for consumption by our garbage > collector (thus, not a hack that works for a specific case but infrastructure > that we think will work for _all_ cases, including libstdc++ container use). I was actually thinking starting with abstractions that do not interact directly with the memory manager, because I would like us to get our feet wet before doing the full plunge. Such a work would be confined to a part of the compiler (say the C++ front-end). Any particular reason you would like to start with the garbage collector which touches just about anything? -- Gaby
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther wrote: > (not sure that I can veto anything - heh) I found out that is the only power a Release Manager has -- apart from fixing the bug himself or herself ;-p -- Gaby
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis wrote: > On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn wrote: >> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo wrote: >>> >>> We would like to start the process to make GCC 4.8 build in C++ mode by >>> default. >>> >>> The mechanics of the change are simple enough. I volunteer to test changing >>> the default on all primary targets (assuming I can get them from the GCC >>> build farm). >> >> I appreciate the motivation, but this may cause major problems on >> non-GNU/Linux platforms. Testing on all primary targets is not >> enough. >> >> Do you expect GCC to be able to bootstrap starting from a vendor C++ >> compiler or will this require G++? > > I would expect that we use C++03, and any C++ compiler. Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we build with GCC to avoid creep in of GNU features. Btw, I think we should only start forcing C++ when 1) there is a branch/patch out that shows benefit from using C++. I previously mentioned that I'd like to see 2) a patch that _properly_ wraps a C++ class for consumption by our garbage collector (thus, not a hack that works for a specific case but infrastructure that we think will work for _all_ cases, including libstdc++ container use). So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined by transitioning vec.h to a C++ template class, with proper GC support. (not sure that I can veto anything - heh) Thanks, Richard.
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/04/2012 12:53 AM, Miles Bader wrote: > I suspect there are better, cleaner, ways to accomplish the underlying > goal, but I suppose the gcc maintainers don't want to spend the time > fiddling around with their build infrastructure for such a minor > issue... Why speculate? I haven't seen any hint on what the better, cleaner, way to accomplish this is. -- Pedro Alves
Re: Why can't copy renaming capture this assignment?
On Wed, Apr 4, 2012 at 1:27 AM, Jiangning Liu wrote: > >> So I suppose for this specific case a pass that performs type >> promotion/demotion >> (as was discussed repeatedly) would be a better thing, and an enablement >> of trivial redundancy removal. >> > This case is from a real benchmark and this problem introduces huge A "real benchmark"? That gave me a laugh ;) > performance loss, because it is in the nested kernel loop. Do you know who > is working on this type promotion/demotion pass? I think it should be > handled in a very early stage if we need that. Not sure if anybody is working on it, but talks were between me, Jakub, Kai and Andrew (public on this list). Richard. > Thanks, > -Jiangning > >> Richard.
Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)
On Tue, Apr 3, 2012 at 6:02 PM, David Malcolm wrote:
> On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote:
>> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
>> wrote:
>> > On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
>> >> I wrote a script and ported my proposed API for GCC plugins from my
>> >> CamelCase naming convention to an underscore_based_convention (and
>> >> manually fixed up things in a few places also).
>> >>
>> >> The result compiles and passes the full test suite for the Python
>> >> plugin; that said, I'm still breaking the encapsulation in quite a few
>> >> places (hey, this is an experimental prototype).
>> >>
>> >> You can see the latest version of it within the "proposed-plugin-api"
>> >> branch of the Python plugin here:
>> >> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
>> >>
>> >> within the "proposed-plugin-api" subdirectory.
>> >
>> > Hmm, how do I get it? I did
>> >
>> > git clone http://git.fedorahosted.org/git/proposed-plugin-api
>> >
>> > but there is nothing in gcc-python-plugin/. And
>> >
>> > git checkout proposed-plugin-api
>> >
>> > says I'm already there ...?
>>
>> Meanwhile the directory magically appeared (heh ...).
>
> [The ways of git are something of a mystery to me: 95% of the time it's
> the best revision control system I've ever used, but 5% of the time the
> most obtuse]
>
>> Overall it looks good
> Thanks for taking a look.
>
>> - but it seems to leak GCC headers into the
>> plugin API (via gcc-plugin.h and input.h inclusion). Thus, it
>> lacks separating the plugin API headers from the plugin API implementation
>> headers?
> That's true. The big information "leak" happens inside
> gcc-semiprivate-types.h, which defines the various structs that act like
> pointers, each with a decl like this:
>
> struct gcc_something {
> some_private_gcc_pointer_type inner;
> };
>
> It would be possible to make this more opaque like this:
>
> struct gcc_something {
> struct some_private_gcc_struct *inner;
> };
>
> given that you then don't need a full definition of that inner struct
> visible to users. Though location_t is leaked, and in this approach,
> there isn't a way around that, I think.
See the reply by Roman.
>
>> Or maybe I'm not looking at the right place.
>> I also dislike the use of GCC_PUBLIC_API, etc. - everything in
>> the plugin API headers should be obviously public - and the implementation
>> detail should be an implementation detail that should not need to care.
>
> I added that macro based on the example of other plugin/embedding
> systems I've seen (e.g. Python), where it's handy to make that macro be
> non-trivial on some platforms. See e.g. CPython's pyport.h:
> http://hg.python.org/cpython/file/9599f091faa6/Include/pyport.h
> where the macros PyAPI_FUNC and PyAPI_DATA have a 44-line definition,
> handling various different compatibility cases.
>
> For example, GCC_PRIVATE_API could have some magic linker flag that lets
> us automatically strip out those symbols so that they're not visible
> externally after the compiler has been linked.
That's for the implementation side - the public API side by definition has
only declarations considered public.
>> >> If this landed e.g. in GCC 4.8, would this be usable by other plugins?
>>
>> For sure. I'd say get the copyright stuff sorted out and start pushing
>> things
>> into the main GCC repository - where the obvious starting point is to
>> get the makefile, configure and install parts correct.
>>
>> I'd concentrate on providing enough API for introspection, like simple
>> things, counting basic-blocks, counting calls, etc. I'm not sure we
>> want to expose gcc_gimple_walk_tree or gcc_gimple_print (or
>> the gcc_printers for a start) - the latter would something that the
>> python plugin
>> would provide, resorting to introspecting the stmt itself.
> FWIW the Python plugin already heavily uses gcc's pretty-printer code,
> so that *is* something I'd want to wrap (but it's fairly easy to do so).
Ok, fair enough.
>> I also wonder about gcc_gimple_phi_upcast - why would you specialize
>> PHI nodes but not any others? I'd have exposed gcc_gimple_code.
>> In general the plugin API should provide exactly one (and the most flexible)
>> way to do a thing (thus, not have gcc_gimple_assign_single_p) and
>> the high-level consumers like the python plugin should provide
>> nice-to-use interfaces.
>
> This touches on the biggest thing that's missing in the API: the
> multitude of tree types, gimple statement types, and rtl types. All I
> added were the "base classes", and gimple-phi is the only instance so
> far in the API of a subclass.
Well, one way is surely to view it as sort-of "classes", the other way is
to view it as tagged structures which you can simply expose. Of course
if there will be a day where somebody converts all of gimple and tree
to a C++ class hierarchy the class way would be a better representation.
> I woul
Re: Switching to C++ by default in 4.8
On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn wrote: > On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo wrote: >> >> We would like to start the process to make GCC 4.8 build in C++ mode by >> default. >> >> The mechanics of the change are simple enough. I volunteer to test changing >> the default on all primary targets (assuming I can get them from the GCC >> build farm). > > I appreciate the motivation, but this may cause major problems on > non-GNU/Linux platforms. Testing on all primary targets is not > enough. > > Do you expect GCC to be able to bootstrap starting from a vendor C++ > compiler or will this require G++? I would expect that we use C++03, and any C++ compiler. > What is the earliest release of G++ that will allow GCC to bootstrap? Any G++ from the last five years should be good. -- Gaby
Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)
On Tue, Apr 3, 2012 at 8:15 PM, Romain Geissler
wrote:
>
> Le 3 avr. 2012 à 18:02, David Malcolm a écrit :
>
>> On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote:
>>> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
>>> wrote:
On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm wrote:
> I wrote a script and ported my proposed API for GCC plugins from my
> CamelCase naming convention to an underscore_based_convention (and
> manually fixed up things in a few places also).
>
> The result compiles and passes the full test suite for the Python
> plugin; that said, I'm still breaking the encapsulation in quite a few
> places (hey, this is an experimental prototype).
>
> You can see the latest version of it within the "proposed-plugin-api"
> branch of the Python plugin here:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
>
> within the "proposed-plugin-api" subdirectory.
Hmm, how do I get it? I did
git clone http://git.fedorahosted.org/git/proposed-plugin-api
but there is nothing in gcc-python-plugin/. And
git checkout proposed-plugin-api
says I'm already there ...?
>>>
>>> Meanwhile the directory magically appeared (heh ...).
>>
>> [The ways of git are something of a mystery to me: 95% of the time it's
>> the best revision control system I've ever used, but 5% of the time the
>> most obtuse]
>>
>>> Overall it looks good
>> Thanks for taking a look.
>>
>>> - but it seems to leak GCC headers into the
>>> plugin API (via gcc-plugin.h and input.h inclusion). Thus, it
>>> lacks separating the plugin API headers from the plugin API implementation
>>> headers?
>> That's true. The big information "leak" happens inside
>> gcc-semiprivate-types.h, which defines the various structs that act like
>> pointers, each with a decl like this:
>>
>> struct gcc_something {
>> some_private_gcc_pointer_type inner;
>> };
>>
>> It would be possible to make this more opaque like this:
>>
>> struct gcc_something {
>> struct some_private_gcc_struct *inner;
>> };
>>
>> given that you then don't need a full definition of that inner struct
>> visible to users. Though location_t is leaked, and in this approach,
>> there isn't a way around that, I think.
>
> Well i think we you should define a public type like this :
>
> typedef struct some_private_gcc_struct *gcc_something;
>
> extern some_type retrieve_some_value(gcc_something);
Indeed. I'd go one step further and do
typedef struct gcc_something_s *gcc_something;
and in the implementations only expose struct some_private_gcc_struct
by means of casting the pointer. For the public API gcc_something
is a pointer to an opaque thing, never dereferenced.
> Also, nothing should be noted public or private : all definitions
> that will appear in a header installed in
> $(gcc -print-file-name=plugin)/include will be public by definition.
Right.
Richard.
> Any additional header that would be needed to implement the
> API should be kept separate (like the actual *.c implementing it)
> and placed in the gcc/ directory in the trunk (or better something
> like gcc/plugin-impl/ to start being modular). Any definition defined
> in those additional headers are private.
>
> Thus, you should define two sets of headers files (public and private ones),
> plus body c files, and import only public header files from public header
> files.
>
> Do you have any plan on starting integrating it to the trunk (or at least on
> an
> new branch on the official gcc repository) soon, like suggested by Richard ?
> I might help setting up the configure/makefile and later writing some
> wrappers.
> (although i don't have write permission).
> Cheers
>
> Romain Geissler
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/04/2012 01:53 AM, Miles Bader wrote: > Pedro Alves writes: >>> OK, you've all made clear you have your sensible reasons to have the '.info' >> >> ... >>> it available only though the new, undocumented option named (literally) >>> "hack!info-in-builddir". I hope this is acceptable to you. >> ... >>> *undocumented* option '!hack!info-in-builddir' (whose name should >>> made it clear that it is not meant for public consumption). >> >> So will this be called a hack forever, or will the naming be revisited >> before a release? IMO, either the feature is sensible, and there doesn't >> seem to be a good reason other users couldn't also use it, and hence it >> should get a non-hackish name and be documented; or it isn't sensible, and >> then it shouldn't exist. Why the second-class treatment? > > I suspect there are better, cleaner, ways to accomplish the underlying > goal, but I suppose the gcc maintainers don't want to spend the time > fiddling around with their build infrastructure for such a minor > issue... > Exactly; basically, I wrote the proposed hack because the Binutils, GDB and GCC packages are important enough that is worth to cater for their unusual (or even maybe slightly broken) usages, even when that requires a little extra work on the Automake part. But then it turned out that the new hack is not really needed, since those packages already have another hack in place to obtain the behaviour they want (see my recent answer to Tom), and one that works also with older Automake releases (back at least to Automake 1.9). So I've retired my patch, and the hack it introduces. Regards, Stefano
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/03/2012 10:39 PM, Tom Tromey wrote: >> "Stefano" == Stefano Lattarini writes: > > Stefano> On a second though, by double-checking the existing code, I > Stefano> couldn't see how the 'cygnus' option could possibly influence > Stefano> the location of the generated info files -- and it turned out > Stefano> it didn't! Despite what was documented in the manual, the > Stefano> 'cygnus' option did *not* cause the generated '.info' files to > Stefano> be placed in the builddir (see attached test case). > > It certainly does for me: > Yes, but (at least for the binutils case) that's only because you already have an hack *unrelated to the cygnus option* to make it work; i.e., in 'binutils/doc/Makefile.am', I read: # Automake 1.9 will only build info files in the objdir if they are # mentioned in DISTCLEANFILES. It doesn't have to be unconditional, # though, so we use a bogus condition. if GENINSRC_NEVER DISTCLEANFILES = binutils.info endif > barimba. pwd > /home/tromey/gnu/baseline-gdb/build/binutils > barimba. grep '^srcdir = ' Makefile > srcdir = ../../src/binutils > barimba. find . -name 'binutils.info' > ./doc/binutils.info > barimba. find ../../src/binutils -name 'binutils.info' > barimba. > > How did you test it? > With the testcase attached to my mail (warning: it requires the Automake testsuite infrastructure to work). I can transform it in an independent test script if you are really interested. > If you built from a distribution tar, then it is expected that the info > file would be in srcdir. > I didn't use the binutils distribution to test my claim, but the minimal test case I had created on purpose, and attached in the previous mail. Regards, Stefano
Re: Switching to C++ by default in 4.8
On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote: > > We would like to start the process to make GCC 4.8 build in C++ mode by > default. > > The mechanics of the change are simple enough. I volunteer to test changing > the default on all primary targets (assuming I can get them from the GCC > build farm). Is it already possible to build stage1 with c++ ? The VMS targets are not yet ready with build in C++ mode. This target is somewhat special because it can be built only with a cross-compiler (we don't support regular 3 stages native builds because there is no complete and working well enough UNIX emulation tools). I started to build g++ (and gfortran) for ia64 and alpha VMS in order to prepare this transition, but having a soft path would be better to me. (Clearly VMS is not a blocking target for the GCC community - that's not the point). Tristan.
